[Cloud OnAir] Dive to Google Kubernetes Engine 2018年8月2日 放送
•
2 likes•1,282 views
Google Kubernetes Engine (GKE) を活用して、高速にデプロイ可能かつ No-Ops なアプリケーション実行基盤を構築しましょう！ Continuous Delivery の実現方法、Container Registry を始めとするサービスとの連携方法や、特にこれから GKE を本番環境で動かすことを検討されている方、活用を促進していきたい方はお見逃しなく。
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to [Cloud OnAir] Dive to Google Kubernetes Engine 2018年8月2日 放送
Similar to [Cloud OnAir] Dive to Google Kubernetes Engine 2018年8月2日 放送 (20)
More from Google Cloud Platform - Japan
More from Google Cloud Platform - Japan (19)
Recently uploaded
Recently uploaded (8)
[Cloud OnAir] Dive to Google Kubernetes Engine 2018年8月2日 放送
- 1. Cloud Onr Cloud OnAir Cloud OnAir Dive into Google Kubernetes Engine 2018 年 8 月 2 日 放送
- 3. Cloud OnAir Google Kubernetes Engine (GKE)
- 4. Cloud OnAir コンテナオーケストレーション Cluster ● 複数のノードに対するコンテナのデプロイは？ ● ノード障害が発生した場合は？ ● コンテナ障害が発生した場合は？ ● アプリケーションのアップグレードはどうやって管理する？ Node NodeNode ??? コンテナ コンテナ コンテナ コンテナコンテナコンテナ
- 6. Cloud OnAir Kubernetes におけるクラスタとは クラスタ Kubernetes ノードプール(Node Pool) ノードプール(Node Pool)
- 7. Cloud OnAir Kubernetes Best Practicesも合わせて御覧ください
- 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
- 12. Cloud OnAir 共有 VPC を使用する上での注意事項
- 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等 のアカウントを指定可能
- 15. Cloud OnAir Role Based Access Control (RBAC)
- 16. Cloud OnAir ● 利用ケース ○ 1 つのクラスターを共有する ● 共有の単位・粒度 ■ 開発のステージ単位 (開発、ステージング、本番 ) ● 例：小規模のチーム ■ マイクロサービス単位 ● 例：規模が拡大中のチーム ■ チーム単位 ● 例：大規模な企業 ■ グループ単位 ● 例：大規模エンタープライズ企業 (multiple team in group, external company team) Role Based Access Control (RBAC)
- 18. Cloud OnAir CI/CD パイプラインの全体像 Cloud Build Build/ Test Artifact storage GCR GCS DeploySource CSR Monitor StackdriverCloud Build サードパーティーのソフトウェア /サービス (オンプレミス/クラウド)
- 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 ~~
- 25. Cloud OnAir プリエンプティブノードの活用イメージ バッチジョブ 耐障害性システム Nodepool (preemptible-pool) Node (n1-standard-1) Node (n1-standard-1) POD POD Nodepool (non-preemptible-pool) Node (n1-standard-1) Node (n1-standard-1) POD POD Nodepool (preemptible-pool) Node (n1-standard-1) Node (n1-standard-1) POD POD キュー
- 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
- 29. Cloud OnAir マルチゾーンクラスター 新規作成時または既存 クラスタにゾーンを追加する ことで設定可能 # マルチゾーンクラスタを作成する $ gcloud container clusters create my-cluster --zone asia-northeast1-a --node-locations asia-northeast1-b, asia-northeast1-c # 既存クラスタにゾーンを追加する $ gcloud beta container clusters update my-cluster --zone asia-northeast1-a --node-locations asia-northeast1-b
- 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
- 33. Cloud OnAir ログ収集 # ログ収集を有効にしてクラスタを作成する(デフォルトで 有効なため、明示的に指定しなくても問題ない) $ gcloud container clusters create my-cluster --enable-cloud-logging # 既存クラスタに対してログ収集を有効にする(ベータ) $ gcloud beta container clusters update my-cluster --logging-service logging.googleapis.com ● 特徴 ○ ログ管理を StackDriver Logging に 移譲 ○ ログ管理の効率化 ● 利用ケース ○ ログ管理を効率的に行いたい
- 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