Kubernetes에 배포
Azure DevOps Services | Azure DevOps Server 2022
Azure Pipelines를 사용하여 다른 클라우드 공급자가 제공하는 Azure Kubernetes Service 및 Kubernetes 클러스터에 배포할 수 있습니다. Azure Pipelines에는 Kubernetes 작업을 위한 두 가지 작업이 있습니다.
- 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 기반 파이프라인은 단일 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는 AKS(Azure Kubernetes Service), GKE(Google Kubernetes Engine), Amazon Elastic Kubernetes Service(EKS) 또는 다른 클라우드 공급자의 클러스터에 배포하는 데 사용할 수 있습니다.
다중 클라우드 배포 를 설정하려면 환경을 만든 다음 Kubernetes 클러스터의 네임스페이스와 연결된 Kubernetes 리소스를 추가합니다.
기존 서비스 계정을 기반으로 하는 제네릭 공급자 접근 방식은 Azure를 비롯한 모든 클라우드 공급자의 클러스터에서 작동합니다. 대신 Azure Kubernetes Service 옵션을 사용하면 새로 만든 RoleBinding 개체가 ServiceAccount의 작업을 선택한 네임스페이스로만 제한할 수 있도록 새 ServiceAccount 및 RoleBinding 개체(기존 ServiceAccount를 다시 사용하는 대신)를 만들 수 있다는 이점이 있습니다.
제네릭 공급자 접근 방식을 사용하는 경우 RoleBinding이 있는지 확인하여 원하는 서비스 계정에 권한을 editClusterRole 부여합니다. Azure Pipelines에서 선택한 네임스페이스에서 개체를 만드는 데 서비스 계정을 사용할 수 있도록 올바른 서비스 계정에 권한을 부여해야 합니다.
여러 클라우드에 병렬 배포
다음 예제에서는 여러 클라우드의 클러스터에 병렬 배포를 수행하는 방법을 보여 줍니다. 이 예제에는 AKS, GKE, EKS 및 OpenShift 클러스터에 대한 배포가 있습니다. 이러한 네임스페이스는 환경의 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 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기