Kubernetes へのデプロイ
Azure DevOps Services | Azure DevOps Server 2022
Azure Pipelines を使用して、他のクラウド プロバイダーによって提供される Azure Kubernetes Service および Kubernetes クラスターにデプロイできます。 Azure Pipelines には、Kubernetes を操作するための 2 つのタスクがあります。
- KubernetesManifest タスク: Helm、Kompose、または Kustomize を使用してマニフェストをベイクして Kubernetes クラスターにデプロイする
- Kubectl タスク: kubectl コマンドを実行して、Azure Container Service で Kubernetes クラスターをデプロイ、構成、更新する
いずれかのタスクで Azure Kubernetes Service を使用している場合は、プライベート クラスターまたはローカル アカウントが無効になっているクラスターに接続する最適な方法は、Azure Resource Manager サービス接続の種類です。
デプロイの追跡可能性を高めるには、Kubernetes タスクがある環境 で Kubernetes リソースを使用します。
Azure Pipelines と Azure Kubernetes サービスの使用を開始するには、「Azure Pipelines を使用したビルドと Azure Kubernetes Service へのデプロイ」を参照してください。 Azure Pipelines、Kubernetes、カナリア デプロイ戦略の使用を開始するには、Azure Pipelines を使用した Kubernetes デプロイにカナリア デプロイ戦略を使用する方法に関するページを参照してください。
KubernetesManifest タスク
KubernetesManifest タスクは、タスクを成功または失敗としてマークする前に、オブジェクトの安定性をチェックします。 このタスクは、成果物の置換の実行、パイプラインのトレーサビリティ関連の注釈の追加、imagePullSecrets の作成と参照の簡略化、マニフェストのベイク、デプロイ戦略のロールアウトの支援を行うこともできます。
注意
YAML ベースのパイプラインでは 1 つの Git リポジトリでトリガーがサポートされていますが、別の Git リポジトリに格納されているマニフェスト ファイルのトリガーが必要な場合や、Azure Container Registry または Docker Hub にトリガーが必要な場合は、YAML ベースのパイプラインではなくクラシック パイプラインを使用する必要があります。
Kubernetes マニフェスト タスクのベイク アクションを使用して、テンプレートを Kubernetes マニフェスト ファイルにベイクできます。 このアクションを使用すると、Helm、Kustomize、Kompose などのツールを使用できます。 Kubernetes マニフェスト タスクのベイク アクションにより、デプロイで使用される入力テンプレートと終了マニフェスト ファイル間の変換が可視化されます。 Kubernetes マニフェスト タスクのデプロイ アクションの入力として、ベイクされたマニフェスト ファイルをダウンストリーム (タスク内) で使用できます。
デプロイ ジョブを使用して、環境の一部である Kubernetes リソースをターゲットにすることができます。 環境とリソースのデプロイを使用すると、パイプラインの追跡可能性を向上させてデプロイの問題を診断することができます。 また、同じ正常性機能を使用せずに、通常のジョブを使用して Kubernetes クラスターにデプロイすることもできます。
次の 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
Kubectl タスク
KubernetesManifest KubernetesManifest タスクの代わりに、Kubectl タスクを使用して kubectl コマンドを実行し、Azure Container Service で Kubernetes クラスターをデプロイ、構成、更新することができます。
次の例は、サービス接続を使用して Kubernetes クラスターを参照する方法を示しています。
- task: Kubernetes@1
displayName: kubectl apply
inputs:
connectionType: Kubernetes Service Connection
kubernetesServiceEndpoint: Contoso
スクリプト タスク
スクリプト タスクで kubectl を使用することもできます。
次に、スクリプトを使用して kubectl を実行する例を示します。
- script: |
kubectl apply -f manifest.yml
Kubernetes デプロイ戦略
Kubernetes マニフェスト タスクは、現在、カナリア デプロイ戦略をサポートしています。 完全なロールアウトの前に新しい変更が現在のデプロイと共存するように、新しい変更を部分的にデプロイするには、カナリア デプロイ戦略を使用します。
パイプラインを使用したカナリア デプロイの詳細については、Azure Pipelines を使用して Kubernetes デプロイにカナリア デプロイ戦略を使う方法に関するページを参照してください。
マルチクラウド Kubernetes デプロイ
Kubernetes は、すべてのクラウド プロバイダーで同じ方法で実行されます。 Azure Pipelines は、Azure Kubernetes Service (AKS)、Google Kubernetes Engine (GKE)、Amazon Elastic Kubernetes Service (EKS)、または他のクラウド プロバイダーのクラスターへのデプロイに使用できます。
マルチクラウド デプロイを設定するには、環境を作成してから、Kubernetes クラスターの名前空間に関連付けられている Kubernetes リソースを追加してください。
既存のサービス アカウントに基づく汎用プロバイダー アプローチは、Azure を含む任意のクラウド プロバイダーのクラスターで機能します。 代わりに Azure Kubernetes Service オプションを使用する利点は、(既存の ServiceAccount を再利用するのではなく) 新しい ServiceAccount および RoleBinding オブジェクトが作成され、新しく作成される RoleBinding オブジェクトにより ServiceAccount の操作を選択した名前空間のみに制限できるようになることです。
汎用プロバイダー アプローチを使用する場合は、RoleBinding が存在することを確認してください。これにより、editClusterRole に希望するサービス アカウントへのアクセス許可が付与されます。 Azure Pipelines でサービス アカウントを使用して、選択した名前空間にオブジェクトを作成できるように、適切なサービス アカウントにアクセス許可を付与する必要があります。
複数のクラウドへの並列デプロイ
次の例は、複数のクラウド内のクラスターに対して並列デプロイを行う方法を示しています。 この例では、AKS、GKE、EKS、OpenShift クラスターへのデプロイがあります。 これら 4 つの名前空間は、contoso 環境の Kubernetes リソースに関連付けられています。
trigger:
- main
jobs:
- deployment:
displayName: Deploy to AKS
pool:
vmImage: ubuntu-latest
environment: contoso.aksnamespace
strategy:
runOnce:
deploy:
steps:
- checkout: self
- task: KubernetesManifest@0
displayName: Deploy to Kubernetes cluster
inputs:
action: deploy
kubernetesServiceConnection: serviceConnection #replace with your service connection
namespace: aksnamespace
manifests: manifests/*
- deployment:
displayName: Deploy to GKE
pool:
vmImage: ubuntu-latest
environment: contoso.gkenamespace
strategy:
runOnce:
deploy:
steps:
- checkout: self
- task: KubernetesManifest@0
displayName: Deploy to Kubernetes cluster
inputs:
action: deploy
kubernetesServiceConnection: serviceConnection #replace with your service connection
namespace: gkenamespace
manifests: manifests/*
- deployment:
displayName: Deploy to EKS
pool:
vmImage: ubuntu-latest
environment: contoso.eksnamespace
strategy:
runOnce:
deploy:
steps:
- checkout: self
- task: KubernetesManifest@0
displayName: Deploy to Kubernetes cluster
inputs:
action: deploy
kubernetesServiceConnection: serviceConnection #replace with your service connection
namespace: eksnamespace
manifests: manifests/*
- deployment:
displayName: Deploy to OpenShift
pool:
vmImage: ubuntu-latest
environment: contoso.openshiftnamespace
strategy:
runOnce:
deploy:
steps:
- checkout: self
- task: KubernetesManifest@0
displayName: Deploy to Kubernetes cluster
inputs:
action: deploy
kubernetesServiceConnection: serviceConnection #replace with your service connection
namespace: openshiftnamespace
manifests: manifests/*
- deployment:
displayName: Deploy to DigitalOcean
pool:
vmImage: ubuntu-latest
environment: contoso.digitaloceannamespace
strategy:
runOnce:
deploy:
steps:
- checkout: self
- task: KubernetesManifest@0
displayName: Deploy to Kubernetes cluster
inputs:
action: deploy
kubernetesServiceConnection: serviceConnection #replace with your service connection
namespace: digitaloceannamespace
manifests: manifests/*
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示