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

概要

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 IP^1 （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.kind: "F5BigIP" とクラスタ構成ファイル内の loadBalancer.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" です。"ManualLB" は、サードパーティのロードバランサ（F5 BIG-IP や Citrix など）の場合に使用します。"MetalLB" は、MetalLB ロードバランサを使用する Google 提供のバンドル型ロード バランシング ソリューションの場合に使用します。

バージョン 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 エージェントで対応（変更なし）

注: 移行後も、F5 エージェントはクラスタ内のワークロードとして実行されるため、同じ方法で Service を作成できます。唯一の違いは、移行後に 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
データディスク サイズ	100 GB × 1	25 GB × 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 へのユーザー クラスタの移行がトリガーされます。

      注: このステップは、管理クラスタでは必要ありません。管理クラスタをバージョン 1.30 にアップグレードすると、クラスタが自動的に 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 以降の場合は、グループ移行プロセスを使用できます。詳しい手順については、以下のガイドをご覧ください。

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