第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,node-role.kubernetes.io/infra=true color=blue

上記のコマンドでは、--selector フラグを使用して、関連のノードラベルでクラスターのサブセットと一致し、照合したすべての項目に color=blue のラベルを付けます。

「既存のクラスターへのホストの追加」に記載の手順を使用して、新規ノードホストを追加します。この手順にある [new_nodes] グループで、インベントリーファイルを更新するときにこれらの変数が設定されているようにしてください。

たとえば、以下の新しいノードホストが既存のインベントリーに追加されます。以前のインベントリーに含まれていた項目はすべて残して置く必要があります。

[new_nodes]
node4.example.com openshift_node_group_name='node-config-compute' openshift_schedulable=false
node5.example.com openshift_node_group_name='node-config-compute' openshift_schedulable=false
node6.example.com openshift_node_group_name='node-config-compute' openshift_schedulable=false
infra-node3.example.com openshift_node_group_name='node-config-infra' openshift_schedulable=false
infra-node4.example.com openshift_node_group_name='node-config-infra' openshift_schedulable=false

新規ノードをデプロイしてから、oc label node コマンドを使用して、ノードごとに 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.
...