Version 1.13. This version is no longer supported. For information about how to upgrade to version 1.14, see Upgrading Anthos on bare metal in the 1.14 documentation. For more information about supported and unsupported versions, see the Version history page in the latest documentation.

クラスタを更新する

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

クラスタの構成ファイル（デフォルトでは bmctl-workspace/CLUSTER-NAME/CLUSTER-NAME.yaml にある）の特定のフィールドの値を変更します。
bmctl update コマンドを実行してクラスタを更新します。

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

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

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

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

Anthos clusters on bare metal には、コントロールプレーンノードプール、ロードバランサノードプール、ワーカーノードプールの 3 種類のノードプールがあります。

ノードプールのノードを追加または削除するには、クラスタの構成ファイルの特定のセクションからノードの IP アドレスを追加または削除します。以下のリストは、特定のノードプールに対してマニフェストのどのセクションを編集する必要があるかを示しています。

ワーカーノードプール: kind: NodePool セクションに表示される spec.nodes フィールドから、ノードの IP アドレスを追加または削除します。
コントロールプレーンのノードプール: kind: Cluster セクションに表示される spec.controlPlane.nodePoolSpec.nodes フィールドから、ノードの IP アドレスを追加または削除します。
ロードバランサノードプール: 既存のロードバランサアドレスプールから変更（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

ワーカーノードプールからノードを削除するには、次の手順を行います。

クラスタの構成ファイルからノードの IP アドレスのエントリを削除します。

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

クラスタを更新します。
```
bmctl update cluster -c CLUSTER_NAME \
    --kubeconfig=KUBECONFIG
```
次のように変更します。
- CLUSTER_NAME は、更新するクラスタの名前に置き換えます。
- クラスタが自己管理クラスタ（管理クラスタやスタンドアロンクラスタなど）の場合、KUBECONFIG はクラスタの kubeconfig ファイルへのパスに置き換えます。クラスタがユーザークラスタの場合は、KUBECONFIG は管理クラスタの kubeconfig ファイルへのパスに置き換えます。

ノードを削除する前に、bmctl でノードから Pod をドレインする必要があるので注意してください。Pod を他のノードに再スケジュールできない場合、ノードはクラスタから削除されません。

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"

構成ファイルを変更した後、次の 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