2020 年 1 月 21 日開催　GKE & Cloud Spanner 勉強会【基礎編】 セッション：GKE 入門 講師：川原　雄太（Yutty） 　　　カスタマーエンジニア　ゲーム業界担当

1. GKE & Spanner 勉強会
【基礎編】
2020.01.21
#gke_spanner

2. GKE 入門
川原 雄太（Yutty）
カスタマーエンジニア ゲーム業界担当
#gke_spanner

3. 1. コンテナと Kubernetes
2. Kubernetes のアーキテクチャ
3. Kubernetes における基本リソース
4. Google Kubernetes Engine (GKE) vs Kubernetes
GKE 入門のアジェンダ

4. コンテナと Kubernetes

5. Google では 10 年間に渡り、すべてのサービスをコンテ
ナで動かしてきた
毎週 40 億以上のコンテナを立ち上げている
Images by Connie Zhou

6. © 2018 Google LLC. All rights reserved.
Google はワークロードを
運用チームの 10 倍早く成長さ
せた
Core ops
team
Number of
running
containers
コンテナは運用を楽にする

7. コンテナはアプリケーションコードと
その依存性を 1 つのユニットとしてまとめる
これにより、アプリケーションとインフラを
疎結合にすることができる
- コンテナはアプリケーションとその依存性がまとまっている
ので、例えば、開発環境、テスト環境、 本番環境をま
たいだデプロイが容易になる
- オンプレミス、プライベートクラウド、
パブリッククラウド等、異なる実行環境間の移動が
容易になる
コンテナ イメージ
依存性
アプリケーションコード
コンテナとは

8. VM vs Container
VM
Container
Container Engine

9. なぜコンテナ？
軽量
仮想マシンに比べて
軽量でシンプル
数十ミリ秒で起動
ポータブル
様々な実行環境に対応し、
デプロイメントが容易
効率性
リソース使用量が少なく、コ
ンピュートリソースを
細分化して効率的に
利用可能

10. コンテナのライフサイクル
Dockerfile
① コンテナイメージ作成
docker build
コンテナイメージ
レジストリ
アプリケーション実行に必要な最低限の
ファイルやデータをパッケージ ② コンテナイメージを保存・公開
docker push
アプリケーションバイナリ
ライブラリ
③ ホストサーバーにコンテナイ
メージを配布・実行
docker pull
docker run
Node
コンテナを稼働させるた
めのホストサーバ
イメージの作成手
順を記載
コンテナイ
メージ
コンテナ
イメージ
コンテナ
イメージ
コンテナ
イメージ
コンテナコンテナ

12. コンテナ管理の課題
Node Node
Cluster
Node
???
● 複数の Node にどうやってコンテナをデプロイする ?
● Node がダウンしたらどうする ?
● コンテナに障害が発生したらどうする ?
● アプリケーションの更新はどうする ?
● コンテナ間の通信はどうする ?
コンテナ コンテナ コンテナ コンテナコンテナ コンテナ

13. Kubernetes
κυβερνήτης: Greek for “pilot” or “helmsman of a ship”
the open source cluster manager from Google

14. Kubernetes (k8s) とは
オープンソース の
コンテナオーケストレーションシステム
Kubernetes とはギリシャ語で操舵手の意味
略称は “k8s”
Go 言語で書かれている
https://kubernetes.io/

15. ● コンテナをホストする(コンテナを動かす)
● コンテナのスケジューリング( どこに配置するか決める)
● ( 負荷が増えたら) オートスケーリング
● ( 壊れたら ) オートヒーリング
● (新しいアプリに置き換えたい) ローリングアップデート
Kubernetes は拡張性が高いのも特徴の1 つ
Custom Resource Definition (CRD) を使うことで比較的容易に独自機能を
追加することが出来る
Kubernetes が主に出来ること
例えば...

16. Kubernetes の大きな特徴の一つ
マニフェストという設定ファイルを使う
従来の命令型 API と違い処理 ( How ) を書くのではなく、何を達成したいか( What ) だけを書
く
利用者はコンテナを利用するための細かいインフラ周りの処理を把握する必要はない
Kubernetes はマニフェストに書かれた状態を常に維持しようとするため、人の手を介さずともシ
ステムの健常な状態を維持できる（e.g. オートヒーリング）
宣言型 モデル (API)

17. Kubernetes のアーキテクチャ

18. Scheduler
Controller
Manager
API Server
etcd
kubelet
Container
Engine
Pod
(Containers)
K8s の設定
Kubectl / API
Kubernetes Master Kubernetes Nodes
kube-proxy
Kubernetes のアーキテクチャ

19. Master
API server / Scheduler / Controller manager
Node
1つまたは複数の Pod を実行するワーカーマシン (VM インスタンスや物理
サーバ)
Kubernetes の主要なコンポーネント

20. Master のコンポーネント
API Server
→ kubectl は API Server を REST API で叩くコマンドツール
Scheduler
→ Pod を Node にスケジュールするコンポーネント
Controller
→ クラスタの状態を常に監視するバックグラウンドプロセス
→ 定義された状態と異なると、それを修正するコンポーネント
etcd
→ 分散 KVS
→ クラスタの全データを格納するデータストア

21. Node のコンポーネント
kubelet
→ Node のエージェント
→ Pod の YAML ファイルに基づいて、定義されたコンテナを実行し、ストレージなどをマウント
し、正常に起動していることを担保
kube-proxy
→ 各 Node で実行するネットワークプロキシ
→ Service の IP アドレスを管理、コネクションフォワーディング
→ userspace, iptables, IPVS を使う 3 つのモードを選択可能

22. Kubernetes における基本リソース

23. Pod
Kubernetes のデプロイ単位。1 つまたは複数のコンテナが含まれる
Deployment
定義された Pod 数と稼働中の Pod を等しい状態を実現するリソース
可用性を担保
Service
Pod をクラスタの内部/外部に公開するためのリソース
Ingress
L7 レイヤーで負荷分散するためのリソース（ GKE では GCLB ）
Kubernetes の基本的なリソース

24. シンプルなアプリケーション
● 非常にシンプルなアプリケーションを公開すると仮定
● クライアントからのインターネット経由でのアクセス
● アプリケーションからデータベースへのインターナルなアクセス
アプリケーション データベース負荷分散

25. ● 非常にシンプルなアプリケーションを公開すると仮定
● クライアントからアプリケーションへの、インターネット経由でのアクセス
● アプリケーションからデータベースへの、インターナルなアクセス
Kubernetes Cluster
シンプルなアプリケーション
アプリケーション データベース負荷分散

26. Pod
Kubernetes のデプロイ単位。1 つまたは複数のコンテナが含まれる
Deployment
定義された Pod 数と稼働中の Pod を等しい状態を実現するリソース
可用性を担保
Service
Pod をクラスタの内部/外部に公開するためのリソース
Ingress
L7 レイヤーで負荷分散するためのリソース（ GKE では GCLB ）
Kubernetes の基本的なリソース

27. Pod
1 つ、もしくは複数のコンテナをデプロイする単位
● 関連するコンテナ
● 同じコンテキストで実行するコンテナ
同じ Pod のコンテナは同じホスト名を持つ
各 Pod の隔離は：
● Namespace (process isolation)
● cgroups (リソース制御)
複数のプロセスを実行する VM の代替
コンテナ:
ポッド

28. Deployment
● YAML ファイルに設定された Pod の数
が常に起動しているかを保証する
→ Pod のシャットダウン／起動
● Deployment を replicas: 1 で作成する
と、1 つの Pod が常に起動していること
を保証する
● デプロイするコンテナイメージと公開する
ポートを指定する
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-deployment
labels:
name: web
app: demo
spec:
replicas: 1
template:
metadata:
labels:
app: demo
spec:
containers:
- name: web
image:
gcr.io/sample-google/hello-app:v1
ports:
- containerPort: 5000
name: http
protocol: TCP

29. あるべき状態 : Pod A: 2 Pod, Pod B: 1 Pod
現在の状態 : Pod A: 2 Pod, Pod B: 1 Pod
Pod A
Pod B
Pod A
Deployment

30. あるべき状態 : Pod A: 2 Pod, Pod B: 1 Pod
現在の状態 : Pod A: 2 Pod, Pod B: 1 Pod
Pod A
Pod B
Pod A
Deployment

31. あるべき状態 : Pod A: 2 Pod, Pod B: 1 Pod
現在の状態 : Pod A: 1 Pod, Pod B: 0 Pod
Pod A
Pod B
Pod A
Deployment

32. あるべき状態 : Pod A: 2 Pod, Pod B: 1 Pod
現在の状態 : Pod A: 1 Pod, Pod B: 0 Pod
Pod A
Pod B
Pod A Pod A
Pod B
Deployment

33. あるべき状態 : Pod A: 2 Pod, Pod B: 1 Pod
現在の状態 : Pod A: 2 Pod, Pod B: 1 Pod
Pod A Pod A
Pod B
Deployment

34. ● 非常にシンプルなアプリケーションを公開すると仮定
● クライアントからアプリケーションへの、 インターネット経由でのアクセス
● アプリケーションからデータベースへの、 インターナルなアクセス
●
Kubernetes Cluster
シンプルなアプリケーション
アプリケーション データベース負荷分散

35. Service
アプリケーションのエンドポイントを提供する
● TCP / UDP をサポート
● kube-proxy 経由で iptables を操作
Types
● ClusterIP (クラスタ内のみでアクセスできるVIP)
● NodePort (クラスタ外からアクセス可能なサービス)
● LoadBalancer (L4 LB 経由でアクセス可能なサービス)
● ExternalName (クラスタ外のサービスを指定可能)
apiVersion: v1
kind: Service
metadata:
name: web
labels:
name: web
app: demo
spec:
selector:
name: web
type: LoadBalancer
ports:
- port: 80
targetPort: 5000
protocol: TCP

36. Ingress
アプリケーションのエンドポイントを提供する
● L7 での負荷分散を提供
○ GKE では GCLB
apiVersion: v1
kind: Ingress
metadata:
name: test-ingress
spec:
rules:
- http:
paths:
- path: /testpath
backend:
serviceName: test
servicePort: 80

37. cluster
Service / Ingress をデプロイ
Node Node
cluster
Node Node
L4 LB
cluster
Node Node
Service:
Type:NodePort
Service:
Type:LoadBalancer
Service:
Type:ClusterIP
Client
Client
cluster
Node Node
L7 LB
Ingress
Client
Pod A Pod B Pod A Pod A Pod A Pod A
Pod A Pod B
/app-a/* /app-b/*

38. Kubernetes の基本的なリソース
Pod
Kubernetes のデプロイ単位。1 つまたは複数のコンテナが含まれる
Deployment
定義された Pod 数と稼働中の Pod を等しい状態を実現するリソース
可用性を担保
Service
Pod をクラスタの内部/外部に公開するためのリソース
Ingress
L7 レイヤーで負荷分散するためのリソース

39. Google Kubernetes Engine (GKE)
vs Kubernetes

40. Demo 1
クラスターを作成する

41. Google Kubernetes Engine (A.K.A. GKE)
Google が提供する Kubernetes のマネージドサービス
● コマンド一発で k8s のクラスタを作成、利用開始可能
● マスターの管理は全てGoogle が行い、お客様はノードの費
用のみ負担頂く
GCP の各種サービスとのインテグレーションも便利
● Network services (HTTP(S) LB, NW LB, VPC)
● CI / CD (Cloud Build)
● Logging / Monitoring (Stackdriver)

42. コマンド一発で k8s のクラスタを作成
Kubernetes クラスタを手動で作る必要はない
自前では、全てを手動でインストールする必要がある
● ネットワーク：クラスタ間で Pod はどのように通信するのか？ flannel や
weave を使う?
● インストールが必要なバイナリー：
○ マスタ：etcd, kube-apiserver, kube-controller-manager,
kube-scheduler
○ 各 Node：Container Engine, kubelet, kube-proxy
● API Server を HTTPS で設定するなら、証明書が必要
● Addonのインストール： DNS, Logging, Dashboard などなど
GKE が全部やってくれます！

43. Master の管理は Google が提供
● Master は Google により管理されており、自動的に更新される
→ Node はユーザによってコントロール
→ Node のマイナー バージョン（x.X.x）がマスターのバージョンより 3 つ以上
古くなると、その Node は正しく動作しない場合がある
例: マスタが1.3 になると 1.0 が実行している Node は動作しない場合がある
● クラスタの設定を持つ etcd の自動バックアップ
● Google の SRE が面倒見てくれます！

44. Auto-Everything
k8s をスケーラブルに使うために必要なものが全て自動化されている
● Auto-repair
○ パフォーマンスに問題があったり故障した Nodes を自動的にリプレイス
● Auto-upgrade
○ Nodes の Kubernetes / GKE バージョンを常に最新版に自動的に更新
● Auto-scale (Cluster Autoscaler)
○ 需要に応じて Node pool 内の Nodes 数を自動的に増減
● Auto-provision (beta)
○ Cluster Autoscaler の一部として動作し、リソースに最適な Node pool を作成・削除

45. GKE チームは Kubernetes 本体へのコントリビューションの内
40% 以上を占める！
→ Kubernetes は Google が論文で出した Borg (社内コンテナオーケストレー
ションシステム) からインスパイアされている
Kubernetes は Google の Borg からインスパイア
Source: CNCF, https://gke.page.link/KubernetesCompanyContributions

46. GCP の各種サービスとのインテグレーション
● Cloud IAM / Workload Identity
→ クラスタのアクセス制御、クラスタ内は RBAC で
● Stackdriver Monitoring & Logging
→ One click で Monitoring と Logging を設定
● Network Route , FW & Load Balancers (ingress)
→ HTTP LB, TCP/UDP LB, Route & FW ルールを自動的に作成
● Persistent Disk (PDHDD & PDSSD)
→ Stateful アプリケーションも PDHDD & PDSSD でサポート
→ ReplicaSet でも自動 PD のプロビジョニング
● GCP コンソールに Dashboard インテグレーション

47. Container-Optimized OS (COS)
● 高速なブート
→ スケールアウトが早い
● セキュリティ
→ コンテナに必要なコンポーネントだけを持つOS
→ Verified boot
● Open Source
→ https://cloud.google.com/container-optimized-os/

48. Demo 2
サービスの公開、スケール

49. Thank you!