bmctl
を使用してクラスタを作成したら、そのクラスタのカスタム リソースを更新できます。たとえば、ノードプール内でノードを追加または削除できます。別の場所を指定しない限り、構成ファイルは bmctl-workspace/CLUSTER-NAME/CLUSTER-NAME.yaml
として保存されます。
このドキュメントでは、ノードの追加や削除など、クラスタの作成後に更新できるクラスタ構成オプションについて説明します。
クラスタにノードを追加または削除する
ベアメタル版 Anthos クラスタでは、クラスタのノードプール定義を編集することで、クラスタ内のノードの追加または削除を行います。ノードの IP アドレスを使用すると、ノードプールでノードを追加または削除できます。定義の変更には 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
ノードプールからノードを削除するには、ノードの 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
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