クラスタを更新する

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

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

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 コマンドを実行して構成を更新します。

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

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

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

GDCV for Bare Metal には、コントロール プレーン ノードプール、ロードバランサ ノードプール、ワーカー ノードプールの 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.16
    ...
    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.16      abm-admin-cluster1   RUNNING
    abm-user-cluster1b   europe-west1  1.16      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 のノードプールのステータスを表示します。

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.avoidBuggyIPsaddressPools.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;...' \

この値には、poolavoid-buggy-ipmanual-assignaddresses というキーワードで始まるセグメントがあります。各セグメントはカンマで区切ります。

  • 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-assignFalse に設定されます。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 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:

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

高度なネットワーキング

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

bmctl

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

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

次の例は、クラスタ構成ファイルのデフォルト値で追加されたフィールドを示しています。アノテーション 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 レートとキューサイズを調整すると、他のスロットリング関連の問題にも対処できます。負の値は使用できません。

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