Google Kubernetes Engine（GKE）勉強会

2021年8月30日のクラウド技術情報共有コミュニティ勉強会の資料です。本セッションでは、Google CloudのマネージドKubernetesサービスであるGoogle Kubernetes Engine（GKE）について紹介します。

※本資料に含まれる内容は勉強会当時の情報であり、最新の情報とは異なる場合があるためご注意ください。

Transcript

1. © Matt. 2021. All rights reserved. 株式会社 日立製作所 / Software CoE / クラウドビジネス推進センタ 2021年8月30日 松沢 敏志 Google Kubernetes Engine(GKE)勉強会 クラウド技術情報共有コミュニティ勉強会
2. © Matt. 2021. All rights reserved. 1 自己紹介 一言でいうと 日立のクラウドCoEチーム所属のソリューションアーキテクト、通称CCoEの何でも屋 所属 株式会社 日立製作所 / Software CoE / クラウドビジネス推進センタ 職歴 (※1) - 2007年に日立製作所入社以降、LinuxカーネルモジュールやOSSの開発エンジニア、 Red Hat製品のテクニカルサービス/サポートサービスL3エンジニア、 VMware/Microsoft製品を活用した国内HCIビジネス企画/立ち上げ、などを経験 - 2019年10-11月に米国FinTech系スタートアップにてデータ分析プログラムの開発 (インターン) - 2020年4月に日立グループのクラウドCoEチーム設立とともに異動、 クラウドアーキテクト/SREの役割でAWS/Azure/GCP案件に参画しての設計支援活動を中心に、 社内へのクラウド技術の普及活動、社外イベント講演などのプレゼンス向上活動にも従事 資格・受賞歴 (※1) - AWS認定資格12種コンプ、Azure認定資格6種、GCP認定資格3種など - 2021 APN AWS Top Engineer & APN ALL AWS Certifications Engineer受賞 その他 - 好きなものは真っ赤なスポーツカーとロックミュージック、趣味は投資と仕事 - 21年度目標は「国内初のGoogle Cloud Partner Top Engineerに、俺はなるっ!!!」 ※1：詳細はLinkedIn（https://www.linkedin.com/in/satoshi-matsuzawa-b209a1157/）をご参照ください。 まつざわ さとし 松沢 敏志
3. © Matt. 2021. All rights reserved. 2 本日のアジェンダ ⚫ Kubernetes/GKEの概要 ⚫ GKEのアーキテクチャ設計についての話 ⚫ GKEのトラフィック負荷分散はすごいんだぞという話 ⚫ GKEのアップグレード戦略についての話 ⚫ GKE Autopilotについての話 ⚫ Anthos Service Meshなどの拡張機能の話 ⚫ 他クラウドサービス比較の話 ⚫ まとめ
4. © Matt. 2021. All rights reserved. 3 本日のアジェンダ ⚫ Kubernetes/GKEの概要 ⚫ GKEのアーキテクチャ設計についての話 ⚫ GKEのトラフィック負荷分散はすごいんだぞという話 ⚫ GKEのアップグレード戦略についての話 ⚫ GKE Autopilotについての話 ⚫ Anthos Service Meshなどの拡張機能の話 ⚫ 他クラウドサービス比較の話 ⚫ まとめ
5. © Matt. 2021. All rights reserved. 4 Kubernetesとは Kubernetes クーバネティス (略称は”k8s”) ＝ザックリ言えば、コンテナ群を複数ホスト上で動かそう/管理しよう って思ったときに必要となる機能が詰まったソフトウェア キーワード: Google発祥、GO言語
6. © Matt. 2021. All rights reserved. 5 k8sのアーキテクチャ kubectl / API k8sの操作 APIの受付 データ保存 PodをNodeへ割当 Nodeのダウン検知、 Podのレプリカ数維持など Podへのネットワーク接続を簡易化するコンポーネント Nodeに割り当てられたPodを管理するエージェント コンテナを動かす container runtime (containerd/ dockerd)
7. © Matt. 2021. All rights reserved. 6 Pod Pod 主要なk8sリソースと相関関係 Deployment ReplicaSet Horizontal Pod Autoscaler StatefulSet Pod Container Persistent Volume Claim ConfigMap Secret Persistent Volume Service Ingress 作成/更新/削除 更新 作成/更新/削除 作成/更新/削除 Volumeマウント アサイン/動的割当 外部ストレージ 負荷分散(L4 LB) 負荷分散(L7 LB)
8. © Matt. 2021. All rights reserved. 7 k8sの機能を拡張するソフトウェア Istio ＝ サービスメッシュを実現するためのソフトウェア イスティオ Knative ＝ サーバレスを実現するためのソフトウェア ケイネイティブ マイクロサービス化が進むとサービスが増えてって依存関係にあるサービスの情報管理などに課題が。 Istioはマイクロサービス管理に役立つ様々な機能を提供してくれる。 余談、Istioを入れるとすべてのPodでサイドカーコンテナ(Envoy Proxy)が動き、 (kube-proxyと同様なイメージで)サービス間のネットワーク接続を簡素化してくれる。 つながった後の姿がメッシュ構造になっているからサービスメッシュといわれているようだ。 Nginxと似た機能を持つソフトウェア k8sのややこしいリソースを抽象化して、開発者がよりシンプルにアプリのビルド、デプロイ、管理を できるようにする機能を提供してくれる。 余談、Cloud Run(Google Cloudのサーバレスコンテナサービス)の実装にもこのソフトウェアが活用されているようですよ。 これ重要よ！
9. © Matt. 2021. All rights reserved. 8 Google Kubernetes Engine(GKE)とは Google Kubernetes Engine (略称は”GKE”) ➢ Googleが提供するKubernetesのマネージドサービス ➢ Control PlaneはGoogle管理、ユーザは原則Nodeのみの管理でOK ➢ Load Balancer/Logging/Monitor/Network Securityなどの Google Cloudサービスとネイティブにインテグレーション ジーケーイー = k8sリソースを作るとこれらのサービスが裏で自動的に設定されて使われてっぞ！という意味
10. © Matt. 2021. All rights reserved. 9 Google Cloudのk8s関連サービス Anthos ＝マルチクラウド/ハイブリッドクラウドで動作するKubernetesの 統合管理などをするためのGoogleが提供するサービス アンソス とはいえ、 Anthos Service Mesh(Googleが手を加えたIstioのフルマネージドサービス) などの機能拡張系サービスの ユースケースはGKE単体でもあるため、マルチ/ハイブリッドじゃなくても意識はしときましょう！
11. © Matt. 2021. All rights reserved. 10 Anthosが提供する機能 2. マイクロサービス管理機能 3. k8sクラスタ管理機能 1. GitOps的な機能/ポリシー(=セキュリティガードレール)管理機能 /GCPリソースをk8sマニフェストで管理する機能など ポイント: これらの機能は必ずしも全部使う必要はない、GKE+ASMだけ使うとかでもOK！ VMware vSphere環境に GKE On-Premのソフトウェアを入れる
12. © Matt. 2021. All rights reserved. 11 本日のアジェンダ ⚫ Kubernetes/GKEの概要 ⚫ GKEのアーキテクチャ設計についての話 ⚫ GKEのトラフィック負荷分散はすごいんだぞという話 ⚫ GKEのアップグレード戦略についての話 ⚫ GKE Autopilotについての話 ⚫ Anthos Service Meshなどの拡張機能の話 ⚫ 他クラウドサービス比較の話 ⚫ まとめ
13. © Matt. 2021. All rights reserved. 12 GKEの主要な設計ポイント ⚫ クラスタのロケーションタイプ（ゾーン vs リージョン） ⚫ Control Planeのバージョン（静的 vs リリースチャネル） ⚫ クラスタタイプ（一般公開 vs 限定公開） ➢ 限定公開時のインバウンド/アウトバウンド方式 ⚫ Control Planeのエンドポイントタイプ（Public vs Private） ➢ パブリック時のアクセス元IP制限 ⚫ Nodeの種類（OS、コンテナランタイム） ⚫ サービスメッシュ（Istio vs ASM）
14. © Matt. 2021. All rights reserved. 13 クラスタのロケーションタイプはどれを選ぶのが良いか (Control Planeの)ロケーションタイプ ゾーン リージョン ➢ Control Planeをシングルゾーンに展開、Control PlaneのSLAは99.5% ➢ NodeはControl Planeと同じゾーンのみ(デフォルト)、もしくはマルチゾーンへの展開が可能 ➢ シングルゾーンにするとゾーン間通信が発生しないのでお試しでコスト安く使いたい場合に有用 ➢ Control Planeもリージョン内の3つのゾーンに展開、Control PlaneのSLAは99.95% ➢ Nodeは3つのゾーンへ展開する(デフォルト) 推奨
15. © Matt. 2021. All rights reserved. 14 Control Planeのバージョンはどれを選ぶのが良いか コントロールプレーンのバージョン 静的バージョン リリースチャンネル Stableチャンネル Regularチャンネル(デフォルト) Rapidチャンネル アルファクラスタ 推奨 ➢ バグなどが枯れた古いバージョン、更新頻度は数か月に1回程度 ※但しASMなどの一部機能は未サポート ➢ GKE機能を最大限に活用できるバージョン、更新頻度は1か月に複数回程度 ➢ 最新機能を使いたいときに活用するチャンネル、更新頻度の目安は毎週 ➢ ベータより前のアルファ機能を体験したいときに活用、作ってから30日で有効期限が切れる ➢ リリースチャンネルの採用が困難、独自ルールに従ってNodeのアップグレードをやりたいというケースで利用 (例えばバージョン2つは適用を見送ってサポート切れるタイミングのみで一気にアップグレードv1.19→v1.20→v1.21させるとか、詳細はアップブレード戦略にて) 2021/09/15追記 Googleサポートよりオンプレや他クラウド上のk8sはNGだが、 GKE限定でk8sの古いマイナーVerもASMをサポートするのでStableでもOKとのこと。 現実解 メモ： アップストリームがv1.22 だったとして、各々のバー ジョンは次のような感じ。 ・Rapid：v1.20~1.21系 ・Regular：v1.20系 ・Stable：v1.19系
16. © Matt. 2021. All rights reserved. 15 クラスタタイプはどれを選ぶのが良いか クラスタタイプ 一般公開クラスタ 限定公開クラスタ ➢ NodeのIPアドレスをプライベートIPアドレスのみとするクラスタ 一般公開クラスタと比較して、よりセキュアな運用が可能 ➢ Control PlaneにもNodeにもパブリックIPアドレスを付与するクラスタ 推奨
17. © Matt. 2021. All rights reserved. 16 ご参考、一般公開クラスタ Docker Hubからイメージ取ってきてぱっとお試しする程度なら NodeにパブリックIPついてた方が便利だけどお勧めはしないよ！
18. © Matt. 2021. All rights reserved. 17 ご参考、限定公開クラスタ 外からNodeにログインしたいならIAPを使おう！
19. © Matt. 2021. All rights reserved. 18 ご参考、限定公開クラスタ（Podへのインバウンド通知）
20. © Matt. 2021. All rights reserved. 19 ご参考、限定公開クラスタ（Podからのアウトバウンド通知） ポイント2 ポイント1 Docker Hubとか Container Registryとか
21. © Matt. 2021. All rights reserved. 20 Control Planeのエンドポイントタイプはどれを選ぶのが良いか 限定公開クラスタにおけるControl Planeの2種類のエンドポイントタイプ パブリックエンドポイント プライベートポイント ➢ インターネット越しにアクセス可能 ※Cloud Shellなどからk8s APIアクセスさせるなら要パブリック化 ➢ 承認済みネットワーク機能によりアクセス元のIPを限定することが可能 ➢ GKEクラスタが存在するVPC内からしかアクセスできない とはいえ、承認済みネットワーク機能と組み合わせると設定が面倒なのでCloud Shellからの実行はあまりお勧めしない Poralから情報を見たりもできなくなっちゃうよ！ 一概にこれがお勧めとは言いにくいが以下のように選定するのが良いのではないだろうか ➢ 操作性を考えるとパブリック+承認済みネットワーク ➢ セキュリティガチガチにするならプライベート
22. © Matt. 2021. All rights reserved. 21 ご参考、パブリックエンドポイント+承認済みネットワーク
23. © Matt. 2021. All rights reserved. 22 ご参考、プライベートエンドポイント
24. © Matt. 2021. All rights reserved. 23 小ネタ、Control Planeへのk8s API接続編 ◼ Public Endpoint型のControl PlaneにPrivate Endpoint経由でアクセスする方法 ➢ 基本的に、接続するGKEクラスタのクレデンシャル情報を取得してからkubectlを実行、という流れになるが、 クレデンシャル情報を取得するコマンドgcloud container cluster get-credentialsを実行する際に --internal-ip オプションを付与して実行するだけ。
25. © Matt. 2021. All rights reserved. 24 その他ネットワーク関連の考慮すべきポイント VPCネイティブクラスタ/VPCネイティブトラフィックルーティングの有効化 ➢ 普通のk8sだとNodeへの振り分けとPodへの振り分けのところで2重で負荷分散していてちょっと無駄だし、 マルチゾーンクラスタだとゾーン間通信でお金も余計にかかる ➢ GKEではServiceの裏でNEGが動き、直接LBからPodへ振り分けを行うのでトラフィック性能が良くなる 推奨
26. © Matt. 2021. All rights reserved. 25 ノードの種類はどれを選ぶのが良いか OS Container-Optimized OS Ubuntu ➢ コンテナを動かすコンポだけを持つOS、スケールアウトが早い、ChromeOSベース コンテナランタイム Containerd Docker 推奨 推奨 Windows Red Hat系Linuxがないのがおそらく痛いと思う人が多いはず！
27. © Matt. 2021. All rights reserved. 26 コンテナイメージはどうするのが良いか ベースOS Java マネージドベースイメージ 上記以外 ➢ Googleが定期的にパッチを当てたイメージをmarketplace.gcr.ioに上げており、ユーザ側での定期メンテ工数が削れる。 個別のバグ修正みたいなサポートみたいなのは無さげ。対象はCentOS/Debian/Ubuntuのみ。 https://cloud.google.com/artifact-management/docs/managed-base-images#google-provided_base_images ➢ Container Registry/Artifact Registryの脆弱性スキャン機能があるのでこれのサポートOSは意識しておくのが吉。 サポートOSはDebian/Ubuntu/Alpine/CentOS/RHELのみ。 https://cloud.google.com/container-analysis/docs/container-scanning-overview#supported_versions ➢ 開発のしやすさ、保守のしやすさなどを元に選定するのが良いかと思います。 ➢ AWSではCorretto、AzureではZuluといったものが用意されているがGoogle Cloudには同等機能がない、、、 結局、有償だが保守がしっかりしているであろうOracle？いやいやOpenJDKで十分？の判断はPJ次第になってまうな、と。
28. © Matt. 2021. All rights reserved. 27 サービスメッシュにはIstioとASMのどっちを選ぶのが良いか サービスメッシュ Istio on GKE Anthos Service Mesh(ASM) ➢ Googleが手を加えたIstioを使ったマネージドサービス、Istio APIと互換あり ➢ コミュニティ版のIstioをGKEにインストールして利用することができる（GKEのオプションで有効化するだけ) ➢ 現時点ではベータ機能なのでプロダクション用途には向かない 推奨 ASMのインストール方法 asmcliコマンド(プレビュー)を使用したインストール install_asmスクリプトを使用したインストール 推奨 ➢ https://cloud.google.com/service-mesh/docs/unified-install/asmcli-overview?hl=ja ➢ https://cloud.google.com/service-mesh/docs/scripted-install/asm-onboarding?hl=ja
29. © Matt. 2021. All rights reserved. 28 本日のアジェンダ ⚫ Kubernetes/GKEの概要 ⚫ GKEのアーキテクチャ設計についての話 ⚫ GKEのトラフィック負荷分散はすごいんだぞという話 ⚫ GKEのアップグレード戦略についての話 ⚫ GKE Autopilotについての話 ⚫ Anthos Service Meshなどの拡張機能の話 ⚫ 他クラウドサービス比較の話 ⚫ まとめ
30. © Matt. 2021. All rights reserved. 29 アップグレードの基礎 リリースサイクル ➢ Kubernetesは~4か月ごとに最新マイナーバージョンをリリース、パッチは~1か月ごとにリリース ➢ GKEはKubernetesのリリースに加えて、独自にセキュリティおよびバグ修正を提供 GKEのバージョンポリシー ➢ NodeはControl Planeよりも新しいバージョンは利用できない ➢ NodeはControl Planeから2マイナーバージョン古いものまで利用可能 1.20.8-gke.2100 マイナーバージョン パッチバージョン GKE独自パッチバージョン
31. © Matt. 2021. All rights reserved. 30 アップグレードのパターン リリースチャンネルを利用したクラスタ ➢ 各チャンネルごとに設定された頻度に従い、Control PlaneもNodeも自動アップグレードされる ➢ 自動アップグレード自体は無効化できない ➢ 自動アップグレードを待たずに手動アップグレードすることが可能 静的バージョンを指定したクラスタ ➢ Control Planeは自動アップグレードされる（無効化できない） ➢ Nodeはデフォルトでは自動アップグレードが有効（無効化できる） ➢ Nodeの自動アップグレードを無効化した場合は、サポートが切れる前にユーザによる手動アップグレードが必要 ➢ アップグレードをする際はマイナーバージョンを飛ばすのは避けたほうが吉。
32. © Matt. 2021. All rights reserved. 31 メンテナンスの時間枠と除外 メンテナンス時間枠 ➢ 自動メンテナンスの実行を許可する定期的な時間枠 ➢ 14日周期で最低24時間の時間枠の確保が必要 ➢ 各時間枠は4時間以上の連続時間である必要あり メンテナンス除外 ➢ 自動メンテナンスの実行を禁止する定期的な時間枠 ➢ 除外期間は最大30日間 ➢ 1つのクラスタに付き3つまで指定可能
33. © Matt. 2021. All rights reserved. 32 Nodeのアップグレードの流れ
34. © Matt. 2021. All rights reserved. 33 サージアップグレードの設定とPod側で推奨される設定 サージアップグレードの早さを変える 最大サージ (デフォルト1) 古いバージョンのNodeからPodをEvictする際の影響を最小限にする オフライン上限 (デフォルト0) ➢ アップグレード中に追加可能なNode数、数を増やすほどアップグレードを早められる ➢ アップグレード中に使用不可になるNode数、数を増やすほど縮退を気にせずにガンガン更新させられる PodDisruptionBudget TerminationGracePeriodSeconds ➢ NodeのDrain時にEvictされるPodのあるべき状態(数)を明示的に指定することでサービス断の影響を減らす ➢ Evictのために古いNodeから当該Podを削除する際、強制終了(SIGKILL)まで指定した時間待機させることで、 安全にシャットダウンを行うことできる など
35. © Matt. 2021. All rights reserved. 34 新しいアップブレードへの気づき方 1. GKEのリリースノートをRSSフィードを使ってウォッチする 2. get-server-config APIを使ってavailable versionとdefault versionをウォッチする 3. Cloud Pub/SubでNotificationメッセージを受け取る ➢ Cloud Functionsと組み合わせてチャットツールへの通知可能 推奨
36. © Matt. 2021. All rights reserved. 35 本番環境で無理なくアップグレードしていくために 2. 自動アップグレードの前にテストを行う 3. なるべくStableチャンネルを使う 4. メンテナンス時間枠を正しく設定する 5. メンテナンス除外枠を正しく設定する ➢ テスト用クラスタを常設し、事前にテスト用クラスタで手動で最新バージョンにあげて動作確認をする ➢ バグもアップグレード頻度も少なめにする ➢ ビジネス時間と被らないようにする ➢ ビジネスのピークタイム (ECサイトのセールなど)は絶対に避けよう ワークフロー例 1. アップグレードの存在にいち早く気付く ➢ Pub/SubとCloud Functionsを設定してアップグレードのメッセージ通知をタイムリーに受け取る
37. © Matt. 2021. All rights reserved. 36 本日のアジェンダ ⚫ Kubernetes/GKEの概要 ⚫ GKEのアーキテクチャ設計についての話 ⚫ GKEのトラフィック負荷分散はすごいんだぞという話 ⚫ GKEのアップグレード戦略についての話 ⚫ GKE Autopilotについての話 ⚫ Anthos Service Meshなどの拡張機能の話 ⚫ 他クラウドサービス比較の話 ⚫ まとめ
38. © Matt. 2021. All rights reserved. 37 GKE Autopilotとは GKEの新しいモード、従来のGKE Standardと比較して以下の特徴がある ➢ (Control Planeも)Nodeもフルマネージド ➢ Pod単位の課金 ➢ Pod単位のSLA ➢ Control Planeは99.95% ➢ Podは99.9%（2つ以上のゾーン展開）
39. © Matt. 2021. All rights reserved. 38 Node管理の仕組み GKEが従来から持つ、Cluster auto-scaler(CA)とNode auto provisioning(NAP)を利用 同じサイズのNodeでスケールアウト Podの入るサイズでスケールアウト 逆に言えば、Nodeの作成や削除はPodのスケジューリングに依存している → Nodeをあらかじめ用意しておいてスパイクに備えるということは基本的にはできない
40. © Matt. 2021. All rights reserved. 39 その他注意点 AutopilotはNode管理しなくていいのでとっても便利な反面、制約もあるんです、、、 ➢ Privileged podは利用できない ➢ HostPortやHostNetworkは使えない ➢ NodeにSSHできない ➢ Nodeのパラメタチューニングできない ➢ Mutating Admission Webhookが使えない（これによりIstio/ASMが使えない) など
41. © Matt. 2021. All rights reserved. 40 ユースケース 基本的に何でも行けるけど、特徴を考えると以下のユースケースに特にハマる(らしい) ➢ バッチ ➢ 非同期のワーカー ➢ オートスケールの早さをそこまで求めないワークロード ➢ 大量のリクエストトラフィックをさばかないワークロード ➢ 開発、テスト環境用途 ➢ ステートレス など
42. © Matt. 2021. All rights reserved. 41 GKE Autopilot vs GKE Standard もっと詳しい表が公式ドキュメントにあるよ！！
43. © Matt. 2021. All rights reserved. 42 本日のアジェンダ ⚫ Kubernetes/GKEの概要 ⚫ GKEのアーキテクチャ設計についての話 ⚫ GKEのトラフィック負荷分散はすごいんだぞという話 ⚫ GKEのアップグレード戦略についての話 ⚫ GKE Autopilotについての話 ⚫ Anthos Service Meshなどの拡張機能の話 ⚫ 他クラウドサービス比較の話 ⚫ まとめ
44. © Matt. 2021. All rights reserved. 43 まとめ ⚫ GKEにはStandardとAutopilotの2つのモードがある ⚫ Standardは、設計要素が多いけれど柔軟な設計が可能 ⚫ Autopilotは、制約があるものの運用の複雑さの簡易化が可能 ⚫ 運用をうまく回すには事前のアップグレード戦略の作成がとっても重要 ⚫ GKEには他のクラウドにはない機能も入っていて魅力的 とはいえ、GKEはまだまだ成長段階！ 今日できなかったことが明日できるようになっていてもおかしくありませんし、 今日のベストプラクティスが明日のアンチパターンになっていてもおかしくありません！ ご利用の際は、常に最新の公式ドキュメントから情報を入手するように心がけましょう！
45. © Matt. 2021. All rights reserved. END Google Kubernetes Engine(GKE)勉強会 クラウド技術情報共有コミュニティ勉強会 2021年8月30日 株式会社 日立製作所 / Software CoE / クラウドビジネス推進センタ 松沢 敏志