Kubernetes マルチクラウド: フェデレーション、サブマリーナ、および統合管理
企業組織の 76% が複数のクラウド プロバイダーを使用しています (Flexera の現状 クラウド 2026)。ベンダーロックインを回避するためのものもあれば、要件に準拠するためのものもあります データ主権 (GDPR: 欧州における欧州データ)、その他災害復旧用 地理的な。その結果、複数の Kubernetes クラスターを管理する方法という同じ課題が生じます。 まるで単一のプラットフォームであるかのように、さまざまなクラウドに分散されていますか?
この記事では、次の戦略とツールについて説明します。 マルチクラウド Kubernetes フェデレーション: から サブマリーナー ネットワーキング用 クラスター間 (AWS 上のポッドが GCP 上のポッドと通信できるようにする)、例: アドミラルティ/リコ クラスタ間スケジューリングの場合、最大 フリートマネージャー e ArgoCD アプリケーションセット 管理用 単一のコントロール ポイントからの数十のクラスターの宣言。
何を学ぶか
- マルチクラスター モデル: アクティブ-アクティブ、アクティブ-パッシブ、フェデレーテッド
- Submariner: 異なるクラウド間のクラスター間オーバーレイ ネットワーク
- マルチクラスタ サービス検出のための MCS API を使用した ServiceExport/ServiceImport
- N 個のクラスターに展開するためのクラスター ジェネレーターを備えた ArgoCD ApplicationSet
- KubeAdmiral/Liqo: インテリジェントなクラスタ間ワークロード スケジューリング
- Rancher Fleet: 1000 以上のクラスターの一元管理
- マルチクラスター Istio: 異なるクラスター間で統合されたサービス メッシュ
- K8s マルチクラウドにおけるセキュリティとコンプライアンスの考慮事項
マルチクラスタアーキテクチャモデル
マルチクラスタリングに対する単一のアプローチはありません。選択は目的によって異なります。
| モデル | 説明 | 使用事例 |
|---|---|---|
| ハブアンドスポーク | ハブ クラスターは ArgoCD/Flux 経由でスポーク クラスターを管理します | 一元化された GitOps、ポリシー管理 |
| アクティブ-アクティブ | 複数のアクティブなクラスター、グローバル ロード バランサーでトラフィックを分散 | グローバル ユーザー向けの高可用性、低遅延 |
| アクティブ-パッシブ (DR) | プライマリ クラスタ + ディザスタ リカバリ クラスタ | ビジネス継続性、RTO/RPO の定義 |
| エッジ + セントラル | 中央クラスター + 地理的エッジクラスター | IoT、CDN ロジック、超低遅延 |
| データ主権 | GDPR の地域別クラスター (EU、米国、APAC) | 規制データのコンプライアンス |
サブマリーナー: クラスター間ネットワーキング
マルチクラスタリングの根本的な問題は、各クラスタが独自の IP 範囲を持っていることです。 ポッドとサービス。クラスター A のポッドはクラスター B のポッドに到達できません。 彼らは孤立している。 サブマリーナー 安全なオーバーレイ ネットワークを作成することでこれを解決します IPsec トンネルまたは WireGuard 経由でクラスタ間を接続します。
サブマリーナの設置
# Installa subctl (CLI di Submariner)
curl -Ls https://get.submariner.io | VERSION=0.17.0 bash
# Pre-requisiti: i cluster devono potersi raggiungere (IP pubblici o VPN)
# Imposta kubeconfig per entrambi i cluster
export KUBECONFIG=~/.kube/cluster-aws:~/.kube/cluster-gcp
# Prepara il cluster broker (uno dei cluster diventa il "broker" di coordinamento)
subctl deploy-broker --kubeconfig ~/.kube/cluster-aws
# Unisci il cluster AWS al broker (il cluster che diventa broker)
subctl join broker-info.subm --kubeconfig ~/.kube/cluster-aws \
--clusterid cluster-aws \
--cable-driver wireguard # WireGuard per performance, IPsec per compatibilita
# Unisci il cluster GCP al broker
subctl join broker-info.subm --kubeconfig ~/.kube/cluster-gcp \
--clusterid cluster-gcp \
--cable-driver wireguard
# Verifica la connessione inter-cluster
subctl show connections # mostra lo stato dei tunnel tra i cluster
subctl verify --kubeconfig ~/.kube/cluster-aws --toconfig ~/.kube/cluster-gcp --verbose
ServiceExport および ServiceImport: サービス検出マルチクラスター
Submariner がネットワークに接続した後、 マルチクラスタ サービス (MCS) API あるクラスターからサービスをエクスポートし、別のクラスターにインポートするには:
# Nel cluster GCP: esporta il database Service
# ServiceExport rende il Service visibile agli altri cluster
apiVersion: multicluster.x-k8s.io/v1alpha1
kind: ServiceExport
metadata:
name: postgres-primary
namespace: data-layer
---
# Nel cluster AWS: il Service appare automaticamente come ServiceImport
# (Submariner lo sincronizza tramite il broker)
# Il Service e raggiungibile come:
# postgres-primary.data-layer.svc.clusterset.local
# Test di connettivita cross-cluster
kubectl run -n app-layer --rm -it test-pod \
--image=postgres:16 \
-- psql -h postgres-primary.data-layer.svc.clusterset.local -U app -d mydb
# SubmarineER gestisce automaticamente il routing del traffico:
# Pod in cluster-aws -> tunnel WireGuard -> Pod in cluster-gcp
# con latenza aggiuntiva ~5-10ms (tunnel overhead)
マルチクラスター展開用の ArgoCD ApplicationSet
ArgoCD ApplicationSet と Cluster Generator を使用すると、同じアプリケーションをデプロイできます 単一のマニフェストを使用して ArgoCD に登録されているすべてのクラスター上で:
# Registra i cluster in ArgoCD
argocd cluster add cluster-aws --name production-aws
argocd cluster add cluster-gcp --name production-gcp
argocd cluster add cluster-azure --name production-azure
# Verifica cluster registrati
argocd cluster list
---
# applicationset-multi-cluster.yaml
# Deploya la stessa app su tutti i cluster con label environment=production
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: api-service-global
namespace: argocd
spec:
generators:
# Usa il Cluster Generator: genera un'Application per ogni cluster ArgoCD
- clusters:
selector:
matchLabels:
environment: production # filtra cluster con questo label
template:
metadata:
name: 'api-service-{{name}}' # {{name}} = nome del cluster
labels:
cluster: '{{name}}'
spec:
project: production
source:
repoURL: https://github.com/company/k8s-manifests
targetRevision: main
path: apps/api-service/production
kustomize:
# Personalizzazione per cluster specifici
patches:
- target:
kind: Deployment
name: api-service
patch: |-
- op: replace
path: /spec/replicas
value: '{{metadata.annotations.replicas | default "3"}}'
destination:
server: '{{server}}' # URL API server del cluster
namespace: api-service
syncPolicy:
automated:
prune: true
selfHeal: true
Rancher Fleet: 1000 以上のクラスターの管理
牧場主の艦隊 (Rancher プロジェクトの一部) を処理するように設計されています。 単一の GitOps コントロール プレーンを持つ数千のクラスター。そして特に役立つのが エッジ コンピューティング (IoT クラスター) および顧客ごとにクラスターを持つ組織の場合:
# Fleet usa il concetto di Bundle: un insieme di manifest da deployare
# e un GitRepo che definisce la sorgente Git
# gitrepo.yaml - registra il repo Git con Fleet
apiVersion: fleet.cattle.io/v1alpha1
kind: GitRepo
metadata:
name: company-apps
namespace: fleet-default
spec:
repo: https://github.com/company/k8s-manifests
branch: main
paths:
- apps/
targets:
# Deploya su tutti i cluster con label env=production
- name: production
clusterSelector:
matchLabels:
env: production
helm:
values:
replicaCount: 3
resources:
requests:
cpu: 250m
# Configurazione diversa per dev
- name: development
clusterSelector:
matchLabels:
env: development
helm:
values:
replicaCount: 1
---
# Verifica stato deploy su tutti i cluster
kubectl get bundles -A
kubectl get bundledeployments -A | grep -v Healthy # mostra solo problemi
Istio マルチクラスター: 統合サービス メッシュ
異なるクラスター上のサービス間の mTLS とトラフィック管理を有効にするには、Istio 共有メッシュを使用したマルチクラスター モードをサポートします。
# Istio multi-cluster con Primary-Remote topology
# Il cluster primario ha il control plane, il remote lo usa
# 1. Installa Istio sul cluster primario
istioctl install --set profile=default \
--set meshConfig.trustDomain=company.com \
--set values.pilot.env.EXTERNAL_ISTIOD=true
# 2. Crea il secret con le credenziali del cluster remote
istioctl x create-remote-secret \
--kubeconfig=~/.kube/cluster-gcp \
--name=cluster-gcp | kubectl apply -f -
# 3. Configura il cluster GCP per usare il control plane AWS
helm install istio-remote manifests/charts/istio-control/istio-discovery \
--set profile=remote \
--set values.global.remotePilotAddress=PILOT_EXTERNAL_IP \
-f kubeconfig.yaml
# Con Istio multi-cluster configurato:
# - mTLS automatico tra servizi su cluster diversi
# - Traffic routing cross-cluster con DestinationRule
# - Kiali mostra la topology completa multi-cluster
# VirtualService per routing intelligente multi-cluster:
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: api-service
spec:
hosts:
- api-service
http:
- route:
# 70% traffico cluster locale (latenza minore)
- destination:
host: api-service.production.svc.cluster.local
port:
number: 8080
weight: 70
# 30% traffico cluster GCP (per load balancing globale)
- destination:
host: api-service.production.svc.clusterset.local # MCS
port:
number: 8080
weight: 30
Cloudflare と AWS Global Accelerator によるグローバル負荷分散
# DNS-based Global Load Balancing con failover automatico
# Cloudflare Load Balancing con health checks per ogni cluster
# Regola Terraform per configurare il Global LB:
resource "cloudflare_load_balancer" "global_api" {
zone_id = var.cloudflare_zone_id
name = "api.company.com"
fallback_pool_id = cloudflare_load_balancer_pool.aws.id
default_pool_ids = [
cloudflare_load_balancer_pool.aws.id,
cloudflare_load_balancer_pool.gcp.id
]
steering_policy = "geo" # routing geografico
proxied = true
region_pools {
region = "EEU"
pool_ids = [cloudflare_load_balancer_pool.gcp_eu.id]
}
region_pools {
region = "WNAM"
pool_ids = [cloudflare_load_balancer_pool.aws_us.id]
}
}
resource "cloudflare_load_balancer_pool" "aws" {
name = "k8s-aws-production"
origins {
name = "aws-ingress"
address = var.aws_ingress_ip
enabled = true
weight = 1
}
health_check_id = cloudflare_load_balancer_monitor.http.id
}
resource "cloudflare_load_balancer_monitor" "http" {
type = "http"
path = "/health"
expected_codes = "200"
interval = 60
retries = 2
timeout = 5
}
マルチクラスターのバックアップと災害復旧
# Velero per backup cross-cluster
# Installa Velero su tutti i cluster con lo stesso backend S3
helm install velero vmware-tanzu/velero \
--namespace velero \
--create-namespace \
--set configuration.backupStorageLocation[0].name=aws-s3 \
--set configuration.backupStorageLocation[0].provider=aws \
--set configuration.backupStorageLocation[0].bucket=company-k8s-backups \
--set configuration.backupStorageLocation[0].config.region=eu-west-1
# Schedule backup giornaliero
apiVersion: velero.io/v1
kind: Schedule
metadata:
name: daily-backup
namespace: velero
spec:
schedule: "0 2 * * *" # ogni notte alle 2:00
template:
includedNamespaces:
- production
- data-layer
snapshotVolumes: true
ttl: 720h # mantieni per 30 giorni
# Restore su cluster GCP (DR)
velero restore create --from-backup daily-backup-20260901 \
--include-namespaces production \
--kubeconfig ~/.kube/cluster-gcp
マルチクラウド Kubernetes のセキュリティに関する考慮事項
マルチクラウドセキュリティチェックリスト
- 分離されたクラスターの認証情報: 各クラスターには独自のサービス アカウントがあります。クラスタ間で資格情報を共有しないでください
- 暗号化されたクラスター間通信: WireGuard または IPsec を備えた Submariner は、クラスター間で転送されるデータの機密性を保証します
- OPA による統合ポリシー: 一元化された OPA/ゲートキーパー レジストリを使用して、すべてのクラスタにわたって一貫したセキュリティ ポリシーを確保します
- 一元化された監査ログ: すべてのクラスターからの API 監査ログを中央の SIEM に集約します。
- GDPR ガバナンス: ネットワーク ポリシーとノード アフィニティを使用して、EU データが EU クラスタに残っているかどうかを定期的にテストします。
- 自動ローテーション証明書: 各クラスターの cert-manager を使用して、TLS 証明書のローテーションを自動化します。
結論: Kubernetes の大規模パス
これは、「Kubernetes at Scale」シリーズの最後の記事です。 12 の記事で詳しく説明します Cilium による高度なネットワーキングからエンタープライズ Kubernetes 運用の全範囲 eBPF、StatefulSet および CSI ドライバーを備えたストレージ、ステートフル ワークロードの Operator、 Karpenter による自動スケーリング、Istio によるサービス メッシュ、RBAC と OPA によるセキュリティ、 Submariner と Federation によるマルチクラウドまで。
マルチクラウド Kubernetes は目的地ではなく旅です。2 つのクラスターから始まります。 (おそらくプロダクション + DR)、Submariner や ArgoCD ApplicationSet などのツールが追加されます。 徐々にスケールします。重要なのは、安全なネットワークという強固な基盤の上に構築することです。 GitOps による状態の一貫性、統合された可観測性 - 追加前 マルチクラスターの複雑さ。
Kubernetes at Scale シリーズ全体
- 01 - Kubernetes ネットワーキング: CNI、eBPF を使用した Cilium、およびネットワーク ポリシー
- 02 - 永続ストレージ: CSI、PV、StorageClass、および StatefulSet
- 03 - Kubernetes オペレーター: CRD、コントローラー パターン、オペレーター SDK
- 04 - 自動スケーリング: HPA、VPA、KEDA、Karpenter
- 05 - サービス メッシュ: Istio 対 Linkerd、mTLS およびトラフィック管理
- 06 - セキュリティ: RBAC、ポッド セキュリティ標準、OPA ゲートキーパー
- 07 - マルチテナント: ネームスペース、リソース クォータ、および HNC
- 08 - AI と GPU のワークロード: デバイス プラグインとトレーニング ジョブ
- 09 - FinOps: 適正サイジング、スポット インスタンス、コスト削減
- 10 - ArgoCD を使用した GitOps: 宣言的デプロイとプログレッシブ ロールアウト
- 11 - 可観測性: Prometheus、Grafana、OpenTelemetry
- 12 - マルチクラウド: フェデレーション、サブマリーナ、および統合管理 (この記事)
関連シリーズ
- Terraform とコードとしてのインフラストラクチャ — Kubernetes クラスターのマルチクラウド プロビジョニング
- エッジコンピューティングとサーバーレス — マルチクラウドの拡張としてのエッジ クラスター
- DevSecOps — コードとしてのポリシーとマルチクラウド クラスタ全体にわたる均一なセキュリティ







