[GKE & Spanner 勉強会] GKE 入門
11 likes4,112 views
2020 年 1 月 21 日開催 GKE & Cloud Spanner 勉強会【基礎編】 セッション：GKE 入門 講師：川原 雄太（Yutty） カスタマーエンジニア ゲーム業界担当
![[GKE & Spanner 勉強会] GKE 入門](https://image.slidesharecdn.com/gke01-200121090059/85/GKE-Spanner-GKE-11-320.jpg)
[GKE & Spanner 勉強会] GKE 入門
- 1. GKE & Spanner 勉強会 【基礎編】 2020.01.21 #gke_spanner
- 3. 1. コンテナと Kubernetes 2. Kubernetes のアーキテクチャ 3. Kubernetes における基本リソース 4. Google Kubernetes Engine (GKE) vs Kubernetes GKE 入門のアジェンダ
- 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
- 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)
- 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 つのモードを選択可能
- 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
- 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/
- 49. Thank you!