クラスタを更新する

bmctl を使用してクラスタを作成すると、次の一連のアクションを実行して、クラスタの構成の一部を変更できます。

  1. クラスタの構成ファイル(デフォルトでは bmctl-workspace/CLUSTER-NAME/CLUSTER-NAME.yaml にある)の特定のフィールドの値を変更します。

  2. bmctl update コマンドを実行して、クラスタを更新します。

このようにして、クラスタ内のノードの追加や削除、クラスタ内のノードの置き換えなどを実行できます。このドキュメントでは、クラスタに対してこれらの操作や他の更新を行う方法について説明します。

ただし、クラスタ構成の多くの要素は変更不可であり、クラスタの作成後に更新できないことに注意してください。変更可能フィールドと変更不可フィールドの包括的なリストについては、クラスタ構成フィールドのリファレンスをご覧ください。フィールドのリファレンスは、並べ替え可能なテーブルです。列見出しをクリックすると、表示順序を変更できます。フィールド名をクリックすると、その説明が表示されます。

クラスタにノードを追加または削除する

ノードプールとは、クラスタ内で同じ構成を持つノードのグループのことです。ノードは常にノードプールに属していることに留意してください。新しいノードをクラスタに追加するには、そのノードを特定のノードプールに追加する必要があります。ノードプールからノードを削除すると、クラスタからノードを完全に削除することになります。

GDCV for Bare Metal には、コントロール プレーン ノードプール、ロードバランサ ノードプール、ワーカー ノードプールの 3 種類のノードプールがあります。

ノードプールのノードを追加または削除するには、クラスタ構成ファイルの特定のセクションでノードの IP アドレスを追加または削除します。次のリストは、特定のノードプールに対して編集するセクションを示しています。

  • ワーカー ノードプール: NodePool 仕様の spec.nodes セクションで、ノードの IP アドレスを追加または削除します。
  • コントロール プレーン ノードプール: Cluster 仕様の spec.controlPlane.nodePoolSpec.nodes セクションで、ノードの IP アドレスを追加または削除します。
  • ロードバランサ ノードプール: Cluster 仕様の spec.loadBalancer.nodePoolSpec.nodes セクションで、ノードの IP アドレスを追加または削除します。

例: ワーカーノードを削除する方法

以下は、2 つのワーカーノードの仕様を示すクラスタ構成ファイルの例です。

---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: nodepool1
  namespace: cluster-cluster1
spec:
  clusterName: cluster1
  nodes:
  - address: 172.18.0.5
  - address: 172.18.0.6

ノードを削除するには:

  1. (省略可)削除するノードで重要な Pod が実行されている場合は、まずノードをメンテナンス モードにします。

    NodePool リソースの status.nodesDrained フィールドと status.nodesDraining フィールドを確認すると、ワーカーノードのノード ドレイン プロセスをモニタリングできます。

  2. クラスタ構成ファイルを編集して、ノードの IP アドレス エントリを削除します。

  3. クラスタを更新します。

    bmctl update cluster -c CLUSTER_NAME \
        --kubeconfig=ADMIN_KUBECONFIG
    

    次のように置き換えます。

    • CLUSTER_NAME: 更新するクラスタの名前。
    • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルへのパス。

    bmctl update コマンドが正常に実行されてから machine-preflight ジョブと machine-init ジョブが完了するまで少し時間がかかります。ノードとそれぞれのノードプールのステータスを表示するには、このドキュメントの更新内容を確認するセクションで説明されているコマンドを実行します。

ノードを強制的に削除する

bmctl update コマンドでノードを削除できない場合、クラスタから強制的に削除する必要があるかもしれません。詳細については、破損したノードを強制削除するをご覧ください。

HA コントロール プレーン ノードを置き換える

管理クラスタ、ユーザー クラスタ、スタンドアロン クラスタ、ハイブリッド クラスタで高可用性(HA)コントロール プレーン ノードを置き換えることができます。

クラスタ内のノードを置き換えるには、次の手順を実行します。

  1. クラスタ構成ファイルからノードの IP アドレスを削除します。
  2. クラスタを更新します。
  3. クラスタ内のノードのステータスを確認します。
  4. 同じクラスタ構成ファイルに新しいノードの IP アドレスを追加します。
  5. クラスタを更新します。

このセクションの残りの部分で例を示します。

以下は、ユーザー クラスタの 3 つのコントロール プレーン ノードを示すクラスタ構成ファイルの例です。

---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
 name: user-cluster
 namespace: cluster-user-cluster
spec:
  controlPlane:
   nodePoolSpec:
     nodes:
     - address: 10.200.0.11
     - address: 10.200.0.12
     - address: 10.200.0.13

spec.controlPlane.nodePoolSpec.nodes セクションの最後に表示されているノードを置き換えるには、次の手順を実行します。

  1. クラスタ構成ファイルのノードの IP アドレス エントリを削除して、ノードを削除します。この変更を行うと、クラスタ構成ファイルは次のようになります。

    ---
    apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    metadata:
     name: user-cluster
     namespace: cluster-user-cluster
    spec:
      controlPlane:
       nodePoolSpec:
         nodes:
         - address: 10.200.0.11
         - address: 10.200.0.12
    
  2. 次のコマンドを実行して、クラスタを更新します。

    bmctl update cluster -c CLUSTER_NAME \
        --kubeconfig=KUBECONFIG
    

    次のように変更します。

    • CLUSTER_NAME は、更新するクラスタの名前に置き換えます。
    • クラスタが自己管理クラスタ(管理クラスタやスタンドアロン クラスタなど)の場合、KUBECONFIG はクラスタの kubeconfig ファイルへのパスに置き換えます。この例のように、クラスタがユーザー クラスタの場合は、KUBECONFIG管理クラスタの kubeconfig ファイルのパスに置き換えます。
  3. bmctl update コマンドが正常に実行されてから machine-preflight ジョブと machine-init ジョブが完了するまで少し時間がかかります。ノードとそれぞれのノードプールのステータスを表示するには、このドキュメントの更新内容を確認するセクションで説明されているコマンドを実行します。ノードプールとノードの準備が完了したら、次のステップに進みます。

  4. クラスタ構成ファイルの spec.controlPlane.nodePoolSpec.nodes セクションに、新しいコントロール プレーン ノードの IP アドレスを追加して、ノードプールに新しいコントロール プレーン ノードを追加します。この変更を行うと、クラスタ構成ファイルは次のようになります。

    ---
    apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    metadata:
     name: user-cluster
     namespace: cluster-user-cluster
    spec:
      controlPlane:
       nodePoolSpec:
         nodes:
         - address: 10.200.0.11
         - address: 10.200.0.12
         - address: 10.200.0.14
    
  5. 次のコマンドを実行して、クラスタを更新します。

    bmctl update cluster -c CLUSTER_NAME \
        --kubeconfig=KUBECONFIG
    

    次のように変更します。

    • CLUSTER_NAME は、更新するクラスタの名前に置き換えます。
    • クラスタが自己管理クラスタ(管理クラスタやスタンドアロン クラスタなど)の場合、KUBECONFIG はクラスタの kubeconfig ファイルへのパスに置き換えます。この例のように、クラスタがユーザー クラスタの場合は、KUBECONFIG管理クラスタの kubeconfig ファイルのパスに置き換えます。

更新内容を確認する

ノードのステータスとそれに対応するノードプールは、kubectl get コマンドを使用して表示できます。

たとえば、次のコマンドは、クラスタの名前空間 cluster-my-cluster のノードプールのステータスを表示します。

kubectl -n cluster-my-cluster get nodepools.baremetal.cluster.gke.io

次のような結果が表示されます。

NAME                    READY   RECONCILING   STALLED   UNDERMAINTENANCE   UNKNOWN
cluster-my-cluster      3       0             0         0                  0
cluster-my-cluster-lb   2       0             0         0                  0
np1                     3       0             0         0                  0

Reconciling=1 は、調整ステップがまだ進行中であることを意味します。ステータスが Reconciling=0 に変わるまで待つ必要があります。

次のコマンドを実行して、クラスタ内のノードのステータスを確認することもできます。

kubectl get nodes --kubeconfig=KUBECONFIG

クラスタの診断方法について詳しくは、クラスタを診断するためにスナップショットを作成するをご覧ください。

更新で変更できる機能

ノードの追加、削除、置き換えに加えて、bmctl update コマンドを使用して、クラスタ構成ファイル内の特定の変更可能なフィールド値、カスタム リソース(CR)、アノテーションを変更できます。

クラスタ リソースを更新するには、クラスタ構成ファイルを編集して bmctl update で変更を適用します。

次のセクションでは、フィールド値、CR、アノテーションのいずれかを変更して既存のクラスタを更新する一般的な例についていくつか概説します。

loadBalancer.addressPools

addressPools セクションは、バンドルされたロードバランサのロード バランシング プールを指定するためのフィールドが含まれています。ロード バランシング アドレスプールはいつでも追加できますが、既存のアドレスプールの削除や変更はできません。

addressPools:
- name: pool1
  addresses:
  - 192.168.1.0-192.168.1.4
  - 192.168.1.240/28
- name: pool2
  addresses:
  - 192.168.1.224/28

不用意なクラスタの削除を防ぐ

baremetal.cluster.gke.io/prevent-deletion: "true" アノテーションをクラスタ構成ファイルに追加すると、クラスタが削除されなくなります。たとえば、kubectl delete clusterbmctl reset cluster を実行するとエラーが発生します。

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: ci-10c3c6f4d9c698e
  namespace: cluster-ci-10c3c6f4d9c698e
  annotations:
    baremetal.cluster.gke.io/prevent-deletion: "true"
spec:
  clusterNetwork:

bypassPreflightCheck

bypassPreflightCheck フィールドのデフォルト値は false です。クラスタ構成ファイルでこのフィールドを true に設定した場合、既存のクラスタにリソースを適用するときに内部プリフライト チェックは行われません。

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
  annotations:
    baremetal.cluster.gke.io/private-mode: "true"
spec:
  bypassPreflightCheck: true

loginUser

loginUser フィールドは、ノードアクセス構成の下に設定できます。このフィールドにより、マシンのログインにパスワードなしの sudo 機能がサポートされます。

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
  annotations:
    baremetal.cluster.gke.io/private-mode: "true"
spec:
  nodeAccess:
    loginUser: abm

NetworkGatewayGroup

NetworkGatewayGroup カスタム リソースは、下り(外向き)NAT ゲートウェイまたは BGP を使用してバンドルされたロード バランシング機能などの高度なネットワーク機能を対象にフローティング IP アドレスを指定するために使用されます。NetworkGatewayGroup カスタム リソースと関連するネットワーキング機能を使用するには、クラスタの作成時に clusterNetwork.advancedNetworkingtrue に設定する必要があります。

apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100

BGPLoadBalancer

BGP を使用してバンドル ロードバランサを構成すると、データプレーンのロード バランシングでは、デフォルトでコントロール プレーン ピアリングに指定した同じ外部ピアが使用されます。または、BGPLoadBalancer カスタム リソース(および BGPPeer カスタム リソース)を使用して、データプレーンのロード バランシングを個別に構成することもできます。詳細については、BGP を使用してバンドルされたロードバランサを構成するをご覧ください。

apiVersion: networking.gke.io/v1
kind: BGPLoadBalancer
metadata:
  name: default
  namespace: cluster-bm
spec:
  peerSelector:
    cluster.baremetal.gke.io/default-peer: "true"

BGPPeer

BGP を使用してバンドル ロードバランサを構成すると、データプレーンのロード バランシングでは、デフォルトでコントロール プレーン ピアリングに指定した同じ外部ピアが使用されます。または、BGPPeer カスタム リソース(および BGPLoadBalancer カスタム リソース)を使用して、データプレーンのロード バランシングを個別に構成することもできます。詳細については、BGP を使用してバンドルされたロードバランサを構成するをご覧ください。

apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
  name: bgppeer1
  namespace: cluster-bm
  labels:
    cluster.baremetal.gke.io/default-peer: "true"
spec:
  localASN: 65001
  peerASN: 65002
  peerIP: 10.0.3.254
  sessions: 2

NetworkAttachmentDefinition

bmctl update コマンドは、ネットワークに対応する NetworkAttachmentDefinition カスタム リソースを変更するために使用できます。

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: gke-network-1
  namespace: cluster-my-cluster
spec:
  config: '{
  "type": "ipvlan",
  "master": "enp2342",
  "mode": "l2",
  "ipam": {
    "type": "whereabouts",
    "range": "172.120.0.0/24"

サービスのネットワーク範囲を拡張する

初期の上限よりも多くのサービスを作成するには、IPv4 サービスの CIDR マスクを縮小し、クラスタのサービス ネットワークを拡張します。マスク(「/」後の値)を減らすと、ネットワーク範囲が拡大されます。

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  ...
  clusterNetwork:
    services:
      cidrBlocks:
        - 172.26.0.0/14
  ...

IPv4 サービスの CIDR の範囲は拡張のみできます。ネットワークの範囲は縮小できません。つまり、マスク(「/」後の値)を増やすことはできません。

kubelet イメージの pull 設定を構成する

kubelet は、クラスタの各ノードで実行されます。kubelet はノード上のコンテナをモニタリングし、コンテナが正常な状態であることを確認する役割を果たします。必要に応じて、kubelet はイメージをクエリし、Container Registry から pull します。

kubelet 構成を手動で更新し、すべてのクラスタノード間で同期させることは困難な場合があります。さらに問題を悪化させるのは、クラスタをアップグレードすると、ノードで実施した手動による kubelet の構成変更が失われることです。

同期更新を容易かつ永続的に行うことができるように、GKE on Bare Metal では、クラスタ ノードプール(コントロール プレーン ノード、ロードバランサ ノード、ワーカーノード)ごとに kubelet の一部の設定を指定できます。この設定は特定のプール内のすべてのノードに適用され、クラスタのアップグレード後も保持されます。これらの設定のフィールドは変更可能であるため、クラスタの作成中に限らず、いつでも更新できます。

次のサポートされているフィールドにより、kubelet での Container Registry からの pull オペレーションが制御されます。

  • registryBurst(デフォルト: 10)
  • registryPullQPS(デフォルト: 5)
  • serializeImagePulls(デフォルト: true)

各 kubelet 構成フィールドの詳細については、クラスタ構成フィールドのリファレンスをご覧ください。

これらのフィールドは、次のノードプールのクラスタ仕様と NodePool 仕様の kubeletConfig セクションで指定できます。

次の例は、クラスタ構成ファイルのデフォルト値で追加されたフィールドを示しています。アノテーション preview.baremetal.cluster.gke.io/custom-kubelet: "enable" は必須です。

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
  annotations:
    preview.baremetal.cluster.gke.io/custom-kubelet: "enable"
spec:
  ...
  controlPlane:
    nodePoolSpec:
      kubeletConfig:
        registryBurst: 10
        registryPullQPS: 5
        serializeImagePulls: true
  ...
  loadBalancer:
    nodePoolSpec:
      kubeletConfig:
        registryBurst: 10
        registryPullQPS: 5
        serializeImagePulls: true
  ...
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: node-pool-new
  namespace: cluster-cluster1
spec:
  clusterName: cluster1
  ...
  kubeletConfig:
    registryBurst: 10
    registryPullQPS: 5
    serializeImagePulls: true

いずれの場合も、設定はプール内のすべてのノードに適用されます。

使い方

イメージの pull を調整する際の考慮事項のいくつかを以下に示します。

  • イメージはデフォルトで順番に pull されるため、イメージの pull に時間を要すると、ノードにスケジュール設定されているその他すべてのイメージの pull に遅延が生じる可能性があります。遅延したイメージの pull によってアップグレード プロセスが妨げられる場合があります(特に GKE on Bare Metal の新しいイメージをノードにデプロイする必要がある場合)。イメージの pull の遅延に影響される場合は、serializeImagePullsfalse に設定して、イメージの並列 pull を許可します。

  • pull QPS exceeded などのイメージの pull スロットリングにエラーが発生した場合は、registryPullQPSregistryBurst の値を引き上げてイメージ pull のスループットを向上させることをおすすめします。これら 2 つのフィールドで pull のレートとキューサイズを調整すると、他のスロットリング関連の問題にも対処できます。負の値は使用できません。

bmctl update を使用して変更を適用する

構成ファイルを変更した後、次の bmctl update コマンドを実行してクラスタを更新します。

bmctl update cluster -c CLUSTER_NAME --kubeconfig=KUBECONFIG

次のように変更します。

  • CLUSTER_NAME は、更新するクラスタの名前に置き換えます。
  • クラスタが自己管理クラスタ(管理クラスタやスタンドアロン クラスタなど)の場合、KUBECONFIG はクラスタの kubeconfig ファイルへのパスに置き換えます。クラスタがユーザー クラスタの場合は、KUBECONFIG管理クラスタの kubeconfig ファイルへのパスに置き換えます。