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
BGPLoadBalancer
bmctl
を使用すると、Google のパッケージ化されたバンドル LB オプションを使用して BGP ベースのロードバランサを適用、更新できます。
apiVersion: "networking.gke.io/v1alpha1"
kind: BGPLoadBalancer
metadata:
name: default
namespace: cluster-cluster1
spec:
localASN: 65001
peers:
- peerASN: 65000
peerIP: 10.0.1.1
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