CKA 受験者の皆さん、ご注意ください: これらの展開ポイントが役立ちます!

1. デプロイメントとは何か

Kubernetes では、Deployment は Pod のデプロイ方法を定義および管理するために使用される API オブジェクトです。特定のデプロイメントの詳細を気にすることなく、アプリケーションの望ましい状態を記述できる宣言型のアプローチを提供します。デプロイメントの主な目的は、定義された数の Pod レプリカが常にクラスター内で実行され、ローリング アップデートとロールバック操作がサポートされるようにすることです。 Deployment の主な特徴と機能は次のとおりです。

• 宣言型構成: Deployment を使用すると、ポッドの数、使用されるイメージ、ポートなど、アプリケーションの望ましい状態を YAML ファイルを通じて記述できます。
• 自動ローリング アップデート: アプリケーションを更新する必要がある場合は、デプロイメント構成を変更することで更新できます。デプロイメントは、ポッドを徐々に更新し、プロセス全体を通じてアプリケーションが利用可能であることを保証する責任を負います。
• レプリカ セット管理: デプロイメントではレプリカ セット (ReplicaSet) を使用して、指定された数の Pod インスタンスが常に実行されるようにします。いずれかのポッドが失敗したり削除されたりした場合、デプロイメントはそれらを置き換えるために新しいポッドを起動します。
• ローリング ロールバック: 更新中に問題が発見された場合、簡単にロールバックを実行し、デプロイメントを以前のバージョンにロールバックして安定した状態に復元できます。
• 自動修復: デプロイメントはポッドの状態を自動的に監視し、障害が発生した場合に自動的に修復を試みます。ポッドに障害が発生した場合、デプロイメントは新しいポッドを起動して、必要な数のレプリカが常に実行されるようにします。

2. デプロイメントの基本的な使用方法

1. デプロイメントを作成する

デプロイメント リソースを作成するには、リソース リストを書き込む方法と、kubectl コマンドラインを使用して作成する方法の 2 つの方法があります。次の yaml ファイルは、3 つの nginx Pod レプリカを含む ReplicaSet を作成する Deployment を定義します。

 apiVersion:apps/v1 kind:Deployment metadata: name:nginx-deployment labels: app:nginx spec: replicas:3 selector: matchLabels: app:nginx template: metadata: labels: app:nginx spec: containers: -name:nginx image:nginx:1.7.9 ports: -containerPort:80

この例では、

(1) .metadata.nameフィールドで指定された名前で、nginx-deploymentという名前のデプロイメントが作成されます。

（2）このデプロイメントは3つのポッドレプリカを作成します。レプリカの数は.spec.replicasフィールドで指定されます。

（3）.spec.selectorフィールドは、デプロイメントが管理するポッドを見つける方法を指定します。この場合、Pod テンプレートで定義されたラベル (app: nginx) を使用します。稀なケースでは、このフィールドでより複雑なルールを定義することもできます。

（4）.templateフィールドには以下のフィールドが含まれます。

• .template.metadata.labels フィールドは Pod のラベルを指定します (アプリ: nginx)
• .template.spec.containers[].imageフィールドは、Podがコンテナnginx:1.7.9を実行していることを示します。
• .template.spec.containers[].name フィールドは、コンテナの名前が nginx であることを示します。

デプロイメントを作成するには、次のコマンドを実行します。

 kubectl apply -f nginx-deployment.yaml

または、次のコマンドで作成します。

 kubectl create deploy nginx-deployment --image=nginx:1.7.9 --port=80 --replicas=3

作成は成功し、次のコマンドで照会できます。

 controlplane $ kubectl get deploy NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 10s controlplane $ kubectl get pod NAME READY STATUS RESTARTS AGE nginx-deployment-867765c857-24rdz 1/1 Running 0 54s nginx-deployment-867765c857-6r86m 1/1 Running 0 54s nginx-deployment-867765c857-xj7c5 1/1 Running 0 54s

2. 容量拡張を展開する

デプロイメントの spec.replicas フィールドを変更して、必要なレプリカの数を指定します。たとえば、上記の nginx-deployment のコピー数を 5 に変更する必要があります。これは、kubect edit deploy nginx-deployment で変更できます。

spec.replicas を 3 から 5 に変更します。保存して編集を終了します。次に、次のコマンドを実行して、nginx-deployment がコピー数を 3 から 5 に正常に変更したことを確認します。

 controlplane $ kubectl get deployments.apps NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 5/5 5 5 5m17s controlplane $ kubectl get pod NAME READY STATUS RESTARTS AGE nginx-deployment-867765c857-24rdz 1/1 Running 0 6m13s nginx-deployment-867765c857-6r86m 1/1 Running 0 6m13s nginx-deployment-867765c857-vfr55 1/1 Running 0 62s nginx-deployment-867765c857-vrj4f 1/1 Running 0 62s nginx-deployment-867765c857-xj7c5 1/1 Running 0 6m13s

または、次のコマンドを使用して展開することもできます。

 controlplane $ kubectl scale deployment nginx-deployment --replicas=5 deployment.apps/nginx-deployment scaled

3. ローリングアップデート

（１）ローリングアップデートの紹介

ローリング アップデートは、よりスムーズなユーザー エクスペリエンスを提供する高度に自動化されたリリース方法です。これは、成熟したテクノロジー組織で現在使用されている主流のリリース方法です。ローリング リリースは通常、複数のリリース バッチで構成され、各バッチの数量は通常構成可能 (リリース テンプレートを使用して定義可能) です。たとえば、最初のバッチでは 1 ユニット、2 番目のバッチでは 10%、3 番目のバッチでは 50%、4 番目のバッチでは 100% などです。各バッチの間には観察間隔があり、次のバッチを送信する前に問題がないことを確認するために手動検証または監視フィードバックが実行されるため、ローリングリリースプロセスは一般的に遅くなります。

（２）コントローラポリシーの表示

kubectl explain deploy.spec.strategy を通じてコン​​トローラー戦略を表示できます。以下のように表示されます。

（３）アップデート方法の展開

• 再作成とローリングアップデートの2種類の更新をサポートします
• 再作成は再構築更新であり、1つを削除して1つを更新します

RollingUpdate はローリングアップデートの更新方法を定義します。つまり、ポッドの数を増減でき、更新の強度が制御されます。

①ローリングアップデート

kubectl explain deploy.spec.strategy.RollingUpdate を通じてローリング アップデートのヘルプ ドキュメントを表示します。以下のように表示されます。

maxSurge (最大拡張値) と maxUnavailable (最大使用不可) は、ローリング更新戦略を制御するために使用されます。値の範囲は数値とパーセンテージに分かれています。

まずはパーセンテージを見てみましょう:

• maxUnavailable: [0%, 100%] 切り捨て。例えば、レプリカが10個ある場合、5% == 0.5ですが、計算は0に基づいています。
• maxSurge: [0%, 100%] 切り上げ。例えば、レプリカが10個ある場合、5% == 0.5 となるが、計算は1を基準とする。

数値を見てみましょう:

• maxUnavailable: [0, コピー数]
• maxSurge: [0, レプリカ数]

②再現する

デプロイ更新戦略を再作成に変更します。

 apiVersion:apps/v1 kind:Deployment metadata: name:nginx-deployment labels: app:nginx spec: replicas:3 strategy: type:Recreate ...省略...

次のコマンドで更新します。

 kubectl apply -f deploy-demo1.yaml #另一个窗口实时监控kubectl get pods -w

出力は次のようになります。

デプロイメントの詳細な使用方法は次のとおりです。

• 展開の概要[1]
• 展開[2]

3. CKAの実際の質問

1. 実際の質問のスクリーンショット

2. 中国の分析

k8s クラスター環境を切り替えます: kubectl config use-context k8s

タスク：

ロードバランサー デプロイメントによって管理される Pod のレプリカの数を 6 に拡張します。

3. 参考資料

展開[3]

4. 質問を解いて答える

クラスター環境を切り替えます。

 kubectl config use-context k8s

既存のポッドの数を確認します。

 kubectl get deploy loadbalancer -o wide

ロードバランサー デプロイメントによって管理される Pod のレプリカの数を 6 に拡張します。

 kubelct scale deploy loadbalancer --replicas=6

ポッドの数を確認します:

 kubectl get pod

参考文献:

• [1] デプロイメント入門: https://www.kuboard.cn/learning/k8s-intermediate/workload/wl-deployment/
• [2]デプロイメント: https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/deployment/
• [3]デプロイメント: https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/deployment/