クラスタを更新する

クラスタを作成した後、クラスタの構成の一部の側面を変更できます。たとえば、次のようなことを行えます。

ノードを追加、削除、または置換します。
クラスタにアノテーションを追加したり削除します。
クラスタとノードプールリソースの変更可能なフィールドの値を変更します。
その他のカスタムリソースを変更します。

bmctl または Google Cloud CLI を使用して、クラスタを更新できます。Terraform を使用して管理クラスタまたはユーザークラスタを作成した場合は、Terraform を使用してクラスタを更新できます。次の点にご注意ください。

クラスタ構成の多くの側面は変更不可であり、クラスタの作成後に更新できません。変更可能フィールドと変更不可フィールドの包括的なリストについては、クラスタ構成フィールドのリファレンスをご覧ください。フィールドのリファレンスは、並べ替え可能なテーブルです。並べ替え順を変更するには、列見出しをクリックします。フィールド名をクリックすると、その説明が表示されます。
gcloud CLI と Terraform は、管理クラスタとユーザークラスタの更新のみをサポートします。他のクラスタタイプを更新するには、bmctl を使用する必要があります。
gcloud CLI と Terraform は、クラスタリソースとノードプールリソースの変更のみをサポートします。クラスタに影響する他のカスタムリソースの更新には、kubectl または bmctl を使用する必要があります。

クラスタを更新する方法

通常、クラスタを更新するには以下の一連のアクションを行います。

`bmctl`

クラスタの構成ファイルで、該当するフィールドの値を変更します。デフォルトでは、次の場所にあります。
bmctl-workspace/CLUSTER-NAME/CLUSTER-NAME.yaml
次の bmctl update コマンドを実行して、クラスタを更新します。
```
bmctl update cluster -c CLUSTER_NAME --kubeconfig=KUBECONFIG
```
次のように置き換えます。
- CLUSTER_NAME: 更新するクラスタの名前。
- KUBECONFIG: 管理クラスタ、ハイブリッドクラスタ、スタンドアロンクラスタの場合は、クラスタの kubeconfig ファイルのパス。ユーザークラスタの場合は、adminクラスタの kubeconfig ファイルのパスを入力します。

クラスタ構成ファイルを編集するときは、bmctl update と kubectl apply -f を相互に置き換えずに使用しないでください。これらのコマンドを同じ意味で使用すると、クラスタ仕様のヘッダーによって入力された内容が意図せず削除される可能性があります。たとえば、bmctl update を使用してクラスタ構成ファイルを更新し、レジストリミラーを構成できます。調整後、クラスタには spec.nodeConfig.registryMirrors が入力されます。

その後、kubectl apply -f コマンドでクラスタ構成を使用してクラスタを変更しようとすると、クラスタの調整ツールによって入力された spec.nodeConfig.registryMirrors が削除されます。この現象は、構成がクラスタ構成仕様に存在せず、クラスタには存在する場合に発生します。

gcloud CLI

変更する構成のフラグのみを指定します。
該当する以下の更新コマンドを実行します。
- 管理クラスタ: gcloud container bare-metal admin-clusters update
- ユーザークラスタ: gcloud container bare-metal clusters update
- ユーザークラスタ上のノードプール: gcloud container bare-metal node-pools update

Terraform

クラスタまたはノードプールの作成に使用した Terraform 構成ファイル内の該当する以下のフィールドの値を変更します。フィールドの詳細については、Terraform のリファレンスドキュメントをご覧ください。
terraform apply コマンドを実行して構成を更新します。

以降のセクションでは、既存のクラスタを更新する一般的ないくつかの例について概説します。

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

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

ベアメタル版 GKE には、コントロールプレーンノードプール、ロードバランサノードプール、ワーカーノードプールの 3 種類のノードプールがあります。以下のセクションでは、ノードプールの種類ごとにノードを追加または削除する方法について説明します。

`bmctl`

ノードプールのノードを追加または削除するには、クラスタ構成ファイルの特定のセクションでノードの 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: 192.0.2.1
  - address: 192.0.2.2

ノードを削除するには:

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

NodePool リソースの status.nodesDrained フィールドと status.nodesDraining フィールドを確認すると、ワーカーノードのノードドレインプロセスをモニタリングできます。
クラスタ構成ファイルを編集して、ノードの IP アドレスエントリを削除します。

クラスタを更新します。

bmctl update cluster1 \
    --kubeconfig=ADMIN_KUBECONFIG

gcloud CLI

ノードを追加または削除するには、update コマンドを使用します。使用する update コマンド、IP アドレスを指定するフラグは、更新するノードプールのタイプによって異なります。

ワーカーノードプール: gcloud container bare-metal node-pools update を実行し、フラグ --node-configs 'node-ip=IP_ADDRESS' で IP アドレスを指定します。
管理クラスタのコントロールプレーンノードプール: gcloud container bare-metal admin-clusters update を実行し、フラグ --control-plane-node-configs 'node-ip=IP_ADDRESS' で IP アドレスを指定します。
ユーザークラスタのコントロールプレーンノードプール: gcloud container bare-metal clusters update を実行し、フラグ --control-plane-node-configs 'node-ip=IP_ADDRESS' で IP アドレスを指定します。
ロードバランサノードプール: gcloud container bare-metal clusters update を実行し、フラグ --metal-lb-load-balancer-node-configs 'node-ip=IP_ADDRESS' または
--bgp-load-balancer-node-configs 'node-ip=IP_ADDRESS' で IP アドレスを指定します。

IP アドレスを指定するフラグは、node-ip を 1 つのみを許可します。ノードプールの各 IP アドレスに対してフラグを指定します。

update コマンドは、すべての IP アドレスを指定した IP アドレスに置き換えます。ノードを追加するには、update コマンドに既存のノードの IP アドレスと新しいノードの IP アドレスを含めます。同様に、ノードを削除する場合は、保持するノードの IP アドレスのみを含めます。

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

このセクションでは、サンプルデータを使用してノードプールからワーカーノードを削除する方法について説明します。以下のステップには、有用な gcloud CLI コマンドも含まれています。

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

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

list コマンドを実行して、クラスタ内のすべてのノードプールを一覧表示します。

gcloud container bare-metal node-pools list \
    --cluster=abm-user-cluster1 \
    --project=example-project-12345 \
    --location=us-central1

出力は次のようになります。

NAME         LOCATION     STATE
node-pool-1  us-central1  RUNNING
node-pool-2  asia-east1   RUNNING

describe コマンドを実行して、ノードプール内のすべての IP アドレスを一覧表示します。
```
gcloud container bare-metal node-pools describe node-pool-1 \
    --cluster=abm-user-cluster1 \
    --project=example-project-12345 \
    --location=us-central1
```
次の出力例は、読みやすくするために省略しています。
```
annotations:
  ...
  baremetal.cluster.gke.io/version: 1.29
...
name: projects/example-project-12345/locations/us-central1/bareMetalClusters/abm-user-cluster1/bareMetalNodePools/node-pool-1
nodePoolConfig:
  nodeConfigs:
  - nodeIp: 192.0.2.1
  - nodeIp: 192.0.2.2
  operatingSystem: LINUX
state: RUNNING
...
```
出力例では次の点に注意してください。
- name フィールドには、ノードプールの完全修飾名が示されます。コマンドでノードプール名を指定する場合は、完全修飾名を指定するか、node-pool-1 などのノードプール名を --cluster、--project、--location フラグとともに指定できます。
- nodeConfigs セクションには、ノードの IP アドレスが指定された 2 つの nodeIp フィールドが含まれています。
次のコマンドを実行して、IP アドレス 192.0.2.1 を持つノードを削除します。
```
gcloud container bare-metal node-pools update node-pool-1 \
    --cluster=abm-user-cluster1 \
    --project=example-project-12345 \
    --location=us-central1 \
    --node-configs='node-ip=192.0.2.2'
```
update コマンドは、すべての IP アドレスを、指定した IP アドレスに置き換えます。192.0.2.1 が含まれていないため、そのノードは削除されます。

コマンドの出力は、次のようになります。
```
Waiting for operation [projects/example-project-12345/locations/us-central1/operations/operation-1697154681749-6078d9def4030-76686d6e-9fcb1de9] to complete
```
この出力例では、operation-1697154681749-6078d9def4030-76686d6e-9fcb1de9 という文字列は長時間実行オペレーションの OPERATION_ID です。オペレーションのステータスを確認するには、別のターミナルウィンドウで次のコマンドを実行します。
```
gcloud container bare-metal operations describe operation-1697154681749-6078d9def4030-76686d6e-9fcb1de9 \
    --project= example-project-12345 \
    --location=us-central1
```
このコマンドを頻繁に実行してステータスを確認できます。

ノードの削除に失敗した場合は、クラスタから強制的に削除できます。詳細については、破損したノードを強制削除するをご覧ください。

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

`bmctl`

bmctl を使用して、すべてのクラスタタイプの高可用性（HA）コントロールプレーンノードを置き換えることができます。

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

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

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

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

---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: user-cluster
namespace: cluster-user-cluster
spec:
  controlPlane:
  nodePoolSpec:
    nodes:
    - address: 192.0.2.11
    - address: 192.0.2.12
    - address: 192.0.2.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: 192.0.2.11
    - address: 192.0.2.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: 192.0.2.11
    - address: 192.0.2.12
    - address: 192.0.2.14
```
次のコマンドを実行して、クラスタを更新します。
```
bmctl update cluster -c CLUSTER_NAME \
  --kubeconfig=KUBECONFIG
```

gcloud CLI

gcloud CLI を使用して、管理クラスタとユーザークラスタ内の高可用性（HA）コントロールプレーンノードを置き換えることができます。

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

該当する以下の update コマンドを実行して、ノードの IP アドレスを削除します。
- ユーザークラスタ: gcloud container bare-metal clusters update
- 管理クラスタ: gcloud container bare-metal admin-clusters update
gcloud container bare-metal operations describe OPERATION_ID を実行して、クラスタ内のノード削除のステータスを確認します。
該当する update コマンドを実行して、新しいノードの IP アドレスを追加します。

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

このセクションでは、サンプルデータを使用してクラスタのコントロールプレーンを置き換える方法について説明します。以下のステップには、有用な gcloud CLI コマンドも含まれています。

list コマンドを実行して、Google Cloud プロジェクト内のすべてのユーザークラスタを一覧表示します。
```
gcloud container bare-metal clusters list \
    --project=example-project-12345 \
    --location=-
```
--location=- と設定すると、すべてのリージョンのクラスタがすべて一覧表示されます。リストを絞り込む必要がある場合は、--location を特定のリージョンに設定します。

出力は次のようになります。
```
NAME                 LOCATION      VERSION   ADMIN_CLUSTER        STATE
abm-user-cluster1a   us-central1   1.29      abm-admin-cluster1   RUNNING
abm-user-cluster1b   europe-west1  1.29      abm-admin-cluster1   RUNNING
```
クラスタで describe コマンドを実行します。
```
gcloud container bare-metal clusters describe abm-user-cluster1  \
    --project=example-project-12345 \
    --location=us-central1
```
この出力例は、読みやすくするために省略しています。
```
...
controlPlane:
  controlPlaneNodePoolConfig:
    nodePoolConfig:
      nodeConfigs:
      - nodeIp: 192.0.2.11
      - nodeIp: 192.0.2.12
      - nodeIp: 192.0.2.13
      operatingSystem: LINUX
...
name: projects/example-project-1234567/locations/us-central1/bareMetalClusters/abm-user-cluster1a
...
```
出力例では次の点に注意してください。
- name フィールドには、クラスタの完全修飾名が示されます。コマンドでクラスタ名を指定する場合は、完全修飾名を指定するか、abm-user-cluster1a などのクラスタ名を --project、--location flags とともに指定できます。
- nodeConfigs セクションには、コントロールプレーンノードの IP アドレスが指定された 3 つの nodeIp フィールドが含まれています。

IP アドレス 192.0.2.13 を持つノードを削除します。

gcloud container bare-metal cluster update abm-user-cluster1a \
    --project=example-project-12345 \
    --location=us-central1 \
    --control-plane-node-configs 'node-ip=192.0.2.11'
    --control-plane-node-configs 'node-ip=192.0.2.12'

コマンドの出力は、次のようになります。

Waiting for operation [projects/example-project-12345/locations/us-central1/operations/operation-1956154681749-6078d9def4030-76686d6e-9fcb1d7] to complete

この出力例では、operation-1956154681749-6078d9def4030-76686d6e-9fcb1de7 という文字列は長時間実行オペレーションの OPERATION_ID です。オペレーションのステータスを確認するには、別のターミナルウィンドウで次のコマンドを実行します。

gcloud container bare-metal operations describe operation-1956154681749-6078d9def4030-76686d6e-9fcb1de7 \
    --project= example-project-12345 \
    --location=us-central1

このコマンドを頻繁に実行してステータスを確認できます。

IP アドレス 192.0.2.14 を持つ新しいノードを追加します。

gcloud container bare-metal cluster update abm-user-cluster1a \
    --project=example-project-12345 \
    --location=us-central1 \
    --control-plane-node-configs 'node-ip=192.0.2.11'
    --control-plane-node-configs 'node-ip=192.0.2.12'
    --control-plane-node-configs 'node-ip=192.0.2.14'

更新内容を確認する

`kubectl`

ノードのステータスとそれに対応するノードプールは、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

gcloud CLI

前述のように、update コマンドを実行した後に、gcloud container bare-metal operations describe OPERATIONS_ID を使用してオペレーションのステータスを確認できます。コマンドの出力には、次の例のようにノードのステータスが表示されます。

  ...
  metrics:
  - intValue: '1'
    metric: NODES_RECONCILING
  - intValue: '2'
    metric: NODES_HEALTHY
  - intValue: '0'
    metric: NODES_FAILED
  - intValue: '0'
    metric: NODES_IN_MAINTENANCE
  - intValue: '3'
    metric: NODES_TOTAL
  stage: HEALTH_CHECK
...

ノードプールの更新に使用するツールにかかわらず、前述のように該当する describe コマンドを実行すると、ノードプールの現在のステータスを取得できます。

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

ロードバランサのアドレスプール

bmctl

addressPools セクションには、MetalLB と Border Gateway Protocol（BGP）のバンドル型ロードバランサのロードバランシングプールを指定するためのフィールドが含まれています。ロードバランシングアドレスプールはいつでも追加できますが、既存のアドレスプールは削除できません。GKE on Bare Metal バージョン 1.16.0 以降では、addressPools.avoidBuggyIPs と addressPools.manualAssign の値をいつでも変更できます。

addressPools:
- name: pool1
  addresses:
  - 198.51.100.0-198.51.100.4
  - 198.51.100.240/28
- name: pool2
  addresses:
  - 198.51.100.224/28

gcloud CLI

バンドル型ロードバランサには、いつでもロードバランシングアドレスプールを追加できますが、既存のアドレスプールは削除できません。アドレスプールを追加するために gcloud container bare-metal clusters update で指定するフラグは、バンドル型ロードバランサのタイプによって異なります。

MetalLB（レイヤ 2）: --metal-lb-address-pools フラグを使用します。
Border Gateway Protocol（BGP）: --bgp-address-pools フラグを使用します。

フラグの値の形式は次のとおりです。

'pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \

この値には、pool、avoid-buggy-ip、manual-assign、addresses というキーワードで始まるセグメントがあります。各セグメントはカンマで区切ります。

pool: ノードプールに付ける名前。
avoid-buggy-ips: True に設定すると、IP アドレス管理（IPAM）コントローラは、.0 または .255 で終わる IP アドレスを Service に割り当てません。これにより、バグの多いコンシューマデバイスが、これらの特別な IP アドレスに送信されたトラフィックを誤って破棄するという問題を回避できます。指定しない場合、デフォルトで False になります。GKE on Bare Metal バージョン 1.16.0 以降では、既存のアドレスプールでこの値を変更できます。
manual-assign: IPAM コントローラによって、このプールから Service に IP アドレスが自動的に割り当てられないようにする場合は、True に設定します。次に、デベロッパーは、LoadBalancer タイプの Service を作成し、プールからアドレスのいずれか 1 つを手動で指定します。指定しない場合、manual-assign は False に設定されます。GKE on Bare Metal バージョン 1.16.0 以降では、既存のアドレスプールでこの値を変更できます。
addresses のリスト内: 各アドレスは CIDR 形式またはハイフン付きの範囲で指定する必要があります。プール内の単一の IP アドレス（Ingress VIP など）を指定するには、CIDR 表記の /32 を使用します（例: 192.0.2.1/32）。

以下の構文ルールに注意してください。

値全体を単一引用符で囲みます。
空白文字は使用できません。
各 IP アドレス範囲はセミコロンで区切ります。

次の例に示すように、複数のフラグのインスタンスを指定できます。

--metal-lb-address-pools='pool=pool2,avoid-buggy-ips=False,manual-assign=True,addresses=198.51.100.0/30;198.51.100.64-198.51.100.72'
--metal-lb-address-pools='pool=pool3,avoid-buggy-ips=True,manual-assign=True,addresses=203.0.113.0/28'

ロードバランサのアドレスプールの詳細については、バンドル型ロードバランシングの構成に記載されている loadBalancer.addressPools をご覧ください。

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

`bmctl`

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:

gcloud CLI

--add-annotations フラグに baremetal.cluster.gke.io/prevent-deletion="true" の値を指定すると、クラスタを削除できません。例:

アノテーションを追加して、クラスタが誤って削除されるのを防ぎます。

gcloud container bare-metal clusters update abm-user-cluster1a \
    --project=example-project-12345 \
    --location=us-central1 \
    --add-annotations=baremetal.cluster.gke.io/prevent-deletion="true"

ユーザークラスタを削除しようとします。

gcloud container bare-metal clusters delete abm-user-cluster1a \
    --project=example-project-12345 \
    --location=us-central1 \
    --force \
    --allow-missing

このコマンドのレスポンスは、次のようになります。

ERROR: (gcloud.container.bare-metal.clusters.delete) INVALID_ARGUMENT:
invalid request: admission webhook "vcluster.kb.io" denied the request:
annotations[baremetal.cluster.gke.io/prevent-deletion]: Invalid value:
"true": Annotation "baremetal.cluster.gke.io/prevent-deletion" should be
removed in order to delete this cluster

アノテーションを削除するには、update コマンドで --remove-annotations=baremetal.cluster.gke.io/prevent-deletion="true" を指定します。

プリフライトチェックをバイパスする

この機能は bmctl update でのみ使用できます。

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

クラスタ管理者を追加または削除する

`bmctl`

ユーザークラスタのクラスタ管理者としてユーザーまたはサービスアカウントを追加または削除するには、クラスタ構成ファイルの clusterSecurity.authorization.clusterAdmin.gcpAccounts セクションでメールアドレスを指定します。アカウントにはクラスタに対するクラスタ管理者ロールが付与され、クラスタに対する完全アクセス権が付与されます。

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  clusterSecurity:
    authorization:
      clusterAdmin:
        gcpAccounts:
        - alex@example.com
        - hao@example.com
        - my-sa@example-project-12345.iam.gserviceaccount.com

ユーザークラスタを更新してアカウントを追加する場合は、リストにすべてのアカウント（既存のアカウントと新しいアカウントの両方）を含めてください。これは、構成ファイルで指定した内容で bmctl update がリストを上書きするためです。アカウントを削除するには、クラスタを構成ファイルから削除し、bmctl update を実行します。

gcloud CLI

クラスタ管理者としてユーザーまたはサービスアカウントを追加または削除するには、--admin-users フラグでメールアドレスを指定します。このフラグで指定できるメールアドレスは 1 つのみです。複数のユーザーを追加するには、各フラグに 1 つのアカウントを指定します。次に例を示します。

gcloud container bare-metal clusters update abm-user-cluster1a \
    --project=example-project-12345 \
    --location=us-central1 \
    --admin-users=alex@example.com \
    --admin-users=hao@example.com
    --admin-users=my-sa@example-project-12345.iam.gserviceaccount.com

update コマンドは、権限付与リスト全体を上書きします。クラスタ管理者になるすべての既存ユーザーと新規ユーザーを指定します。

ログインユーザーを設定する

クラスタ内のノードマシンへのパスワードなしの sudo 機能アクセスに使用する root 以外のユーザー名を指定できます。SSH 認証鍵 sshPrivateKeyPath は、指定したユーザーに対して機能する必要があります。クラスタの作成および更新オペレーションでは、指定したユーザーと SSH 認証鍵を使用してノードマシンにアクセスできることを確認します。

`bmctl`

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

gcloud CLI

--login-user フラグで、ノードマシンにアクセスするために使用するユーザーを指定します。次に例を示します。

gcloud container bare-metal clusters update abm-user-cluster1a \
    --project=example-project-12345 \
    --location=us-central1 \
    --login-user=abm

ユーザーに対してパスワードなしで sudo アクセスできるようにするには、各クラスタノードマシンで次の手順を行います。

sudo visudo を使用して、sudoers ファイルを編集用に開きます。
```
sudo visudo -f /etc/sudoers
```
visudo コマンドは、sudoers ファイルをロックして同時編集を防ぎ、保存時にファイルの構文を検証します。
ログインユーザーの sudoers ファイルに次のようなエントリを追加します。
```
USERNAME ALL=(ALL) NOPASSWD: ALL
```
ファイルを閉じて保存します。
ログインユーザーの権限でコマンドを実行するには、次のコマンドを実行します。
```
su - USERNAME
```
ログインユーザーが sudo コマンドを実行する際にパスワードが必要ないことを確認するには、次の sudo コマンドを実行します。
```
sudo ip a
```

高度なネットワーキング

クラスタの作成後に、さまざまなカスタムリソースで高度なネットワーク機能を構成します。カスタムリソース、関連するネットワーキング機能を使用するには、クラスタの作成時に高度なネットワーキングを有効にする必要があります。

`bmctl`

クラスタの作成時に、クラスタ構成で clusterNetwork.advancedNetworking を true に設定します。

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  clusterNetwork:
    ...
    advancedNetworking: true
    ...

gcloud CLI

クラスタの作成時に gcloud container bare-metal clusters create コマンドに --enable-advanced-networking フラグを指定します。

高度なネットワーキングを有効にしてクラスタを作成したら、kubectl apply を使用して、このセクションで説明するカスタムリソースを構成できます。

`NetworkGatewayGroup`

NetworkGatewayGroup カスタムリソースは、Egress NAT ゲートウェイまたは BGP を使用するバンドル型ロードバランシング機能などの高度なネットワーキング機能にフローティング IP アドレスを指定するために使用されます。

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

BGP ロードバランシング

Border Gateway Protocol（BGP）ロードバランシングをクラスタリソースとその他のカスタムリソースで構成します。gcloud container bare-metal clusters create コマンドと update コマンドは、クラスタリソースでの BGP の構成をサポートしますが、カスタムリソースではサポートしません。

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

`BGPLoadBalancer`

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

`BGPPeer`

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

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

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

`bmctl`

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

gcloud CLI

ユーザークラスタの IPv4 サービスの CIDR 範囲を拡大するには、--island-mode-service-address-cidr-blocks フラグで新しい範囲を指定します。

gcloud container bare-metal clusters update cluster1 \
    --project=example-project-12345 \
    --location=us-central1 \
    --island-mode-service-address-cidr-blocks=192.0.2.0/14

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

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

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

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

`bmctl`

次のサポートされているフィールドにより、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

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

gcloud CLI

以下のフラグは、kubelet の Container Registry の pull オペレーションを制御します。

使い方

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

イメージはデフォルトで順番に pull されるため、イメージの pull に時間を要すると、ノードにスケジュール設定されているその他すべてのイメージの pull に遅延が生じる可能性があります。遅延したイメージの pull によってアップグレードプロセスが妨げられる場合があります（特に GKE on Bare Metal の新しいイメージをノードにデプロイする必要がある場合）。イメージの pull の遅延の影響を受ける場合は、イメージの pull のシリアル化を無効にして、イメージの並列 pull を許可できます。
pull QPS exceeded など、イメージの pull のスロットリングエラーが発生した場合は、*-registry-pull-qps と *-registry-burst の値を引き上げてイメージの pull のスループットを向上させることをおすすめします。これら 2 つのフィールドで pull レートとキューサイズを調整すると、他のスロットリング関連の問題にも対処できます。負の値は使用できません。

クラスタを更新する

クラスタを更新する方法

bmctl

gcloud CLI

Terraform

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

bmctl

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

gcloud CLI

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

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

bmctl

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

gcloud CLI

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

更新内容を確認する

kubectl

gcloud CLI

ロードバランサのアドレスプール

bmctl

gcloud CLI

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

bmctl

gcloud CLI

プリフライト チェックをバイパスする

クラスタ管理者を追加または削除する

bmctl

gcloud CLI

ログイン ユーザーを設定する

bmctl

gcloud CLI

高度なネットワーキング

bmctl

gcloud CLI

NetworkGatewayGroup

BGP ロード バランシング

BGPLoadBalancer

BGPPeer

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

bmctl

gcloud CLI

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

bmctl

gcloud CLI

使い方

リファレンス ドキュメント

bmctl

gcloud CLI

Terraform

`bmctl`

`bmctl`

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

`bmctl`

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

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

`kubectl`

`bmctl`

プリフライトチェックをバイパスする

`bmctl`

ログインユーザーを設定する

`bmctl`

`bmctl`

`NetworkGatewayGroup`

BGP ロードバランシング

`BGPLoadBalancer`

`BGPPeer`

`bmctl`

`bmctl`

リファレンスドキュメント

`bmctl`