Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

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

注記

このトピックでは、インプレースアップグレード方法に代わるノードホストのアップグレード方法について説明します。

Blue-Green デプロイメント のアップグレード方式はインプレース方式と同様のフローに基づいて実行されます。 この場合もマスターおよび etcd サーバーが最初にアップグレードされます。 ただし、インプレースアップグレードを実行する代わりに、新規ノードホストの並列環境が作成されます。

この方式では、管理者は新規デプロイメントの検証後、古いノードホストセット (例: Blueデプロイメント) から新規セット (例: Green デプロイメント) にトラフィックを切り換えることができます。問題が検出される場合も、古いデプロイメントへのロールバックを簡単かつすぐに実行できます。

Blue-Green はソフトウェアについての証明済みの有効なデプロイストラテジーであるものの、トレードオフも常にあります。すべての環境が Blue-Green デプロイメントの適切な実行に必要な同じアップタイム要件を満たす訳ではなく、必要なリソースがある訳でもありません。

OpenShift Container Platform 環境では、Blue-Green デプロイメントに最も適しているのはノードホストです。すべてのユーザープロセスはこれらのシステムで実行され、OpenShift Container Platform インフラストラクチャーの重要な部分もこれらのリソースで自己ホストされます。アップタイムはこれらのワークロードで最も重要であり、Blue-Green デプロイメントによって複雑性が増すとしてもこれを確保できる場合には問題になりません。

この方法の実際の実装は要件に応じて異なります。通常、主な課題は、この方法を容易に実行するための追加の容量を確保することにあります。

図3.1 Blue-Green デプロイメント

Blue-Green Deployment Upgrade

3.1. Blue-Green アップグレードの準備

インプレースアップグレード で説明されている方法を使用してマスターと etcd ホストをアップグレードした後に、以下のセクションを参照して残りのノードホストの Blue-Green アップグレードの環境を準備します。

3.1.1. ソフトウェアエンタイトルメントの共有

管理者は Blue-Green デプロイメント間で Red Hat ソフトウェアエンタイトルメントを一時的に共有するか、または Red Hat Satellite などのシステムでインストールコンテンツへのアクセスを提供する必要があります。これは、以前のノードホストからのコンシューマー ID を共有して実行できます。

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

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

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

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

3.1.2. Blue ノードのラベリング

実稼働環境の現在のノードホストに blue または green のいずれかのラベルが付けられていることを確認する必要があります。以下の例では、現在の実稼働環境は blue となり、新規の環境は green になります。

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

    $ oc get nodes

  2. 現在の実稼働環境内にあるマスター以外のノードホスト (コンピュートノード) および専用のインフラストラクチャーノードに、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 のラベルが付けられます。

3.1.3. Green ノードの作成およびラベリング

等しい数の新規ノードホストを既存のクラスターに追加して Green 環境を作成します。

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

    • ノードが 健全 であるとみなされるまでワークロードのスケジューリングを遅らせるために (健全性については後の手順で検証します)、それぞれの新規ノードホストに openshift_schedulable=false 変数を設定し、これらが初期の時点でスケジュール対象外となるようにします。

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

    $ oc label node <node_name> color=green

3.1.4. Green ノードの検証

新規 Green ノードが健全な状態にあることを確認します。

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

    $ oc get nodes

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

  2. 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

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

    $ 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.
...