コントローラでワークロードを転がす

目標

Deployment、ReplicaSet、DaemonSet、StatefulSetの4つのコントローラーの違いを手で確認し、ローリングアップデートのパラメーターを調整して、実際のロールアウトとロールバックを実行します。

なぜ重要なのか

試験では、「イメージを更新して、問題が起きたら元に戻せ」が定番の問題です。しかし、元に戻せる理由を知らないと、落とし穴にはまります。rollout undoは魔法ではなく、レプリカ0のまま残っている古いReplicaSetを、再び大きくすることです。そのため、revisionHistoryLimitを0にすると元に戻せず、イメージを手で元に戻すと、元に戻したのではなく、リビジョンがもう1つ積み上がります。

4つのコントローラーの選択基準も明確です。互いに区別する必要のないレプリカならDeployment、ノードごとにちょうど1つならDaemonSet、名前・順序・ボリュームが固定される必要があればStatefulSetです。StatefulSetがヘッドレスサービスを要求する理由は、Podごとにそれぞれ、DNS名を与えるためです。

ステップ

1. ネームスペースcka-workloadsを作成し、Deploymentwebを作成してください。イメージはnginx:1.25、レプリカは2です。
2. webをレプリカ4にスケールし、4/4 Readyを確認してください。
3. webの戦略をRollingUpdateにし、maxSurge: 2、maxUnavailable: 0、revisionHistoryLimit: 3に設定してください。
4. Deploymentapiを作成してください(イメージnginx:1.25、レプリカ3)。そのあと、イメージをnginx:1.27に入れ替え、ロールアウトが終わるまで待ってください。
5. apiのロールアウト履歴を、/root/cka-workloads/history.txtに保存してください。リビジョンが2つ以上、見えている必要があります。
6. apiを直前のリビジョンに戻してください。戻したあとのイメージは、再びnginx:1.25である必要があります。
7. cka-workloadsにDaemonSetnode-agentを作成してください。イメージはbusybox:1.36で、コンテナがすぐに終了しないよう、長時間動き続けるコマンドを指定してください。すべてのノードで、1つずつReadyである必要があります。
8. ヘッドレスサービスdb-headless(clusterIP None、ポート5432、セレクターapp=db)を作成し、StatefulSetdbを作成してください。serviceNameはdb-headless、レプリカは2、イメージはnginx:1.27、updateStrategyはRollingUpdateでpartition: 1にします。2/2 Readyを確認してください。

参考

• kubectl rollout status deployment/api -n cka-workloadsで、完了を待てます。
• kubectl get rs -n cka-workloadsで、リビジョンごとにReplicaSetが残っていることを、目で確認してみてください。
• よくあるミス1: ステップ6で、set imageで古いタグを再び入れてしまうことです。それはロールバックではなく、新しいリビジョンです。
• よくあるミス2: ステップ8で、StatefulSetのPodラベルとヘッドレスサービスのセレクターが、ずれたままになっていることです。app=dbに合わせる必要があります。

Deploymentを作成する

ネームスペースcka-workloadsを作成し、Deploymentwebを作成してください。イメージはnginx:1.25、レプリカは2です。

kubectl create deploymentで骨格を作り、必要な値だけを直すほうが速いです。イメージのタグまで、正確に合わせる必要があります。

スケールしてReadyを確認する

webをレプリカ4にスケールし、4/4 Readyを確認してください。

scaleコマンドが最も速いですが、マニフェストを修正して適用してもかまいません。status.readyReplicasが目標値に届くまで、少し時間がかかります。

ローリングアップデートのパラメーターを調整する

webの戦略をRollingUpdateにし、maxSurge: 2、maxUnavailable: 0、revisionHistoryLimit: 3に設定してください。

strategy.rollingUpdateの下に、2つの値が入ります。整数もパーセントも使えますが、今回は整数である必要があります。revisionHistoryLimitはstrategyの外側で、specのすぐ下です。

イメージを入れ替えてロールアウトの完了を待つ

Deploymentapiを作成してください(イメージnginx:1.25、レプリカ3)。そのあと、イメージをnginx:1.27に入れ替え、ロールアウトが終わるまで待ってください。

set imageで変更すると、新しいReplicaSetができます。rollout statusで完了を待ってください。採点は、新しいリビジョンの存在とobservedGenerationを見ます。

リビジョン履歴を確認して保存する

apiのロールアウト履歴を、/root/cka-workloads/history.txtに保存してください。リビジョンが2つ以上、見えている必要があります。

rollout historyは、REVISION列のある表を出力します。リビジョンが2つ以上見えていてはじめて、元に戻せるという意味です。

以前のリビジョンに戻す

apiを直前のリビジョンに戻してください。戻したあとのイメージは、再びnginx:1.25である必要があります。

イメージを手で元に戻さないでください。そうすると、元に戻したのではなく、新しいリビジョンをもう1つ作ったことになり、採点はその違いを見ます。rolloutの巻き戻しのコマンドを使ってください。

DaemonSetをデプロイする

cka-workloadsにDaemonSetnode-agentを作成してください。イメージはbusybox:1.36で、コンテナがすぐに終了しないよう、長時間動き続けるコマンドを指定してください。すべてのノードで、1つずつReadyである必要があります。

DaemonSetはreplicasを使いません。ノードごとに1つずつ起動しているかは、statusのdesiredNumberScheduledとnumberReadyで確認します。コンテナがすぐに終わらないよう、長時間動き続けるコマンドを指定してください。

ヘッドレスサービスとStatefulSetを結び付ける

ヘッドレスサービスdb-headless(clusterIP None、ポート5432、セレクターapp=db)を作成し、StatefulSetdbを作成してください。serviceNameはdb-headless、レプリカは2、イメージはnginx:1.27、updateStrategyはRollingUpdateでpartition: 1にします。2/2 Readyを確認してください。

StatefulSetのserviceNameは、必ず存在するヘッドレスサービスを指している必要があります。partitionはupdateStrategy.rollingUpdateの下にあり、その序数以上のものだけを更新するという意味です。