第2章 クラスターの自動インプレースアップグレードの実行

OpenShift Container Platform 3.10 以降では、ノードの設定はマスターから「ブートストラップ」されるようになりました。ノードサービスが起動されると、ノードは、kubeconfig および他のノード設定ファイルが存在するかどうかをクラスターに参加する前に確認します。存在しない場合には、ノードはマスターから設定をプルしてから、クラスターに参加します。

このプロセスが導入され、管理者はノードホストごとに一意にノード設定を手動でメンテナンスする必要がなくなり、ノードホストの /etc/origin/node/node-config.yaml ファイルの内容がマスターから取得する ConfigMaps により提供されるようになりました。

どのノードホストにどの ConfigMap を使用するかをマッピングするには、インベントリーファイルにホストごとに ノードグループ を定義してから設定する必要があります。これらの手順は、「自動化アップグレードの準備」のセクションで取り扱います。

ノードの ConfigMaps

ノード設定の定義用の ConfigMaps は openshift-node プロジェクトで利用できる必要があります。ConfigMaps はノードラベルの信頼できる定義となり、以前の openshift_node_labels の値は事実上、無視されます。

インストーラーには Playbook が含まれており、以下のデフォルトの ConfigMaps を作成します。

以下の ConfigMaps も作成され、複数のロールにノードをラベル付けします。

ノードグループの定義

openshift-ansible パッケージのアップグレード後に、ノードグループ定義のデフォルトセットが /usr/share/ansible/openshift-ansible/roles/openshift_facts/defaults/main.yml ファイルの YAML 形式ではどのようになっているかを確認できます。

openshift_node_groups:
  - name: node-config-master 1
    labels:
      - 'node-role.kubernetes.io/master=true' 2
    edits: [] 3
  - name: node-config-infra
    labels:
      - 'node-role.kubernetes.io/infra=true'
    edits: []
  - name: node-config-compute
    labels:
      - 'node-role.kubernetes.io/compute=true'
    edits: []
  - name: node-config-master-infra
    labels:
      - 'node-role.kubernetes.io/infra=true,node-role.kubernetes.io/master=true'
    edits: []
  - name: node-config-all-in-one
    labels:
      - 'node-role.kubernetes.io/infra=true,node-role.kubernetes.io/master=true,node-role.kubernetes.io/compute=true'
    edits: []

インベントリーファイルの [OSEv3:vars] グループに openshift_node_groups 変数が設定されていない場合には、上記で定義したデフォルト値が使用されます。ただし、これらのデフォルト値とは違う値を使用する場合には、インベントリーファイルに (任意の全ノードグループなど) openshift_node_groups の構造全体を定義する必要があります。

openshift_node_groups の値は、デフォルト値とマージされないので、YAML 定義を先に Python ディクショナリーに変換する必要があります。その後に、edits フィールドを使用して、鍵と値のペアを指定して任意のノード設定変数に変更できます。

たとえば、インベントリーファイルの以下のエントリーは、node-config-master、node-config-infra および node-config-compute という名前のグループを定義し、node-config-compute の ConfigMap を編集して kubeletArguments.pods-per-core を 20 に設定します。

openshift_node_groups=[{'name': 'node-config-master', 'labels': ['node-role.kubernetes.io/master=true']}, {'name': 'node-config-infra', 'labels': ['node-role.kubernetes.io/infra=true',]}, {'name': 'node-config-compute', 'labels': ['node-role.kubernetes.io/compute=true'], 'edits': [{ 'key': 'kubeletArguments.pods-per-core','value': ['20']}]}]

openshift_node_group.yml Playbook が実行されるたびに、edits フォールドで定義した変更により、関連の ConfigMap (この例では node-config-compute) が更新され、最終的にホスト上のノードの設定ファイルに影響を与えます。

3.9 から 3.10 へのコントロールプレーンの自動アップグレードでは、以下の手順が実行されます。

3.9 から 3.10 へのノードの自動アップグレードではノードのローリングアップデートを実行し、以下が行われます。

自動化されたアップグレード Playbook は、インベントリーファイルと共に ansible-playbook コマンドを使用して Ansible で直接実行されます。これは通常インストール (advanced installation) 方式と同様です。以下のいずれのシナリオでも、同じ v3_10 アップグレード Playbook を使用することができます。

OpenShift Container Platform クラスターは 1 つまたは複数のフェーズでアップグレードできます。単一の Ansible Playbook を実行してすべてのホストを 1 つのフェーズでアップグレードすることも、別々の Playbook を使用して コントロールプレーン (マスターコンポーネント) およびノードを複数のフェーズでアップグレードすることもできます。

複数のフェーズでアップグレードする場合、コントロールプレーンのフェーズには、以下のアップグレードが含まれます。

ノードのみをアップグレードする場合、コントロールプレーンはすでにアップグレードされている必要があります。ノードのフェーズには、以下のアップグレードが含まれます。

アップグレードを単一または複数フェーズのいずれで実行する場合でも、-e オプションを使って特定の Ansible 変数をアップグレード Playbook に渡すことで、アップグレードのノード部分の処理方法をカスタマイズできます。

openshift_upgrade_nodes_serial 変数は整数またはパーセンテージに設定して同時にアップグレードできるノードホストの数を制御できます。デフォルトは 1 であり、この場合ノードは一度に 1 つずつアップグレードされます。

たとえば、一度に検出されるノードの全体数の 20 パーセントをアップグレードするには、以下を実行します。

$ ansible-playbook -i <path/to/inventory/file> \
    </path/to/upgrade/playbook> \
    -e openshift_upgrade_nodes_serial="20%"

openshift_upgrade_nodes_label 変数を指定すると、特定のラベルを持つノードのみをアップグレードするように指定できます。これは openshift_upgrade_nodes_serial 変数と組み合わせて使用することもできます。

たとえば、group1 リージョンのノードのみを一度に 2 つアップグレードするには、以下を実行します。

$ ansible-playbook -i <path/to/inventory/file> \
    </path/to/upgrade/playbook> \
    -e openshift_upgrade_nodes_serial="2" \
    -e openshift_upgrade_nodes_label="region=group1"

openshift_upgrade_nodes_max_fail_percentage 変数を使用すると、各バッチで失敗するノードの数を指定できます。失敗のパーセンテージは Playbook がアップグレードを中止する前に指定した値を上回っている必要があります。

openshift_upgrade_nodes_drain_timeout 変数を使用すると、終了前の待機時間の長さを指定できます。

以下の例では、一度に 10 ノードをアップグレードして、20 パーセントを超えるノードが失敗する場合にはアップグレードが中断されます。ノードをドレイン (解放) するまでに 600 秒の待機時間があります。

$ ansible-playbook -i <path/to/inventory/file> \
    </path/to/upgrade/playbook> \
    -e openshift_upgrade_nodes_serial=10 \
    -e openshift_upgrade_nodes_max_fail_percentage=20 \
    -e openshift_upgrade_nodes_drain_timeout=600

OpenShift Container Platform のアップグレード時の特定の操作の実行中に、Hook というシステムでカスタムタスクを実行できます。Hook を使うと、管理者はアップグレード時の特定分野の前後に実行するタスクを定義するファイルを指定できます。これは、OpenShift Container Platform のアップグレード時にカスタムインフラストラクチャーを検証し、変更するのに非常に便利です。

Hook が失敗すると操作も失敗することに留意してください。つまり、Hook が適切であると複数回実行でき、同じ結果を出せます。適切な Hook にはべき等性があります。

[OSEv3:vars]
openshift_master_upgrade_pre_hook=/usr/share/custom/pre_master.yml
openshift_master_upgrade_hook=/usr/share/custom/master.yml
openshift_master_upgrade_post_hook=/usr/share/custom/post_master.yml

openshift_node_upgrade_pre_hook=/usr/share/custom/pre_node.yml
openshift_node_upgrade_hook=/usr/share/custom/node.yml
openshift_node_upgrade_post_hook=/usr/share/custom/post_node.yml

---
# Trivial example forcing an operator to ack the start of an upgrade
# file=/usr/share/custom/pre_master.yml

- name: note the start of a master upgrade
  debug:
      msg: "Master upgrade of {{ inventory_hostname }} is about to start"

- name: require an operator agree to start an upgrade
  pause:
      prompt: "Hit enter to start the master upgrade"