Google Kubernetes Engine（GKE）勉強会

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© 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/）をご参照ください。まつざわさとし松沢敏志

Slide 3

Slide 3 text

© Matt. 2021. All rights reserved. 2 本日のアジェンダ ⚫ Kubernetes/GKEの概要 ⚫ GKEのアーキテクチャ設計についての話 ⚫ GKEのトラフィック負荷分散はすごいんだぞという話 ⚫ GKEのアップグレード戦略についての話 ⚫ GKE Autopilotについての話 ⚫ Anthos Service Meshなどの拡張機能の話 ⚫ 他クラウドサービス比較の話 ⚫ まとめ

Slide 4

Slide 4 text

© Matt. 2021. All rights reserved. 3 本日のアジェンダ ⚫ Kubernetes/GKEの概要 ⚫ GKEのアーキテクチャ設計についての話 ⚫ GKEのトラフィック負荷分散はすごいんだぞという話 ⚫ GKEのアップグレード戦略についての話 ⚫ GKE Autopilotについての話 ⚫ Anthos Service Meshなどの拡張機能の話 ⚫ 他クラウドサービス比較の話 ⚫ まとめ

Slide 5

Slide 5 text

Slide 6

Slide 6 text

© Matt. 2021. All rights reserved. 5 k8sのアーキテクチャ kubectl / API k8sの操作 APIの受付データ保存 PodをNodeへ割当 Nodeのダウン検知、 Podのレプリカ数維持など Podへのネットワーク接続を簡易化するコンポーネント Nodeに割り当てられたPodを管理するエージェントコンテナを動かす container runtime (containerd/ dockerd)

Slide 7

Slide 7 text

© 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)

Slide 8

Slide 8 text

© Matt. 2021. All rights reserved. 7 k8sの機能を拡張するソフトウェア Istio ＝サービスメッシュを実現するためのソフトウェアイスティオ Knative ＝サーバレスを実現するためのソフトウェアケイネイティブマイクロサービス化が進むとサービスが増えてって依存関係にあるサービスの情報管理などに課題が。 Istioはマイクロサービス管理に役立つ様々な機能を提供してくれる。余談、Istioを入れるとすべてのPodでサイドカーコンテナ(Envoy Proxy)が動き、 (kube-proxyと同様なイメージで)サービス間のネットワーク接続を簡素化してくれる。つながった後の姿がメッシュ構造になっているからサービスメッシュといわれているようだ。 Nginxと似た機能を持つソフトウェア k8sのややこしいリソースを抽象化して、開発者がよりシンプルにアプリのビルド、デプロイ、管理をできるようにする機能を提供してくれる。余談、Cloud Run(Google Cloudのサーバレスコンテナサービス)の実装にもこのソフトウェアが活用されているようですよ。これ重要よ！

Slide 9

Slide 9 text

© 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リソースを作るとこれらのサービスが裏で自動的に設定されて使われてっぞ！という意味

Slide 10

Slide 10 text

© Matt. 2021. All rights reserved. 9 Google Cloudのk8s関連サービス Anthos ＝マルチクラウド/ハイブリッドクラウドで動作するKubernetesの統合管理などをするためのGoogleが提供するサービスアンソスとはいえ、 Anthos Service Mesh(Googleが手を加えたIstioのフルマネージドサービス) などの機能拡張系サービスのユースケースはGKE単体でもあるため、マルチ/ハイブリッドじゃなくても意識はしときましょう！

Slide 11

Slide 11 text

© Matt. 2021. All rights reserved. 10 Anthosが提供する機能 2. マイクロサービス管理機能 3. k8sクラスタ管理機能 1. GitOps的な機能/ポリシー(=セキュリティガードレール)管理機能 /GCPリソースをk8sマニフェストで管理する機能などポイント: これらの機能は必ずしも全部使う必要はない、GKE+ASMだけ使うとかでもOK！ VMware vSphere環境に GKE On-Premのソフトウェアを入れる

Slide 12

Slide 12 text

© Matt. 2021. All rights reserved. 11 本日のアジェンダ ⚫ Kubernetes/GKEの概要 ⚫ GKEのアーキテクチャ設計についての話 ⚫ GKEのトラフィック負荷分散はすごいんだぞという話 ⚫ GKEのアップグレード戦略についての話 ⚫ GKE Autopilotについての話 ⚫ Anthos Service Meshなどの拡張機能の話 ⚫ 他クラウドサービス比較の話 ⚫ まとめ

Slide 13

Slide 13 text

© Matt. 2021. All rights reserved. 12 GKEの主要な設計ポイント ⚫ クラスタのロケーションタイプ（ゾーン vs リージョン） ⚫ Control Planeのバージョン（静的 vs リリースチャネル） ⚫ クラスタタイプ（一般公開 vs 限定公開） ➢ 限定公開時のインバウンド/アウトバウンド方式 ⚫ Control Planeのエンドポイントタイプ（Public vs Private） ➢ パブリック時のアクセス元IP制限 ⚫ Nodeの種類（OS、コンテナランタイム） ⚫ サービスメッシュ（Istio vs ASM）

Slide 14

Slide 14 text

© 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つのゾーンへ展開する(デフォルト) 推奨

Slide 15

Slide 15 text

© 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系

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

© Matt. 2021. All rights reserved. 20 Control Planeのエンドポイントタイプはどれを選ぶのが良いか限定公開クラスタにおけるControl Planeの2種類のエンドポイントタイプパブリックエンドポイントプライベートポイント ➢ インターネット越しにアクセス可能 ※Cloud Shellなどからk8s APIアクセスさせるなら要パブリック化 ➢ 承認済みネットワーク機能によりアクセス元のIPを限定することが可能 ➢ GKEクラスタが存在するVPC内からしかアクセスできないとはいえ、承認済みネットワーク機能と組み合わせると設定が面倒なのでCloud Shellからの実行はあまりお勧めしない Poralから情報を見たりもできなくなっちゃうよ！一概にこれがお勧めとは言いにくいが以下のように選定するのが良いのではないだろうか ➢ 操作性を考えるとパブリック+承認済みネットワーク ➢ セキュリティガチガチにするならプライベート

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

© 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 オプションを付与して実行するだけ。

Slide 25

Slide 25 text

© Matt. 2021. All rights reserved. 24 その他ネットワーク関連の考慮すべきポイント VPCネイティブクラスタ/VPCネイティブトラフィックルーティングの有効化 ➢ 普通のk8sだとNodeへの振り分けとPodへの振り分けのところで2重で負荷分散していてちょっと無駄だし、マルチゾーンクラスタだとゾーン間通信でお金も余計にかかる ➢ GKEではServiceの裏でNEGが動き、直接LBからPodへ振り分けを行うのでトラフィック性能が良くなる推奨

Slide 26

Slide 26 text

© Matt. 2021. All rights reserved. 25 ノードの種類はどれを選ぶのが良いか OS Container-Optimized OS Ubuntu ➢ コンテナを動かすコンポだけを持つOS、スケールアウトが早い、ChromeOSベースコンテナランタイム Containerd Docker 推奨推奨 Windows Red Hat系Linuxがないのがおそらく痛いと思う人が多いはず！

Slide 27

Slide 27 text

© 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次第になってまうな、と。

Slide 28

Slide 28 text

© 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

Slide 29

Slide 29 text

© Matt. 2021. All rights reserved. 28 本日のアジェンダ ⚫ Kubernetes/GKEの概要 ⚫ GKEのアーキテクチャ設計についての話 ⚫ GKEのトラフィック負荷分散はすごいんだぞという話 ⚫ GKEのアップグレード戦略についての話 ⚫ GKE Autopilotについての話 ⚫ Anthos Service Meshなどの拡張機能の話 ⚫ 他クラウドサービス比較の話 ⚫ まとめ

Slide 30

Slide 30 text

© 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独自パッチバージョン

Slide 31

Slide 31 text

© Matt. 2021. All rights reserved. 30 アップグレードのパターンリリースチャンネルを利用したクラスタ ➢ 各チャンネルごとに設定された頻度に従い、Control PlaneもNodeも自動アップグレードされる ➢ 自動アップグレード自体は無効化できない ➢ 自動アップグレードを待たずに手動アップグレードすることが可能静的バージョンを指定したクラスタ ➢ Control Planeは自動アップグレードされる（無効化できない） ➢ Nodeはデフォルトでは自動アップグレードが有効（無効化できる） ➢ Nodeの自動アップグレードを無効化した場合は、サポートが切れる前にユーザによる手動アップグレードが必要 ➢ アップグレードをする際はマイナーバージョンを飛ばすのは避けたほうが吉。

Slide 32

Slide 32 text

© Matt. 2021. All rights reserved. 31 メンテナンスの時間枠と除外メンテナンス時間枠 ➢ 自動メンテナンスの実行を許可する定期的な時間枠 ➢ 14日周期で最低24時間の時間枠の確保が必要 ➢ 各時間枠は4時間以上の連続時間である必要ありメンテナンス除外 ➢ 自動メンテナンスの実行を禁止する定期的な時間枠 ➢ 除外期間は最大30日間 ➢ 1つのクラスタに付き3つまで指定可能

Slide 33

Slide 33 text

Slide 34

Slide 34 text

© Matt. 2021. All rights reserved. 33 サージアップグレードの設定とPod側で推奨される設定サージアップグレードの早さを変える最大サージ (デフォルト1) 古いバージョンのNodeからPodをEvictする際の影響を最小限にするオフライン上限 (デフォルト0) ➢ アップグレード中に追加可能なNode数、数を増やすほどアップグレードを早められる ➢ アップグレード中に使用不可になるNode数、数を増やすほど縮退を気にせずにガンガン更新させられる PodDisruptionBudget TerminationGracePeriodSeconds ➢ NodeのDrain時にEvictされるPodのあるべき状態(数)を明示的に指定することでサービス断の影響を減らす ➢ Evictのために古いNodeから当該Podを削除する際、強制終了(SIGKILL)まで指定した時間待機させることで、安全にシャットダウンを行うことできるなど

Slide 35

Slide 35 text

© 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と組み合わせてチャットツールへの通知可能推奨

Slide 36

Slide 36 text

© Matt. 2021. All rights reserved. 35 本番環境で無理なくアップグレードしていくために 2. 自動アップグレードの前にテストを行う 3. なるべくStableチャンネルを使う 4. メンテナンス時間枠を正しく設定する 5. メンテナンス除外枠を正しく設定する ➢ テスト用クラスタを常設し、事前にテスト用クラスタで手動で最新バージョンにあげて動作確認をする ➢ バグもアップグレード頻度も少なめにする ➢ ビジネス時間と被らないようにする ➢ ビジネスのピークタイム (ECサイトのセールなど)は絶対に避けようワークフロー例 1. アップグレードの存在にいち早く気付く ➢ Pub/SubとCloud Functionsを設定してアップグレードのメッセージ通知をタイムリーに受け取る

Slide 37

Slide 37 text

© Matt. 2021. All rights reserved. 36 本日のアジェンダ ⚫ Kubernetes/GKEの概要 ⚫ GKEのアーキテクチャ設計についての話 ⚫ GKEのトラフィック負荷分散はすごいんだぞという話 ⚫ GKEのアップグレード戦略についての話 ⚫ GKE Autopilotについての話 ⚫ Anthos Service Meshなどの拡張機能の話 ⚫ 他クラウドサービス比較の話 ⚫ まとめ

Slide 38

Slide 38 text

Slide 39

Slide 39 text

© Matt. 2021. All rights reserved. 38 Node管理の仕組み GKEが従来から持つ、Cluster auto-scaler(CA)とNode auto provisioning(NAP)を利用同じサイズのNodeでスケールアウト Podの入るサイズでスケールアウト逆に言えば、Nodeの作成や削除はPodのスケジューリングに依存している → Nodeをあらかじめ用意しておいてスパイクに備えるということは基本的にはできない

Slide 40

Slide 40 text

© Matt. 2021. All rights reserved. 39 その他注意点 AutopilotはNode管理しなくていいのでとっても便利な反面、制約もあるんです、、、 ➢ Privileged podは利用できない ➢ HostPortやHostNetworkは使えない ➢ NodeにSSHできない ➢ Nodeのパラメタチューニングできない ➢ Mutating Admission Webhookが使えない（これによりIstio/ASMが使えない) など

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

© Matt. 2021. All rights reserved. 42 本日のアジェンダ ⚫ Kubernetes/GKEの概要 ⚫ GKEのアーキテクチャ設計についての話 ⚫ GKEのトラフィック負荷分散はすごいんだぞという話 ⚫ GKEのアップグレード戦略についての話 ⚫ GKE Autopilotについての話 ⚫ Anthos Service Meshなどの拡張機能の話 ⚫ 他クラウドサービス比較の話 ⚫ まとめ

Slide 44

Slide 44 text

© Matt. 2021. All rights reserved. 43 まとめ ⚫ GKEにはStandardとAutopilotの2つのモードがある ⚫ Standardは、設計要素が多いけれど柔軟な設計が可能 ⚫ Autopilotは、制約があるものの運用の複雑さの簡易化が可能 ⚫ 運用をうまく回すには事前のアップグレード戦略の作成がとっても重要 ⚫ GKEには他のクラウドにはない機能も入っていて魅力的とはいえ、GKEはまだまだ成長段階！今日できなかったことが明日できるようになっていてもおかしくありませんし、今日のベストプラクティスが明日のアンチパターンになっていてもおかしくありません！ご利用の際は、常に最新の公式ドキュメントから情報を入手するように心がけましょう！