導入
Kubernetes が、ほぼ同じ作業を実行するために異なるオブジェクトを持っている理由を不思議に思うかもしれません。すでに述べたように、rc の機能は rs and deployment によって拡張されています。’Rs 社では、同じ作業を実行しています。 rc とは異なるセレクター形式を使用した場合のみです。’ここでは、その他の新しいオブジェクトをチェックアウト–し、導入を展開し、そこからの機能について解説します。
導入の作成
Kind 属性を ReplicaSet から配備’に変更するだけでは、配備オブジェクトの yaml ファイルが得られます。
#deploy-webserver-do.yaml apiVersion: apps/v1 kind: Deployment metadata: name: webserver labels: app: webserver spec: replicas: 1 selector: matchLabels: app: webserver matchExpressions: - {key: app, operator: In, values: [webserver]} template: metadata: name: webserver labels: app: webserver spec: containers: - name: webserver image: contrailk8sdayone/contrail-webserver securityContext: privileged: true ports: - containerPort: 80
を使用して導入を作成する kubectl
コマンド
..... $ kubectl create -f deploy-webserver-do.yaml deployment.extensions/webserver created $ kubectl get deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE deployment.apps/webserver 1 1 1 1 21s .....
実際の導入では、rc と rs よりも比較的高いレベルの抽象化が行われます。導入によって pod が直接作成されるわけではなく、[説明] コマンドは次のようになります。
$ kubectl describe deployments Name: webserver Namespace: default CreationTimestamp: Sat, 14 Sep 2019 23:17:17 -0400 Labels: app=webserver Annotations: deployment.kubernetes.io/revision: 5 kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"apps/v1","kind":"Deployment", "metadata":{"annotations":{}, "labels":{"app":"webserver"}, "name":"webserver","namespace":"defa... Selector: app=webserver,app in (webserver) Replicas: 1 desired | 1 updated | 1 total | 1 available | 0 unavailable StrategyType: RollingUpdate MinReadySeconds: 0 RollingUpdateStrategy: 25% max unavailable, 25% max surge Pod Template: Labels: app=webserver Containers: webserver: Image: contrailk8sdayone/contrail-webserver Port: 80/TCP Host Port: 0/TCP Environment: <none> Mounts: <none> Volumes: <none> Conditions: Type Status Reason .... ..... ...... Available True MinimumReplicasAvailable Progressing True NewReplicaSetAvailable OldReplicaSets: <none> NewReplicaSet: webserver-7c7c458cc5 (1/1 replicas created) #<--- Events: <none>
導入ワークフロー
配置を作成すると、レプリカセットが自動的に作成されます。導入オブジェクトに定義されているポッドは、導入’のレプリケーションによって作成および監視されます。
Figure 1は、ワークフローを示しています。
場合によっては、導入とポッドの間に1つ以上のレイヤーを配置し’、その後に回答することで、rs が必要になる理由が気になるかもしれません。
ローリング更新
ローリング更新機能は、導入オブジェクトに付属する強力な機能の1つです。’この機能について、テストケースでどのように動作するかを示します。
実際には、以前の rc オブジェクトに対しても同様のローリング更新機能が存在します。この実装には、導入によってサポートされる新しいバージョンと比べてかなり不利な点があります。このガイドでは、導入に伴う新しい実装について説明します。
テストケース: ローリング更新
たとえば、 nginx-deployment
、レプリカ = 3、pod image 1.7.9 が使用されています。当社では、イメージをバージョン1.7.9 から新しいイメージバージョン1.9.1 にアップグレードしたいと考えています。Kuberctl では、[イメージの設定] オプションを使用して新しいバージョン番号を指定し、更新をトリガーすることができます。
$ kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 deployment.extensions/nginx-deployment image updated
次に、導入情報をもう一度確認してみましょう。
$ kubectl describe deployment/nginx-deployment Name: nginx-deployment Namespace: default CreationTimestamp: Tue, 11 Sep 2018 20:49:45 -0400 Labels: app=nginx Annotations: deployment.Kubernetes.io/revision=2 Selector: app=nginx Replicas: 3 desired | 1 updated | 4 total | 3 available | 1 unavailable StrategyType: RollingUpdate MinReadySeconds: 0 RollingUpdateStrategy: 25% max unavailable, 25% max surge Pod Template: Labels: app=nginx Containers: nginx: Image: nginx:1.9.1 #<------ Port: 80/TCP Host Port: 0/TCP Environment: <none> Mounts: <none> Volumes: <none> Conditions: Type Status Reason .... ..... ..... Available True MinimumReplicasAvailable Progressing True ReplicaSetUpdated OldReplicaSets: nginx-deployment-67594d6bf6 (3/3 replicas created) NewReplicaSet: nginx-deployment-6fdbb596db (1/1 replicas created) Events: Type Reason Age From Message .... ...... ... .... ...... Normal ScalingReplicaSet 4m deployment-controller Scaled up replica set nginx-deployment-67594d6bf6 to 3 #<--- Normal ScalingReplicaSet 7s deployment-controller Scaled up replica set nginx-deployment-6fdbb596db to 1 #<---
ここでは、以下の2つの変更を行うことができます。
配置のイメージバージョンが更新されます。
新しい rs nginx-deployment-6fdbb596db が作成され、レプリカは1にセット
また、レプリカを1とした新しい rs では、新しい pod (4 つ目) が生成されました。
$ kubectl get pods NAME READY STATUS RESTARTS AGE nginx-deployment-67594d6bf6-88wqk 1/1 Running 0 4m nginx-deployment-67594d6bf6-m4fbj 1/1 Running 0 4m nginx-deployment-67594d6bf6-td2xn 1/1 Running 0 4m nginx-deployment-6fdbb596db-4b8z7 0/1 ContainerCreating 0 17s #<------
新しい pod は新しい画像で使用されています。
$ kubectl describe pod/nginx-deployment-6fdbb596db-4b8z7 | grep Image: ...(snipped)... Image: nginx:1.9.1 #<--- ...(snipped)...
古い pod は依然として古い画像を使用しています。
$ kubectl describe pod/nginx-deployment-67594d6bf6-td2xn | grep Image: ...(snipped)... Image: nginx:1.7.9 #<------ ...(snipped)...
’S を待機し、ポッドのステータス…を常にチェックして、すべての古いポッドが終了し、3個の新しいポッドが pod 名を実行–していることを確認します。これは新しいもので、
$ kubectl get pods NAME READY STATUS RESTARTS AGE nginx-deployment-6fdbb596db-4b8z7 1/1 Running 0 1m nginx-deployment-6fdbb596db-bsw25 1/1 Running 0 18s nginx-deployment-6fdbb596db-n9tpg 1/1 Running 0 21s
そのため、更新が行われ、すべてのポッドが新しいバージョンの画像で実行されるようになりました。
仕組み
Kubernetes は新しいイメージで3個の新しいポッドを使用して古いポッドを置き換えるので、このようなことは、これを「置換」と呼んでいます。正確に言えば、これは真実です。しかし、これが機能しています。Kubernetes’の原理は、ポッドが安価であることを理解–しているため、各ポッドにログインし、古い画像をアンインストールし、環境をクリーンアップして、新しい画像をインストールすることが簡単であると考えられます。この’プロセスの詳細を確認して、ローリング更新と呼ばれる理由を理解してみましょう。
ポッドを新しいソフトウェアで更新すると、配備オブジェクトは、pod 更新プロセスを開始する新しい rs を導入します。ここでの考え方は、既存の pod にログインしてイメージを更新することではありません。新しい rs は、新しいソフトウェアリリースを備えた新しいポッドを作成するだけです。この新しい (そして追加の) ポッドが起動して実行されると、元の rs は1つずつスケールダウンされるため、動作しているポッドの合計数は変化しません。新しい rs は1つの拡張を続け、元の rs は1つずつ拡張されます。このプロセスは、新しい rs によって作成されたポッド数が、導入時に定義された元のレプリカ番号に到達するまで繰り返されます。これは、元のすべての rs ポッドが終了したときです。Figure 2は、このプロセスを示しています。
ご覧のように、新しい rs を作成するプロセス全体、新しい rs をスケールアップする、同時に古いものを拡張することは、完全に自動化され、導入オブジェクトによって実現します。この導入は、ReplicaSet オブジェクトを導入して推進しているので、このような意味ではバックエンドとしてのみ機能しています。
その理由は、導入が Kubernetes の上位レイヤーオブジェクトと見なされる理由と、導入なしでは ReplicaSet のみを使用しないことが正式に推奨されているためです。
録画
また、導入によってロール更新のプロセス全体を記録することもできるため、必要に応じて、更新ジョブの完了後に更新プログラムの履歴を確認できます。
$ kubectl describe deployment/nginx-deployment Name: nginx-deployment ...(snipped)... NewReplicaSet: nginx-deployment-6fdbb596db (3/3 replicas created) Events: Type Reason Age From Message Normal ScalingReplicaSet 28m deployment-controller Scaled up replica set nginx-deployment-67594d6bf6 to 3 Normal ScalingReplicaSet 24m deployment-controller Scaled up replica set nginx-deployment-6fdbb596db to 1 Normal ScalingReplicaSet 23m deployment-controller Scaled down replica set nginx-deployment-67594d6bf6 to 2 Normal ScalingReplicaSet 23m deployment-controller Scaled up replica set nginx-deployment-6fdbb596db to 2 Normal ScalingReplicaSet 23m deployment-controller Scaled down replica set nginx-deployment-67594d6bf6 to 1 Normal ScalingReplicaSet 23m deployment-controller Scaled up replica set nginx-deployment-6fdbb596db to 3 Normal ScalingReplicaSet 23m deployment-controller Scaled down replica set nginx-deployment-67594d6bf6 to 0
一時停止/再開/元に戻す
さらに、更新プロセスを一時停止/再開して、変更内容を確認してから続行することもできます。
$ kubectl rollout pause deployment/nginx-deployment $ kubectl rollout resume deployment/nginx-deployment
メンテナンス期間中に問題が発生した場合、更新を取り消すこともできます。
$ kubectl rollout undo deployment/nginx-deployment $ kubectl describe deployment/nginx-deployment Name: nginx-deployment ...(snipped)... NewReplicaSet: nginx-deployment-6fdbb596db (3/3 replicas created) NewReplicaSet: nginx-deployment-67594d6bf6 (3/3 replicas created) Events: Type Reason Age From Message Normal DeploymentRollback 8m deployment-controller Rolled back deployment "nginx-deployment" to revision 1 #<------ Normal ScalingReplicaSet 8m deployment-controller Scaled up replica set nginx-deployment-67594d6bf6 to 1 #<------ Normal ScalingReplicaSet 8m deployment-controller Scaled down replica set nginx-deployment-6fdbb596db to 2 #<------ Normal ScalingReplicaSet 8m deployment-controller Scaled up replica set nginx-deployment-67594d6bf6 to 2 #<------ Normal ScalingReplicaSet 8m deployment-controller Scaled up replica set nginx-deployment-67594d6bf6 to 3 #<------ Normal ScalingReplicaSet 8m deployment-controller Scaled down replica set nginx-deployment-6fdbb596db to 1 #<------ Normal ScalingReplicaSet 8m deployment-controller Scaled down replica set nginx-deployment-6fdbb596db to 0 #<------
これは通常、導入環境で問題が発生した場合に行います。従来の期間のメンテナンス期間中にソフトウェアアップグレードを準備するのにかかる時間と比較すると、これはソフトウェアアップグレードを行ったすべての人にとって驚くべき機能と言えます。
これは、Junos ロールバックマジックコマンドと非常に似ています。ルーターに加えた変更をすばやく元に戻す必要がある場合に、毎日使用することをお勧めします。