🍠 酸いも甘いもある Shared VPC（共有VPC） GKE Autopilot を Shared VPC で構築する際の苦悩 Copyright © 3-shake, Inc. All Rights Reserved. 2024/2/22 【Google Cloud】GDG Tokyo Monthly Online Tech Talks - @866mfs

Whoami 前職では、AWS をメインとしたクラウドインフラ構築支援を実施する中で、2023 Japan AWS Jr.Champions も受賞 スリーシェイクに SRE として Join 後は Google Cloud や Kubernetes を中心としたアプリケー ションインフラの構築・運用を通して、カルチャー変革を含む Cloud Native な SRE 支援を実践中 Google Cloud の公式 User Community である「 Jagu'e'r 」の運営リードもしています Annosuke Yokoo 3-shake, inc (@866mfs)

Agenda 01. Shared VPC 02. Google Kubernetes Engine - Autopilot 03. GKE を Shared VPC 環境で構築する際の技術的奮闘 04. まとめ

おことわり 超ニッチな内容です！ なので、今後誰も使わないかもしれませんが温か い目で見ていただき、使う時に頭の片隅から引き 出してください🙏

Shared VPC （共有VPC） 01 Copyright © 3-shake, Inc. All Rights Reserved.

Shared VPC https://cloud.google.com/vpc/docs/shared-vpc?hl=ja#use_cases Google CloudのShared VPCを所有するプロジェクトを ホストプロジェクト、Shared VPC を利用するプロジェク トをサービスプロジェクトと呼ぶ Shared VPCを使用することで、ホストプロジェクトから 複数のサービスプロジェクトへのネットワークリソース の共有が可能となり、リソースの集中管理が実現でき る

Shared VPC のユースケース https://cloud.google.com/vpc/docs/shared-vpc?hl=ja#use_cases Shared VPCは、特に大規模な組織（エンプラ組織） や複数のチームが関与するプロジェクトでその価値 を発揮 例： 複数の開発チームが異なるプロジェクトを担当して いるが、全てのチームが共通のネットワークリソース （サブネット、IPアドレス範囲、ファイアウォールルー ルなど）にアクセスする必要がある場合

アーキテクチャユースケース ● Google Cloud 上に新規に構築する ● モノリシックなアプリケーション ○ 迅速に実現するという観点から Micro Service ではなく、汎用的かつシンプルな（ユニバーサル）モノリシック Web アプリケーションアーキテクチャを想定 ● Cloud Native な特性を持つアーキテクチャを目指すべく、コアとする Workload には Contaier ベースのものを選択 肢とする ● ホストプロジェクトは IaC 化されていない

アーキテクチャ構成図 Simple Web Application on Containers in Google Cloud

構築範囲 ネットワーク管理者（ネットワークチーム）

Google Kubernetes Engine - Autopilot 02 Copyright © 3-shake, Inc. All Rights Reserved.

Google Kubernetes Engine - Standard Google Cloud マネージドの Kubernetes 環境 ● Kubernetes 運用のベストプラクティスをマネージド サービスとして提供 ● アップグレードやバックアップと復元など、完全に自動 化されたクラスタライフサイクル管理 ● ノードの自動プロビジョニング ● ワークロードを簡単に移行できる自動ツール ● Google Cloud の各種サービスと統合されている

Google Kubernetes Engine - Autopilot ● Control plane に加えて Node も完全マネージドな Kubernetes クラスタ ● Workload ベースの考え方（ Pod 単位の課金 / Pod 単 位の SLA ） ● 本番ワークロードに適したベストプラクティスがデフォル ト構成 ● GKE の良さを踏襲しつつ、より運用レスを実現できる

Node も完全マネージドな状態とは？ これまで行っていた Node の運用を意識しない ● ワークロードの Toleration の設定 ● ワークロードに合わせたノードの プロビジョニング ● ノードのハードウェア定義からノード Taint の構成と適用 ● Node の作成、更新、削除は自動 ● バージョンアップグレードも自動 ユーザーは、より Kubernetes の中の世界に集中 することが可能に！

GKE Autopilot は制約もある （組み込みのセキュリティが充実しているという言い方もできるが ...） ● Privileged pod（特権コンテナ） は利用出来ない ● GKE がノードを管理するため hostNetwork は利用出来ない ● hostPath は /var/log 配下のみ許可 ● Node の sysctl / kubelet のパラメーターチューニングは出来ない ● Node への SSH アクセスをブロック ● Mutating Admission webhook は一部使えない , etc. 詳細は公式ドキュメント

GKE Autopilot は制約もある Node の作成、スケール、削除には従来の GKE が備えている、 Cluster autoscaler (CA) と Node auto provisioning (NAP) を使用 詳しくはこちらで解説されている Node の作成、削除は Pod のスケジューリングに依存している ● 余剰の Node を予め用意しておいてスパイクに備えるということは基本出来ない ● Node 上にスペースを作りにくいため、Pod の水平スケールと同時に Node のス ケールが走りやすい ○ 特にバージョン 1.28 より前の GKE の場合、Node あたりの Pod 数の上 限は 32 個となっているため Node のスケールが多くなることも Horizontal Pod Autoscaler (HPA) Cluster Autoscaler (CA) Node Auto Provisioning (NAP)

GKE Autopilot - Scaling workaround Balloon pods ● 余剰のノードを予め用意しておいて、ノードのスケールを発生せずに Pod をス ケジュールする https://wdenniss.com/gke-autopilot-spare-capacity イメージストリーミング ● コンテナイメージをリモートのファイルシステムから Lazy-pulling でダウンロード して Pod の起動時間を高速化する https://cloud.google.com/kubernetes-engine/docs/how-to/image-streaming?hl=ja Pod や Node を事前にスケールする ● トラフィックが増えるタイミングが予測可能な場合、事前に Pod のスケールを増 やすことで Node のスケールを行う https://cloud.google.com/kubernetes-engine/docs/tutorials/reducing-costs-by-scaling- down-gke-off-hours?hl=ja 01 02 03

GKEをShared VPC環境で構築する際の技術的奮闘 03 Copyright © 3-shake, Inc. All Rights Reserved.

VPC Service Controlsによる制限 https://cloud.google.com/vpc-service-controls/docs/overview?hl=ja VPC - SC（Service Controls） 境界外プロジェクトからの API アクセスをブロックする Shared VPC の場合だと・・・ ホストプロジェクトとサービスプロジェクトを同じ境界にいれる必 要がある ホストプロジェクトでの作業になるため、ネットワーク管理者に 依頼が必要😔

サービス アカウントの権限借用 サービス アカウントによる認証は、以下２つの方法 サービス アカウント キー ● キーを持つユーザーなら誰でもサービス アカウントを使って認証 を受けれてしまう ● それを回避するために、定期的ローテーションでキーを管理し、 API キーの制限を追加する必要がある サービス アカウントの権限借用 ● サービス アカウント キーへのアクセスは不要で、代わりに IAM 権 限を使用して、サービス アカウントの使用を承認 ● ユーザー アカウントに与える権限を減らすことが可能 ● ユーザーがサービス アカウントにアクセスする必要がなくなった ら、IAM で、そのサービス アカウントのリソースからユーザー ID を 削除するだけ ● AWS でいうと Assume Role のイメージ https://blog.g-gen.co.jp/entry/using-google-cloud-service-account-impersonation

サービス アカウントの権限借用 - terraform

GKE 用のサブネット設計 https://cloud.google.com/blog/ja/products/containers-kubernetes/ip-address-management-in-gke ※ GKE Autopilot（GKE: v1.27までは）では、NodeあたりのPod数の上限が32となっているため、 Standardモードより も広いCIDRが必要となるので設計に注意 https://cloud.google.com/kubernetes-engine/docs/how-to/flexible-pod-cidr?hl=ja#cidr_settings_for_clusters

TIPS : 不連続マルチPod CIDR https://cloud.google.com/kubernetes-engine/docs/how-to/multi-pod-cidr?hl=ja#how_discontiguous_multi-pod_cidr_works CIDRの拡張 ● SecondaryのIPが足らなければ、不連続マルチ Pod CIDRを使い、Node レベルで必要なIPアドレス を拡張する ● ちなみに、ServiceレベルのCIDR拡張はKubernetes 1.29 でアルファ機能として搭載されている ○ APIs to manage IP address ranges for Services (SIG Network) {#ip-address-range-apis}

他にも GKE で考慮すべきこと https://cloud.google.com/kubernetes-engine/docs/how-to/multi-pod-cidr?hl=ja#how_discontiguous_multi-pod_cidr_works ホストプロジェクトでFirewall Ruleを設定しないとGKE Nodeに対するヘルスチェックが通らない デフォルトFirewallルールでは、サービスプロジェクトに所属するGKEノードへのFirewallルールが許可されていないた め、ホストプロジェクトにFirewallルールを作成（こちらもネットワーク管理者への依頼が必要） 限定公開クラスタのPodのインターネット接続には、ホストプロジェクト内にCloud Natが必要 NodeのサブネットをホストプロジェクトのCloud Natのマッピングに含める必要がある 例えば、Docker Hubなど外部のレジストリからDockerコンテナを取得できるようにCloud NATの対象サブネットにノード のサブネットを追加（こちらもネットワーク管理者への依頼が必要） ip-masq-agent でSNATされるサブネットを設定する FWルールの関係でPodのIPではなくNodeのIPにNATする必要がある場合の設定 デフォルトでip-masq-agentがデプロイされていてNoSNATにいろいろ入っているため、必要に応じて削除

まとめ 04 Copyright © 3-shake, Inc. All Rights Reserved.

まとめ ● Shared VPCでGKEを構築する際には、さまざまな考慮すべき事項（苦悩）がある ● 特にネットワークを共有する GKE では、ホストプロジェクト ↔ サービスプロジェクト で考えることが多い ○ ここにサイロ化された組織だとコミュケーションコストや調整コストが乗ってきて単純な構築よりも負担がかかる ● ネットワークリソースの一元管理やサイロ化された組織での運用には合致している点もありますが、構築おける一定の 奮闘も必要であるということを理解した上で、取り組む必要がある ● そうはいっても、組織・サービスが多くなればなるほど Shared VPC による効果は大きい

Thank you Copyright © 3-shake, Inc. All Rights Reserved.