Google Distributed Cloud（GDC）エアギャップを使用すると、GDC 上の GKE を使用して、作成後に Kubernetes クラスタを管理できます。このサービスを使用すると、進化するコンテナ ワークロードの要件に対応できます。
始める前に
Kubernetes クラスタのノードプールを表示して管理するには、次のロールが必要です。
- ユーザー クラスタ管理者（
user-cluster-admin） - ユーザー クラスタ ノード閲覧者（
user-cluster-node-viewer）
これらのロールは Namespace にバインドされていません。
Kubernetes クラスタに対してコマンドを実行するには、次のリソースがあることを確認してください。
Kubernetes クラスタ名を確認するか、プラットフォーム管理者にクラスタ名を確認します。
まだ Kubernetes クラスタの kubeconfig ファイルがない場合は、ログインして生成します。
これらの手順では、Kubernetes クラスタの kubeconfig パスを使用して
KUBERNETES_CLUSTER_KUBECONFIGを置き換えます。
ノードのメンテナンスを行う
ノードの修復またはメンテナンスが必要な場合は、まずノードをメンテナンス モードにします。ノードをメンテナンス モードにすると、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 edit cluster KUBERNETES_CLUSTER_NAME \ -n KUBERNETES_CLUSTER_NAMESPACE \ --kubeconfig KUBERNETES_CLUSTER_KUBECONFIGKubernetes クラスタの次の項目を置き換えます。
KUBERNETES_CLUSTER_NAME: クラスタの名前。KUBERNETES_CLUSTER_NAMESPACE: クラスタの名前空間。KUBERNETES_CLUSTER_KUBECONFIG: kubeconfig ファイルのパス。
クラスタ構成が適用されると、クラスタは該当するノードをメンテナンス モードにします。
クラスタ構成ファイルに
maintenanceBlocksセクションを追加して、メンテナンス モードにするノードの単一の IP アドレスまたはアドレス範囲を指定します。次のサンプルでは、IP アドレスの範囲を指定して複数のノードを選択する方法を示します。
... metadata: name: my-cluster namespace: cluster-my-cluster spec: maintenanceBlocks: cidrBlocks: - 172.16.128.1-172.16.128.64 ...クラスタ内のノードのステータスを取得します。
kubectl get nodes -n KUBERNETES_CLUSTER_NAME \ --kubeconfig KUBERNETES_CLUSTER_KUBECONFIG結果は次のようになります。
NAME STATUS ROLES AGE VERSION user-gdc-01 Ready master 2d22h v1.23.5-gke.1502 user-gdc-04 Ready none 2d22h v1.23.5-gke.1502 user-gdc-05 Ready,SchedulingDisabled none 2d22h v1.23.5-gke.1502 user-gdc-06 Ready none 2d22h v1.23.5-gke.1502ステータスが
SchedulingDisabledの場合、ノードがメンテナンス モードであることを示します。メンテナンス モードのノード数を取得します。
kubectl get nodepools --kubeconfig KUBERNETES_CLUSTER_KUBECONFIGレスポンスは次の出力のようになります。
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 環境の KUBERNETES クラスタでは、ワークロードの変化に合わせてノードプールのサイズを変更できます。Kubernetes クラスタのノードプールを管理するには、ユーザー クラスタ管理者（user-cluster-admin）ロールが必要です。このロールは Namespace にバインドされていません。
既存のクラスタでノードプールをスケーリングするには、次の操作を行います。
コンソール
- ダッシュボードで、編集するクラスタが存在するプロジェクトを選択します。
- ナビゲーション メニューで、[Kubernetes Engine] > [クラスタ] を選択します。
- ノードプールが関連付けられているクラスタ名を選択します。[クラスタの詳細] ページが表示されます。
- [ノードプール] タブをクリックします。
- サイズ変更するノードプールの edit [編集] アイコンを選択します。[ノードプールの編集] プロンプトが表示されます。
[ノード数] フィールドを更新して、ノードプールに必要な新しいノード数を反映します。ワークロードの要件に合わせてノード数を増減できます。
[保存] をクリックします。
クラスタの [ノードプール] タブに戻り、サイズ変更されたノードプールが
Readyステータスで、ノード数が正しいことを確認します。ノードプールが指定した仕様にスケーリングされるまでに数分かかることがあります。
API
インタラクティブ エディタを使用して、
kubectlCLI でClusterカスタム リソース仕様を開きます。kubectl edit clusters.cluster.gdc.goog/KUBERNETES_CLUSTER_NAME -n platform \ --kubeconfig MANAGEMENT_API_SERVER次のように置き換えます。
KUBERNETES_CLUSTER_NAME: ノードプールをホストするクラスタの名前。MANAGEMENT_API_SERVER: Kubernetes クラスタがホストされているゾーン API サーバーの kubeconfig パス。ターゲット ゾーンの API サーバーの 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/KUBERNETES_CLUSTER_NAME -n platform -o json \ --kubeconfig MANAGEMENT_API_SERVER | jq .status.workerNodePoolStatusesreadyNodesの数値が、ノードプールに設定したノード数を反映していることを確認します。ノードプールが指定した仕様にスケーリングされるまでに数分かかることがあります。
プロジェクト階層内のクラスタを移動する
プロジェクトは、サービス インスタンスの論理グループを提供します。GDC プロジェクト階層で Kubernetes クラスタを追加および削除して、サービスを適切にグループ化できます。
プロジェクトをクラスタに接続する
GDC コンソールからクラスタを作成する場合は、コンテナ ワークロードを正常にデプロイする前に、少なくとも 1 つのプロジェクトを関連付ける必要があります。既存のクラスタにプロジェクトを追加する必要がある場合は、次の手順を行います。
- ナビゲーション メニューで、[Kubernetes Engine] > [クラスタ] を選択します。
- クラスタのリストでクラスタをクリックして、[クラスタの詳細] ページを開きます。
- [プロジェクトを接続] を選択します。
- プロジェクト リストから、追加する利用可能なプロジェクトを選択します。[保存] をクリックします。
クラスタからプロジェクトを切り離す
既存の Kubernetes クラスタからプロジェクトを切り離すには、次の操作を行います。
- ナビゲーション メニューで、[Kubernetes Engine] > [クラスタ] を選択します。
- クラスタのリストでクラスタをクリックして、[クラスタの詳細] ページを開きます。
クラスタから切り離すプロジェクトの [delete 切り離し] をクリックします。
組織内のすべてのクラスタを表示する
組織で使用可能なすべての Kubernetes クラスタ（ステータス、Kubernetes バージョン、その他の詳細を含む）を表示できます。Kubernetes クラスタはゾーンリソースであるため、クラスタはゾーンごとにのみ一覧表示できます。
コンソール
ナビゲーション メニューで、[Kubernetes Engine] > [クラスタ] を選択します。
組織内の利用可能なすべてのクラスタが、ステータスなどの情報とともに表示されます。
kubectl
組織内のゾーンで使用可能な Kubernetes クラスタを一覧表示します。
kubectl get clusters.cluster.gdc.goog -n platform \ --kubeconfig MANAGEMENT_API_SERVERMANAGEMENT_API_SERVERは、ゾーン API サーバーの kubeconfig パスに置き換えます。ターゲット ゾーンの API サーバーの kubeconfig ファイルをまだ生成していない場合は、ログインで詳細を確認してください。出力は次のようになります。
NAME STATE K8S VERSION user-vm-1 Running 1.25.10-gke.2100 user-test Running 1.26.5-gke.2100
更新可能なプロパティを表示する
Kubernetes クラスタごとに、作成後に変更できるプロパティのセットがあります。変更できるのは、Cluster カスタム リソースの spec にある変更可能なプロパティのみです。spec のすべてのプロパティが、クラスタのプロビジョニング後に更新できるわけではありません。更新可能なプロパティを表示するには、次の操作を行います。
コンソール
ナビゲーション メニューで、[Kubernetes Engine] > [クラスタ] を選択します。
Kubernetes クラスタのリストで、クラスタ名をクリックしてプロパティを表示します。
編集可能なプロパティには、edit（編集）アイコンが表示されます。
kubectl
Cluster仕様のプロパティのリストと、各プロパティに対応する有効な値を表示します。kubectl explain clusters.cluster.gdc.goog.spec \ --kubeconfig MANAGEMENT_API_SERVERMANAGEMENT_API_SERVERは、ゾーン API サーバーの kubeconfig パスに置き換えます。ターゲット ゾーンの API サーバーの 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 GDC air-gapped 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, GDC maintains the cluster versions for users. Optional. Mutable.これらの設定を更新するには、GDC コンソールまたは
kubectlCLI を使用します。たとえば、ノードプ��ルのサ���ズを変更できます。
Ingress サービス IP アドレスのサイズをスケーリングする
Kubernetes クラスタを作成した後で、Ingress サービス IP アドレスのサイズをスケーリングできます。
インタラクティブ エディタを使用して、
kubectlCLI でClusterカスタム リソース仕様を開きます。kubectl edit clusters.cluster.gdc.goog/KUBERNETES_CLUSTER_NAME -n platform \ --kubeconfig MANAGEMENT_API_SERVER次のように置き換えます。
KUBERNETES_CLUSTER_NAME: IP アドレスを提供するクラスタの名前。MANAGEMENT_API_SERVER: Kubernetes クラスタがホストされているゾーン API サーバーの kubeconfig パス。ターゲット ゾーンの API サーバーの kubeconfig ファイルをまだ生成していない場合は、ログインをご覧ください。
ingressServiceIPSizeフィールドを新しい IP アドレス サイズに更新します。... spec: ... loadBalancer: ingressServiceIPSize: INGRESS_SERVICE_IP_SIZE ...INGRESS_SERVICE_IP_SIZEは、更新された上り（内向き）サービス IP アドレスのサイズに置き換えます。ファイルを保存し、エディタを終了します。
上り（内向き）サービス IP アドレスのサイズに設定された上限はありません。リクエストした IP アドレスの数は、組織に基づいて割り当てられます。リクエストを満たせない場合、クラスタはエラーを報告します。
Kubernetes クラスタをアップグレードする
Kubernetes クラスタの自動アップグレードまたは手動アップグレードを実行できます。クラスタのアップグレード方法の詳細については、クラスタのアップグレード セクションをご覧ください。