概要
このページでは、バージョン 1.30 以降の管理クラスタを次の推奨機能に移行する方法について説明します。
ロードバランサの構成:
統合型 F5 BIG-IP ロードバランサの構成から
ManualLB。または
バンドルされた Seesaw ロードバランサから MetalLB。
非 HA 管理クラスタから高可用性（HA）管理クラスタに移行します。同じ数の VM を使用しながら、HA 管理クラスタを使用すると、可用性が大幅に向上します。非 HA 管理クラスタには、1 つのコントロール プレーン ノードと 2 つのアドオンノードがあります。HA 管理クラスタの 3 つのノードはすべてコントロール プレーン ノードであり、アドオンノードはありません。
このページは、基盤となる技術インフラストラクチャのライフサイクルを管理する IT 管理者と運用担当者を対象としています。Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。
移行計画の詳細については、推奨機能へのクラスタの移行を計画するをご覧ください。
ベスト プラクティス
テスト環境、開発環境、本番環境など複数の環境がある場合は、最初に、テストなどの重要度の低い環境を移行することをおすすめします。移行が成功したことを確認したら、このプロセスを環境ごとに繰り返し、最後に本番環境を移行します。これにより、各移行の成功を確認し、ワークロードが正しく実行されていることを確認してから、次のより重要な環境の移行に進むことができます。
要件
- 管理クラスタはバージョン 1.30 以降である必要があります。
- ユーザー クラスタを推奨機能に移行するで説明されているように、管理クラスタによって管理されているすべてのユーザー クラスタが推奨機能にすでに移行されている必要があります。
移行中のダウンタイムを計画する
移行では、コントロール プレーンの限定的なダウンタイムを計画します。非 HA 管理クラスタでは Kubernetes API アクセスが約 20 分間利用できなくなりますが、F5 を使用する HA 管理クラスタでは Kubernetes コントロール プレーンは引き続き使用できます。移行中、Kubernetes データプレーンは安定した状態で動作し続けます。
| 変革前 | 移行先 | Kubernetes API アクセス | ユーザー ワークロード |
|---|---|---|---|
F5 BIG-IP を使用した HA 管理クラスタ |
|
影響なし |
影響なし |
|
同じ種類のロードバランサを使用する HA 管理クラスタ |
影響あり |
影響なし |
F5 BIG-IP を使用した非 HA 管理クラスタ |
|
影響あり |
影響なし |
Seesaw を使用した非 HA 管理クラスタ |
MetalLB を使用した HA 管理クラスタ |
影響あり |
影響なし |
- 影響あり: 移行中にサービスが中断します。
- 影響なし: サービスが中断しないか、ほとんど気づきません。
移行を準備する
管理クラスタが HA でない場合、このセクションの手順に沿って HA 管理クラスタへの移行を準備します。管理クラスタがすでに HA になっている場合は、次のセクションのロードバランサの移行の準備に進みます。
追加の IP アドレスを割り振る
管理クラスタを非 HA から HA に移行する場合は、4 つの IP アドレスを追加で割り当てます。これらの IP アドレスが既存の管理クラスタノードと同じ VLAN にあり、既存のノードによって使用されていないことを確認します。
- 管理クラスタ構成ファイルの
loadBalancer.vips.controlPlaneVIPフィールドに、新しいコントロール プレーン VIP 用に 1 つの IP アドレスを割り当てます。 - 管理クラスタ構成ファイルの
network.controlPlaneIPBlockセクションで、3 つのコントロール プレーン ノードごとに新しい IP アドレスを割り振ります。
ファイアウォール ルールを更新する
管理クラスタを非 HA から HA に移行する場合は、管理クラスタのファイアウォール ルールを更新します。これにより、管理クラスタのファイアウォール ルールで説明されているように、コントロール プレーン ノードに新しく割り振られた IP アドレスが、必要なすべての API やその他の宛先に到達できるようになります。
ロードバランサの移行を準備する
管理クラスタで統合 F5 BIG-IP 構成またはバンドルされた Seesaw ロードバランサを使用している場合は、このセクションの手順に沿って、管理クラスタ構成ファイルに必要な変更を加えます。それ以外の場合は、次のセクションの 非 HA から HA に移行する準備に進みます。
F5 BIG-IP
管理クラスタで統合 F5 BIG-IP 構成を使用している場合は、管理クラスタ構成ファイルに次の変更を行います。
loadBalancer.kindフィールドを"ManualLB"に設定します。loadBalancer.vips.controlPlaneVIPフィールドの値を設定するか、そのままにします。管理クラスタがすでに HA の場合は、同じ値を維持します。非 HA 管理クラスタから HA 管理クラスタに移行する場合は、loadBalancer.vips.controlPlaneVIPフィールドの値を割り振り済みの IP アドレスに変更します。loadBalancer.f5BigIPセクション全体を削除します。
次の管理クラスタ構成ファイルの例は、これらの変更を示しています。
loadBalancer: vips: controlPlaneVIP: 192.0.2.6 kind:"F5BigIP""ManualLB"f5BigIP: address: "203.0.113.20" credentials: fileRef: path: ""my-config-folder/user-creds.yaml" entry: "f5-creds" partition: "my-f5-user-partition"
Seesaw
管理クラスタで Seesaw ロードバランサを使用している場合は、管理クラスタ構成ファイルに次の変更を加えます。
loadBalancer.kindフィールドを「MetalLB」に設定します。network.hostConfigセクションはそのままにします。loadBalancer.vips.controlPlaneVIP]5 フィールドの値を設定するか、そのままにします。管理クラスタがすでに HA の場合は、同じ値を維持できます。非 HA 管理クラスタから HA 管理クラスタに移行する場合は、loadBalancer.vips.controlPlaneVIPフィールドの値を割り振り済みの IP アドレスに変更します。loadBalancer.seesawセクションを削除します。
次の管理クラスタ構成ファイルの例は、これらの変更を示しています。
network: hostConfig: dnsServers: - "203.0.113.1" - "203.0.113.2" ntpServers: - "203.0.113.3" loadBalancer: vips: controlPlaneVIP: 192.0.2.6 kind: "MetalLB""Seesaw"seesaw: ipBlockFilePath: "user-cluster-1-ipblock.yaml" vrid: 1 masterIP: "" cpus: 4 memoryMB: 3072
非 HA から HA への移行を準備する
管理クラスタが HA でない場合、このセクションの手順に沿って HA への移行を準備します。
管理クラスタがすでに HA の場合は、次のセクションの管理クラスタを移行するに進みます。
管理クラスタのバージョンが 1.29.0 ～ 1.29.600 または 1.30.0 ～ 1.30.100 で、バージョン 1.14 以前の管理クラスタで Secret の常時暗号化が有効になっている場合は、移行を開始する前に暗号鍵をローテーションする必要があります。そうしないと、新しい HA 管理クラスタは Secret を復号できません。
クラスタが古い暗号鍵を使用しているかどうかを確認するには:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret -n kube-system admin-master-component-options -o jsonpath='{.data.data}' | base64 -d | grep -oP '"GeneratedKeys":\[.*?\]'
次の例のように、出力に空の鍵が表示された場合は、この既知の問題の手順に沿って暗号鍵をローテーションする必要があります。
"GeneratedKeys":[{"KeyVersion":"1","Key":""}]
管理クラスタの構成ファイルを更新する
管理クラスタ構成ファイルに次の変更を加えます。
network.controlPlaneIPBlockに、コントロール プレーン ノードに割り振った 3 つの IP アドレスを入力します。network.hostConfigセクションに入力されていることを確認します。このセクションには、クラスタノードである VM で使用される NTP サーバー、DNS サーバー、DNS 検索ドメインに関する情報を掲載しています。loadBalancer.vips.controlPlaneVIPの値は、割り振った IP アドレスに置き換えてください。adminMaster.replicasを 3 に設定します。vCenter.dataDiskフィールドを削除します。HA 管理クラスタの場合、コントロール プレーン ノードで使用される 3 つのデータディスクのパスは、データストアのルート ディレクトリanthosの下に自動的に生成されます。loadBalancer.kindが"ManualLB"に設定されている場合は、loadBalancer.manualLB.controlPlaneNodePortを 0 に設定します。
次の管理クラスタ構成ファイルの例は、これらの変更を示しています。
vCenter: address: "my-vcenter-server.my-domain.example" datacenter: "my-data-center"dataDisk: "xxxx.vmdk"... network: hostConfig: dnsServers: - 203.0.113.1 - 203.0.113.2 ntpServers: - 203.0.113.3 ... controlPlaneIPBlock: netmask: "255.255.255.0" gateway: "198.51.100.1" ips: - ip: "192.0.2.1" hostname: "admin-cp-hostname-1" - ip: "192.0.2.2" hostname: "admin-cp-hostname-2" - ip: "192.0.2.3" hostname: "admin-cp-hostname-3" ... ... loadBalancer: vips: controlPlaneVIP:192.0.2.6192.0.2.50 kind: ManualLB manualLB:controlPlaneNodePort: 300030 ... adminMaster: replicas: 3 cpus: 4 memoryMB: 8192 ...
必要に応じてロードバランサのマッピングを調整する
管理クラスタで手動ロード バランシングを使用している場合は、このセクションの手順を完了します。
統合 F5 BIG-IP から手動ロード バランシングに移行する場合、または MetalLB に移行する場合は、次のセクションの管理クラスタを移行するに進みます。
network.controlPlaneIPBlock セクションで指定した 3 つの新しいコントロール プレーン ノードの IP アドレスごとに、外部ロードバランサ（F5 BIG-IP や Citrix など）でこのマッピングを構成します。
(old controlPlaneVIP:443) -> (NEW_NODE_IP_ADDRESS:old controlPlaneNodePort)
これにより、移行中に古いコントロール プレーン VIP が引き続き機能します。
管理クラスタを移行する
管理クラスタ構成ファイルに加えたすべての変更を慎重に確認します。移行のためにクラスタを更新する場合を除き、すべての設定は不変です。
クラスタを更新します。
gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--config ADMIN_CLUSTER_CONFIG
Replace the following:
ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。ADMIN_CLUSTER_CONFIG: 管理クラスタ構成ファイルのパス
コマンドにより、移行の進行状況が表示されます。
指示に従って、「Y」と入力して次に進みます。
HA 以外のクラスタから HA クラスタに移行する間、古いコントロール プレーン VIP は引き続き機能し、新しい HA 管理クラスタへのアクセスに使用できます。移行が完了すると、新しいコントロール プレーン VIP を使用するように管理クラスタの kubeconfig ファイルが自動的に更新されます。
移行後
更新が完了したら、管理クラスタが実行されていることを確認します。
kubectl get nodes --kubeconfig ADMIN_CLUSTER_KUBECONFIG
想定される出力は次のようになります。
ロードバランサの移行
ロードバランサを移行した場合は、ロードバランサ コンポーネントが正常に実行されていることを確認します。
MetalLB
MetalLB に移行した場合は、次のコマンドを使用して MetalLB コンポーネントが正常に実行されていることを確認します。
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods \
--namespace kube-system --selector app=metallb
出力には、MetalLB コントローラとスピーカーの Pod が表示されます。次に例を示します。
metallb-controller-744884bf7b-rznr9 1/1 Running
metallb-speaker-6n8ws 1/1 Running
metallb-speaker-nb52z 1/1 Running
metallb-speaker-rq4pp 1/1 Running
移行が正常に完了したら、管理クラスタがパワーオフ状態の Seesaw VM を削除します。Seesaw VM 名は、構成ディレクトリの seesaw-for-gke-admin.yaml ファイルの vmnames セクションにあります。
ManualLB
手動ロード バランシングを使用するようにクラスタを更新した後も、クラスタへのトラフィックは中断されません。これは、次のコマンドを実行するとわかるように、既存の F5 リソースがまだ存在するためです。
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
想定される出力は次のようになります。
Warning: v1 ComponentStatus is deprecated in v1.19+
NAMESPACE NAME TYPE DATA AGE
kube-system secret/bigip-login-xt697x Opaque 4 13h
NAMESPACE NAME SECRETS AGE
kube-system serviceaccount/bigip-ctlr 0 13h
kube-system serviceaccount/load-balancer-f5 0 13h
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE
kube-system deployment.apps/k8s-bigip-ctlr-deployment 1/1 1 1 13h
kube-system deployment.apps/load-balancer-f5 1/1 1 1 13h
NAME ROLE AGE
clusterrolebinding.rbac.authorization.k8s.io/bigip-ctlr-clusterrole-binding ClusterRole/bigip-ctlr-clusterrole 13h
clusterrolebinding.rbac.authorization.k8s.io/load-balancer-f5-clusterrole-binding ClusterRole/load-balancer-f5-clusterrole 13h
NAME CREATED AT
clusterrole.rbac.authorization.k8s.io/bigip-ctlr-clusterrole 2024-03-25T04:37:34Z
clusterrole.rbac.authorization.k8s.io/load-balancer-f5-clusterrole 2024-03-25T04:37:34Z