More Related Content
Similar to [Cloud OnAir] Dive to Google Kubernetes Engine 2018年8月2日 放送 (20)
More from Google Cloud Platform - Japan (19)
[Cloud OnAir] Dive to Google Kubernetes Engine 2018年8月2日 放送
- 9. Cloud OnAir
COS (Container-Optimized OS)
● 特徴
○ Google Compute Engine, Kubernetes Engine で
利用可能なセキュア・軽量 OS
○ 最低限のプロセスのみ動作
○ ブート時、ブートイメージの改竄チェック
○ 大部分が read only もしくは ephemeral fs
○ コンテナは sandbox で動作
○ AppArmor によるプロセス制限
○ サービス Listen ポートの最小化
○ 自動 OS アップデート
● 利用ケース
○ Node レベルのセキュリティを強化したい
○ GKE をフル活用したい
- 10. Cloud OnAir
限定公開クラスタ(Private Cluster)の活用 (ベータ)
● 特徴
○ クラスタへのアクセスを VPC 内に限定
○ プライベート Google アクセスにより、外部 IP を
持たずに Google のマネージド・サービスとの
通信が可能
○ インターネット上のサービスと通信をする場合は NAT
サーバが必要
● 利用ケース
○ エンタープライズで求められる、プライベート
セキュリティモデル (インターネットから隔離 )の
実現
- 11. Cloud OnAir
共有 VPC の活用(ベータ)
● 特徴
○ クラスタ作成時、共有 VPC に対して
クラスタをデプロイできる
● 利用ケース
○ ネットワークチームによる統制を
効かせたい
○ 支払いやトラッキング容易性の観点で
GCP プロジェクトを分割したい
○ 機密情報をプロジェクトレベルで
分割し、IAM で管理したい GCP Project
Compute Resources
(e.g.; GCE, GKE)
GCP Project
Compute Resources
(e.g.; GCE, GKE)
GCP Project
Routes
VPC Network
Subnetwork
Compute Resources
(e.g.; GCE, GKE)
Subnetwork
Firewall
Rules
- 13. Cloud OnAir
● 特徴
○ RBAC によりユーザーもしくはサービスアカウントの権限を制御できる
■ 注) IAM と異なり、Google グループに権限を割り当てることはできません
○ IAM はクラスターレベルの制御、クラスター内の権限制御は RBAC を用いる
○ RBAC により権限をネームスペースに適応できる
Role Based Access Control (RBAC)
Project_1
参照
グループ
クラスター
ノード ノード
ネームスペース(custom)
ネームスペース(default)
Pod Pod
PodPod
ユーザー
POD作成
- 14. Cloud OnAir
Role Based Access Control (RBAC)
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
namespace: microservice-a
name: msa-dev
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get","list","watch"]
- apiGroups: ["extensions","apps"]
resources: ["deployments","replicasets"]
verbs: ["get","list","watch"]
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: msa-devteam
namespace: microservice-a
subjects:
- kind: User
name: first_user@samuraitaiga.io
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: msa-dev
apiGroup: rbac.authorization.k8s.io
Role の定義 Binding の定義
G Suite, Cloud Identity等
のアカウントを指定可能
- 16. Cloud OnAir
● 利用ケース
○ 1 つのクラスターを共有する
● 共有の単位・粒度
■ 開発のステージ単位 (開発、ステージング、本番 )
● 例:小規模のチーム
■ マイクロサービス単位
● 例:規模が拡大中のチーム
■ チーム単位
● 例:大規模な企業
■ グループ単位
● 例:大規模エンタープライズ企業 (multiple team in group, external
company team)
Role Based Access Control (RBAC)
- 19. Cloud OnAir
● 特徴
○ プライベート Git リポジトリ
○ StackDriver を用いた分析との簡単な統合
○ Google 管理アカウント(G Suite、Cloud Identity、
サードパーティー アカウント管理等)を使った
リポジトリへのアクセス権設定
● 利用ケース
○ アプリケーションのデバッグ速度を上げたい
○ リポジトリの認証を G Suite・Cloud Identityに
統合したい
Cloud Source Repository
- 20. Cloud OnAir
Cloud Source Repository
リポジトリ
グループ
(Google グループ)
書き込み
ユーザー ユーザー ユーザー
GCP で管理
G 管理アカウントで
管理
リポジトリ
グループ
(Google グループ)
書き込み
GCP で管理
G 管理アカウントで
管理
社員グループ
(Google グループ、
G Suite)
パートナーグループ
(Google グループ、
Cloud Identity)
エンタープライズでのアカウント管理小規模チームでのアカウント管理
- 21. Cloud OnAir
● 特徴
○ マネージドな継続的なビルド・テスト・デプ
ロイをするためのサービス
○ ビルドを自動化するトリガー
○ 様々なビルドソースに対応 (GCS、CSR、
サードパーティー)
● 利用ケース
○ CI/CD を実現してデプロイを高度化
○ CI/CD における、ビルドに時間が
かかっているため高速化したい
Cloud Build
# cloudbuild.yaml
steps:
- name: gcr.io/cloud-builders/gcloud
args: ['app', 'deploy']
gcloud builds submit
--config cloudbuild.yaml .
- 22. Cloud OnAir
Google Container Registry
● 特徴
○ Docker イメージをプライベート保存
○ Opt-in 可能な脆弱性スキャン機能
○ イメージ変更時、脆弱性情報が
発見/更新時に Pub/Sub に情報を
Push 可能※1
● 利用ケース
○ コンテナレベルのセキュリティを
強化したい
○ 定期的に行っている脆弱性の情報収集に
関するコストを削減したい
※1 イメージ変更時の通知はベータ、脆弱性情報の通知はアルファ
- 24. Cloud OnAir
● 特徴
○ 最大 24 時間しか稼働しないが、
最大 80%コストが削減できるノード
○ プリエンプティブノード上の Pod は
graceful shutdown されることが
保証されない
● 利用ケース
○ バッチジョブを低コストで実行したい
○ 耐障害性のあるシステムを低コストで
実行したい
プリエンプティブノード(ベータ)
$ kubectl describe node xxx
~~
Name: xxx
Roles: <none>
Labels:
cloud.google.com/gke-preemptible=true
~~
- 26. Cloud OnAir
● 特徴
○ GUI から簡単に GPU 利用可能な
クラスタを作成可能
○ GPU 演算を簡単にクラウド上に
スケール可能
○ プリエンプティブノード、
クラスタオートスケールと
組み合わせて更に効率化が可能
● 利用ケース
○ ローカルで行っている GPU 演算を
スケールさせたい
○ GPU リソースをチーム・組織で
共有して利用したい
GPU の活用(ベータ)
$ kubectl describe node xxx
~~
capacity:
cpu: 1
ephemeral-storage: 98868448Ki
hugepages-2Mi: 0
memory: 3787652Ki
nvidia.com/gpu: 2
pods: 110
~~
- 28. Cloud OnAir
ノードの自動復旧
COS(Container-Optimized OS) を
選択した場合に利用可能。
継続的にヘルスチェックを行い、
長時間にわたって(10 分前後)
ヘルスチェックに失敗すると、
修復プロセスを開始する
# ノードの自動修復を有効にしてクラスタを作成する
$ gcloud container clusters create my-cluster
--enable-autorepair
# 既存クラスタに対して自動修復を有効にする
$ gcloud container clusters update my-cluster
--node-pool=default-pool
--enable-autorepair
# 既存ノードプールに対して自動修復を有効にする
$ gcloud container node-pools update default-pool
--cluster=my-cluster
--enable-autorepair
- 30. Cloud OnAir
クラスタオートスケール
ノードプールに設定された
ノードのテンプレートが採用
つまり同じ種類のノードが
スケールする
# クラスタオートスケーラーを設定してクラスタを作成する
$ gcloud container clusters create my-cluster
--enable-autoscaling
--min-nodes 3 --max-nodes 10
# 既存クラスタに対してクラスタオートスケーラーを有効にする
$ gcloud container clusters update my-cluster
--node-pool=default-pool
--enable-autoscaling
--min-nodes 3 --max-nodes 10
# 既存ノードプール default-pool に対してクラスタオートスケーラーを有効に
する
$ gcloud container clusters update my-cluster
--node-pool=default-pool
--enable-autoscaling
--min-nodes 3 --max-nodes 10
- 31. Cloud OnAir
● 制約
○ 最大 1000 ノード
○ 各ノードで可動できる Pod 数 30
○ スケールダウン時は 10 分間の 猶予期間があり、それを超えると Pod は
強制終了されてしまう。
● スケールイン(ノード削除)を防ぐための条件
○ Pod affinity もしくは anti-affiniti が設定している
○ ローカルストレージを持っている Pod
○ Deployment、StatefulSet, Job or ReplicaSet などのコントローラーによって
管理されていない Pod
○ PodDisruptionBudget が設定されており、Node 削除により Budget を超えてしまう場合
クラスタオートスケールの活用
- 32. Cloud OnAir
リージョナルクラスタ(ベータ)
● 特徴
○ 1 つのリージョンにおいて、 master
および node を複数ゾーンに配置
● 利用ケース
○ システムの冗長性を上げたい
○ master のソフトウェア更新時にも
master を利用不可にしたくない
# リージョナルクラスタを作成する
$ gcloud beta container clusters create
my-regional-cluster
--region=asia-northeast1
--node-locations=asia-northeast1-b,asia-nort
heast1-c
- 34. Cloud OnAir
● Structured Logging
○ 標準出力、標準エラーに出力される”単一行”の JSON String は
structured log として Stackdriver へ読み込まれる。
ログ収集の活用
# echo "{"message": "hello", "severity": "CRITICAL",
"my_vars": 123}" >&2
{"message": "hello", "severity": "CRITICAL", "my_vars": 123}
- 35. Cloud OnAir
ログ収集の活用
● Severity
○ 標準出力へ書き込まれるメッセージは情報 (INFO) として保存、標準エラーに
書き込まれるメッセージはエラー (ERROR) として保存される。
Severity をカスタマイズしたい Structured Logging を使用する。
● BigQuery へエクスポートする
○ エクスポート機能を用いて BigQuery、Pub/Sub などへエクスポートが可能。 BigQuery
へエクスポートされたログのフォーマットと構造は保持される。
● アラートを設定する
○ ログベースの指標を使用して、 Stackdriver Monitoring でアラートを設定可能。
- 36. Cloud OnAir
ログ収集の活用イメージ
Log Ingestion /
Processing Layer
Storage
Layer
Container App
GKE/Kubernetes
ログ基盤 /
データウェア
ハウス
BigQuery
Application &
Presentation
App
Engine
分析者
Cloud
Datalab
Stackdriver
Logging
BI Interface
Data Studio
Cloud
Pub/Sub
Cloud
Dataflow
Application Layer
- 38. Google Kubernetes Engine は
コンテナ化されたアプリケーションをデプロイする
プロダクションレディかつマネージドの環境です。
本日ご紹介した様々な機能、使い方を活用することで
一歩進んだコンテナによるサービス運用を実現しましょう!
Cloud OnAir