Helm을 사용하여 여러 Kubernetes 클러스터에 애플리케이션 배포

Dailymotion이 Kubernetes를 사용하는 방법: 애플리케이션 배포

Dailymotion에서는 3년 전부터 프로덕션 환경에서 Kubernetes를 사용하기 시작했습니다. 하지만 여러 클러스터에 애플리케이션을 배포하는 것은 재미있기 때문에 지난 몇 년 동안 우리는 도구와 작업 흐름을 개선하기 위해 노력해 왔습니다.

어디서 시작되었나요?

여기에서는 전 세계 여러 Kubernetes 클러스터에 애플리케이션을 배포하는 방법을 설명합니다.

여러 Kubernetes 객체를 한 번에 배포하려면 다음을 사용합니다. 키, 모든 차트는 하나의 git 저장소에 저장됩니다. 여러 서비스에서 전체 애플리케이션 스택을 배포하기 위해 소위 요약 차트를 사용합니다. 기본적으로 이는 종속성을 선언하고 하나의 명령으로 API와 해당 서비스를 초기화할 수 있는 차트입니다.

또한 검사를 수행하고, 차트를 생성하고, 비밀을 추가하고, 애플리케이션을 배포하기 위해 Helm 위에 작은 Python 스크립트를 작성했습니다. 이러한 모든 작업은 도커 이미지를 사용하여 중앙 CI 플랫폼에서 수행됩니다.

요점을 살펴 보겠습니다.

메모. 이 글을 읽으면서 Helm 3의 첫 번째 릴리스 후보가 이미 발표되었습니다. 메인 버전에는 과거에 겪었던 일부 문제를 해결하기 위한 다양한 개선 사항이 포함되어 있습니다.

차트 개발 작업 흐름

우리는 애플리케이션에 분기를 사용하고 차트에도 동일한 접근 방식을 적용하기로 결정했습니다.

• 나뭇가지 DEV 개발 클러스터에서 테스트할 차트를 만드는 데 사용됩니다.
• Pull Request가 제출되면 석사, 스테이징에서 확인됩니다.
• 마지막으로, 변경 사항을 브랜치에 커밋하기 위한 풀 요청을 생성합니다. 찌르다 그리고 이를 프로덕션에 적용합니다.

각 환경에는 차트를 저장하는 자체 개인 저장소가 있으며 우리는 차트박물관 매우 유용한 API를 사용합니다. 이러한 방식으로 우리는 프로덕션에서 차트를 사용하기 전에 환경과 실제 차트 테스트 간의 엄격한 격리를 보장합니다.

다양한 환경의 차트 저장소

개발자가 dev 브랜치를 푸시하면 차트 버전이 자동으로 dev Chartmuseum으로 푸시된다는 점은 주목할 가치가 있습니다. 따라서 모든 개발자는 동일한 개발 저장소를 사용하므로 실수로 다른 사람의 변경 사항을 사용하지 않도록 차트 버전을 신중하게 지정해야 합니다.

또한, 우리의 작은 Python 스크립트는 다음을 사용하여 Kubernetes OpenAPI 사양에 대해 Kubernetes 객체를 검증합니다. 큐브발, Chartmusem에 게시하기 전에.

차트 개발 작업 흐름에 대한 일반적인 설명

1. 사양에 따라 파이프라인 작업 설정 gazr.io 품질 관리(린트, 단위 테스트)를 위한 것입니다.
2. 애플리케이션을 배포하는 Python 도구를 사용하여 Docker 이미지를 푸시합니다.
3. 브랜치 이름으로 환경을 설정합니다.
4. Kubeval을 사용하여 Kubernetes yaml 파일 유효성 검사
5. 차트 및 상위 차트(변경되는 차트에 의존하는 차트)의 버전을 자동으로 높입니다.
6. 환경에 맞는 Chartmuseum에 차트 제출

클러스터 간의 차이점 관리

클러스터 연합

사용하던 시절이 있었습니다. Kubernetes 클러스터 페더레이션, Kubernetes 객체는 단일 API 엔드포인트에서 선언될 수 있습니다. 그러나 문제가 발생했습니다. 예를 들어, 일부 Kubernetes 개체는 페더레이션 엔드포인트에서 생성할 수 없으므로 개별 클러스터에 대한 페더레이션 개체 및 기타 개체를 유지 관리하기가 어렵습니다.

문제를 해결하기 위해 우리는 클러스터를 독립적으로 관리하기 시작했으며 이로 인해 프로세스가 크게 단순화되었습니다(우리는 페더레이션의 첫 번째 버전을 사용했지만 두 번째 버전에서는 내용이 변경되었을 수 있습니다).

지리적으로 분산된 플랫폼

우리 플랫폼은 현재 6개 지역(로컬 3개, 클라우드 3개)에 배포되어 있습니다.

분산 배포

글로벌 투구 가치

4개의 전역 Helm 값을 사용하면 클러스터 간의 차이점을 식별할 수 있습니다. 모든 차트에는 기본 최소값이 있습니다.

global:
  cloud: True
  env: staging
  region: us-central1
  clusterName: staging-us-central1

글로벌 가치

이러한 값은 애플리케이션의 컨텍스트를 정의하는 데 도움이 되며 모니터링, 추적, 로깅, 외부 호출, 확장 등 다양한 목적으로 사용됩니다.

• "클라우드": 하이브리드 Kubernetes 플랫폼이 있습니다. 예를 들어 API는 GCP 영역과 데이터 센터에 배포됩니다.
• "env": 비프로덕션 환경에서는 일부 값이 변경될 수 있습니다. 예를 들어 리소스 정의 및 자동 크기 조정 구성이 있습니다.
• "지역": 이 정보는 클러스터의 위치를 ​​결정하는 데 도움이 되며 외부 서비스에 대한 근처 엔드포인트를 결정하는 데 사용될 수 있습니다.
• "clusterName": 개별 클러스터에 대한 값을 정의하려는 경우.

구체적인 예는 다음과 같습니다.

{{/* Returns Horizontal Pod Autoscaler replicas for GraphQL*/}}
{{- define "graphql.hpaReplicas" -}}
{{- if eq .Values.global.env "prod" }}
{{- if eq .Values.global.region "europe-west1" }}
minReplicas: 40
{{- else }}
minReplicas: 150
{{- end }}
maxReplicas: 1400
{{- else }}
minReplicas: 4
maxReplicas: 20
{{- end }}
{{- end -}}

투구 템플릿 예

이 논리는 Kubernetes YAML이 복잡해지지 않도록 도우미 템플릿에 정의되어 있습니다.

지원서 발표

우리의 배포 도구는 여러 YAML 파일을 기반으로 합니다. 다음은 클러스터에서 서비스와 확장 토폴로지(복제본 수)를 선언하는 방법의 예입니다.

releases:
  - foo.world

foo.world:                # Release name
  services:               # List of dailymotion's apps/projects
    foobar:
      chart_name: foo-foobar
      repo: [email protected]:dailymotion/foobar
      contexts:
        prod-europe-west1:
          deployments:
            - name: foo-bar-baz
              replicas: 18
            - name: another-deployment
              replicas: 3

서비스 정의

이는 배포 워크플로를 정의하는 모든 단계의 개요입니다. 마지막 단계에서는 애플리케이션을 여러 작업자 클러스터에 동시에 배포합니다.

Jenkins 배포 단계

비밀은 어떻습니까?

보안과 관련하여 우리는 다양한 장소의 모든 비밀을 추적하여 고유한 저장소에 저장합니다. 둥근 천장 파리에서.

우리의 배포 도구는 Vault에서 비밀 값을 추출하고 배포 시간이 오면 이를 Helm에 삽입합니다.

이를 위해 Vault의 비밀과 애플리케이션에 필요한 비밀 간의 매핑을 정의했습니다.

secrets:                                                                                                                                                                                                        
     - secret_id: "stack1-app1-password"                                                                                                                                                                                  
       contexts:                                                                                                                                                                                                   
         - name: "default"                                                                                                                                                                                         
           vaultPath: "/kv/dev/stack1/app1/test"                                                                                                                                                               
           vaultKey: "password"                                                                                                                                                                                    
         - name: "cluster1"                                                                                                                                                                           
           vaultPath: "/kv/dev/stack1/app1/test"                                                                                                                                                               
           vaultKey: "password"

• Vault에 비밀을 기록할 때 따라야 할 일반 규칙을 정의했습니다.
• 비밀이 적용되는 경우 특정 컨텍스트 또는 클러스터에, 특정 항목을 추가해야 합니다. (여기서 클러스터1 컨텍스트에는 비밀 stack-app1-password에 대한 자체 값이 있습니다).
• 그렇지 않으면 값이 사용됩니다. 기본적으로.
• 이 목록의 각 항목에 대해 쿠버네티스 비밀 키-값 쌍이 삽입됩니다. 따라서 차트의 비밀 템플릿은 매우 간단합니다.

apiVersion: v1
data:
{{- range $key,$value := .Values.secrets }}
  {{ $key }}: {{ $value | b64enc | quote }}
{{ end }}
kind: Secret
metadata:
  name: "{{ .Chart.Name }}"
  labels:
    chartVersion: "{{ .Chart.Version }}"
    tillerVersion: "{{ .Capabilities.TillerVersion.SemVer }}"
type: Opaque

도전과 한계

여러 저장소 작업

이제 우리는 차트 개발과 애플리케이션 개발을 분리합니다. 이는 개발자가 두 개의 git 리포지토리에서 작업해야 함을 의미합니다. 하나는 애플리케이션용이고 다른 하나는 Kubernetes에 대한 배포를 정의하기 위한 것입니다. 2개의 git 리포지토리는 2개의 작업 흐름을 의미하므로 초보자가 혼동하기 쉽습니다.

일반화된 차트 관리가 번거로움

이미 말했듯이 일반 차트는 종속성을 식별하고 여러 애플리케이션을 신속하게 배포하는 데 매우 유용합니다. 하지만 우리는 --reuse-values이 일반화된 차트의 일부인 애플리케이션을 배포할 때마다 모든 값이 전달되는 것을 방지합니다.

지속적인 전달 워크플로에는 정기적으로 변경되는 두 가지 값, 즉 복제본 수와 이미지 태그(버전)만 있습니다. 다른 보다 안정적인 값은 수동으로 변경되는데 이는 매우 어렵습니다. 더욱이, 우리 자신의 경험에서 보았듯이 일반화된 차트를 배포할 때 한 번의 실수로 인해 심각한 실패가 발생할 수 있습니다.

여러 구성 파일 업데이트

개발자가 새 애플리케이션을 추가할 때 애플리케이션 선언, 비밀 목록, 일반화된 차트에 포함된 애플리케이션을 종속성으로 추가하는 등 여러 파일을 변경해야 합니다.

Jenkins 권한이 Vault에서 너무 확장되었습니다.

이제 우리는 하나를 가지고 있습니다 앱 역할, Vault에서 모든 비밀을 읽습니다.

롤백 프로세스가 자동화되지 않았습니다.

롤백하려면 여러 클러스터에서 명령을 실행해야 하는데 이로 인해 오류가 발생합니다. 올바른 버전 ID가 지정되었는지 확인하기 위해 이 작업을 수동으로 수행합니다.

우리는 GitOps로 나아가고 있습니다

우리의 목표

배포하는 애플리케이션의 저장소로 차트를 반환하려고 합니다.

작업 흐름은 개발과 동일합니다. 예를 들어 분기가 마스터로 푸시되면 배포가 자동으로 트리거됩니다. 이 접근 방식과 현재 워크플로의 주요 차이점은 다음과 같습니다. 모든 것은 git에서 관리됩니다 (애플리케이션 자체 및 Kubernetes에 배포되는 방식)

몇 가지 장점이 있습니다:

• 많이 더 명확하게 개발자를 위해. 로컬 차트에 변경 사항을 적용하는 방법을 배우는 것이 더 쉽습니다.
• 서비스 배포 정의를 지정할 수 있습니다. 코드와 같은 위치 서비스.
• 일반화된 차트 제거 관리. 서비스에는 자체 Helm 릴리스가 있습니다. 이를 통해 다른 서비스에 영향을 주지 않도록 가장 작은 수준에서 애플리케이션 수명주기(롤백, 업그레이드)를 관리할 수 있습니다.
• 자식의 장점 차트 관리: 변경 사항 취소, 감사 로그 등. 차트 변경 사항을 취소해야 하는 경우 git을 사용하여 취소할 수 있습니다. 배포가 자동으로 시작됩니다.
• 다음과 같은 도구를 사용하여 개발 작업 흐름을 개선하는 것을 고려할 수 있습니다. 비계, 이를 통해 개발자는 프로덕션과 가까운 상황에서 변경 사항을 테스트할 수 있습니다.

XNUMX단계 마이그레이션

우리 개발자들은 현재 2년 동안 이 워크플로를 사용해 왔기 때문에 마이그레이션이 최대한 수월해지기를 바랍니다. 따라서 우리는 목표를 달성하는 도중에 중간 단계를 추가하기로 결정했습니다.
첫 번째 단계는 간단합니다.

• 애플리케이션 배포 설정을 위해 유사한 구조를 유지하지만 DailymotionRelease라는 단일 개체에 있습니다.

apiVersion: "v1"
kind: "DailymotionRelease"
metadata:
  name: "app1.ns1"
  environment: "dev"
  branch: "mybranch"
spec:
  slack_channel: "#admin"
  chart_name: "app1"
  scaling:
    - context: "dev-us-central1-0"
      replicas:
        - name: "hermes"
          count: 2
    - context: "dev-europe-west1-0"
      replicas:
        - name: "app1-deploy"
          count: 2
  secrets:
    - secret_id: "app1"
      contexts:
        - name: "default"
          vaultPath: "/kv/dev/ns1/app1/test"
          vaultKey: "password"
        - name: "dev-europe-west1-0"
          vaultPath: "/kv/dev/ns1/app1/test"
          vaultKey: "password"

• 애플리케이션당 릴리스 1개(일반화된 차트 제외)
• 애플리케이션의 git 저장소에 있는 차트입니다.

우리는 모든 개발자들과 이야기를 나눴으므로 마이그레이션 프로세스가 이미 시작되었습니다. 첫 번째 단계는 여전히 CI 플랫폼을 사용하여 제어됩니다. XNUMX단계: GitOps 워크플로로 이동한 방법에 대해 곧 다른 게시물을 작성할 예정입니다. 유량. 모든 것을 설정하는 방법과 어떤 어려움(여러 저장소, 비밀 등)이 발생했는지 알려 드리겠습니다. 뉴스를 팔로우하세요.

여기서 우리는 지난 몇 년간 애플리케이션 배포 워크플로의 진행 상황을 설명하려고 노력했으며, 이는 GitOps 접근 방식에 대한 생각으로 이어졌습니다. 우리는 아직 목표에 도달하지 않았으며 결과를 보고할 것입니다. 그러나 이제 우리는 모든 것을 단순화하고 개발자의 습관에 더 가깝게 만들기로 결정했을 때 올바른 일을 했다고 확신합니다.

출처 : habr.com