概要
このページでは、バージョン 1.30 以降の管理クラスタを次の推奨機能に移行する方法について説明します。
ロードバランサの構成:
統合型 F5 BIG-IP ロードバランサの構成を
ManualLBに移行します。または
バンドルされた Seesaw ロードバランサを MetalLB に移行します。
非高可用性（HA）管理クラスタから HA 管理クラスタに移行します。HA 管理クラスタを使用すると、使用する VM の数が同じでも可用性が大幅に向上します。非 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.6192.0.2.50 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.6192.0.2.50 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":""}]
必要に応じて暗号鍵をローテーションする
前のセクションの手順で、暗号鍵をローテーションする必要があるとわかった場合は、次の手順で操作します。
管理クラスタ構成ファイルで
keyVersionの値をインクリメントします。管理クラスタを更新します。
gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config ADMIN_CLUSTER_CONFIG
これにより、新しいバージョン番号と一致する新しい鍵が作成され、各 Secret が再暗号化されて、古い Secret が安全に消去されます。後続のすべての新しい Secret は、新しい暗号鍵を使用して暗号化されます。
管理クラスタの構成ファイルを更新する
管理クラスタ構成ファイルで次の変更を行います。
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