このドキュメントでは、Google Kubernetes Engine クラスタにアプリケーションをデプロイする方法について説明します。
Cloud Deploy を使用すると、コンテナベースのワークロードを任意の Google Kubernetes Engine クラスタにデプロイできます。GKE ターゲットにデプロイする場合、Cloud Deploy のすべての機能がサポートされます。
始める前に
デプロイする 1 つ以上の GKE クラスタがある。
デプロイする GKE クラスタがない場合は、作成できます。
実行サービス アカウントに必要なロールと権限があることを確認します。
この skaffold.yaml ファイルの deploy スタンザには kubectl が含まれています。これは、Skaffold が Kubernetes（GKE）用にレンダリングし、GKE にデプロイすることを示します。このアプリケーションに使用するマニフェストがそこに表示されます。
ターゲット構成を作成する
各ターゲットは、デリバリー パイプライン YAML で構成することも、別のファイルで構成することもできます。また、同じファイルで複数のターゲットを構成することもできますが、異なる kind: Target スタンザに配置する必要があります。
ターゲットは、配信パイプラインと同じプロジェクトとリージョンで定義する必要があります。ただし、サービス アカウントがそれらのプロジェクトにアクセスできる限り、ターゲットがデプロイされるクラスタは、異なるプロジェクトとリージョンに配置できます。
ターゲット定義で、GKE クラスタを参照する gke スタンザを作成します。
gke:
cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]
この GKE リソース ID では、次の要素が使用されます。
[
project_name] は、このクラスタを実行する Google Cloud プロジェクトの名前です。デプロイするクラスタは、デリバリー パイプラインと同じプロジェクトにある必要はありません。
[
location] は、クラスタが作成されたリージョンです。[
cluster_name] は、クラスタの作成時に付けられた名前です。この名前は、Google Cloud コンソールのプロジェクトのクラスタのリストで確認できます。
次のターゲット構成は、GKE クラスタを参照しています。
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
name: dev
description: development cluster
gke:
cluster: projects/my-app/locations/us-central1/clusters/my-app-dev-cluster
Skaffold 構成を作成する
このセクションでは、GKE クラスタにデプロイするときに使用する簡単な Skaffold 構成の例について説明します。
GKE クラスタにデプロイする skaffold.yaml ファイルの例を次に示します。
apiVersion: skaffold/v4beta7
kind: Config
metadata:
name: gke-application
manifests:
rawYaml:
- deployment.yaml
deploy:
kubectl: {}
Cloud Deploy で Skaffold を使用するでは、デリバリー パイプラインで Skaffold を使用する方法について詳しく説明します。
Kubernetes マニフェストを準備する
アプリケーションを GKE にデプロイするには、Cloud Deploy に 1 つ以上の Kubernetes マニフェストを指定します。このマニフェストをレンダリングしてから、アプリケーションをデプロイするターゲット クラスタに適用します。
これらのマニフェストがない場合は、Cloud Deploy 配信パイプラインを使用してデプロイする前に作成します。
マニフェストの作成には、Kustomize または Helm を使用できます。マニフェストがテンプレート化されていてレンダリングが必要な場合は、Kustomize または Helm を使用することもできます。
すべてを組み合わせる
Kubernetes マニフェスト、skaffold.yaml 構成、Cloud Deploy ターゲット定義を作成し、Cloud Deploy リソースとしてターゲットを登録したため、デリバリー パイプラインを呼び出して、リリースを作成し、パイプラインで定義されたターゲットの進行状況に沿って進めることができます。
プロキシを使用してデプロイする
ターゲット GKE クラスタのプロキシを指定できます。これは、プロキシ経由でのみクラスタにアクセスするように設定されている組織を対象としています。
これを行うには、ターゲット構成の gke スタンザに proxyUrl プロパティを追加します。
gke:
cluster: projects/my-app/locations/us-central1/clusters/my-app-dev-cluster
proxyUrl: [URL]
ここで、URL はプロキシの URL です。
限定公開クラスタにデプロイする
限定公開 GKE クラスタにアプリケーションをデプロイするには、次のいずれかの方法を使用します。
Virtual Private Cloud ネットワークを使用する
Virtual Private Cloud ネットワークに接続された限定公開 GKE クラスタにデプロイするようにターゲットを構成できます。
-
限定公開クラスタは、ノードと Pod がデフォルトで公共のインターネットから分離されている VPC ネイティブ クラスタです。
限定公開クラスタ ターゲットの内部 IP を使用する場合は、ターゲット構成の
gkeでinternalIpをtrueに設定します。 Cloud Build で、この限定公開クラスタにデプロイするために使用できる限定公開ワーカープールを作成します。
そのプライベート プールを使用するように実行環境を構成します。
RENDERにはこのプールを使用する必要があります。DEPLOYとVERIFYにも使用できます。RENDERとDEPLOYを使用する例を次に示します。executionConfigs: - usages: - RENDER - DEPLOY workerPool: "projects/p123/locations/us-central1/workerPools/wp123"
詳細は、GKE 用 Identity Service を使用して Cloud Build プライベート プールから限定公開 GKE クラスタにアクセスするおよび Cloud Build プライベート プールで限定公開 GKE クラスタにアクセスするをご覧ください。
プロジェクトと権限に関する考慮事項
プライベート クラスタにデプロイできるプライベート ワーカープールを使用するようにターゲットを構成できます。ただし、リソースが異なるプロジェクトにある場合は、注意すべき点があります。
- Cloud Deploy とワーカープールが別々のプロジェクトにある場合
VPC にアクセスでき、ターゲットとは異なるプロジェクトにあるプライベート プールと通信するには、Cloud Deploy サービス エージェントに通信するための十分な権限が必要です。
実行サービス アカウントには、Cloud Storage バケットにアクセスする権限も必要です。
- ワーカープールとクラスタが別々のプロジェクトにある場合
限定公開 GKE クラスタが限定公開のワーカープールとは異なるプロジェクトにある場合、実行サービス アカウントには、クラスタが存在するプロジェクトと通信するための十分な権限が必要です。
GKE Enterprise ターゲットと Connect Gateway を使用する
Anthos ターゲットと接続ゲートウェイを使用して、限定公開の GKE クラスタにデプロイするターゲットを構成できます。
このアプローチでは、Virtual Private Cloud または仮想プライベート ネットワーク接続を使用する必要はありません。