[Google Kubernetes Day 19] ユーザからみた Anthos GKE On-Prem の利用について NTT Ltd. Group 桑山 純弥 2019/09/03

Transcription

1 [Google Kubernetes Day 19] ユーザからみた Anthos GKE On-Prem の利用について NTT Ltd. Group 桑山 純弥 2019/09/03

2 桑山 純弥 NTT Ltd. Group 仕事 GCP 歴 趣味 好きな GCP Service : : : : クラウドサービスの企画業務 2年 筋トレ Anthos

3 当社について 2019 年 7 月に NTT コミュニケーションズ (以下 NTT Com) は NTT Ltd. と NTT コミュニケーションズに再編成されました 国内から海外まで End to End のワンストップでのサポートを NTT Com として 提供しつつ NTT グループとして海外における競争力を一層強化します

4 Next Tokyo 19 の説明について Google Cloud Next Tokyo 19 でも Anthos について話させて頂きました なぜ当社で kubernetes / Anthos を導入したかなどを説明していますので よろしければ 本日の説明と合わせて動画をご覧ください

5 01 GKE と GKE On-Prem について アジェンダ 02 環境構築について 03 ベストプラクティス 04 今後について

6 01 01 GKE と GKE On-Prem について

7 GKE / GKE On-Prem を使う前に アップデート情報に 常にアンテナを貼る. 組織的に学習する環境 を整備する. リーダーの理解を得る. 説明責任を果たす. Kubernetes の環境 や 関連ツールの 進化はとても早いです 常に知識をアップデートする必要があり ます Kubernetes の 導入は残念ながら 簡単ではないです. メリットを IT の経験が浅い人に説明する 機会が付きものだと思います 導入メリットや解決したい課題を 丁寧に説明を行なう必要があります 継続的に学習できること 学習する 文化を一緒に作っていきましょう.

8 GKE / GKE On-Prem 関連の最近のアップデート Google Kubernetes Engine, GKE On-Prem 双方で 多くのアップデートが常に走っています. Kubernetes 自体も独立してアップデートを繰り返しています. GKE On-Prem GKE Version Up 11 回 ( ) Admin Workstation の デプロイ仕様変更 Version Up 14回 ( ) 大阪リージョンが 利用可能に Monitoring / Logging の 仕様変更 Manual LB の サポート拡大 Kubernetes Monitoring のサポート Workload Identity が利用可能に Calico のサポート拡大と Ver.up Istio Ingress controller のサポートと Ver.up Cloud Run On GKE が 利用可能に コンテナランタイムの サポート拡大 & Ver.up

9 Managed kubernetes サービスに求めるもの Kubernetes のアップデート をサポートしているか 周辺ツールでのサポート / 統合のケイパビリティ ネットワーク / ストレージとの統 合 Kubernetes 自体のソフトェアアップデー トが早いので アップデートのサポートポ リシーだけでなく どのようにアップデー トするかを推奨しているかは非常に重要 なファクターになります CI / CD 周りのサポート や 認証 / 認可 の設定の容易さ メトリクス収集 など 商 用利用時に便利な機能をどのようにサ ポートしているかは重要です ベストプラ クティスがどのように掲示されているかや ユーザーベースのコミュニティの情報が 豊富なことも大事な点です 設計の時にネットワークとストレージが どのように提供されるかは注意してみる べき点です ロードバランサの選択 や 永続ストレー ジの有無や提供方法 などを事前に確認 しましょう

10 Managed Kubernetes として 重要なファクタと考えられる機能とGKE On-Prem の対応を以下に挙げます 機能 GKE On-Prem コメント VMマネジメント 統合して提供 VMも含めたデプロイをサポート LB の提供 F5 との統合をベース 他社製品に依存 (現時点) ネットワーク Calico NetworkPolicy もあり 永続ストレージ 現時点でサポートなし 今後に期待 IaaS vsphere or 3rd Party Cloud 現時点では vsphere のみ検証 / 冗長設計は vsphere 側で必要 CI / CD Cloud Build or/and Marketplace Cloud Build はクラウド利用

11 ユーザとしての理解: GKE をどこでも Managed by Google な kubernetes 実行環境がどこでも作成 / 運用 できるという理解をしてい ます Anthos GKE 上でのプラグイン Serverless Istio Market Place Google Kubernetes Engine GCP のクラウド上で稼働 VPC 上で動作 VMレイヤは基本的に GCEに依存 Migrate Config GKE On-Prem vsphere 環境ならどこでも稼働 オンプレネットワーク 上で動作 VMレイヤの冗長は オンプレに依存 GCP のマネージドサービス

12 GKE と GKE On-Prem との比較 機能 GKE GKE On-Prem ネットワーク VPC と結合可能 設計次第 ファイアーウォール機能 Firewall Rules 基本的に自分の環境で準備 ロードバランサ (L4) Load balancer と連携 F5 BIG-IP と連携 or 独自で ロードバランサ (L7) Load balancer と連携 Istio VM GCE vsphere VM DB などミドルウェア Google Managed Service 自分で準備 or Marketplace Metrics / Logs Stackdriver Stackdriver

13 構成の比較 Internet Google Network Cloud Armor ファイアー ウォール機能 ロード バランサ ロード バランサ GKE GKE On-Prem Cloud SQL (Stateful) Stateful Workload Cloud Shell Admin Work Station On Premise Network VPC / region Run on vsphere

14 ハイブリッド構成の例 自社設備に紐づく資産を中心にオンプレミスにワークロードを残して Web 経由のアクセスが中心 となるワークロードを GCP に移行する取り組みを実施中. Web サービス / オーダー管理システム etc. 設備管理システム / 契約管理システム etc. クラウドのスケーラビリティを生かすワークロード 設備の場所に依存するサービスや 機密情報を含むワークロード App 間連携 Stackdriver 連携等 GKE Managed Service Workloads in Cloud Stackdriver.etc GKE On-Prem Other Workloads Workloads in On-Premise Devices

15 Summary アップデートの煩雑さや インストールの難しさから kubernetes の運用は余程多くの専用チームを 組む選択肢がない限り managed service を利用する選択肢がベストと言えます managed kubernetes をどれを使うかを慎重に選ぶことも重要ですが まずは 導入前に組織として kubetnetes を利用するための体制作り 常に情報をアップデートしていくことが重要です GKE On-Prem もまだまだこれからアップデートが続くことが予想されるため うまく情報を集めていくことが 求められます

16 02 環境構築について 02

17 環境構築の前に 実行環境を考える. 既存環境との統合は慎重に ネットワークの構成を考える. 特性を理解する. ワークロードの特性を見る. ~ ステートをどう持たせるか ~ どのような環境が必要かを事前に理解 することは非常に重要です 仮に既存の環境上にデプロイを行う場 合は 環境の管理者と設計を丁寧に行 いましょう. ネットワークの構成は慎重に考えて設 計するようにします. 通信の方法など事前に仕様を理解 した上で構成するようにしましょう. 動かすワークロードの特性と GCPの クラウドではマネージドサービスに頼っ ているワークロードの扱いについて事 前に確認しましょう

18 GKE On-Prem が提供するもの. Kubernetes Cluster + Cluster Management のツールを中心に提供されます Admin cluster kubectl API Server User cluster Agent User Pod Istio GCP のマネージドサービス k8s cluster gkectl Admin Workstation Admin Control Plane User Control Plane User Cluster Node VM提供基盤 (VMware vsphere など) + Load Balancer API VM コントローラ (vcenter) API ロードバランサ (F5 BIG-IP) Stateful Workload

19 インフラ観点からの GKE On-Prem GKE On-Prem は 現状 vsphere 環境上で動作し L4ロードバランサとして F5 BIG IP LTM をサポートしています コンテナ & Kubernetes GKE On-Prem Load Balancer 連携機能 仮想化 物理サーバ等 自身で準備

20 Kubernetes クラスタの管理 クラスタの管理そのものをYAML 形式で外部ファイルで定義します gkectl create --config <YAML FILE> というコマンドでクラスタを作成します gkeplatformversion: gke.19 vcenter: <vcenter へのログイン情報など > Admincluster: <Admin Cluster の情報> Usercluster: <User Cluster の情報> Masternode: <Master Node のサイズ> Workernode: <Worker Node のサイズ> lbmode: Integrated # LB の連携 gkeconnect: <Stackdriver など> vcenter Server (VM Control) LB Control Admin Control Plane User Control Plane Admin Cluster Worker Node Worker Node User Cluster デプロイ時に作成

21 クラスタ管理の考え方 クラスタを全体で見た場合に 以下のような管理ができます 各コンポーネント毎に 自動化 / コードでの管理を目指しています Container Container Container Containers VM VM VM IaaS Network Server Hardware Storage 管理プレーンはデプロイ時に自動作成 & YAML 形式で管理 Admin Workstation は terraform 対応あり その他のVMも必要に応じてコード管理 ベアメタルサービスのプロバイダを利用 していれば 一部コード管理が可能.

22 ネットワークの設計 GKE On-Prem と GKE をハイブリッドで利用する場合には 大まかに クラスタ内部のネットワークの設計と 外部接続の設計 が必要になります Google APIs Cloud Router interconnect GCP Services クラスタ内部の ネットワーク設計 クラスタ外部との ネットワーク設計 Vi ual Private Cloud

23 ネットワークを理解する ~ 通信 ~ GKE On-Prem にどのような通信が発生するかは以下の3つのパターンを おさえていれば良いと思います. Pod への通信 管理通信 Client クラスタ作成時指定の VIP Control Plane VIP Client Pod からの通信 Container Application Service 作成で指定 Service Virtual IP (NodePort) SNAT kube-apiserver Service (NodePort/clusterIP) Container Application Target

24 ネットワークを理解する. ~ IP の払い出し ~ 先ほどの通信要件に加えて IP がどのように払い出されるかは事前に十分設計をしてから作成し た方が良いと思います Client Node Subnet VIP Pool Control / Data Plane 通信 クラスタ作成時の IP 払い出し (DHCP or Static) VIP F5 BIG-IP LTM Service Pool LB の VIP の払い出し (Service 作成時の IP指定) IP Pool から自動払い出し (Range は作成時に指定 ) Node IP Node IP Node IP Virtual IP (clusterip) Pod IP Pool Pod IP Pod IP Pod IP UCN VM UCN VM UCN VM

25 当社の 環境 当社の環境は以下のような構成で作成しています FW /24 port group 1 Data Plane(VIP) Subnet F5 LB VIP Pool VLAN /24 Data Plane(Node) Subnet Admin Control Plane User cluster control plane User Clusters port group 2 VLAN /24 Management Plane(Management) Subnet vcenter port group 3 VLAN 10

26 Summary GKE On-Prem を既存環境にデプロイするような場合は 構築する前に あるべき構成をデプロイ先の環境 の責任者と十分に議論した上でインストールをするようにしましょう もし kubernetes の導入が初めてであれば コンサルティングなどを積極的に利用してクラスタ管理のポリ シーをなるべく明確にすることが重要です 場合によってはクラスタの再作成が発生することもあるため 慎重に設計するようにしましょう

27 03 03 ベストプラクティス

28 本格導入に向けて考慮しておきたいこと 認証 / 認可を適切に設定 デプロイパイプラインの設計 メトリクス管理 Kubernetes の API へのアクセス をどのように制御すべきかを中心に RBACの設定ポリシーを明確にしま す オンプレミス側にあっても 可用性を担保しつつ クラウドに近い 形でデプロイパイプラインの設計がで きることがベストです いかに有効なメトリクスを管理するか 設計と同時に マネージドサービスとうま く組み合わせて利用できる設計をしま す

29 本格導入に向けて考慮しておきたいこと 認証 / 認可を適切に設定 デプロイパイプラインの設計 メトリクス管理 Kubernetes の API へのアクセス をどのように制御すべきかを中心に RBACの設定ポリシーを明確にしま す オンプレミス側にあっても 可用性を担保しつつ クラウドに近い 形でデプロイパイプラインの設計がで きることがベストです いかに有効なメトリクスを管理するか 設計と同時に マネージドサービスとうま く組み合わせて利用できる設計をしま す

30 はじめに: RBAC の概念を浸透させる. GCP や クラウド のリソースを どんな権限レベル で 何 に対してアクセスするかを Role とし て 定義し 誰が アクセスできるかを考えます 誰が サービスアカウント 何 に ネットワーク どのレベルで GET: 参照する PUT: 変更する コンテナ(podなど) POST: 作成 ユーザアカウント ユーザ管理 DELETE: 削除する

31 認証 / 認可 への対応 GKE On-Prem で意識すべき認証 / 認可 を以下 3つ挙げておきます Kubernetes への 管理アクセス Admin cluster kubectl User cluster API Server Agent User Pod Istio GCP のマネージドサービス k8s cluster gkectl Admin Workstation GKE On-Prem への 管理アクセス Admin Control Plane User Control Plane GCPの コンテナから User Cluster Node マネージドサービスへのアクセス VM提供基盤 (VMware vsphere など) + Load Balancer API VM コントローラ (vcenter) API ロードバランサ (F5 BIG-IP) Stateful Workload

32 やりたいこと: RBAC と IAM を適切に管理 開発環境からプロダクション環境において 一貫した環境 と アプリケーション開発に 集中できる 環境を作るために 適切な(最小限の) 認証 / 認可 を各チームに払い出すことを目的とし ます namespace SRE Staging Project App1 Staging Project GCP Managed Services App2 Staging Project GCP Managed Services App1 Production Project GCP Managed Services App2 Production Project GKE Cluster namespace namespace SRE Production Project GCP Managed Services Team: App2 GKE Cluster namespace Team: App1 Team: SRE

33 OIDC を使った ユーザベースの認証. クラスタの設定の中で Open ID Connect ベースの認証を有効に設定します これにより利用している G Suite のアカウントをベース にログインすることができます GCP Console から設定が可能 1. 認証 組織のポリシー 管理に従う G Suite users 2. アクセス GKE On-Prem Control Plane

34 サービスアカウントベースの 認証 / 認可 OIDC の他に 各チームの踏み台にサービスアカウントを配置するといった方法も 考えています kubernetes 標準の機能を利用して実現が可能です RoleBinding A member A Service Account A Role A Team A namespace A member C Resource B RoleBinding B member B Resource A Service Account B Role A Team B namespace B Resource C Resource D

35 今後: サービスアカウントと ユーザベースの認証 / 認可 で双方の使い方がうまく Group 単位で連携さ れる選択肢を持てるようにしたいです ユーザベース サービスアカウントベース CDツール Team: App01 Team: App02 Team: SRE Google Group01 Google Group02 Google Group 03 Namespace 01 Service Account 01 Namespace 01 Service Account 02 Namespace 02 Namespace 02 Service Account 02

36 本格導入に向けて考慮しておきたいこと 認証 / 認可を適切に設定 デプロイパイプラインの設計 メトリクス管理 Kubernetes の API へのアクセス をどのように制御すべきかを中心に RBACの設定ポリシーを明確にしま す オンプレミス側にあっても 可用性を担保しつつ クラウドに近い 形でデプロイパイプラインの設計がで きることがベストです いかに有効なメトリクスを管理するか 設計と同時に マネージドサービスとうま く組み合わせて利用できる設計をしま す

37 CI / CD パイプラインで実現したいこと 開発からオペレーションに至る一貫したプロセスの自動化/ 省人化を通して 実現したいと考えています 開発 テスト デプロイ オペレーション プロセス間も含めた一貫した自動化 Cloud Source Repositories Cloud Build Container Registry Deploy/ Rollback Kubernetes Engine Spinnaker Sync Developer Call Test Return Result Code Push GitHub Scenario Test Kick Test Jenkins Return Result Postman

38 CI / CD パイプラインで実現したいこと 開発からオペレーションに至る一貫したプロセスの自動化/ 省人化を通して 実現したいと考えています 開発 テスト デプロイ オペレーション プロセス間も含めた一貫した自動化 Cloud Source Repositories Cloud Build Container Registry Deploy/ Rollback Kubernetes Engine Spinnaker Sync Developer Call Test Return Result Code Push GitHub Scenario Test Kick Test Jenkins Return Result Postman

39 Image Registry ~ Docker Registry vs Cloud Build ~ 標準的に Docker Registry を Admin Work Station 上に起動することが可能ですが Cloud Build での イメージ保管によるスケーラビリティ Docker Registry Cloud Build (Container Registry) Image の 場所 オンプレミス (VM のストレージ) Cloud (Cloud Storage) 可用性 VM に依存 Cloud Storage スケーラビリティ VM のストレージに依存 Cloud Storage に依存 (スケール可能 ) 認証 / 認可 Docker Registry に依存 IAM に統合可能 通信 オンプレミス内部通信 インターネット経由

40 GKE On-Prem での Cloud build の利用 GKE On-Prem でも cluster 利用の際のサービスアカウントを Cloud Build 側のIAM に登録するこ とで利用が可能です. そのため クラウドでの利用と多くを変えずに設計が可能なことを確認していま す Image Build Cloud Build IAM機能を利用してサービスアカウントに事前に認 可を譲渡 image pull Image Store Container Registry コンテナ実行環境 GKE On-Prem

41 CI / CD パイプラインで実現したいこと 開発からオペレーションに至る一貫したプロセスの自動化/ 省人化を通して 実現したいと考えています 開発 テスト デプロイ オペレーション プロセス間も含めた一貫した自動化 Cloud Source Repositories Cloud Build Container Registry Deploy/ Rollback Kubernetes Engine Spinnaker Sync Developer Call Test Return Result Code Push GitHub Scenario Test 基本的に変更は不要 Kick Test Jenkins Return Result Postman

42 本格導入に向けて考慮しておきたいこと 認証 / 認可を適切に設定 デプロイパイプラインの設計 メトリクス管理 Kubernetes の API へのアクセス をどのように制御すべきかを中心に RBACの設定ポリシーを明確にしま す オンプレミス側にあっても 可用性を担保しつつ クラウドに近い 形でデプロイパイプラインの設計がで きることがベストです いかに有効なメトリクスを管理するか 設計と同時に マネージドサービスとうま く組み合わせて利用できる設計をしま す

43 メトリクス管理で実現したいもの. SLI (Service Level Indicator の略) の設定 サービスレベルの指標として計測され 多くのサービスでは 重要な SLI としてリクエストのレイテンシを考慮 するため実現方法を考えます SLO (内部の目標) と SLA (利用者との合意) の設定 上記の SLI に加えて 内部の目標値である SLO と サービスの利用者との同意である SLA を設定して 数 値をベースとした管理を行う 目的に合わせた ポリシーの策定 上記の SLI の指標となるメトリクスに加えて 問題が生じた場合や リソースの管理に利用する メトリクス をどのように使える状態かを認識し 可能であればポリシーとして持っておく

44 メトリクス管理のライフサイクル 利用用途に従って メトリクスデータをいかに管理していくかを決めて 一部のSLI に利用す るようなデータは BigQuery にエクスポートするようなライフサイクルを目指しています. SLIの設定 指標の取得 カスタム メトリクス Uptime Check GCP標準 メトリクス DWHへの 格納 長期指標 Dashboard 振り返り向け Notebook Notification 必要に 応じて利用 仕様に 従って削除 [振り返り自動化] 用途に合わせたデータへのアクセシビリティ 活用までのサポート体制を準備

45 SLI の基準として Uptime Check のメトリクスを採用 Stackdriver の Uptime Check 機能を利用することで アプリケーションがユーザから見て 動いているか 遅延がないか を見るシンプル かつ 実用的 な基準を作ることができます Dashboard 動作イメージ Stackdriver Uptime Check GCP のインフラからヘ ルスチェック. - 任意のエンドポイント - タイムアウト値 などを指定 Application

46 オンプレミス環境での利用 Uptime Check を クラウド上のアプリケーションと同様にオンプレミス側でも動作させること が可能なため ハイブリッド構成でも同様のSLI 設定が可能. 特定のソースIP Stackdriver Uptime Check On-Premise Firewall On-Premise Load Balancer Application (GKE On-Prem) Workloads in On-Premise ブラックボックス監視によるヘルスチェック Cloud Armor Google Cloud Load Balancer Workloads in Cloud Application (GKE)

47 Prometheus / Logging 含む全体像 について 目的別にメトリクスを管理できるように通常通り以下のようなポリシーに従って構成するのが一 つの選択肢 だと考えています. それぞれのメトリクスの用途に従って構成しています 長期的な可視化 総合的な可視化 短期的な可視化 Data Portal Metrics Dashboard Dashboard (Grafana) BigQuery Stackdriver Monitoring Metrics Mgmt. (Prometheus) Cloud Functions Google Cloud Platform Application (Pod) On-Premise K8s MGMT (api etc.)

48 Stackdriver との統合機能を利用 GA 版から ネイティブで Stackdriver との統合がサポートされ クラスタ管理に必要最低限なメ トリクスが自動収集されています Kubernetes Monitoring の GKE On-Prem でのサポートな ど 今後の拡張にも期待しています

49 Summary GCP で提供される GKE On-Prem を使う場合は クラウドのマネージドサービスと うまく組み合わせることを前提とする ことで クラウドのスケーラビリティをうまく取り込むことができ ると思います. また 今後は 永続ストレージの利用可能などをRDB などをどのようにオンプレミス側で構成して いくかの設計&検証をしていきたいと考えています.

50 04 04 今後について

51 今後の アクション ~ 事例作り ~ 現時点では 機能テストを中心として進めているため 実際のワークロードが乗るようなプロ ジェクト対応を進めたいと考えています. Cloud Run の導入も含めて開発者やシステム導入者がフレキシブルに選択可能な環境導入 を想定しています 用途に従って選択 VM GKE オンプレミス Cloud Run GKE GCE クラウド Cloud Run

52 今後の アクション ~ 皆様の導入をサポート ~ GKE On-Prem の導入を中心に Anthos のお客様向けの導入サポートを実施します - GKE On-Prem の設計サポート ネットワークの設計やツール周りの導入コンサルティングを実施 - GKE On-Prem の導入サービス 実際に vsphere のクラスタ構築から導入をお客様の代わりに実施

53 今後の Anthos への期待 1. ハイブリッドクラウドおよびコンテナのマーケットプレイスへの期待 Kubernetes を中心とした アプリケーション / ミドルウェア の成熟 を通して より広いユースケースに対応していく 2. エッジでの利用など多様なユースケースへの対応 現時点では vsphere のクラスタ利用が必須 などエッジで利用する用途は限定的なた め 今後軽量化 や GPU 対応など現状の GKE で可能な領域の対応だけでなく GKE で は難しいユースケースへの対応もあればより魅力的な選択肢になると思います

54 ご清聴ありがとうございました