クラスタを更新する

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

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

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

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

  • gcloud CLI と Terraform は、管理クラスタとユーザー クラスタの更新のみをサポートしています。他のクラスタタイプの更新には bmctl を使用する必要があります。

  • gcloud CLI と Terraform は、クラスタとノードプール リソースの変更のみをサポートします。クラスタに影響する他のカスタム リソースの更新には、kubectl または bmctl を使用する必要があります。

クラスタを更新する方法

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

bmctl

  1. クラスタの構成ファイルで該当するフィールドの値を変更します。デフォルトでは、このファイルは次の場所にあります。
    bmctl-workspace/CLUSTER-NAME/CLUSTER-NAME.yaml

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

    bmctl update cluster -c CLUSTER_NAME --kubeconfig=KUBECONFIG

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

    • CLUSTER_NAME: 更新するクラスタの名前。
    • KUBECONFIG: 管理クラスタ、ハイブリッド クラスタ、スタンドアロン クラスタの場合は、クラスタの kubeconfig ファイルのパス。ユーザー クラスタの場合は、管理クラスタの kubeconfig ファイルのパスを入力します。

gcloud CLI

  1. 変更する構成のフラグのみを指定します。

  2. 該当する更新コマンドを実行します。

Terraform

  1. クラスタまたはノードプールの作成に使用した Terraform 構成ファイルで、該当する以下のフィールドの値を変更します。フィールドの詳細な説明については、Terraform リファレンス ドキュメントをご覧ください。

  2. terraform apply コマンドを実行して構成を更新します。

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

クラスタにノードの追加または削除を行う

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

Google Distributed Cloud には、コントロール プレーン ノードプール、ロードバランサ ノードプール、ワーカー ノードプールの 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

ノードを削除するには:

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

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

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

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

    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 コマンドについても説明します。

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

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

  2. 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

  3. 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.30
...
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 フィールドがあります。

  4. 次のコマンドを実行して、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）コントロール プレーン ノードを置き換えることができます。

クラスタ内のノードを置き換えるには、次の操作を行います。

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

例: 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 セクションの最後に示されているノードを置き換えるには、次の操作を行います。

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

  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: 192.0.2.11
    - address: 192.0.2.12
    - address: 192.0.2.14

  5. 次のコマンドを実行して、クラスタを更新します。

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

gcloud CLI

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

クラスタ内のノードを置き換えるには、次の操作を行います。

  1. 該当する以下の update コマンドを実行して、ノードの IP アドレスを削除します。

    • ユーザー クラスタ: gcloud container bare-metal clusters update
    • 管理クラスタ: gcloud container bare-metal admin-clusters update

  2. gcloud container bare-metal operations describe OPERATION_ID を実行して、クラスタ内のノードの削除ステータスを確認します。

  3. 該当する update コマンドを実行して、新しいノードの IP アドレスを追加します。

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

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

  1. 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.30      abm-admin-cluster1   RUNNING
abm-user-cluster1b   europe-west1  1.30      abm-admin-cluster1   RUNNING

  2. クラスタで 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 フィールドがあります。

  3. 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

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

  4. 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 Namespace のノードプールのステータスを表示します。

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）のバンドルされたロードバランサのロード バランシング プールを指定するフィールドがあります。ロード バランシング アドレスプールはいつでも追加できますが、既存のアドレスプールは削除できません。Google Distributed Cloud バージョン 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 になります。Google Distributed Cloud バージョン 1.16.0 以降では、既存のアドレスプールでこの値を変更できます。

  • manual-assign: IPAM コントローラによって、このプールから Service に IP アドレスが自動的に割り当てられないようにする場合は、True に設定します。次に、デベロッパーは、LoadBalancer タイプの Service を作成し、プールからアドレスのいずれかを手動で指定します。指定しない場合、manual-assign は False に設定されます。Google Distributed Cloud バージョン 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" の値を指定すると、クラスタを削除できません。例:

  1. クラスタの誤削除を防ぐためにアノテーションを追加します。

    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"

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

    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 アクセスを許可するには、各クラスタノード マシンで次の操作を行います。

  1. sudo visudo を使用して sudoers ファイルを開き、編集します。

    sudo visudo -f /etc/sudoers

    visudo コマンドは、sudoers ファイルをロックして同時編集を防ぎ、保存時にファイルの構文を検証します。

  2. ログイン ユーザーの sudoers ファイルに、次のようにエントリを追加します。

    USERNAME ALL=(ALL) NOPASSWD: ALL

  3. ファイルを閉じて保存します。

  4. ログイン ユーザーの権限でコマンドを実行するには、次のコマンドを実行します。

    su - USERNAME

  5. ログイン ユーザーが 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 の構成変更が失われます。

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

bmctl

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

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

gcloud CLI

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

使い方

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

  • イメージはデフォルトで順番に pull されるため、イメージの pull に時間を要すると、ノードにスケジュール設定されている他のイメージの pull に遅延が生じる可能性があります。遅延したイメージの pull によってアップグレード プロセスが妨げられる場合があります（特に Google Distributed Cloud の新しいイメージをノードにデプロイする必要がある場合）。イメージの pull の遅延の影響を受ける場合は、イメージの pull のシリアル化を無効にして、イメージの並列 pull を許可できます。

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

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

bmctl

gcloud CLI

Terraform