3.2. Green ノードの準備
Pod を Blue 環境から Green に移行するには、必要なコンテナーイメージをプルする必要があります。
ネットワークのレイテンシーやレジストリーへの負荷により、環境の容量が十分にない場合に遅延が生じる可能性があります。新規 Pod デプロイメントを新規ノードに対してトリガーするために新規イメージストリームをインポートすることにより、実行中のシステムへの影響を最小限に抑えることができます。
メジャーリリースの OpenShift Container Platform (および一部の非同期エラータ更新) では、Source-to-Image (S2I) のユーザー向けにビルダーイメージの新規イメージストリームを導入しています。インポート時に、イメージ変更トリガー で設定されるビルドおよびデプロイメントが自動的に作成されます。
ビルドをトリガーする別の利点として、各種のビルダーイメージ、Pod インフラストラクチャーイメージおよびデプロイヤーなどの多数の補助イメージをすべてのノードホストに効果的に取り込める点があります。Green ノードは予想される負荷の増加に対応できるように準備され、その他の残りはノードの退避時に迅速に移行します。
アップグレードプロセスに進む準備ができたら、以下の手順に従って Green ノードを準備します。
Green ノードをスケジュール対象 (Schedulable) に設定し、新規 Pod がそれらのノードにデプロイさせるようにします。
$ oc adm manage-node --schedulable=true --selector=color=green
Blue ノードをスケジュール対象外 (Unschedulable) に設定し、新規 Pod がそれらのノードで実行されないようにします。
$ oc adm manage-node --schedulable=false --selector=color=blue
node-role.kubernetes.io/infra=true
ラベルを使用するように、レジストリーとルーターデプロイメント設定のノードセレクターを更新します。この変更により、レジストリーおよびルーター Pod を新規のインフラストラクチャーノードに配置する新規のデプロイメントが起動します。docker-registry デプロイメント設定を編集します。
$ oc edit -n default dc/docker-registry
nodeSelector
パラメーターを以下の値を使用するように更新し (引用符で囲まれた"true"
を使用します)、変更を保存します。nodeSelector: node-role.kubernetes.io/infra: "true"
router デプロイメント設定を編集します。
$ oc edit -n default dc/router
nodeSelector
パラメーターを以下の値を使用するように更新し (引用符で囲まれた"true"
を使用します)、変更を保存します。nodeSelector: node-role.kubernetes.io/infra: "true"
新規インフラストラクチャーノードで docker-registry および router Pod が実行中で、Ready の状態であることを確認します。
$ oc get pods -n default -o wide NAME READY STATUS RESTARTS AGE IP NODE docker-registry-2-b7xbn 1/1 Running 0 18m 10.128.0.188 infra-node3.example.com router-2-mvq6p 1/1 Running 0 6m 192.168.122.184 infra-node4.example.com
- デフォルトのイメージストリームとテンプレートを更新します。
- 最新のイメージをインポートします。このプロセスで多数のビルドがトリガーされる可能性がありますが、ビルドは Green ノードで実行されるため、これが Blue デプロイメントのトラフィックに影響を与えることはありません。
クラスター内のすべての namespace (プロジェクト) でのビルドプロセスをモニターするには、以下を実行します。
$ oc get events -w --all-namespaces
大規模な環境では、ビルドはほとんど停止することがありません。しかしながら、管理上のイメージのインポートによって大きな増減が生じます。