このドキュメントでは、アプリケーションを Google Kubernetes Engine クラスタにデプロイする方法について説明します。
Cloud Deploy では、コンテナベースのワークロードを任意の Google Kubernetes Engine クラスタにデプロイできます。GKE ターゲットにデプロイする際には、Cloud Deploy のすべての機能がサポートされます。
始める前に
デプロイする 1 つ以上の GKE クラスタがある。
デプロイする GKE クラスタがない場合は、クラスタを作成できます。
実行サービス アカウントに、必要なロールと権限があることを確認します。
この skaffold.yaml ファイルでは、deploy スタンザに kubectl が含まれています。これは、Skaffold が Kubernetes（GKE）でレンダリングされ、デプロイされていることを示します。このアプリケーションに使用するマニフェストが、その下に表示されます。
ターゲット構成を作成する
各ターゲットは、デリバリー パイプライン YAML で構成することも、別のファイルで構成することもできます。また、同じファイルに複数のターゲットを構成できますが、それらは異なる kind: Target スタンザに存在する必要があります。
ターゲット定義で、GKE クラスタを参照する 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 です。
限定公開クラスタにデプロイする
次の 2 つの方法のいずれかを使用して、アプリケーションを限定公開 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 ターゲットを使用してゲートウェイを接続する
Anthos ターゲットと接続ゲートウェイを使用して、限定公開 GKE クラスタにデプロイするターゲットを構成できます。
このアプローチでは、Virtual Private Cloud または Virtual Private Network 接続を使用する必要はありません。