第3章 blue-green クラスターアップグレードの実行

アップグレードされるそれぞれの古いノードホストで、コンシューマー ID であるその system identity 値を書き留めておいてください。

# subscription-manager identity | grep system
system identity: 6699375b-06db-48c4-941e-689efd6ce3aa

古いノードホストに置き換わるそれぞれの新規 RHEL 7 または RHEL Atomic Host 7 システムで、直前の手順のそれぞれのコンシューマー ID を使用して登録を行います。

# subscription-manager register --consumerid=6699375b-06db-48c4-941e-689efd6ce3aa

クラスターに認識されるノード名の現在の一覧を取得します。

$ oc get nodes

現在の実稼働環境内にあるマスター以外のノードホスト (コンピュートノード) および専用のインフラストラクチャーノードに、color=blue のラベルを付けます。

$ oc label node --selector=node-role.kubernetes.io/compute=true color=blue

$ oc label node --selector=node-role.kubernetes.io/infra=true color=blue

上記のコマンドでは、--selector フラグを使用して、関連するノードラベルでクラスターのサブセットと一致させるように設定され、すべての一致項目には color=blue のラベルが付けられます。

Adding Hosts to an Existing Cluster に説明されている手順を使用して、新規ノードホストを追加します。この手順にある [new_nodes] グループでインベントリーファイルを更新する際に、これらの変数が設定されていることを確認します。

新規ノードをデプロイしてから、新規のノードごとに color=green ラベルを適用します。

$ oc label node <node_name> color=green

新規ノードがクラスター内で検出され、Ready,SchedulingDisabled 状態にあることを確認します。

$ oc get nodes

NAME                STATUS                       ROLES       AGE
node4.example.com   Ready,SchedulingDisabled     compute     1d

Green ノードに適切なラベルがあることを確認します。

$ oc get nodes --show-labels

NAME                STATUS                       ROLES       AGE   LABELS
node4.example.com   Ready,SchedulingDisabled     compute     1d    beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,color=green,kubernetes.io/hostname=m01.example.com,node-role.kubernetes.io/compute=true

クラスターの診断チェックを実行します。

$ oc adm diagnostics

[Note] Determining if client configuration exists for client/cluster diagnostics
Info:  Successfully read a client config file at '/root/.kube/config'
Info:  Using context for cluster-admin access: 'default/m01-example-com:8443/system:admin'
[Note] Performing systemd discovery

[Note] Running diagnostic: ConfigContexts[default/m01-example-com:8443/system:admin]
       Description: Validate client config context is complete and has connectivity
...
         [Note] Running diagnostic: CheckExternalNetwork
              Description: Check that external network is accessible within a pod

       [Note] Running diagnostic: CheckNodeNetwork
              Description: Check that pods in the cluster can access its own node.

       [Note] Running diagnostic: CheckPodNetwork
              Description: Check pod to pod communication in the cluster. In case of ovs-subnet network plugin, all pods
should be able to communicate with each other and in case of multitenant network plugin, pods in non-global projects
should be isolated and pods in global projects should be able to access any pod in the cluster and vice versa.

       [Note] Running diagnostic: CheckServiceNetwork
              Description: Check pod to service communication in the cluster. In case of ovs-subnet network plugin, all
pods should be able to communicate with all services and in case of multitenant network plugin, services in non-global
projects should be isolated and pods in global projects should be able to access any service in the cluster.
...