NTT Ltd. Group 桑山 純弥2019/09/03

[Google Kubernetes Day ‘19]ユーザからみた Anthos GKE On-Prem の利用について

桑山 純弥

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 ベストプラクティス

　04 今後について

0101 GKE と GKE On-Prem について

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 双方で、多くのアップデートが常に走っています. Kubernetes 自体も独立してアップデートを繰り返しています.

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

01Kubernetes のアップデート

をサポートしているか

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 On-Prem の対応を以下に挙げます。

ユーザとしての理解: GKE をどこでも

Google KubernetesEngine GKE On-Prem

● GCP のクラウド上で稼働● VPC 上で動作● VMレイヤは基本的にGCEに依存

● vSphere 環境ならどこでも稼働● オンプレネットワーク上で動作● VMレイヤの冗長はオンプレに依存

Anthos

GKE 上でのプラグイン GCP のマネージドサービスIstioServerless Market Place Migrate Config

　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

Metrics / Logs Stackdriver Stackdriver

構成の比較

On PremiseNetwork

Run onvSphere

GoogleNetwork

Internet

VPC / region

CloudArmor

ロードバランサ

ファイアーウォール機能

ロードバランサ

GKE GKE On-Prem

Cloud Shell

Cloud SQL(Stateful)

Admin WorkStation

StatefulWorkload

ハイブリッド構成の例

Workloads in Cloud Workloads in On-Premise

GKE On-Prem

Other

WorkloadsGKE

Managed Service

Stackdriver

.etc

App 間連携

Stackdriver 連携等

Devices

Web サービス / オーダー管理システム etc.

クラウドのスケーラビリティを生かすワークロード

設備管理システム / 契約管理システム etc.

設備の場所に依存するサービスや、機密情報を含むワークロード

　自社設備に紐づく資産を中心にオンプレミスにワークロードを残して、Web 経由のアクセスが中心となるワークロードを GCP に移行する取り組みを実施中.　

Summary

　アップデートの煩雑さや、インストールの難しさから、 kubernetes の運用は余程多くの専用チームを

組む選択肢がない限り、 managed service を利用する選択肢がベストと言えます。

managed kubernetes をどれを使うかを慎重に選ぶことも重要ですが、まずは、導入前に組織として

kubetnetes を利用するための体制作り、常に情報をアップデートしていくことが重要です。 GKE On-Prem もまだまだこれからアップデートが続くことが予想されるため、うまく情報を集めていくことが

求められます。

0202 環境構築について

環境構築の前に.

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

AdminControl Plane

UserControl Plane

UserCluster Node

k8s cluster

API Server

Admin cluster

gkectl

kubectl Agent User Pod Istio

User cluster

Stateful Workload

GCP のマネージドサービス

インフラ観点からの GKE On-Prem

物理サーバ等

仮想化

コンテナ& Kubernetes

LoadBalancer

自身で準備

GKE On-Prem

連携機能

　GKE On-Prem は、現状 vSphere 環境上で動作し、L4ロードバランサとして F5 BIG IP LTM をサポートしています。　

　クラスタの管理そのものを YAML 形式で外部ファイルで定義します。“gkectl create --config <YAML FILE>” というコマンドでクラスタを作成します。　　

Admin Cluster

Kubernetes クラスタの管理

gkeplatformversion: 1.12.7-gke.19vcenter: <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 ControlPlane

User ControlPlane

User Cluster

Worker Node Worker Node

デプロイ時に作成

クラスタ管理の考え方

IaaS

HardwareNetwork Server Storage

VM

Containers

VM

Container

　クラスタを全体で見た場合に、以下のような管理ができます。

各コンポーネント毎に 自動化 / コードでの管理を目指しています。

VM

Container Container 管理プレーンはデプロイ時に自動作成 & YAML 形式で管理

Admin Workstation は terraform 対応ありその他のVMも必要に応じてコード管理

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

Vi ual Private Cloud

CloudRouter

ネットワークの設計

interconnect

Google APIs

GCPServicesクラスタ内部の

ネットワーク設計

クラスタ外部とのネットワーク設計

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

クラスタ内部のネットワークの設計 と 外部接続の設計 が必要になります。

　GKE On-Prem にどのような通信が発生するかは以下の3つのパターンを

おさえていれば良いと思います.

ネットワークを理解する ~ 通信 ~

管理通信 Pod への通信 Pod からの通信

Client

Control Plane VIP

kube-apiserver

Client

Virtual IP

Service(NodePort/clusterIP)

ContainerApplication

クラスタ作成時指定の VIP Service 作成で指定

Service(NodePort)

ContainerApplication

SNAT

Target

ネットワークを理解する. ~ IP の払い出し ~

UCN VMUCN 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 IPPool

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 Pool192.168.30.10 - 192.168.30.253

Summary

　GKE On-Prem を既存環境にデプロイするような場合は、構築する前に、あるべき構成をデプロイ先の環境

の責任者と十分に議論した上でインストールをするようにしましょう。

もし kubernetes の導入が初めてであれば、コンサルティングなどを積極的に利用してクラスタ管理のポリ

シーをなるべく明確にすることが重要です。

場合によってはクラスタの再作成が発生することもあるため、慎重に設計するようにしましょう。

0303 ベストプラクティス

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

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

AdminControl Plane

UserControl Plane

UserCluster Node

k8s cluster

API Server

Admin cluster

gkectl

kubectl Agent User Pod Istio

User cluster

Stateful Workload

GCP のマネージドサービス

Kubernetes への管理アクセス

GKE On-Prem への管理アクセス

コンテナからGCPのマネージドサービスへのアクセス

やりたいこと: RBAC と IAM を適切に管理

SREStagingProject

SREProductionProject

App1StagingProject

App2StagingProject

App1Production

Project

App2Production

Project

GKE Cluster

GKE Cluster

GCP ManagedServicesnamespace

namespaceGCP Managed

Services

GCP ManagedServices

GCP ManagedServices

namespace

namespace

Team: SRE

Team: App2

Team: App1

　開発環境からプロダクション環境において、一貫した環境 と、アプリケーション開発に

集中できる 環境を作るために、適切な(最小限の) 認証 / 認可 を各チームに払い出すことを目的とし

ます。

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

G Suite users

GKE On-PremControl 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 Namespace 01Google Group01

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 SourceRepositories

Cloud Build

ContainerRegistry

SpinnakerKubernetesEngine

Jenkins Postman

GitHubCode Push

Sync

Deploy/Rollback

Scenario Test

Kick Test

Return Result

Call Test

Return Result

Developer

開発 テスト デプロイ オペレーション

プロセス間も含めた一貫した自動化

　開発からオペレーションに至る一貫したプロセスの自動化 / 省人化を通して

実現したいと考えています。

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

Cloud SourceRepositories

Cloud Build

ContainerRegistry

SpinnakerKubernetesEngine

Jenkins Postman

GitHubCode 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 Build での イメージ保管によるスケーラビリティ

GKE On-Prem での Cloud build の利用

Image BuildCloud Build

Image StoreContainer Registry

コンテナ実行環境GKE On-Prem

image pull

IAM機能を利用してサービスアカウントに事前に認

可を譲渡

　GKE On-Prem でも cluster 利用の際のサービスアカウントを Cloud Build 側のIAM に登録するこ

とで利用が可能です. そのため、クラウドでの利用と多くを変えずに設計が可能なことを確認していま

す。

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

Cloud SourceRepositories

Cloud Build

ContainerRegistry

SpinnakerKubernetesEngine

Jenkins Postman

GitHubCode 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[振り返り自動化]

用途に合わせたデータへのアクセシビリティ・活用までのサポート体制を準備

必要に応じて利用

仕様に従って削除

UptimeCheck

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

Dashboard 動作イメージ

StackdriverUptime Check

GCP のインフラからヘ

ルスチェック.

Application

- 任意のエンドポイント

- タイムアウト値

などを指定

　Stackdriver の “Uptime Check” 機能を利用することで、アプリケーションがユーザから見て

「動いているか」、「遅延がないか」を見る シンプル かつ 実用的 な基準を作ることができます。　

Workloads in On-Premise

StackdriverUptime Check

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

特定のソースIP

On-PremiseFirewall

On-PremiseLoad Balancer

Application(GKE On-Prem)

ブラックボックス監視によるヘルスチェック

Workloads in Cloud

Google CloudLoad Balancer

Application(GKE)Cloud Armor

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

が可能なため、ハイブリッド構成でも同様の SLI 設定が可能.

Google Cloud Platform On-Premise

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

Metrics Mgmt.(Prometheus)

Dashboard(Grafana)

Application(Pod)

短期的な可視化総合的な可視化

StackdriverMonitoring

長期的な可視化

BigQuery

CloudFunctions

Data Portal MetricsDashboard

K8s MGMT(api etc.)

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

つの選択肢 だと考えています. それぞれのメトリクスの用途に従って構成しています

Stackdriver との統合機能を利用

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

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

ど 今後の拡張にも期待しています。

Summary

　GCP で提供される GKE On-Prem を使う場合は、クラウドのマネージドサービスと

うまく組み合わせることを前提とする ことで、クラウドのスケーラビリティをうまく取り込むことができ

ると思います.　また、今後は 永続ストレージの利用可能などをRDB などをどのようにオンプレミス側で構成して

いくかの設計&検証をしていきたいと考えています.

0404 今後について

今後の アクション ~ 事例作り ~

オンプレミス

VM GKE Cloud Run

クラウド

GCE GKE Cloud Run

用途に従って選択

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

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

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

を想定しています

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

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

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

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

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

実際に、vSphere のクラスタ構築から導入をお客様の代わりに実施

今後の Anthos への期待

1. ハイブリッドクラウドおよびコンテナのマーケットプレイスへの期待

Kubernetes を中心とした アプリケーション / ミドルウェア の成熟 を通して、

より広いユースケースに対応していく

2. エッジでの利用など多様なユースケースへの対応

現時点では、vSphere のクラスタ利用が必須、などエッジで利用する用途は限定的なた

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

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