Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

導入

 

Kubernetes が、ほぼ同じ作業を実行するために異なるオブジェクトを持っている理由を不思議に思うかもしれません。すでに述べたように、rc の機能は rs and deployment によって拡張されています。’Rs 社では、同じ作業を実行しています。 rc とは異なるセレクター形式を使用した場合のみです。’ここでは、その他の新しいオブジェクトをチェックアウト–し、導入を展開し、そこからの機能について解説します。

導入の作成

Kind 属性を ReplicaSet から配備’に変更するだけでは、配備オブジェクトの yaml ファイルが得られます。

を使用して導入を作成する kubectlコマンド

実際の導入では、rc と rs よりも比較的高いレベルの抽象化が行われます。導入によって pod が直接作成されるわけではなく、[説明] コマンドは次のようになります。

導入ワークフロー

配置を作成すると、レプリカセットが自動的に作成されます。導入オブジェクトに定義されているポッドは、導入’のレプリケーションによって作成および監視されます。

Figure 1は、ワークフローを示しています。

Figure 1: 導入ワークフロー
導入ワークフロー

場合によっては、導入とポッドの間に1つ以上のレイヤーを配置し’、その後に回答することで、rs が必要になる理由が気になるかもしれません。

ローリング更新

ローリング更新機能は、導入オブジェクトに付属する強力な機能の1つです。’この機能について、テストケースでどのように動作するかを示します。

Note

実際には、以前の rc オブジェクトに対しても同様のローリング更新機能が存在します。この実装には、導入によってサポートされる新しいバージョンと比べてかなり不利な点があります。このガイドでは、導入に伴う新しい実装について説明します。

テストケース: ローリング更新

たとえば、 nginx-deployment、レプリカ = 3、pod image 1.7.9 が使用されています。当社では、イメージをバージョン1.7.9 から新しいイメージバージョン1.9.1 にアップグレードしたいと考えています。Kuberctl では、[イメージの設定] オプションを使用して新しいバージョン番号を指定し、更新をトリガーすることができます。

次に、導入情報をもう一度確認してみましょう。

ここでは、以下の2つの変更を行うことができます。

  • 配置のイメージバージョンが更新されます。

  • 新しい rs nginx-deployment-6fdbb596db が作成され、レプリカは1にセット

また、レプリカを1とした新しい rs では、新しい pod (4 つ目) が生成されました。

新しい pod は新しい画像で使用されています。

古い pod は依然として古い画像を使用しています。

’S を待機し、ポッドのステータス…を常にチェックして、すべての古いポッドが終了し、3個の新しいポッドが pod 名を実行–していることを確認します。これは新しいもので、

そのため、更新が行われ、すべてのポッドが新しいバージョンの画像で実行されるようになりました。

仕組み

Kubernetes は新しいイメージで3個の新しいポッドを使用して古いポッドを置き換えるので、このようなことは、これを「置換」と呼んでいます。正確に言えば、これは真実です。しかし、これが機能しています。Kubernetes’の原理は、ポッドが安価であることを理解–しているため、各ポッドにログインし、古い画像をアンインストールし、環境をクリーンアップして、新しい画像をインストールすることが簡単であると考えられます。この’プロセスの詳細を確認して、ローリング更新と呼ばれる理由を理解してみましょう。

ポッドを新しいソフトウェアで更新すると、配備オブジェクトは、pod 更新プロセスを開始する新しい rs を導入します。ここでの考え方は、既存の pod にログインしてイメージを更新することではありません。新しい rs は、新しいソフトウェアリリースを備えた新しいポッドを作成するだけです。この新しい (そして追加の) ポッドが起動して実行されると、元の rs は1つずつスケールダウンされるため、動作しているポッドの合計数は変化しません。新しい rs は1つの拡張を続け、元の rs は1つずつ拡張されます。このプロセスは、新しい rs によって作成されたポッド数が、導入時に定義された元のレプリカ番号に到達するまで繰り返されます。これは、元のすべての rs ポッドが終了したときです。Figure 2は、このプロセスを示しています。

Figure 2: 導入の概要
導入の概要

ご覧のように、新しい rs を作成するプロセス全体、新しい rs をスケールアップする、同時に古いものを拡張することは、完全に自動化され、導入オブジェクトによって実現します。この導入は、ReplicaSet オブジェクトを導入して推進しているので、このような意味ではバックエンドとしてのみ機能しています。

その理由は、導入が Kubernetes の上位レイヤーオブジェクトと見なされる理由と、導入なしでは ReplicaSet のみを使用しないことが正式に推奨されているためです。

録画

また、導入によってロール更新のプロセス全体を記録することもできるため、必要に応じて、更新ジョブの完了後に更新プログラムの履歴を確認できます。

一時停止/再開/元に戻す

さらに、更新プロセスを一時停止/再開して、変更内容を確認してから続行することもできます。

メンテナンス期間中に問題が発生した場合、更新を取り消すこともできます。

これは通常、導入環境で問題が発生した場合に行います。従来の期間のメンテナンス期間中にソフトウェアアップグレードを準備するのにかかる時間と比較すると、これはソフトウェアアップグレードを行ったすべての人にとって驚くべき機能と言えます。

Tip

これは、Junos ロールバックマジックコマンドと非常に似ています。ルーターに加えた変更をすばやく元に戻す必要がある場合に、毎日使用することをお勧めします。