推奨機能へのクラスタの移行を計画する

概要

Google Distributed Cloud は、Kubernetes とその他の関連テクノロジーをベースにしています。これらのテクノロジーは、スケーラビリティ、パフォーマンス、セキュリティ、統合機能を向上させるため、更新と改善が継続的に行われています。これに伴い、Google Distributed Cloud でも適応と改善が継続的に行われています。

バージョン 1.30 では、大幅な変更と更新が実施されているため、以前のデプロイメントを移行して、向上した機能を利用することを強くおすすめします。このページでは、古い機能から最新の推奨機能に移行するメリットについて説明します。

各機能領域で、次のようなオプションがあります。

機能領域	おすすめのオプション	元のオプション
Container Network Interface（CNI）	Dataplane V2 （enableDataplaneV2: true）	Dataplane V1（Calico） （enableDataplaneV2: false）
ロードバランサ	ManualLB（F5 Big IP エージェントと連携） （loadBalancer.kind: "ManualLB"） MetalLB （loadBalancer.kind: "MetalLB"）	統合された F5 Big IP1 （loadBalancer.kind: "F5BigIP"） Seesaw （loadBalancer.kind: "Seesaw"）
管理クラスタのコントロール プレーン	高可用性（HA）管理クラスタ （adminMaster.replicas: 3）	非 HA 管理クラスタ （adminMaster.replicas: 1）
ユーザー クラスタのコントロール プレーン	Controlplane V2 （enableControlplaneV2: true）	kubeception ユーザー クラスタ （enableControlplaneV2: false）

^{1 統合 F5 BIG-IP: クラスタ構成ファイルの loadBalancer.f5BigIP セクションの loadBalancer.kind: "F5BigIP" と関連設定を参照してください。}

次の表に、管理クラスタとユーザー クラスタでのこれらの機能のサポート状況を示します。

クラスタタイプ	古い機能	新しいクラスタに追加	クラスタのアップグレードに対応	新機能への移行
バージョン 1.30
管理者	非 HA	×	はい	○
	Seesaw	×	はい	はい
	統合型 F5 Big IP	×	はい	○
ユーザー	kubeception	×	はい	○
	Seesaw	×	はい	はい
	統合型 F5 Big IP	×	はい	○
	Dataplane V1	×	はい	○
バージョン 1.29
管理者	非 HA	×	○	○（プレビュー）
	Seesaw	×	はい	はい
	統合型 F5 Big IP	はい	○	○（プレビュー）
ユーザー	kubeception	○	○	○（プレビュー）
	Seesaw	○	はい	はい
	統合型 F5 Big IP	はい	○	○（プレビュー）
	Dataplane V1	○	はい	×
バージョン 1.28
管理者	非 HA	×	はい	×
	Seesaw	×	はい	はい
	統合型 F5 Big IP	はい	はい	×
ユーザー	kubeception	○	はい	×
	Seesaw	○	はい	はい
	統合型 F5 Big IP	はい	はい	×
	Dataplane V1	○	はい	×

要点:

• バージョン 1.30 以降では、推奨される代替手段へのクラスタの移行にすべての移行ソリューションを利用できます。

• 新しいクラスタの作成で元の機能を利用できないバージョンは次のとおりです。

  • 管理クラスタ:

    • 非 HA コントロール プレーン: 1.28 以降
    • Seesaw ロード バランシング: 1.28 以降
    • 統合型 F5 Big IP: 1.30 以降

  • ユーザー クラスタ:

    • Kubeception: 1.30 以降
    • Seesaw: 1.30 以降
    • 統合型 F5 Big IP: 1.30 以降
    • Dataplane V1: 1.30 以降

• 既存のクラスタは、元の機能を使用してアップグレードできます。

ユーザー クラスタを Dataplane V2 に移行する

コンテナ ネットワーキング機能を提供する Container Network Interface（CNI）を選択できます（Calico または Dataplane V2）。Google の CNI 実装である Dataplane V2 は Cilium をベースにしており、Google Kubernetes Engine（GKE）と Google Distributed Cloud の両方で使用されます。

Dataplane V2 は、最適化された設計と効率的なリソース使用率を実現しています。特に、大規模なクラスタやネットワーク トラフィックの需要が高い環境では、ネットワーク パフォーマンスとスケーラビリティが向上します。最新の機能、ネットワーキング、処理能力を利用できるように、クラスタを Dataplane V2 に移行することを強くおすすめします。

バージョン 1.30 以降では、新しいクラスタを作成するための CNI オプションは Dataplane V2 のみです。

Calico から Dataplane V2 への移行には計画と調整が必要ですが、この移行は既存のワークロードでダウンタイムが発生しないように設計されています。Dataplane V2 に移行することで、次のメリットが得られます。

• パフォーマンスとスケーラビリティの向上: Dataplane V2 の最適化された設計と効率的なリソースの使用により、特に大規模なクラスタやネットワーク トラフィックの需要が高い環境では、ネットワーク パフォーマンスとスケーラビリティが向上します。これは IPTables ではなく EBPF を使用しているためで、これにより、BPF マップを使用してクラスタをスケーリングできます。

• 管理とサポートの簡素化: Google Distributed Cloud と GKE 全体で Dataplane V2 を標準化すると、一貫したツールとドキュメントを利用できるため、クラスタの管理とトラブルシューティングを簡素化できます。

• 高度なネットワーキング機能: EgressNAT などの高度なネットワーキング機能は、Dataplane V2 でのみサポートされています。今後のネットワーキング リクエストは Dataplane V2 レイヤに実装されます。

	移行前	移行後
kube-proxy	必須、自動的にデプロイされる	必須ではなく、デプロイされない
ルーティング	kube-proxy + iptables	eBPF

ロードバランサの種類を移行する

推奨されるロードバランサのタイプ（loadBalancer.kind）は "ManualLB" と "MetalLB" です。F5 BIG-IP や Citrix などのサードパーティ ロードバランサがある場合は、"ManualLB" を使用します。MetalLB ロードバランサを使用するバンドルされたロード バランシング ソリューションには "MetalLB" を使用します。

バージョン 1.30 以降では、これらが新しいクラスタを作成する際の唯一のオプションになります。統合 F5 Big IP またはバンドルされた Seesaw ロードバランサを使用する既存のクラスタには、"F5BigIP" 構成設定を "ManualLB" に移行するためのガイドと、バンドルされたロードバランサを Seesaw から MetalLB に移行するためのガイドが用意されています。

F5 BIG-IP ロードバランサの構成設定を移行する

統合された F5 Big IP を使用するクラスタを ManualLB に移行することを計画してください。統合された F5 Big IP は、ロードバランサ エージェントで F5 BIG-IP を使用します。ロードバランサ エージェントは、次の 2 つのコントローラで構成されます。

• F5 Controller（pod prefix: load-balancer-f5）: LoadBalancer タイプの Kubernetes Service を F5 Common Controller Core Library（CCCL）ConfigMap 形式に調整します。
• F5 BIG-IP CIS Controller v1.14（pod prefix: k8s-bigip-ctlr-deployment）: ConfigMap を F5 ロードバランサ構成に変換します。

元の統合 F5 Big IP には、次の制限があります。

• 表現力の制限: 統合された F5 Big IP では Service API の表現力が制限され、F5 BIG-IP の可能性を最大限に活用できません。このため、特定のニーズに合わせて BIG-IP コントローラを構成したり、アプリケーションに不可欠な F5 の高度な機能を利用できなくなります。
• レガシー コンポーネント: 現在の実装は、CCCL ConfigMap API や 1.x CIS などの古いテクノロジーに依存しています。これらのレガシー コンポーネントは、F5 の最新のサービスの進歩と互換性がない可能性があり、パフォーマンスの改善やセキュリティの強化の機会を逃す可能性があります。

統合型 F5 BIG-IP から ManualLB に移行した後の変更点は次のとおりです。

	移行前	移行後
F5 エージェント コンポーネント	F5 コントローラ OSS CIS コントローラ	F5 コントローラ（変更なし） OSS CIS コントローラ（変更なし）
F5 コンポーネントのバージョン アップグレード	F5 コンポーネントをアップグレードするには、クラスタをアップグレードする必要があります。使用可能なコンポーネント バージョンは、前述のとおり制限されています。	F5 コンポーネントのバージョンは必要に応じてアップグレードできます。
サービスの作成	F5 エージェントで対応	F5 エージェントで対応（変更なし）

Seesaw から MetalLB に移行する

MetalLB には、Seesaw と比較して次の利点があります。

• 管理の簡素化とリソースの削減: Seesaw とは異なり、MetalLB はクラスタノードで直接実行されるため、クラスタ リソースをロード バランシングに動的に使用できます。
• IP の自動割り当て: MetalLB コントローラが Service の IP アドレス管理を行うため、Service ごとに手動で IP アドレスを選択する必要はありません。
• LB ノード間のロード バランシング: 異なる Service の MetalLB のアクティブなインスタンスを異なるノードで実行できます。
• 機能の強化と将来性: MetalLB は積極的に開発されており、より広範な Kubernetes エコシステムと統合されているため、Seesaw と比較して将来性のあるソリューションです。MetalLB を使用すると、ロード バランシング テクノロジーの最新の進歩を活用できます。

	移行前	移行後
LB ノード	追加の Seesaw VM（クラスタ外）	クラスタ内 LB ノード（お客様の選択）
クライアント IP の保持	externalTrafficPolicy: Local を介して実現	DataplaneV2 DSR モードで実現
サービスの作成	手動で指定された Service IP	アドレスプールから自動的に割り当てられる Service IP

ユーザー クラスタを Controlplane V2 に移行し、管理クラスタを HA に移行する

ユーザー クラスタに推奨されるコントロール プレーンは Controlplane V2 です。Controlplane V2 では、コントロール プレーンはユーザー クラスタ自体の 1 つ以上のノードで実行されます。従来のコントロール プレーン（kubeception）では、ユーザー クラスタのコントロール プレーンが管理クラスタで実行されます。高可用性（HA）管理クラスタを作成するには、ユーザー クラスタで Controlplane V2 を有効にする必要があります。

バージョン 1.30 以降では、新しいユーザー クラスタで Controlplane V2 を有効にする必要があります。新しい管理クラスタは HA になります。レガシー コントロール プレーンを使用したユーザー クラスタのアップグレードは、HA 以外の管理クラスタのアップグレードと同様に引き続きサポートされます。

ユーザー クラスタを Controlplane V2 に移行する

これまで、ユーザー クラスタは kubeception を使用していました。バージョン 1.13 では、Controlplane V2 がプレビュー機能として導入され、バージョン 1.14 で一般提供に移行しました。バージョン 1.15 以降、Controlplane V2 はユーザー クラスタの作成のデフォルトとなります。バージョン 1.30 では唯一のオプションです。

kubeception と比較して、Controlplane V2 には次のメリットがあります。

• アーキテクチャの一貫性: 管理クラスタとユーザー クラスタは同じアーキテクチャを使用します。
• 障害の分離: 管理クラスタの障害は、ユーザー クラスタに影響しません。
• 運用の分離: 管理クラスタのアップグレードでユーザー クラスタのダウンタイムは発生しません。
• デプロイの分離: 管理クラスタとユーザー クラスタを、異なるトポロジ ドメインまたは複数のロケーションに配置できます。たとえば、エッジ コンピューティングのデプロイモデルでは、ユーザー クラスタが管理クラスタとは異なるロケーションにある場合があります。

移行中、既存のユーザー クラスタ ワークロードでダウンタイムは発生しません。基盤となる vSphere 環境によっては、Controlplane V2 への切り替え中にダウンタイムが若干発生する場合があります。移行プロセスでは、次の作業を行います。

• ユーザー クラスタに新しいコントロール プレーンを作成します。
• 古いコントロール プレーンから etcd データをコピーします。
• 既存のノードプール ノード（ワーカーノード）を新しいコントロール プレーンに移行します。

	移行前	移行後
コントロール プレーンの Kubernetes ノード オブジェクト	管理クラスタノード	ユーザー クラスタ ノード
Kubernetes コントロール プレーン Pod	管理クラスタの Statefulset / Deployment（ユーザー クラスタの Namespace）	ユーザー クラスタの静的 Pod（kube-system Namespace）
その他のコントロール プレーン Pod	管理クラスタの Statefulset / Deployment（ユーザー クラスタの Namespace）	ユーザー クラスタの Statefulset / Deployment（kube-system Namespace）
コントロール プレーン VIP	管理クラスタのロードバランサ サービス	keepalived + haproxy（ユーザー クラスタの静的 Pod）
Etcd データ	管理クラスタの永続ボリューム	データディスク
コントロール プレーン マシンの IP 管理	IPAM または DHCP	IPAM
コントロール プレーン ネットワーク	管理クラスタ VLAN	ユーザー クラスタ VLAN

HA 管理クラスタに移行する

これまで、管理クラスタは 1 つのコントロール プレーン ノードしか実行できなかったため、単一障害点のリスクが存在していました。非 HA 管理クラスタには、1 つのコントロール プレーン ノードに加えて、2 つのアドオンノードがあります。HA 管理クラスタには 3 つのコントロール プレーン ノードがあり、アドオンノードはありません。そのため、新しい管理クラスタに必要な VM の数は変わりませんが、可用性が大幅に向上します。バージョン 1.16 以降では、高可用性（HA）管理クラスタを使用できます。バージョン 1.28 では。これが新しいクラスタを作成する唯一のオプションになりました。

HA 管理クラスタに移行すると、次のようなメリットがあります。

• 信頼性と稼働時間の向上: HA 構成では単一障害点が排除されるため、コントロール プレーン ノードのいずれかで問題が発生しても、管理クラスタは引き続き動作できます。
• アップグレードと更新の操作性の向上: 管理クラスタのアップグレードと更新に必要なすべての手順が、個別の管理ワークステーションではなくクラスタ内で実行されるようになりました。これにより、管理ワークステーションへの最初のセッションが中断されても、アップグレードと更新が続行されます。
• クラスタ状態の信頼できる真の情報源: HA 以外の管理クラスタは、管理クラスタの状態を保存するために、帯域外のチェックポイント ファイルに依存します。一方、HA 管理クラスタは、最新のクラスタ状態を管理クラスタ自体に保存し、クラスタ状態について信頼できる情報源を提供します。

非 HA 管理クラスタを HA 管理クラスタに移行することもできます。この場合、ユーザー ワークロードのダウンタイムは発生しません。このプロセスにより、コントロール プレーンの切り替えに関連するダウンタイムや、既存のユーザー クラスタへの影響が最小限に抑えられます。移行プロセスでは、次の作業を行います。

• 新しい HA コントロール プレーンを作成します。
• 既存の非 HA クラスタから etcd データを復元します。
• ユーザー クラスタを新しい HA 管理クラスタに移行します。

	移行前	移行後
コントロール プレーン ノードのレプリカ	1	3
アドオンノード	2	0
データディスク サイズ	100GB * 1	25GB * 3
データディスクのパス	管理クラスタ構成ファイルの vCenter.dataDisk で設定します。	/anthos/[ADMIN_CLUSTER_NAME]/default/[MACHINE_NAME]-data.vmdk ディレクトリの下に自動生成されます。
コントロール プレーン VIP	管理クラスタ構成ファイルの loadBalancer.kind で設定します。	keepalived + haproxy
管理クラスタのコントロール プレーン ノードの IP アドレスの割り振り	network.ipMode.type に応じて、DHCP または静的	3 個の静的 IP アドレス

ロードバランサとコントロール プレーンの移行をグループ化する

通常、クラスタを更新する場合は、一度に 1 つの機能または設定のみを更新することをおすすめします。ただし、バージョン 1.30 以降では、ロードバランサとコントロール プレーンの両方の構成変更を移行にグループ化し、クラスタを 1 回だけ更新して両方の変更を加えることができます。

古い CNI を使用しているユーザー クラスタがある場合は、まず DataPlane V2 に移行する必要があります。その後、ロードバランサとコントロール プレーンの移行をグループ化できます。移行をグループ化すると、次のメリットがあります。

• よりシンプルなプロセス: コントロール プレーンとロードバランサの両方を移行する必要がある場合、通常はクラスタを 1 回だけ更新します。また、最初に移行する必要がある機能を決定する必要もありません。
• 全体的なダウンタイムを短縮する: 一部の移行ではコントロール プレーンのダウンタイムが発生するため、これらの移行を 1 つの更新オペレーションにグループ化すると、個別の更新を順番に行う場合と比較して、全体的なダウンタイムを短縮できます。

このプロセスは、クラスタの構成によって異なります。全体として、各クラスタの移行を次の順序で実行します。

1. 推奨される CNI である Dataplane V2 を使用するように各ユーザー クラスタを移行します。

   1. 構成を変更してユーザー クラスタを更新し、Calico から Dataplane V2 へのユーザー クラスタの移行をトリガーします。

2. 推奨されるロードバランサと Controlplane V2 を使用するように各ユーザー クラスタを移行します。

   1. 推奨のロードバランサ（MetalLB または ManualLB）を使用するように構成を変更します。
   2. 構成を変更して Controlplane V2 を有効にします。
   3. ユーザー クラスタを更新して、ロードバランサとコントロール プレーンを移行します。

3. 推奨されるロードバランサを使用してコントロール プレーンを高可用性にする管理クラスタを移行します。

   1. 推奨のロードバランサ（MetalLB または ManualLB）を使用するように構成を変更します。
   2. 構成を変更して、管理クラスタのコントロール プレーンを非 HA から HA に移行します。
   3. 管理クラスタを更新して、ロードバランサとコントロール プレーンを移行します。

4. HA 以外のコントロール プレーン VM のクリーンアップなど、省略可能なクリーンアップ手順を実行します。

管理クラスタとすべてのユーザー クラスタがバージョン 1.30 以降の場合は、グループ移行プロセスを使用できます。詳しい手順については、次のガイドをご覧ください。

• ユーザー クラスタを推奨機能に移行する
• 管理クラスタを推奨機能に移行する