Containers & Kubernetes

Kubernetes と GCP のリソースを統合して、よりシンプルで迅速なデプロイを実現

Google Cloud Kubernetes.jpg

※この投稿は米国時間 2020 年 1 月 29 日に、Google Cloud blog に投稿されたものの抄訳です。

コンテナと Kubernetes を採用すると、特にリソースを構成、維持する方法など、新しい処理方法を採用することになります。宣言型システムである Kubernetes では特定のリソースに対する意図を表現でき、そのリソースを継続的に調整しながら作成、更新します。命令型構成のアプローチとは異なり、Kubernetes スタイルの宣言型構成では、構成をバージョン管理システムに保存して YAML ファイルで定義するという GitOps のベスト プラクティスに従いやすくなります。   

ただし、Kubernetes で実行されるアプリケーションは、多くの場合、Cloud SQL や Cloud Storage などの Kubernetes 外部にあるリソースを使用します。通常、これらのリソースは同じ構成のアプローチを使用しません。そのため、チーム間で摩擦が生じ、デベロッパーは頻繁な「コンテキスト スイッチ」の使用を強いられます。さらに、これらのアプリケーションを構成して運用するには、外部リソース、Kubernetes リソースの順に構成して、最後に前者を後者で使用できるようにするという複数ステップのプロセスが必要になります。

このような状況に対処するため、Google では本日、Config Connector の一般提供を発表しました。これは Google Cloud Platform(GCP)リソースを Kubernetes リソースとして管理できるようにするもので、アプリケーション全体を 1 つの場所で構成できるようになります。

Config Connector は Kubernetes オペレータで、すべての GCP リソースを Kubernetes リソースであるかのように動作させるため、インフラストラクチャを管理するためにさまざまな規則やツールを学習して使用する必要がなくなります。Config Connector により、Kubernetes からすべてのクラウド インフラストラクチャを統一かつ一貫した方法で管理できるようになるため、クラウド ネイティブのデベロッパーは運用とリソース管理を簡素化できます。

インフラストラクチャの整合性を自動化

Kubernetes では、その宣言型アプローチにより、管理するリソースが継続的に調整されています。Kubernetes によって管理されるリソースは継続的に監視され、常にユーザーの望ましい状態を維持できるように「自己修復」されます。ただし、Kubernetes 以外のリソース(SQL サーバー インスタンスなど)の監視と調整は、別のワークフローとして行われます。極端な場合、Cloud Spanner ノード数の変更など、望ましい構成への変更が監視やアラートのインフラストラクチャに伝播されず、そのため誤報が生じてチームに余計な作業が発生する可能性があります。

Config Connector を使用してこれらのリソースを Kubernetes リソースとして扱うことで、インフラストラクチャ全体でリソースの調整が行われ、インフラストラクチャの結果整合性を達成する作業が自動化されます。SQL サーバー インスタンスを個別に起動して、別のワークフローとしてその変更を監視する代わりに、Config Connector により SQL サーバー インスタンスとそのインスタンス上の SQL データベースを作成します。Config Connector により作成したリソースは宣言型アプローチの一部となり、SQL サーバー インスタンスは他の Kubernetes デプロイとまったく同様に有効に自己修復されます。

Kubernetes のリソースモデルを使用すると、デプロイ スクリプトでリソースを明示的に順序指定する必要がなくなります。以下の YAML マニフェストに示すように、ポッド、デプロイ、その他のネイティブの Kubernetes リソースの場合と同様に、SQL インスタンスの完了を明示的に待機してからそのインスタンス上の SQL データベースのプロビジョニングを開始する必要はありません。

さらに、GCP リソースを Kubernetes オブジェクトとして定義することで、これらのリソースで Kubernetes のラベルやセレクタなどの使い慣れた Kubernetes 機能を活用できるようになります。たとえば、ここではリソースでラベルとしてコストセンターを使用しました。これで、kubectl get を使用してこのラベルでフィルタできるようになります。さらに、Anthos Policy Controller などのアドミッション コントローラを使用して、組織のガバナンス ポリシーを適用できます。たとえば、次のようにして、コストセンターのラベルがクラスタ内のすべてのリソースに存在し、許容範囲の値のみを持つように強制できます。
  apiVersion: sql.cnrm.cloud.google.com/v1beta1
kind: SQLInstance
metadata:
  name: my-sql-instance
  labels:
   cost-center: "cc9"
spec:
  databaseVersion: MYSQL_5_7
  region: us-central1
  settings:
    tier: db-f1-micro
------
apiVersion: sql.cnrm.cloud.google.com/v1beta1
kind: SQLDatabase
metadata:
  name: my-sql-db
  labels:
   cost-center: "cc9"
spec:
  instanceRef:
    name: my-sql-instance

簡素化された運用で開発を迅速化

Etsy では、Kubernetes はクラウドへの移行を支援する手段でしたが、そのアプリケーションは複雑で、複数の場所でリソースを管理しており、そのためデプロイが遅くなっていました。

「Etsy では、多数の環境にわたってカスタムコードとクラウド リソースを組み合わせる複雑な Kubernetes アプリケーションを実行しています。Config Connector を使用することで、Etsy では 2 つの個別の切断された CI / CD パイプラインから、両方のアプリケーション コードとそれに必要なインフラストラクチャに対応する単一のパイプラインに移行できます。Config Connector により配信が簡素化され、クラウド インフラストラクチャの変更をエンドツーエンドでテストできるようになります。これにより、クラウド インフラストラクチャの迅速なデプロイと摩擦の低減が期待されます。」 - Etsy 社シニア スタッフ ソフトウェア エンジニア Gregg Donovan 氏

Config Connector を使ってみる

現在、Config Connector を使用して、Bigtable、BigQuery、IAM ポリシー、サービス アカウントおよびサービス アカウントキー、Pub/Sub、Redis、Spanner、Cloud SQL、Cloud Storage、Compute Engine、Networking、Cloud Load Balancer など、60 以上の GCP サービスの管理が可能となっています。

Config Connector は任意の Kubernetes クラスタにスタンドアロンでインストールでき、また Anthos Config Management に統合してハイブリッドおよびマルチクラウド環境を管理することもできます。今すぐ Config Connector の使用を開始して、GKE および GCP 全体での構成管理を簡素化しましょう。 

- By プロダクト マネージャー Sonam Saxena