Google Distributed Cloud エアギャップ アプライアンス（GDC）を使用すると、Kubernetes クラスタを作成した後に管理できるため、進化するコンテナ ワークロードの要件に対応できます。
ノードのメンテナンスを行う
ノードの修復またはメンテナンスが必要な場合は、まずノードをメンテナンス モードにします。ノードをメンテナンス モードにすると、Pod/ワークロードが安全にドレインされ、ノードは Pod のスケジューリング対象から除外されます。メンテナンス モードでは、Pod トラフィックが中断されるリスクなしに、ノードを操作できます。
仕組み
GDC のメンテナンス モードは、特定のノードで kubectl
cordon と kubectl drain を実行するのと似ています。メンテナンス モードに関連する詳細は次のとおりです。
- 指定されたノードはスケジュール不可に設定されます。このアクションは
kubectl cordonが行う処理です。 - 指定されたノードにノード taint が追加され、そのノードで Pod がスケジュールまたは実行されないことが示されます。このアクションは
kubectl drainと似ています。 - ノードが Pod の終了を待って停止するのを防ぐために、20 分のタイムアウトが適用されます。Pod は、すべての taint を許容するよう構成されている場合や、ファイナライザが設定されている場合、終了できないことがあります。GDC クラスタはすべての Pod を終了しようとしますが、タイムアウトを超えた場合、ノードはメンテナンス モードに移行します。このタイムアウトにより、実行中の Pod がアップグレードを妨げることがなくなります。
- ノードで VM ベースのワークロードが実行されている場合、GDC クラスタは仮想マシン インスタンス（VMI）Pod に
NodeSelectorを適用してから、Pod を停止します。NodeSelectorは、ノードがメンテナンス モードを解除されたときに、VMI Pod が同じノードで再起動されるようにします。
ノードをメンテナンス モードにする
クラスタ構成ファイルの maintenanceBlocks セクションで、選択したノードの IP アドレス範囲を指定して、メンテナンス モードにするノードを選択します。選択するノードは、Ready 状態で、クラスタで機能している必要があります。
ノードをメンテナンス モードにするには:
クラスタ構成ファイルを編集して、メンテナンス モードにするノードを選択します。
任意のエディタで構成ファイルを編集するか、次のコマンドを実行して、クラスタのカスタム リソースを直接編集します。
kubectl -n CLUSTER_NAMESPACE edit cluster CLUSTER_NAME次のように置き換えます。
- CLUSTER_NAMESPACE: クラスタの Namespace。
- CLUSTER_NAME: クラスタの名前。
クラスタ構成ファイルに
maintenanceBlocksセクションを追加して、メンテナンス モードにするノードの単一の IP アドレスまたはアドレス範囲を指定します。次のサンプルでは、IP アドレスの範囲を指定して複数のノードを選択する方法を示します。
... metadata: name: my-cluster namespace: cluster-my-cluster spec: maintenanceBlocks: cidrBlocks: - 172.16.128.1-172.16.128.64 ...更新したクラスタ構成を保存して適用します。
kubectl apply -f my-cluster.yamlクラスタ構成が適用されると、クラスタは該当するノードをメンテナンス モードにします。
次のコマンドを実行して、クラスタ内のノードのステータスを確認します。
kubectl get nodes -n CLUSTER_NAME結果は次のようになります。
NAME STATUS ROLES AGE VERSION user-gdch-01 Ready master 2d22h v1.23.5-gke.1502 user-gdch-04 Ready none 2d22h v1.23.5-gke.1502 user-gdch-05 Ready,SchedulingDisabled none 2d22h v1.23.5-gke.1502 user-gdch-06 Ready none 2d22h v1.23.5-gke.1502ステータスが
SchedulingDisabledの場合、ノードがメンテナンス モードであることを示します。次のコマンドを実行して、メンテナンス モードになっているノードの数を確認します。
kubectl get nodepoolsレスポンスは次の出力のようになります。
NAME READY RECONCILING STALLED UNDERMAINTENANCE UNKNOWN np1 3 0 0 1 0このサンプルの
UNDERMAINTENANCE列は、1 つのノードがメンテナンス モードであることを示しています。クラスタでは、ノードがメンテナンス モードになると、ノードに次の taint も追加されます。
baremetal.cluster.gke.io/maintenance:NoExecutebaremetal.cluster.gke.io/maintenance:NoSchedule
ノードプールのサイズを変更する
GDC 環境内の任意のユーザー クラスタで、ワークロードの変化に合わせてノードプールのサイズを変更できます。ユーザー クラスタのノードプールを管理するには、ユーザー クラスタ管理者（user-cluster-admin）のロールが必要です。
既存のクラスタでノードプールをスケーリングするには、次の操作を行います。
コンソール
- ダッシュボードで、編集するクラスタが存在するプロジェクトを選択します。
- ナビゲーション メニューで [クラスタ] を選択します。
- ノードプールが関連付けられているクラスタ名を選択します。[クラスタの詳細] ページが表示されます。
- [ノードプール] タブをクリックします。
- サイズ変更するノードプールの edit [編集] アイコンを選択します。[ノードプールの編集] プロンプトが表示されます。
[ノード数] フィールドを更新して、ノードプールに必要な新しいノード数を反映します。ワークロードの要件に合わせてノード数を増減できます。
[保存] をクリックします。
クラスタの [ノードプール] タブに戻り、サイズ変更されたノードプールが
Readyステータスで、ノード数が正しいことを確認します。ノードプールが指定した仕様にスケーリングされるまでに数分かかることがあります。
API
インタラクティブ エディタを使用して、
kubectlCLI でClusterカスタム リソース仕様を開きます。kubectl edit clusters.cluster.gdc.goog/USER_CLUSTER_NAME -n platform \ --kubeconfig ORG_ADMIN_CLUSTER_KUBECONFIGサイズ変更するノードプールの
nodeCountフィールドを更新します。nodePools: ... - machineTypeName: n2-standard-2-gdc name: nodepool-1 nodeCount: NUMBER_OF_WORKER_NODESNUMBER_OF_WORKER_NODESは、ノードプールでプロビジョニングするワーカーノードの更新された数に置き換えます。ファイルを保存し、エディタを終了します。
ノードプールの構成を確認して、ノードのスケーリングが完了したことを確認します。
kubectl get clusters.cluster.gdc.goog/USER_CLUSTER_NAME -n platform -o json \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG | jq .status.workerNodePoolStatusesreadyNodesの数値が、ノードプールに設定したノード数を反映していることを確認します。ノードプールが指定した仕様にスケーリングされるまでに数分かかることがあります。
組織内のすべてのクラスタを表示する
組織内のすべてのユーザー クラスタ（ステータス、Kubernetes バージョン、その他の詳細を含む）を表示できます。
コンソール
ナビゲーション メニューで [クラスタ] を選択します。
組織内の利用可能なすべてのクラスタが、ステータスなどの情報とともに表示されます。
kubectl
組織で使用可能なユーザー クラスタを一覧表示します。
kubectl get clusters.cluster.gdc.goog -n platform \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG出力は次のようになります。
NAME STATE K8S VERSION user-vm-1 Running 1.25.10-gke.2100 user-test Running 1.26.5-gke.2100
更新可能なプロパティを表示する
各ユーザー クラスタには、作成後に変更できる一連のプロパティがあります。変更できるのは、Cluster カスタム リソースの spec にある変更可能なプロパティのみです。spec のすべてのプロパティが、クラスタのプロビジョニング後に更新できるわけではありません。更新可能なプロパティを表示するには、次の操作を行います。
コンソール
ナビゲーション メニューで [クラスタ] を選択します。
ユーザー クラスタのリストで、クラスタ名をクリックしてプロパティを表示します。
編集可能なプロパティには、edit [編集] アイコンが表示されます。
kubectl
Cluster仕様のプロパティのリストと、各プロパティに対応する有効な値を表示します。kubectl explain clusters.cluster.gdc.goog.spec \ --kubeconfig ORG_ADMIN_CLUSTER_KUBECONFIG出力は次のようになります。
KIND: Cluster VERSION: cluster.gdc.goog/v1 RESOURCE: spec <Object> DESCRIPTION: <empty> FIELDS: clusterNetwork <Object> The cluster network configuration. If unset, the default configurations with pod and service CIDR sizes are used. Optional. Mutable. initialVersion <Object> The GDCH version information of the user cluster during cluster creation. Optional. Default to use the latest applicable version. Immutable. loadBalancer <Object> The load balancer configuration. If unset, the default configuration with the ingress service IP address size is used. Optional. Mutable. nodePools <[]Object> The list of node pools for the cluster worker nodes. Optional. Mutable. releaseChannel <Object> The release channel a cluster is subscribed to. When a cluster is subscribed to a release channel, GDCH maintains the cluster versions for users. Optional. Mutable.これらの設定を更新するには、GDC コンソールまたは
kubectlCLI を使用します。たとえば、ノードプールのサイズを変更できます。
Ingress サービス IP アドレスのサイズをスケーリングする
ユーザー クラスタの作成後に、Ingress サービス IP アドレスのサイズをスケーリングできます。
インタラクティブ エディタを使用して、
kubectlCLI でClusterカスタム リソース仕様を開きます。kubectl edit clusters.cluster.gdc.goog/USER_CLUSTER_NAME -n platform \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGingressServiceIPSizeフィールドを新しい IP アドレス サイズに更新します。... spec: ... loadBalancer: ingressServiceIPSize: INGRESS_SERVICE_IP_SIZE ...INGRESS_SERVICE_IP_SIZEは、更新された Ingress サービス IP アドレスのサイズに置き換えます。ファイルを保存し、エディタを終了します。
Ingress サービス IP アドレスのサイズに設定された上限はありません。リクエストした IP アドレスの数は、組織に基づいて割り当てられます。リクエストを満たせない場合、クラスタはエラーを報告します。