GKE Cluster
GCP Managed Services namespace
namespace GCP Managed
Services
GCP Managed Services
GCP Managed Services namespace
namespace
Team: SRE Team: App2 Team: App1
開発環境からプロダクション環境において、一貫した環境と、アプリケーション開発に
集中できる環境を作るために、適切な
(
最小限の)
認証/
認可を各チームに払い出すことを目的とし ます。“OIDC” を使った ユーザベースの認証 .
G Suite users
GKE On-Prem Control 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 Google Group01 Namespace 01
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 Source Repositories
Cloud Build
Container
Registry Spinnaker Kubernetes
Engine
Jenkins Postman
GitHub Code Push
Sync
Deploy/
Rollback
Scenario Test
Kick Test Return Result Call Test
Return Result Developer
開発 テスト デプロイ オペレーション
プロセス間も含めた一貫した自動化
開発からオペレーションに至る一貫したプロセスの自動化
/
省人化を通して 実現したいと考えています。CI / CD パイプラインで実現したいこと
Cloud Source Repositories
Cloud Build
Container
Registry Spinnaker Kubernetes
Engine
Jenkins Postman
GitHub Code 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 Build Cloud Build
Image Store Container Registry
コンテナ実行環境 GKE On-Prem
image pull
IAM
機能を利用してサービスアカウントに事前に認 可を譲渡
GKE On-Prem
でもcluster
利用の際のサービスアカウントをCloud Build
側のIAM
に登録するこ とで利用が可能です.
そのため、クラウドでの利用と多くを変えずに設計が可能なことを確認していま す。CI / CD パイプラインで実現したいこと
Cloud Source Repositories
Cloud Build
Container
Registry Spinnaker Kubernetes
Engine
Jenkins Postman
GitHub Code Push
Sync
Deploy/
Rollback
Scenario Test
Kick Test Return Result Call Test
Return Result Developer
開発 テスト デプロイ オペレーション
プロセス間も含めた一貫した自動化
基本的に変更は不要
開発からオペレーションに至る一貫したプロセスの自動化
/
省人化を通して 実現したいと考えています。本格導入に向けて考慮しておきたいこと .
01
認証
/
認可を適切に設定Kubernetes
のAPI
へのアクセス をどのように制御すべきかを中心に、RBAC
の設定ポリシーを明確にしま す。02
デプロイパイプラインの設計
オンプレミス側にあっても
可用性を担保しつつ、クラウドに近い 形でデプロイパイプラインの設計がで きることがベストです。
03
メトリクス管理
いかに有効なメトリクスを管理するか 設計と同時に、マネージドサービスとうま く組み合わせて利用できる設計をしま す。