クラスタを更新する

bmctl を使用してクラスタを作成したら、そのクラスタのカスタム リソースを更新できます。別の場所を指定しない限り、構成ファイルは bmctl-workspace/CLUSTER-NAME/CLUSTER-NAME.yaml として保存されます。

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

ベアメタル版 Anthos クラスタでは、クラスタのノードプール定義を編集することで、クラスタ内のノードの追加または削除を行います。定義の変更には bmctl コマンドを使用します。

ベアメタル版 Anthos クラスタには、コントロール プレーン ノードプール、ロードバランサ ノードプール、ワーカー ノードプールの 3 種類のノードプールがあります。

ノードのステータスを表示する

ノードのステータスとそれに対応するノードプールは、kubectl get コマンドを使用して表示できます。

たとえば、次のコマンドは、クラスタの名前空間 my-cluster のノードプールのステータスを表示します。

kubectl -n my-cluster get nodepools.baremetal.cluster.gke.io

次のような結果が表示されます。

NAME                    READY   RECONCILING   STALLED   UNDERMAINTENANCE   UNKNOWN
my-cluster              3       0             0         0                  0
my-cluster-lb           2       0             0         0                  0
np1                     3       0             0         0                  0

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

ノードを変更する

ほとんどのノードの変更はクラスタ構成ファイルで指定され、クラスタに適用されます。クラスタ構成ファイルを、クラスタを更新するプライマリ ソースとして使用することをおすすめします。トラブルシューティングの目的で、変更を追跡するために構成ファイルをバージョン管理システムに保存することをおすすめします。すべてのクラスタタイプで、ノードの変更に合わせてクラスタを更新するには、bmctl update コマンドを使用します。

ベアメタル版 Anthos クラスタの構成ファイルには、認証情報を含むヘッダー セクションが含まれています。認証情報エントリと残りの構成ファイルは有効な YAML ですが、クラスタ リソースでは認証情報エントリは無効です。認証情報の更新には bmctl update credentials を使用します。

クラスタからノードを削除すると、まずポッドがドレインされます。Pod を他のノードで再スケジュールできない場合、ノードはクラスタから削除されません。bmctl update コマンドは、クラスタ構成ファイルを解析し、解析された結果に基づいてカスタム リソースを適用します。

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

ノードプールからノードを削除するには、ノードのエントリを削除します。

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

bmctl update コマンドが正常に実行された後、machine-init または machine-reset の Pod が完了するまでに若干の時間を要します。

以降のセクションでは、特定のノードタイプを更新する際の重要な相違について説明します。

コントロール プレーンとロードバランサのノード

ベアメタル版 Anthos クラスタ用のコントロール プレーンとロードバランサのノードプール仕様は特別なものです。これらの仕様で、重要なクラスタ リソースが宣言され管理されます。そのリソースの原本が、クラスタ構成ファイルのそれぞれのセクションです。

  • spec.controlPlane.nodePoolSpec
  • spec.LoadBalancer.nodePoolSpec

コントロール プレーンまたはロードバランサのノードを追加または削除するには、クラスタ構成ファイルの対応するセクションにある nodes の下に配置されているアドレスの配列を編集します。

高可用性（HA）構成では、コントロール プレーンが失敗しても他のコントロール プレーンがそれを引き継げるクォーラムを確立するために、コントロール プレーン ノードプールが奇数個必要（3 つ以上）になります。ノードのメンテナンスや交換によるノードの追加や削除で、ノード数が一時的に偶数になる場合でも、クォーラムが十分に確保されている限りデプロイは HA を維持します。

ワーカーノード

ワーカーノードは、bmctl コマンドを使用して直接追加や削除を行えます。ワーカー ノードプールには、目的のノードが 1 つ以上必要です。ただし、ノードプール全体を削除するには、kubectl コマンドを使用します。次の例では、コマンドによってクラスタの名前空間の変数が my-cluster である np1 という名前のノードプールが削除されます。

kubectl -n my-cluster delete nodepool np1

その他の変更可能フィールド

ノードの追加と削除に加えて、bmctl update コマンドを使用してクラスタ構成の特定の要素を変更できます。通常、クラスタ リソースを更新するには、クラスタ構成ファイルのローカル バージョンを編集し、bmctl update を使用して変更を適用します。bmctl update コマンドは、kubectl apply コマンドと似ています。

以降のセクションでは、フィールド値や関連するカスタム リソースを変更して既存のクラスタを更新する一般的ないくつかの例について概説します。

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

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

ユーザー クラスタについては、次のコマンドを実行します。

bmctl update cluster -c CLUSTER_NAME --admin-kubeconfig=ADMIN_KUBECONFIG