ビルド パイプラインまたはリリース パイプラインで Kubernetes マニフェスト タスクを使用して、Helm チャートを使用してマニフェストをベイクし、Kubernetes クラスターにデプロイします。
このバージョンのタスクは非推奨です。 KubernetesManifest@1 を使用して、 ワークロード ID フェデレーションなどの最新機能を利用できます。
ビルド パイプラインまたはリリース パイプラインで Kubernetes マニフェスト タスクを使用して、Helm チャートを使用してマニフェストをベイクし、Kubernetes クラスターにデプロイします。
構文
# Deploy to Kubernetes v0
# Use Kubernetes manifest files to deploy to clusters or even bake the manifest files to be used for deployments using Helm charts.
- task: KubernetesManifest@0
inputs:
#action: 'deploy' # 'bake' | 'createSecret' | 'delete' | 'deploy' | 'patch' | 'promote' | 'scale' | 'reject'. Action. Default: deploy.
#kubernetesServiceConnection: # string. Required when action != bake. Kubernetes service connection.
#namespace: # string. Namespace.
#strategy: 'none' # 'canary' | 'none'. Optional. Use when action = deploy || action = promote || action = reject. Strategy. Default: none.
#trafficSplitMethod: 'pod' # 'pod' | 'smi'. Optional. Use when strategy = canary. Traffic split method. Default: pod.
#percentage: '0' # string. Required when strategy = Canary && action = deploy. Percentage. Default: 0.
#baselineAndCanaryReplicas: '1' # string. Required when strategy = Canary && action = deploy && trafficSplitMethod = SMI. Baseline and canary replicas. Default: 1.
#manifests: # string. Required when action = deploy || action = promote || action = reject. Manifests.
#containers: # string. Optional. Use when action = deploy || action = promote || action = bake. Containers.
#imagePullSecrets: # string. Optional. Use when action = deploy || action = promote. ImagePullSecrets.
#renderType: 'helm' # 'helm' | 'kompose' | 'kustomize'. Optional. Use when action = bake. Render Engine. Default: helm.
#dockerComposeFile: # string. Required when action = bake && renderType = kompose. Path to docker compose file.
#helmChart: # string. Required when action = bake && renderType = helm. Helm Chart.
#releaseName: # string. Optional. Use when action = bake && renderType = helm. Helm Release Name.
#overrideFiles: # string. Optional. Use when action = bake && renderType = helm. Override Files.
#overrides: # string. Optional. Use when action = bake && renderType = helm. Overrides.
#kustomizationPath: # string. Optional. Use when action = bake && renderType = kustomize. Kustomization Path.
#resourceToPatch: 'file' # 'file' | 'name'. Required when action = patch. Resource to patch. Default: file.
#resourceFileToPatch: # string. Required when action = patch && resourceToPatch = file. File path.
#kind: # 'deployment' | 'replicaset' | 'statefulset'. Required when action = scale || resourceToPatch = name. Kind.
#name: # string. Required when action = scale || resourceToPatch = name. Name.
#replicas: # string. Required when action = scale. Replica count.
#mergeStrategy: 'strategic' # 'json' | 'merge' | 'strategic'. Required when action = patch. Merge Strategy. Default: strategic.
#arguments: # string. Optional. Use when action = delete. Arguments.
#patch: # string. Required when action = patch. Patch.
#secretType: 'dockerRegistry' # 'dockerRegistry' | 'generic'. Required when action = createSecret. Type of secret. Default: dockerRegistry.
#secretName: # string. Optional. Use when action = createSecret. Secret name.
#secretArguments: # string. Optional. Use when action = createSecret && secretType = generic. Arguments.
#dockerRegistryEndpoint: # string. Optional. Use when action = createSecret && secretType = dockerRegistry. Docker registry service connection.
#rolloutStatusTimeout: '0' # string. Optional. Use when action = deploy || action = patch || action = scale || action = promote. Timeout for rollout status. Default: 0.
入力
action
-
アクションの
string
。 使用できる値: bake
、 createSecret
(シークレットの作成)、 delete
、 deploy
、 patch
、 promote
、 scale
、 reject
。 既定値: deploy
。
実行する操作を指定します。
Kubernetes サービス接続の kubernetesServiceConnection
-
string
。
action != bake
する場合に必要です。
Kubernetes サービス接続を指定します。
namespace
-
名前空間の
string
。
コマンドの名前空間を –namespace
フラグを使用して指定します。 名前空間が指定されていない場合、コマンドは既定の名前空間で実行されます。
strategy
-
戦略
string
。 任意。
action = deploy || action = promote || action = reject
するときに使用します。 使用できる値: canary
、none
。 既定値: none
。
promote
アクションまたは reject
アクションの前に deploy
アクションで使用されるデプロイメント方法を指定します。 現在、 canary
が唯一の許容可能なデプロイ戦略です。
trafficSplitMethod
-
トラフィック分割方式
string
。 任意。
strategy = canary
するときに使用します。 使用できる値: pod
、smi
。 既定値: pod
。
値 smi
の場合、トラフィックの割合の分割は、サービス メッシュを使用して要求レベルで行われます。 サービスメッシュは、クラスタ管理者が設定する必要があります。このタスクは、SMI TrafficSplit オブジェクトのオーケストレーションを処理します。
値 pod
の場合、サービス メッシュがない場合、要求レベルでの割合分割は不可能です。 代わりに、パーセンテージ入力を使用して、ベースラインとカナリアのレプリカが計算されます。 計算は、安定版バリアントの入力マニフェストで指定されたレプリカの割合です。
percentage
-
百分率
string
。
strategy = Canary && action = deploy
する場合に必要です。 既定値: 0
。
マニフェスト ファイルに含まれるワークロードの baseline-variant レプリカと canary-variant レプリカの数を計算するために使用される割合。
指定したパーセンテージ入力に対して、次のように計算します。
(レプリカ数×%)/ 100
結果が整数でない場合は、ベースラインとカナリアのバリアントが作成されるときに、結果の数学的フロアが使用されます。
たとえば、デプロイメント hello-world
が入力マニフェストファイルにあり、次の行がタスク入力にあるとします。
replicas: 4
strategy: canary
percentage: 25
この場合、デプロイメント hello-world-baseline
と hello-world-canary
は、それぞれ 1 つのレプリカで作成されます。 ベースライン バリアントは、安定バージョン (デプロイ前に 4 レプリカ バリアント) と同じイメージとタグを使用して作成されます。 Canary バリアントは、新しくデプロイされた変更に対応するイメージとタグを使用して作成されます。
baselineAndCanaryReplicas
-
ベースラインとカナリアレプリカ
string
。
strategy = Canary && action = deploy && trafficSplitMethod = SMI
する場合に必要です。 既定値: 1
。
trafficSplitMethod
を smi
に設定すると、トラフィック分割の割合はサービス メッシュ プレーンで制御されます。 Canary バリアントとベースラインバリアントのレプリカの実際の数は、トラフィックの分割とは無関係に制御できます。
たとえば、入力デプロイ マニフェストで stable バリアントに 30 個のレプリカが指定されているとします。 また、タスクに次の入力を指定するとします。
strategy: canary
trafficSplitMethod: smi
percentage: 20
baselineAndCanaryReplicas: 1
この場合、安定版はトラフィックの 80% を受け取り、ベースライン バリアントとカナリア バリアントはそれぞれ指定された 20 個のトラフィックの半分%を受け取ります。 ベースラインとカナリアのバリアントは、それぞれ 3 つのレプリカを受け取りません。 代わりに、指定された数のレプリカを受け取る、つまり、それぞれが 1 つのレプリカを受け取ります。
manifests
-
マニフェスト
string
。
action = deploy || action = promote || action = reject
する場合に必要です。
デプロイメントに使用するマニフェスト・ファイルへのパスを指定します。 各線は 1 つのパスを表します。 ファイルマッチングパターンは、各行で許容される値です。
containers
-
コンテナー
string
。 任意。
action = deploy || action = promote || action = bake
するときに使用します。
マニフェスト・ファイルの置換に使用するイメージの完全修飾リソース URL を指定します。 URL contosodemo.azurecr.io/helloworld:test
は一例です。
imagePullSecrets
-
ImagePullシークレット
string
。 任意。
action = deploy || action = promote
するときに使用します。
複数行の入力を指定し、各行には、クラスター内で既に設定されている Docker レジストリシークレットの名前が含まれます。 各シークレット名は、入力マニフェスト ファイルで見つかったワークロードの imagePullSecrets
の下に追加されます。
renderType
-
レンダリングエンジン
string
。 任意。
action = bake
するときに使用します。 使用できる値: helm
、kompose
、kustomize
。 既定値: helm
。
マニフェスト ファイルの生成に使用するレンダリング タイプを指定します。
dockerComposeFile
-
docker compose ファイルへのパス
string
。
action = bake && renderType = kompose
する場合に必要です。
docker-compose ファイルのパスを指定します。
helmChart
-
ヘルムチャート
string
。
action = bake && renderType = helm
する場合に必要です。
ベイクする Helm チャートのパスを指定します。
releaseName
-
Helm リリース名
string
。 任意。
action = bake && renderType = helm
するときに使用します。
使用する Helm リリース名を指定します。
overrideFiles
-
ファイルの上書き
string
。 任意。
action = bake && renderType = helm
するときに使用します。
オーバーライド ファイルへのパスを受け入れる複数行の入力を指定します。 これらのファイルは、Helm チャートのマニフェスト ファイルがベイクされるときに使用されます。
overrides
-
オーバーライド
string
。 任意。
action = bake && renderType = helm
するときに使用します。
設定するオーバーライド値を指定します。
kustomizationPath
-
Kustomization パス
string
。 任意。
action = bake && renderType = kustomize
するときに使用します。
ファイルを含むディレクトリへのパス、またはリポジトリのルートに対する same
を指定するパス サフィックスを持つ git リポジトリ URL である必要がある引数を指定します。
resourceToPatch
-
パッチを適用するリソース
string
。
action = patch
する場合に必要です。 使用できる値: file
、name
。 既定値: file
。
次のいずれかのパッチ方法を示します。
- マニフェスト ファイルは、パッチを適用するオブジェクトを識別します。
- 個々のオブジェクトは、種類と名前でパッチ ターゲットとして識別されます。
指定できる値は file と name です。
resourceFileToPatch
-
ファイル パスの
string
。
action = patch && resourceToPatch = file
する場合に必要です。
パッチに使用するファイルへのパスを指定します。
kind
-
種類
string
。
action = scale || resourceToPatch = name
する場合に必要です。 使用できる値: deployment
、replicaset
、statefulset
。
K8s オブジェクトの種類 ( deployment
、 replicaSet
など) を指定します。
name
-
名前
string
。
action = scale || resourceToPatch = name
する場合に必要です。
K8s オブジェクトの名前を指定します。
replicas
-
レプリカ数
string
。
action = scale
する場合に必要です。
スケーリング先のレプリカの数を指定します。
mergeStrategy
-
マージ戦略
string
。
action = patch
する場合に必要です。 使用できる値: json
、merge
、strategic
。 既定値: strategic
。
提供するパッチのタイプを指定します。
arguments
-
引数
string
。 任意。
action = delete
するときに使用します。
kubectl delete
コマンドの引数を指定します。 次に例を示します。 arguments: deployment hello-world foo-bar
patch
-
パッチ
string
。
action = patch
する場合に必要です。
パッチの内容を指定します。
secretType
-
シークレット の種類
string
。
action = createSecret
する場合に必要です。 使用できる値: dockerRegistry
、generic
。 既定値: dockerRegistry
。
ジェネリックまたは docker imagepullsecret
を作成または更新します。 選択したレジストリの dockerRegistry
を作成または更新する imagepullsecret
を指定します。
imagePullSecret
は、コンテナー レジストリ パスワードを含むシークレットを Kubelet に渡す方法であり、ポッドの代わりにプライベート イメージをプルできます。
シークレット名を secretName
- する
string
。 任意。
action = createSecret
するときに使用します。
シークレットの名前を指定します。 このシークレット名は、Kubernetes YAML 構成ファイルで使用できます。
secretArguments
-
引数
string
。 任意。
action = createSecret && secretType = generic
するときに使用します。
シークレットに挿入するキーとリテラル値を指定します。 たとえば、 --from-literal=key1=value1
--from-literal=key2="top secret"
。
Docker レジストリ サービス接続を dockerRegistryEndpoint
- する
string
。 任意。
action = createSecret && secretType = dockerRegistry
するときに使用します。
クラスタ内に Docker レジストリシークレットを作成するために使用される、指定したサービス接続の認証情報を指定します。
imagePullSecrets
フィールドの下のマニフェスト ファイルは、このシークレットの名前を参照できます。
rolloutStatusTimeout
-
ロールアウト状態のタイムアウト
string
。 任意。
action = deploy || action = patch || action = scale || action = promote
するときに使用します。 既定値: 0
。
watch on rollout
ステータスが終了するまでの待機時間(秒単位)を指定します。
タスク コントロールのオプション
すべてのタスクには、タスク入力に加えて制御オプションがあります。 詳細については、「コントロール オプションと一般的なタスク プロパティを参照してください。
出力変数
このタスクでは、次の 出力変数を定義します。この変数は、ダウンストリームのステップ、ジョブ、およびステージで使用できます。
manifestsBundle
ベイクアクションによって作成されるマニフェストバンドルの場所を指定します。
注釈
注
このタスクには、connectionType
プロパティを使用して、さまざまな方法で Kubernetes クラスターをターゲットにするための追加のサポートを提供する新しいバージョンがあります。 詳細については、「KubernetesManifest@1 と KubernetesManifest@1 サービス接続の解説」を参照してください
ビルド パイプラインまたはリリース パイプラインで Kubernetes マニフェスト タスクを使用して、マニフェストを Kubernetes クラスターにベイクしてデプロイします。
このタスクは、以下をサポートします。
アーティファクトの置換: デプロイ アクションは、指定できるコンテナ イメージのリストを、そのタグとダイジェストと共に入力として受け取ります。 同じ入力は、クラスターに適用される前に、テンプレート化されていないマニフェスト ファイルに置き換えられます。 この置換により、クラスターノードはイメージの正しいバージョンを確実にプルします。
マニフェストの安定性: デプロイされた Kubernetes オブジェクトのロールアウト ステータスがチェックされます。 安定性チェックは、タスクのステータスが成功か失敗かを判断するために組み込まれています。
トレーサビリティ注釈: デプロイされた Kubernetes オブジェクトに注釈が追加され、トレーサビリティ情報を重ね合わせます。 次のアノテーションがサポートされています。
- azure-pipelines/org
- azure-pipelines/プロジェクト
- azure-pipelines/パイプライン
- azure-pipelines/pipelineId
- azure-pipelines/実行
- azure-pipelines/executionuri
- azure-pipelines/ジョブ名
シークレット処理:
createSecret
アクションを使用すると、Docker レジストリ サービス接続を使用して Docker レジストリ シークレットを作成できます。 また、プレーンテキスト変数またはシークレット変数を使用して汎用シークレットを作成することもできます。 クラスターにデプロイする前に、secrets
入力とdeploy
アクションを使用して、入力マニフェスト ファイルを適切なimagePullSecrets
値で拡張できます。マニフェストのベイク: タスクの
bake
アクションにより、テンプレートを Kubernetes マニフェスト ファイルにベイクできます。 アクションでは、Helm、Compose、Kustomize などのツールを使用します。 ベイク処理を使用すると、これらの Kubernetes マニフェスト ファイルをクラスターへのデプロイに使用できます。デプロイ戦略:
deploy
アクションでcanary
戦略を選択すると、-baseline
と-canary
のサフィックスが付いたワークロード名が作成されます。 このタスクは、トラフィック分割の 2 つの方法をサポートしています。サービスメッシュインターフェイス: サービスメッシュインターフェイス (SMI)の抽象化により、
Linkerd
やIstio
などのサービスメッシュプロバイダーで構成できます。 Kubernetes マニフェスト タスクは、デプロイ戦略のライフ サイクル中に、SMITrafficSplit
オブジェクトを安定版、ベースライン、および Canary サービスにマッピングします。サービスメッシュに基づいており、このタスクを使用する Canary デプロイは、より正確です。 この精度は、サービス メッシュ プロバイダーがトラフィックの詳細なパーセンテージベースの分割を有効にする方法によるものです。 サービスメッシュは、ポッドに挿入されるサービスレジストリとサイドカーコンテナを使用します。 このインジェクションは、アプリケーションコンテナと一緒に行われ、きめ細かなトラフィック分割を実現します。
サービスメッシュのないKubernetes:サービスメッシュがない場合、リクエストレベルで必要な正確な割合の分割が得られない可能性があります。 ただし、安定版バリアントの隣にあるベースラインとカナリアバリアントを使用して、カナリアデプロイを行うことができます。
このサービスは、selector-label 制約が満たされると、3 つのワークロードバリアントすべてのポッドにリクエストを送信します。 Kubernetes マニフェストは、ベースラインとカナリアバリアントを作成するときにこれらのリクエストを尊重します。 このルーティング動作は、合計リクエストの一部のみを Canary にルーティングするという意図した効果を実現します。
リリース パイプラインの 手動介入タスク または YAML パイプラインの 遅延タスク を使用して、ベースライン ワークロードとカナリア ワークロードを比較します。 タスクの昇格または拒否アクションを使用する前に、比較を行ってください。
デプロイ アクション
次の YAML コードは、マニフェスト ファイルを使用して Kubernetes 名前空間にデプロイする例です。
steps:
- task: KubernetesManifest@0
displayName: Deploy
inputs:
kubernetesServiceConnection: someK8sSC1
namespace: default
manifests: |
manifests/deployment.yml
manifests/service.yml
containers: |
foo/demo:$(tagVariable1)
bar/demo:$(tagVariable2)
imagePullSecrets: |
some-secret
some-other-secret
上記の例では、タスクはマニフェスト ファイルのイメージ フィールド内のイメージ foo/demo
と bar/demo
のイメージの一致を見つけようとします。 一致が見つかるたびに、 tagVariable1
または tagVariable2
の値が画像名にタグとして追加されます。 また、成果物の置換のために、コンテナー入力でダイジェストを指定することもできます。
注
デプロイ戦略に関連する YAML 入力を使用して deploy
、 promote
、 reject
アクションを作成できますが、手動介入タスクのサポートは現在、ビルド パイプラインでは使用できません。
リリース パイプラインの場合は、デプロイ戦略に関連するアクションと入力を次の順序で使用することをお勧めします。
-
strategy: canary
とpercentage: $(someValue)
で指定されたデプロイ アクション。 - パイプラインを一時停止し、ベースラインバリアントとカナリアバリアントを比較できるようにするための手動介入タスク。
- 手動介入タスクが再開された場合に実行される昇格アクションと、手動介入タスクが拒否された場合に実行される拒否アクション。
シークレットアクションの作成
次の YAML コードは、 Docker レジストリ サービス接続を使用した Docker レジストリ シークレットの作成例を示しています。
steps:
- task: KubernetesManifest@0
displayName: Create secret
inputs:
action: createSecret
secretType: dockerRegistry
secretName: foobar
dockerRegistryEndpoint: demoACR
kubernetesServiceConnection: someK8sSC
namespace: default
この YAML コードは、汎用シークレットの作成例を示しています。
steps:
- task: KubernetesManifest@0
displayName: Create secret
inputs:
action: createSecret
secretType: generic
secretName: some-secret
secretArguments: --from-literal=key1=value1
kubernetesServiceConnection: someK8sSC
namespace: default
ベイクアクション
次の YAML コードは、Helm チャートからマニフェスト ファイルをベイクする例です。 最初のタスクで名前入力が使用されていることに注意してください。 この名前は、ベイク ステップによって生成されたマニフェストへのパスを指定するために、後でデプロイ ステップから参照されます。
steps:
- task: KubernetesManifest@0
name: bake
displayName: Bake K8s manifests from Helm chart
inputs:
action: bake
helmChart: charts/sample
overrides: 'image.repository:nginx'
- task: KubernetesManifest@0
displayName: Deploy K8s manifests
inputs:
kubernetesServiceConnection: someK8sSC
namespace: default
manifests: $(bake.manifestsBundle)
containers: |
nginx: 1.7.9
注
Helm を直接使用してリリースとロールバックを管理するには、「 Helm チャートのパッケージ化とデプロイ」タスクを参照してください。
Kustomizeの例
次の YAML コードは、 kustomization.yaml
ファイルを含む Kustomize で生成されたマニフェスト ファイルをベイクする例です。
steps:
- task: KubernetesManifest@0
name: bake
displayName: Bake K8s manifests from kustomization path
inputs:
action: bake
renderType: kustomize
kustomizationPath: folderContainingKustomizationFile
- task: KubernetesManifest@0
displayName: Deploy K8s manifests
inputs:
kubernetesServiceConnection: k8sSC1
manifests: $(bake.manifestsBundle)
Komposeの例
次の YAML コードは、Docker Compose の変換ツールである Komppose で生成されたマニフェスト ファイルをベイクする例です。
steps:
- task: KubernetesManifest@0
name: bake
displayName: Bake K8s manifests from Docker Compose
inputs:
action: bake
renderType: kompose
dockerComposeFile: docker-compose.yaml
- task: KubernetesManifest@0
displayName: Deploy K8s manifests
inputs:
kubernetesServiceConnection: k8sSC1
manifests: $(bake.manifestsBundle)
スケーリング アクション
次の YAML コードは、スケーリング オブジェクトの例を示しています。
steps:
- task: KubernetesManifest@0
displayName: Scale
inputs:
action: scale
kind: deployment
name: bootcamp-demo
replicas: 5
kubernetesServiceConnection: someK8sSC
namespace: default
パッチアクション
次の YAML コードは、オブジェクトのパッチ適用の例を示しています。
steps:
- task: KubernetesManifest@0
displayName: Patch
inputs:
action: patch
kind: pod
name: demo-5fbc4d6cd9-pgxn4
mergeStrategy: strategic
patch: '{"spec":{"containers":[{"name":"demo","image":"foobar/demo:2239"}]}}'
kubernetesServiceConnection: someK8sSC
namespace: default
削除アクション
この YAML コードは、オブジェクトの削除のサンプルを示しています。
steps:
- task: KubernetesManifest@0
displayName: Delete
inputs:
action: delete
arguments: deployment expressapp
kubernetesServiceConnection: someK8sSC
namespace: default
トラブルシューティング
Kubernetes クラスターはファイアウォールの内側にあり、ホステッド エージェントを使用しています。 このクラスターにデプロイするにはどうすればよいですか?
ホステッド エージェントに対する IP アドレスを許可することにより、ファイアウォール経由のホステッド エージェントへのアクセスを許可できます。 詳細については、エージェントの IP 範囲に関する記事を参照してください。
カナリア デプロイを使用した安定したサービス ルートとバリアント型のサービス ルートに対する要求はどのように機能しますか?
Kubernetes のポッドとサービス間のラベル セレクター関係を使用すると、1 つのサービスが安定したバリアントとカナリア バリアントの両方に要求をルーティングするようにデプロイを設定できます。 Kubernetes マニフェスト タスクは、カナリア デプロイにこれを使用します。
タスクに action: deploy
と strategy: canary
の入力が含まれている場合、入力マニフェスト ファイルで定義されている各ワークロード (Deployment、ReplicaSet、Pod など) に対して、デプロイの -baseline
と -canary
バリアントが作成されます。 この例では、入力マニフェスト ファイルにデプロイ sampleapp
があり、パイプラインの実行番号 22 の完了後に、このデプロイの sampleapp
という名前の安定したバリアントがクラスターにデプロイされます。 その後の実行 (この場合は実行番号 23) では、 action: deploy
と strategy: canary
を含む Kubernetes マニフェスト タスクにより、レプリカの数が sampleapp-baseline デプロイと sampleapp-canary デプロイが作成されます。レプリカの数は percentage
、タスク入力の積と、入力マニフェスト ファイルに従って sampleapp
の最終安定バリアントに必要なレプリカ数の値によって決まります。
レプリカの数を除けば、ベースラインバージョンは安定版と同じ設定を持ち、カナリアバージョンには現在の実行(この場合は実行番号23)によって導入される新しい変更があります。 上記の手順の後にパイプラインで手動介入が設定されている場合、パイプラインを一時停止する機会が確保され、パイプライン管理者はベースライン バージョンとカナリア バージョンの主要なメトリクスを評価し、カナリアの変更が安全で完全なロールアウトに十分であるかどうかを判断できます。
Kubernetes マニフェストタスクの action: promote
と strategy: canary
または action: reject
と strategy: canary
の入力を使用して、それぞれ Canary の変更を昇格または拒否できます。 いずれの場合も、この手順の最後には、入力マニフェスト ファイルで宣言されたワークロードの安定したバリアントのみがクラスターにデプロイされたままになり、エフェメラル ベースライン バージョンとカナリア バージョンがクリーンアップされることに注意してください。