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

NTT Ltd. Group 桑山 純弥

2019/09/03

[Google Kubernetes Day ‘19]

ユーザからみた

Anthos GKE

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

当社について

　2019 年 7 月に NTT コミュニケーションズ (以下 NTT Com) は、NTT Ltd. と

NTT コミュニケーションズに再編成されました。

国内から海外まで _{End to End のワンストップでのサポートを NTT Com として} 提供しつつ、NTT グループとして海外における競争力を一層強化します。

Next Tokyo ‘19 の説明について

　　Google Cloud Next Tokyo ‘19 でも Anthos について話させて頂きました。

なぜ当社で kubernetes / Anthos を導入したかなどを説明していますので、よろしければ 本日の説明と合わせて動画をご覧ください。　

アジェンダ

　

01 GKE と GKE On-Prem について

　

02 環境構築について

　

03 ベストプラクティス

01

GKE / GKE On-Prem を使う前に.

01

アップデート情報に 常にアンテナを貼る_. Kubernetes の環境 や 関連ツールの 進化はとても早いです。 常に知識をアップデートする必要があり ます。

02

組織的に学習する環境 を整備する_. Kubernetes の 導入は残念ながら 簡単ではないです. 継続的に学習できること、学習する 文化を一緒に作っていきましょう.

03

リーダーの理解を得る_. 説明責任を果たす_. メリットを IT の経験が浅い人に説明する 機会が付きものだと思います。 導入メリットや解決したい課題を 丁寧に説明を行なう必要があります。

GKE / GKE On-Prem 関連の最近のアップデート

GKE On-Prem GKE

Version Up 11 回 (2019.3 - 2019.8) Admin Workstation のデプロイ仕様変更 Version Up 14回 (2019.3 - 2019.8) 大阪リージョンが 利用可能に Monitoring / Logging の 仕様変更 Manual LB のサポート拡大 Kubernetes Monitoring のサポート Workload Identity が利用可能に Calico のサポート拡大と

Ver.up Istio Ingress controller のサポートと _Ver.up

Cloud Run On GKE が

利用可能に

コンテナランタイムの サポート拡大 & Ver.up

　Google Kubernetes Engine, GKE On-Prem 双方で、多くのアップデートが常に走っています.

“Managed” kubernetes サービスに求めるもの

01

Kubernetes のアップデート をサポートしているか Kubernetes 自体のソフトェアアップデー トが早いので、アップデートのサポートポ リシーだけでなく、どのようにアップデー トするかを推奨しているかは非常に重要 なファクターになります。

02

周辺ツールでのサポート _/ 統合のケイパビリティ CI / CD 周りのサポート や、認証 / 認可 の設定の容易さ、 メトリクス収集 など、商 用利用時に便利な機能をどのようにサ ポートしているかは重要です。ベストプラ クティスがどのように掲示されているかや ユーザーベースのコミュニティの情報が 豊富なことも大事な点です。

03

ネットワーク _{/ ストレージとの統} 合 設計の時にネットワークとストレージが どのように提供されるかは注意してみる べき点です。 ロードバランサの選択 や、永続ストレー ジの有無や提供方法 などを事前に確認 しましょう。

“Managed Kubernetes” として

機能 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 はクラウド利用

ユーザとしての理解

: GKE をどこでも

Google Kubernetes

Engine GKE On-Prem

● GCP のクラウド上で稼働 ● VPC 上で動作 ● VMレイヤは基本的に GCEに依存 ● vSphere 環境ならどこでも稼働 ● オンプレネットワーク 上で動作 ● VMレイヤの冗長は オンプレに依存 Anthos

GKE 上でのプラグイン _{Serverless Istio Market Place Migrate Config} GCP のマネージドサービス

　Managed by Google な kubernetes 実行環境がどこでも作成 / 運用 できるという理解をしてい ます。

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

構成の比較

On Premise Network Run on vSphere Google Network Internet VPC / region Cloud Armor ロード バランサ ファイアー ウォール機能 ロード バランサ

GKE GKE On-Prem

Cloud Shell Cloud SQL (Stateful) Admin Work Station Stateful Workload

ハイブリッド構成の例

Workloads in Cloud Workloads in On-Premise

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

Summary

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

02

環境構築の前に

.

01

実行環境を考える_. 既存環境との統合は慎重に どのような環境が必要かを事前に理解 することは非常に重要です。 仮に既存の環境上にデプロイを行う場 合は、環境の管理者と設計を丁寧に行 いましょう.

03

ワークロードの特性を見る_. ~ ステートをどう持たせるか ~ 動かすワークロードの特性と、GCPの クラウドではマネージドサービスに頼っ ているワークロードの扱いについて事 前に確認しましょう。

02

ネットワークの構成を考える_. 特性を理解する_. ネットワークの構成は慎重に考えて設 計するようにします. 通信の方法など事前に仕様を理解 した上で構成するようにしましょう.

　Kubernetes Cluster + Cluster Management のツールを中心に提供されます。

GKE On-Prem が提供するもの.

Admin

Workstation _{VM提供基盤 (VMware vSphere など) + Load Balancer} VM コントローラ (vCenter) API ロードバランサ (F5 BIG-IP) API Admin

Control Plane Control PlaneUser Cluster NodeUser k8s cluster

API Server

Admin cluster

gkectl

kubectl Agent User Pod Istio

User cluster

Stateful Workload

インフラ観点からの

GKE On-Prem

物理サーバ等 仮想化 コンテナ & Kubernetes Load Balancer 自身で準備 GKE On-Prem 連携機能

　GKE On-Prem は、現状 vSphere 環境上で動作し、L4ロードバランサとして

　クラスタの管理そのものを YAML 形式で外部ファイルで定義します。

“gkectl create --config <YAML FILE>” というコマンドでクラスタを作成します。　

　 Admin Cluster

Kubernetes クラスタの管理

gkeplatformversion: 1.12.7-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 User Cluster

Worker Node Worker Node

クラスタ管理の考え方

IaaS

Hardware

Network Server Storage VM Containers VM Container 　クラスタを全体で見た場合に、以下のような管理ができます。 各コンポーネント毎に 自動化 / コードでの管理を目指しています。 VM

Container Container _{管理プレーンはデプロイ時に自動作成 &}

YAML 形式で管理

Admin Workstation は terraform 対応あり

その他の_{VMも必要に応じてコード管理}

ベアメタルサービスのプロバイダを利用 していれば、一部コード管理が可能_.

Vi ual Private Cloud Cloud Router

ネットワークの設計

interconnect Google APIs GCP Services クラスタ内部の ネットワーク設計 クラスタ外部との ネットワーク設計

　GKE On-Prem と GKE をハイブリッドで利用する場合には、大まかに

　GKE On-Prem にどのような通信が発生するかは以下の3つのパターンを おさえていれば良いと思います.

ネットワークを理解する

~ 通信 ~

管理通信 _{Pod への通信 Pod からの通信}

Client

Control Plane VIP

kube-apiserver Client Virtual IP Service (NodePort/clusterIP) Container Application クラスタ作成時指定の_{VIP Service 作成で指定} Service (NodePort) Container Application SNAT Target

ネットワークを理解する

. ~ IP の払い出し ~

UCN VM UCN VM F5 BIG-IP LTM VIP Pool VIP Node IP Service Pool _{Node IP} UCN VM Node IP Client Virtual IP (clusterIP)

Pod IP Pod IP Pod IP

Pod IP Pool

Node Subnet

Control / Data Plane 通信

クラスタ作成時の IP 払い出し (DHCP or Static) LB の VIP の払い出し (Service 作成時の IP指定) IP Pool から自動払い出し (Range は作成時に指定 ) 　先ほどの通信要件に加えて、IP がどのように払い出されるかは事前に十分設計をしてから作成し た方が良いと思います。　

　当社の環境は以下のような構成で作成しています。

当社の

環境

F5 LB vCenter Admin Control Plane FW User cluster control plane

Data Plane(VIP) Subnet

Data Plane(Node) Subnet

Management Plane(Management) Subnet

User Clusters port group 1 port group 2 port group 3 VLAN 30 VLAN 20 VLAN 10 192.168.30.0/24 192.168.20.0/24 192.168.10.0/24 VIP Pool 192.168.30.10 - 192.168.30.253

Summary

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

03

本格導入に向けて考慮しておきたいこと

.

01

認証 _{/ 認可を適切に設定} Kubernetes の API へのアクセス をどのように制御すべきかを中心に、 RBACの設定ポリシーを明確にしま す。

02

デプロイパイプラインの設計 オンプレミス側にあっても 可用性を担保しつつ、クラウドに近い 形でデプロイパイプラインの設計がで きることがベストです。

03

メトリクス管理 いかに有効なメトリクスを管理するか 設計と同時に、マネージドサービスとうま く組み合わせて利用できる設計をしま す。

本格導入に向けて考慮しておきたいこと

.

01

認証 _{/ 認可を適切に設定} Kubernetes の API へのアクセス をどのように制御すべきかを中心に、 RBACの設定ポリシーを明確にしま す。

02

デプロイパイプラインの設計 オンプレミス側にあっても 可用性を担保しつつ、クラウドに近い 形でデプロイパイプラインの設計がで きることがベストです。

03

メトリクス管理 いかに有効なメトリクスを管理するか 設計と同時に、マネージドサービスとうま く組み合わせて利用できる設計をしま す。

はじめに

: “RBAC” の概念を浸透させる.

「誰が」 「何」に？ 「どのレベルで」 GET: 参照する PUT: 変更する POST: 作成 DELETE: 削除する サービスアカウント ユーザアカウント ネットワーク コンテナ_(podなど) ユーザ管理 　GCP や クラウド のリソースを「どんな権限レベル」で、「何」に対してアクセスするかを “Role” とし て、定義し、「誰が」アクセスできるかを考えます。

　GKE On-Prem で意識すべき認証 / 認可 を以下 3つ挙げておきます。

認証

/ 認可 への対応

Admin

Workstation _{VM提供基盤 (VMware vSphere など) + Load Balancer} VM コントローラ (vCenter) API ロードバランサ (F5 BIG-IP) API Admin

Control Plane Control PlaneUser Cluster NodeUser k8s cluster

API Server

Admin cluster

gkectl

kubectl Agent User Pod Istio

User cluster Stateful Workload GCP のマネージドサービス Kubernetes への 管理アクセス GKE On-Prem への 管理アクセス コンテナから_GCPの マネージドサービスへのアクセス

やりたいこと

: RBAC と IAM を適切に管理

SRE Staging Project SRE Production Project App1 Staging Project App2 Staging Project App1 Production Project App2 Production Project GKE Cluster GKE Cluster GCP Managed Services namespace

namespace GCP Managed_Services

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

“OIDC” を使った ユーザベースの認証.

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

サービスアカウントベースの

認証 / 認可

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

CDツール

今後

:

Team: SRE Team: App02

Team: App01 Google Group01 Namespace 01

Google Group02 Google Group 03 Namespace 02 ユーザベース サービスアカウントベース Service Account 01 Service Account 02 Namespace 01 Namespace 02 Service Account 02 　サービスアカウントと、ユーザベースの 認証 / 認可 で双方の使い方がうまく Group 単位で連携さ れる選択肢を持てるようにしたいです。

本格導入に向けて考慮しておきたいこと

.

01

認証 _{/ 認可を適切に設定} Kubernetes の API へのアクセス をどのように制御すべきかを中心に、 RBACの設定ポリシーを明確にしま す。

02

デプロイパイプラインの設計 オンプレミス側にあっても 可用性を担保しつつ、クラウドに近い 形でデプロイパイプラインの設計がで きることがベストです。

03

メトリクス管理 いかに有効なメトリクスを管理するか 設計と同時に、マネージドサービスとうま く組み合わせて利用できる設計をしま す。

CI / CD パイプラインで実現したいこと

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

CI / CD パイプラインで実現したいこと

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

Image Registry ~ Docker Registry vs Cloud Build ~

Docker Registry Cloud Build (Container Registry)

Image の 場所 オンプレミス _{(VM のストレージ) Cloud (Cloud Storage)}

可用性 _{VM に依存 Cloud Storage}

スケーラビリティ _{VM のストレージに依存 Cloud Storage に依存}

(スケール可能)

認証 _{/ 認可 Docker Registry に依存 IAM に統合可能}

通信 オンプレミス内部通信 インターネット経由

　標準的に、Docker Registry を Admin Work Station 上に起動することが可能ですが、Cloud

GKE On-Prem での Cloud build の利用

Image Build Cloud Build Image Store Container Registry コンテナ実行環境 GKE On-Prem image pull IAM機能を利用してサービスアカウントに事前に認 可を譲渡

　GKE On-Prem でも cluster 利用の際のサービスアカウントを Cloud Build 側のIAM に登録するこ とで利用が可能です. そのため、クラウドでの利用と多くを変えずに設計が可能なことを確認していま す。

CI / CD パイプラインで実現したいこと

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

本格導入に向けて考慮しておきたいこと

.

01

認証 _{/ 認可を適切に設定} Kubernetes の API へのアクセス をどのように制御すべきかを中心に、 RBACの設定ポリシーを明確にしま す。

02

デプロイパイプラインの設計 オンプレミス側にあっても 可用性を担保しつつ、クラウドに近い 形でデプロイパイプラインの設計がで きることがベストです。

03

メトリクス管理 いかに有効なメトリクスを管理するか 設計と同時に、マネージドサービスとうま く組み合わせて利用できる設計をしま す。

メトリクス管理で実現したいもの

.

●

SLI (Service Level Indicator の略) の設定

　

サービスレベルの指標として計測され、多くのサービスでは、重要な SLI としてリクエストのレイテンシを考慮 するため実現方法を考えます。

●

SLO (内部の目標) と SLA (利用者との合意) の設定

　

上記の _{SLI に加えて、内部の目標値である SLO と、サービスの利用者との同意である SLA を設定して、数} 値をベースとした管理を行う。

● 目的に合わせた

ポリシーの策定

　

上記の _{SLI の指標となるメトリクスに加えて、問題が生じた場合や、リソースの管理に利用する} メトリクス _{をどのように使える状態かを認識し、可能であればポリシーとして持っておく。}

　利用用途に従って、メトリクスデータをいかに管理していくかを決めて、一部の _{SLI に利用す} るようなデータは BigQuery にエクスポートするようなライフサイクルを目指しています.

メトリクス管理のライフサイクル

SLIの設定 指標の取得 GCP標準 メトリクス カスタム メトリクス DWHへの 格納 長期指標 Dashboard 振り返り向け Notebook Notification [振り返り自動化] 用途に合わせたデータへのアクセシビリティ・活用までのサポート体制を準備 必要に 応じて利用 仕様に 従って削除 Uptime Check

SLI の基準として、Uptime Check のメトリクスを採用

Dashboard 動作イメージ Stackdriver Uptime Check GCP のインフラからヘ ルスチェック. Application - 任意のエンドポイント - タイムアウト値 などを指定

　Stackdriver の “Uptime Check” 機能を利用することで、アプリケーションがユーザから見て 「動いているか」、「遅延がないか」を見る シンプル かつ 実用的 な基準を作ることができます。　

Workloads in On-Premise Stackdriver Uptime Check

オンプレミス環境での利用

特定のソースIP On-Premise Firewall On-Premise Load Balancer Application (GKE On-Prem) ブラックボックス監視によるヘルスチェック Workloads in Cloud Google Cloud

Load Balancer Application(GKE) Cloud Armor

　Uptime Check を クラウド上のアプリケーションと同様にオンプレミス側でも動作させること

Google Cloud Platform On-Premise

Prometheus / Logging 含む全体像 について

Metrics Mgmt. (Prometheus) Dashboard (Grafana) Application (Pod) 短期的な可視化 総合的な可視化 Stackdriver Monitoring 長期的な可視化 BigQuery Cloud Functions

Data Portal _DashboardMetrics

K8s MGMT (api etc.) 　目的別にメトリクスを管理できるように 通常通り以下のようなポリシーに従って構成するのが一

Stackdriver との統合機能を利用

　GA 版から ネイティブで Stackdriver との統合がサポートされ、クラスタ管理に必要最低限なメ

トリクスが自動収集されています。Kubernetes Monitoring の GKE On-Prem でのサポートな

Summary

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

04

今後の

アクション ~ 事例作り ~

オンプレミス

VM GKE Cloud Run

クラウド

GCE GKE Cloud Run

用途に従って選択

　現時点では、機能テストを中心として進めているため、実際のワークロードが乗るようなプロ

ジェクト対応を進めたいと考えています.

Cloud Run の導入も含めて開発者やシステム導入者がフレキシブルに選択可能な環境導入

今後の

アクション ~ 皆様の導入をサポート ~

　

　_{GKE On-Prem の導入を中心に Anthos のお客様向けの導入サポートを実施します。}

- GKE On-Prem の設計サポート

ネットワークの設計やツール周りの導入コンサルティングを実施

- GKE On-Prem の導入サービス

今後の

Anthos への期待

1. ハイブリッドクラウドおよびコンテナのマーケットプレイスへの期待 Kubernetes を中心とした アプリケーション / ミドルウェア の成熟 を通して、 より広いユースケースに対応していく 2. エッジでの利用など多様なユースケースへの対応 現時点では、vSphere のクラスタ利用が必須、などエッジで利用する用途は限定的なた

め、今後軽量化 や GPU 対応など現状の GKE で可能な領域の対応だけでなく、GKE で は難しいユースケースへの対応もあればより魅力的な選択肢になると思います。