はじめに
この初級コースの最後のチャレンジへようこそ。これまでの実験では、Pod、Deployment、Service、スケーリング、トラブルシューティング、ロールバックについて学びました。ここでは、それらの知識を、コマンドごとの手順説明なしで、1 つの小規模なリリース作業に応用します。
環境には、web-app という正常に稼働している初期リリースが用意されています。あなたの作業は、3 つの利用可能なレプリカと安定した Service を維持しながら、次の固定バージョンの NGINX イメージをリリースすることです。チャレンジ終了時のクラスター状態と保存済みマニフェストが一致している必要があります。これにより、チャレンジ後もリリースを再現できます。
次の NGINX バージョンをリリースする
環境の起動： この実験では、完全な Kubernetes クラスターが起動します。コントロールプレーン、ノード、ネットワークコンポーネントの構成には通常 2～3 分かかります。環境の読み込みが完了するまで、そのままお待ちください。
現在の状況
プラットフォームチームは、/home/labex/project/final-release/web-app.yaml に初期リリースを用意しています。現在は nginx:1.26-alpine を 3 つのレプリカとして実行し、Service web-app の背後で公開しています。
作業範囲
- 既存の
web-appDeployment、Service、マニフェスト、およびrelease-checkクライアントを使用します。 - リソース名を変更したり、セレクターを変更したり、承認済みのローリングアップデート設定を置き換えたりしないでください。
- 固定されたターゲットイメージを使用してください。
latestのような可変タグは承認対象外です。
目標
既存の Deployment を通じて nginx:1.27-alpine をリリースし、稼働中のクラスター、Service のアクセス経路、保存済みマニフェストが、健全で再現可能な 1 つの状態になるようにします。
受け入れ条件
- Deployment
web-appの希望レプリカ数が正確に 3 であること。 nginxコンテナが固定イメージnginx:1.27-alpineを使用していること。- ローリングアップデート設定が
maxUnavailable: 0およびmaxSurge: 1のままであること。 - 変更理由のアノテーションが NGINX 1.27 のリリース内容を示していること。
- Service
web-appが引き続き Deployment の Pod を選択し、準備完了状態のバックエンドを 3 つ持っていること。 - 更新後の 3 つのレプリカがすべて準備完了かつ利用可能であり、クラスター内から
http://web-appへの HTTP リクエストが成功すること。 /home/labex/project/final-release/web-app.yamlに最終的なイメージとロールアウト設定が記載され、再度適用しても承認済みの状態が維持されること。
Kubernetes の状態確認コマンドとロールアウトコマンドを使って、リリースが完了したかどうかを判断してください。更新がまだ進行中の場合は、最初の kubectl get の結果だけで判断せず、完了するまで待ちます。
ヒント
Deployment の READY、UP-TO-DATE、AVAILABLE 列、Pod のイメージ、ロールアウト履歴、Service の EndpointSlice アドレスを確認するとよいでしょう。
まとめ
Kubernetes Deployment を通じて固定バージョンの NGINX イメージを自分でリリースし、このコースを修了しました。明示的な可用性設定を維持し、更新されたすべてのレプリカを待機し、Service を準備完了状態の 3 つのバックエンドに接続したままにし、クラスター内からのリクエストを検証し、承認済みの状態を YAML に保存しました。
これらの確認手順は、初学者が繰り返し利用できるワークフローを構成します。望ましい状態を宣言し、それを適用し、コントローラーの進行状況を監視し、ワークロードとそのアクセス経路を検証し、マニフェストとクラスターの状態を同期させておく、という流れです。
