クラスタを更新する

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

クラスタの構成ファイル（デフォルトでは bmctl-workspace/CLUSTER-NAME/CLUSTER-NAME.yaml にある）の特定のフィールドの値を変更します。
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

ノードを削除するには:

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

NodePool リソースの status.nodesDrained フィールドと status.nodesDraining フィールドを確認すると、ワーカーノードのノードドレインプロセスをモニタリングできます。
クラスタ構成ファイルを編集して、ノードの IP アドレスエントリを削除します。
クラスタを更新します。
```
bmctl update cluster -c CLUSTER_NAME \
    --kubeconfig=ADMIN_KUBECONFIG
```
次のように置き換えます。
- CLUSTER_NAME: 更新するクラスタの名前。
- ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルへのパス。
bmctl update コマンドが正常に実行されてから machine-preflight ジョブと machine-init ジョブが完了するまで少し時間がかかります。ノードとそれぞれのノードプールのステータスを表示するには、このドキュメントの更新内容を確認するセクションで説明されているコマンドを実行します。

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

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

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

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

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

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

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

以下は、ユーザークラスタの 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 セクションの最後に表示されているノードを置き換えるには、次の手順を実行します。

クラスタ構成ファイルのノードの 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

次のコマンドを実行して、クラスタを更新します。
```
bmctl update cluster -c CLUSTER_NAME \
    --kubeconfig=KUBECONFIG
```
次のように変更します。
- CLUSTER_NAME は、更新するクラスタの名前に置き換えます。
- クラスタが自己管理クラスタ（管理クラスタやスタンドアロンクラスタなど）の場合、KUBECONFIG はクラスタの kubeconfig ファイルへのパスに置き換えます。この例のように、クラスタがユーザークラスタの場合は、KUBECONFIG を管理クラスタの kubeconfig ファイルのパスに置き換えます。
bmctl update コマンドが正常に実行されてから machine-preflight ジョブと machine-init ジョブが完了するまで少し時間がかかります。ノードとそれぞれのノードプールのステータスを表示するには、このドキュメントの更新内容を確認するセクションで説明されているコマンドを実行します。ノードプールとノードの準備が完了したら、次のステップに進みます。
クラスタ構成ファイルの 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
```
次のコマンドを実行して、クラスタを更新します。
```
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 cluster や bmctl 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.advancedNetworking を true に設定する必要があります。

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 セクションで指定できます。

クラスタ仕様:
- コントロールプレーンノード spec.controlPlane.nodePoolSpec.kubeletConfig
- ロードバランサノード spec.loadBalancer.nodePoolSpec.kubeletConfig
NodePool 仕様:
- ワーカーノード spec.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 の遅延に影響される場合は、serializeImagePulls を false に設定して、イメージの並列 pull を許可します。
pull QPS exceeded などのイメージの pull スロットリングにエラーが発生した場合は、registryPullQPS と registryBurst の値を引き上げてイメージ pull のスループットを向上させることをおすすめします。これら 2 つのフィールドで pull のレートとキューサイズを調整すると、他のスロットリング関連の問題にも対処できます。負の値は使用できません。

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

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

bmctl update cluster -c CLUSTER_NAME --kubeconfig=KUBECONFIG

次のように変更します。

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

クラスタを更新する

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

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

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

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

更新内容を確認する

更新で変更できる機能

loadBalancer.addressPools

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

bypassPreflightCheck

loginUser

NetworkGatewayGroup

BGPLoadBalancer

BGPPeer

NetworkAttachmentDefinition