Google Kubernetes Engine(GKE)勉強会

205 Views

August 30, 21

スライド概要

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

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

profile-image

クラウドCoEの何でも屋と呼ばれてました。クラウド資格いっぱい持ってます。ありがたいことに2021年から3年連続でJapan AWS Top Engineersなどに選出いただきました。とはいえAzureもGoogle Cloudも得意です。SRE/FinOpsなどの方法論の普及啓発にも力を入れてます。好きなものは赤いスポーツカーとロックミュージック、趣味は投資と仕事です(え?w

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

Google Kubernetes Engine(GKE)勉強会 クラウド技術情報共有コミュニティ勉強会 2021年8月30日 株式会社 日立製作所 / Software CoE / クラウドビジネス推進センタ 松沢 敏志 © Matt. 2021. All rights reserved.

2.

自己紹介 一言でいうと 日立のクラウド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/)をご参照ください。 © Matt. 2021. All rights reserved. 1

3.

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

4.

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

5.

Kubernetesとは クーバネティス Kubernetes (略称は”k8s”) =ザックリ言えば、コンテナ群を複数ホスト上で動かそう/管理しよう って思ったときに必要となる機能が詰まったソフトウェア キーワード: Google発祥、GO言語 © Matt. 2021. All rights reserved. 4

6.

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

7.

主要なk8sリソースと相関関係 Deployment StatefulSet 作成/更新/削除 作成/更新/削除 ReplicaSet 作成/更新/削除 Pod Pod Pod Container 更新 Horizontal Pod Autoscaler Service 負荷分散(L4 LB) Ingress 負荷分散(L7 LB) Volumeマウント Persistent Volume Claim Persistent Volume アサイン/動的割当 ConfigMap Secret 外部ストレージ © Matt. 2021. All rights reserved. 6

8.

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

9.

Google Kubernetes Engine(GKE)とは ジーケーイー Google Kubernetes Engine (略称は”GKE”) ➢ Googleが提供するKubernetesのマネージドサービス ➢ Control PlaneはGoogle管理、ユーザは原則Nodeのみの管理でOK ➢ Load Balancer/Logging/Monitor/Network Securityなどの Google Cloudサービスとネイティブにインテグレーション = k8sリソースを作るとこれらのサービスが裏で自動的に設定されて使われてっぞ!という意味 © Matt. 2021. All rights reserved. 8

10.

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

11.

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

12.

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

13.

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

14.

クラスタのロケーションタイプはどれを選ぶのが良いか (Control Planeの)ロケーションタイプ ゾーン ➢ Control Planeをシングルゾーンに展開、Control PlaneのSLAは99.5% ➢ NodeはControl Planeと同じゾーンのみ(デフォルト)、もしくはマルチゾーンへの展開が可能 ➢ シングルゾーンにするとゾーン間通信が発生しないのでお試しでコスト安く使いたい場合に有用 リージョン 推奨 ➢ Control Planeもリージョン内の3つのゾーンに展開、Control PlaneのSLAは99.95% ➢ Nodeは3つのゾーンへ展開する(デフォルト) © Matt. 2021. All rights reserved. 13

15.

Control Planeのバージョンはどれを選ぶのが良いか コントロールプレーンのバージョン 静的バージョン ➢ 現実解 リリースチャンネルの採用が困難、独自ルールに従ってNodeのアップグレードをやりたいというケースで利用 (例えばバージョン2つは適用を見送ってサポート切れるタイミングのみで一気にアップグレードv1.19→v1.20→v1.21させるとか、詳細はアップブレード戦略にて) リリースチャンネル Stableチャンネル ➢ 推奨 2021/09/15追記 Googleサポートよりオンプレや他クラウド上のk8sはNGだが、 GKE限定でk8sの古いマイナーVerもASMをサポートするのでStableでもOKとのこと。 バグなどが枯れた古いバージョン、更新頻度は数か月に1回程度 ※但しASMなどの一部機能は未サポート Regularチャンネル(デフォルト) ➢ メモ: アップストリームがv1.22 だったとして、各々のバー ジョンは次のような感じ。 GKE機能を最大限に活用できるバージョン、更新頻度は1か月に複数回程度 Rapidチャンネル ➢ ・Rapid:v1.20~1.21系 ・Regular:v1.20系 ・Stable:v1.19系 最新機能を使いたいときに活用するチャンネル、更新頻度の目安は毎週 アルファクラスタ ➢ ベータより前のアルファ機能を体験したいときに活用、作ってから30日で有効期限が切れる © Matt. 2021. All rights reserved. 14

16.

クラスタタイプはどれを選ぶのが良いか クラスタタイプ 一般公開クラスタ ➢ Control PlaneにもNodeにもパブリックIPアドレスを付与するクラスタ 限定公開クラスタ ➢ 推奨 NodeのIPアドレスをプライベートIPアドレスのみとするクラスタ 一般公開クラスタと比較して、よりセキュアな運用が可能 © Matt. 2021. All rights reserved. 15

17.

ご参考、一般公開クラスタ Docker Hubからイメージ取ってきてぱっとお試しする程度なら NodeにパブリックIPついてた方が便利だけどお勧めはしないよ! © Matt. 2021. All rights reserved. 16

18.

ご参考、限定公開クラスタ 外からNodeにログインしたいならIAPを使おう! © Matt. 2021. All rights reserved. 17

19.

ご参考、限定公開クラスタ(Podへのインバウンド通知) © Matt. 2021. All rights reserved. 18

20.

ご参考、限定公開クラスタ(Podからのアウトバウンド通知) ポイント1 Docker Hubとか Container Registryとか ポイント2 © Matt. 2021. All rights reserved. 19

21.

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

22.

ご参考、パブリックエンドポイント+承認済みネットワーク © Matt. 2021. All rights reserved. 21

23.

ご参考、プライベートエンドポイント © Matt. 2021. All rights reserved. 22

24.

小ネタ、Control Planeへのk8s API接続編 ◼ Public Endpoint型のControl PlaneにPrivate Endpoint経由でアクセスする方法 ➢ 基本的に、接続するGKEクラスタのクレデンシャル情報を取得してからkubectlを実行、という流れになるが、 クレデンシャル情報を取得するコマンドgcloud container cluster get-credentialsを実行する際に --internal-ip オプションを付与して実行するだけ。 © Matt. 2021. All rights reserved. 23

25.

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

26.

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

27.

コンテナイメージはどうするのが良いか ベースOS ➢ 開発のしやすさ、保守のしやすさなどを元に選定するのが良いかと思います。 マネージドベースイメージ ➢ 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 Java ➢ AWSではCorretto、AzureではZuluといったものが用意されているがGoogle Cloudには同等機能がない、、、 結局、有償だが保守がしっかりしているであろうOracle?いやいやOpenJDKで十分?の判断はPJ次第になってまうな、と。 © Matt. 2021. All rights reserved. 26

28.

サービスメッシュにはIstioとASMのどっちを選ぶのが良いか サービスメッシュ Istio on GKE ➢ コミュニティ版のIstioをGKEにインストールして利用することができる(GKEのオプションで有効化するだけ) ➢ 現時点ではベータ機能なのでプロダクション用途には向かない Anthos Service Mesh(ASM) ➢ 推奨 Googleが手を加えたIstioを使ったマネージドサービス、Istio APIと互換あり ASMのインストール方法 asmcliコマンド(プレビュー)を使用したインストール ➢ https://cloud.google.com/service-mesh/docs/unified-install/asmcli-overview?hl=ja install_asmスクリプトを使用したインストール ➢ 推奨 https://cloud.google.com/service-mesh/docs/scripted-install/asm-onboarding?hl=ja © Matt. 2021. All rights reserved. 27

29.

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

30.

アップグレードの基礎 リリースサイクル ➢ Kubernetesは~4か月ごとに最新マイナーバージョンをリリース、パッチは~1か月ごとにリリース ➢ GKEはKubernetesのリリースに加えて、独自にセキュリティおよびバグ修正を提供 1.20.8-gke.2100 マイナーバージョン GKE独自パッチバージョン パッチバージョン GKEのバージョンポリシー ➢ NodeはControl Planeよりも新しいバージョンは利用できない ➢ NodeはControl Planeから2マイナーバージョン古いものまで利用可能 © Matt. 2021. All rights reserved. 29

31.

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

32.

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

33.

Nodeのアップグレードの流れ © Matt. 2021. All rights reserved. 32

34.

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

35.

新しいアップブレードへの気づき方 1. GKEのリリースノートをRSSフィードを使ってウォッチする 2. get-server-config APIを使ってavailable versionとdefault versionをウォッチする 3. Cloud Pub/SubでNotificationメッセージを受け取る ➢ 推奨 Cloud Functionsと組み合わせてチャットツールへの通知可能 © Matt. 2021. All rights reserved. 34

36.

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

37.

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

38.

GKE Autopilotとは GKEの新しいモード、従来のGKE Standardと比較して以下の特徴がある ➢ (Control Planeも)Nodeもフルマネージド ➢ Pod単位の課金 ➢ Pod単位のSLA ➢ Control Planeは99.95% ➢ Podは99.9%(2つ以上のゾーン展開) © Matt. 2021. All rights reserved. 37

39.

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

40.

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

41.

ユースケース 基本的に何でも行けるけど、特徴を考えると以下のユースケースに特にハマる(らしい) ➢ バッチ ➢ 非同期のワーカー ➢ オートスケールの早さをそこまで求めないワークロード ➢ 大量のリクエストトラフィックをさばかないワークロード ➢ 開発、テスト環境用途 ➢ ステートレス など © Matt. 2021. All rights reserved. 40

42.

GKE Autopilot vs GKE Standard もっと詳しい表が公式ドキュメントにあるよ!! © Matt. 2021. All rights reserved. 41

43.

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

44.

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

45.

END Google Kubernetes Engine(GKE)勉強会 クラウド技術情報共有コミュニティ勉強会 2021年8月30日 株式会社 日立製作所 / Software CoE / クラウドビジネス推進センタ 松沢 敏志 © Matt. 2021. All rights reserved.