헬름 3 소개

메모. 번역: 올해 16월 3.0일은 Kubernetes용 패키지 관리자인 Helm 개발에 있어 중요한 이정표가 되는 날입니다. 이날 프로젝트의 향후 주요 버전인 XNUMX의 첫 번째 알파 릴리스가 발표되었습니다. 이번 출시로 오랫동안 기다려온 Helm의 중대한 변화가 가져올 것이며, Kubernetes 커뮤니티의 많은 사람들이 큰 기대를 품고 있습니다. 우리는 애플리케이션 배포를 위해 Helm을 적극적으로 사용하기 때문에 이들 중 하나입니다. CI/CD 구현을 위한 도구에 Helm을 통합했습니다. 워프 때때로 우리는 업스트림 개발에 기여합니다. 이 번역은 Helm 7의 첫 번째 알파 릴리스에 전념하고 프로젝트의 역사와 Helm 3의 주요 기능에 대해 설명하는 공식 Helm 블로그의 3개 노트를 결합합니다. 작성자는 Microsoft 직원인 Matt "bacongobbler" Fisher입니다. Helm의 주요 관리자 중 한 명입니다.

15년 2015월 2일, 현재 Helm으로 알려진 프로젝트가 탄생했습니다. Helm 커뮤니티는 창립 2018년 만에 Kubernetes에 합류하면서 Helm XNUMX를 적극적으로 개발했습니다. XNUMX년 XNUMX월, Helm CNCF에 합류했습니다 개발(인큐베이팅) 프로젝트로. 현재로 빠르게 나아가면 새로운 Helm 3의 첫 번째 알파 릴리스가 곧 출시될 예정입니다. (이번 릴리스 이미 일어났어 XNUMX월 중순~약. 번역).

이 글에서는 모든 것이 어디서 시작되었는지, 어떻게 현재의 위치에 도달했는지에 대해 이야기하고, Helm 3의 첫 번째 알파 릴리스에서 사용할 수 있는 몇 가지 고유한 기능을 소개하고, 앞으로 나아갈 계획을 설명하겠습니다.

요약 :

• Helm 창조의 역사;
• Tiller에게 부드러운 작별 인사를 전합니다.
• 차트 저장소;
• 릴리스 관리;
• 차트 종속성 변경;
• 도서관 차트;
• 다음은?

헬름의 역사

출생

Helm 1은 Deis가 만든 오픈 소스 프로젝트로 시작되었습니다. 우리는 작은 스타트업이었어요 흡수된 2017년 봄의 마이크로소프트. Deis라고도 불리는 다른 오픈 소스 프로젝트에는 도구가 있었습니다. deisctl, Deis 플랫폼을 설치하고 운영하는 데 사용되었습니다. 함대 클러스터. 당시 Fleet은 최초의 컨테이너 오케스트레이션 플랫폼 중 하나였습니다.

2015년 중반에 우리는 방향을 바꾸기로 결정하고 Deis(당시 Deis Workflow로 이름 변경)를 Fleet에서 Kubernetes로 이동했습니다. 처음으로 재설계된 것 중 하나는 설치 도구였습니다. deisctl. 우리는 이를 Fleet 클러스터에 Deis Workflow를 설치하고 관리하는 데 사용했습니다.

Helm 1은 Homebrew, apt 및 yum과 같은 유명한 패키지 관리자의 이미지로 만들어졌습니다. 주요 목표는 Kubernetes에 애플리케이션을 패키징하고 설치하는 등의 작업을 단순화하는 것이었습니다. Helm은 2015년 샌프란시스코에서 열린 KubeCon 컨퍼런스에서 공식적으로 소개되었습니다.

Helm을 사용한 첫 번째 시도는 성공했지만 몇 가지 심각한 제한 사항이 있었습니다. 그는 생성기를 입문 YAML 블록으로 활용한 Kubernetes 매니페스트 세트를 사용했습니다. (서문)* 결과를 Kubernetes에 로드했습니다.

* 메모. 번역: Helm 첫 번째 버전부터 Kubernetes 리소스를 설명하기 위해 YAML 구문이 선택되었으며 구성 작성 시 Jinja 템플릿과 Python 스크립트가 지원되었습니다. 우리는 "Helm의 간략한 역사" 장에서 이에 대한 자세한 내용과 일반적인 Helm 첫 번째 버전의 구조에 대해 썼습니다. 이 자료.

예를 들어 YAML 파일의 필드를 바꾸려면 매니페스트에 다음 구성을 추가해야 했습니다.

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

오늘날 템플릿 엔진이 존재한다는 것은 대단한 일입니다. 그렇지 않습니까?

여러 가지 이유로 이 초기 Kubernetes 설치 프로그램에는 하드 코딩된 매니페스트 파일 목록이 필요했으며 소규모의 고정된 이벤트 시퀀스만 실행했습니다. 사용하기가 너무 어려워서 Deis Workflow R&D 팀이 제품을 이 플랫폼으로 이전하려고 할 때 어려움을 겪었습니다. 그러나 아이디어의 씨앗은 이미 뿌려졌습니다. 우리의 첫 번째 시도는 훌륭한 학습 기회였습니다. 우리는 사용자의 일상적인 문제를 해결하는 실용적인 도구를 만드는 데 진정으로 열정이 있다는 것을 깨달았습니다.

과거의 실수 경험을 바탕으로 Helm 2 개발을 시작했습니다.

투구 만들기 2

2015년 말에 Google 팀에서 연락이 왔습니다. 그들은 Kubernetes를 위한 유사한 도구를 개발하고 있었습니다. Kubernetes용 배포 관리자는 Google Cloud Platform에 사용되었던 기존 도구의 포트였습니다. 그들은 “며칠 동안 유사점과 차이점에 대해 토론해 볼까요?”라고 물었습니다.

2016년 2월, Helm 팀과 배포 관리자 팀은 시애틀에서 만나 아이디어를 교환했습니다. 협상은 두 프로젝트를 결합하여 Helm XNUMX를 만드는 야심찬 계획으로 끝났습니다. Deis 및 Google과 함께 스킵박스 (현재 Bitnami의 일부 - 대략 번역), 우리는 Helm 2 작업을 시작했습니다.

Helm의 사용 편의성을 유지하고 싶었지만 다음을 추가했습니다.

• 사용자 정의를 위한 차트 템플릿;
• 팀을 위한 클러스터 내 관리;
• 세계적 수준의 차트 저장소;
• 서명 옵션이 있는 안정적인 패키지 형식;
• 의미론적 버전 관리 및 버전 간의 하위 호환성 유지에 대한 강한 의지입니다.

이러한 목표를 달성하기 위해 Helm 생태계에 두 번째 요소가 추가되었습니다. 이 클러스터 내 구성 요소는 Tiller라고 하며 Helm 차트 설치 및 관리를 담당했습니다.

2년 Helm 2016가 출시된 이후 Kubernetes에는 몇 가지 주요 혁신이 추가되었습니다. 역할 기반 액세스 제어가 추가되었습니다(RBAC)는 결국 ABAC(속성 기반 액세스 제어)를 대체했습니다. 새로운 리소스 유형이 도입되었습니다(당시 배포는 아직 베타 버전이었습니다). 사용자 정의 리소스 정의(원래 타사 리소스 또는 TPR이라고 함)가 발명되었습니다. 그리고 가장 중요한 것은 일련의 모범 사례가 등장했다는 것입니다.

이러한 모든 변화 속에서도 Helm은 계속해서 Kubernetes 사용자에게 충실하게 서비스를 제공했습니다. XNUMX년이 지나고 많은 새로운 추가가 이루어진 후, Helm이 진화하는 생태계의 증가하는 요구 사항을 계속해서 충족할 수 있도록 코드베이스를 크게 변경해야 할 때라는 것이 분명해졌습니다.

틸러와의 부드러운 작별 인사

Helm 2를 개발하는 동안 Google 배포 관리자와의 통합의 일부로 Tiller를 도입했습니다. Tiller는 공통 클러스터 내에서 작업하는 팀에게 중요한 역할을 했습니다. 이를 통해 인프라를 운영하는 다양한 전문가가 동일한 릴리스 세트와 상호 작용할 수 있었습니다.

Kubernetes 1.6에서는 역할 기반 액세스 제어(RBAC)가 기본적으로 활성화되었으므로 프로덕션에서 Tiller를 사용하는 것이 더 어려워졌습니다. 가능한 보안 정책의 수가 엄청나게 많기 때문에 우리의 입장은 기본적으로 허용되는 구성을 제공하는 것이었습니다. 이를 통해 초보자는 먼저 보안 설정에 들어가지 않고도 Helm과 Kubernetes를 실험해 볼 수 있었습니다. 불행하게도 이 권한 구성은 사용자에게 필요하지 않은 너무 광범위한 권한을 부여할 수 있습니다. DevOps 및 SRE 엔지니어는 다중 테넌트 클러스터에 Tiller를 설치할 때 추가 운영 단계를 배워야 했습니다.

커뮤니티가 특정 상황에서 Helm을 어떻게 사용했는지 알게 된 후 우리는 Tiller의 릴리스 관리 시스템이 릴리스 정보의 중앙 허브로서 상태나 기능을 유지하기 위해 클러스터 내 구성 요소에 의존할 필요가 없다는 것을 깨달았습니다. 대신, 간단히 Kubernetes API 서버로부터 정보를 수신하고, 클라이언트 측에서 차트를 생성하고, 설치 기록을 Kubernetes에 저장할 수 있었습니다.

Tiller의 주요 목표는 Tiller 없이도 달성할 수 있었으므로 Helm 3에 관한 우리의 첫 번째 결정 중 하나는 Tiller를 완전히 포기하는 것이었습니다.

Tiller가 사라지면서 Helm의 보안 모델은 근본적으로 단순화되었습니다. Helm 3은 이제 현재 Kubernetes의 모든 최신 보안, ID 및 인증 방법을 지원합니다. Helm 권한은 다음을 사용하여 결정됩니다. kubeconfig 파일. 클러스터 관리자는 사용자 권한을 모든 세부 수준으로 제한할 수 있습니다. 릴리스는 클러스터 내에 계속 저장되며 Helm의 나머지 기능은 그대로 유지됩니다.

차트 저장소

상위 수준에서 차트 저장소는 차트를 저장하고 공유할 수 있는 장소입니다. Helm 클라이언트는 차트를 패키징하여 저장소로 보냅니다. 간단히 말해서 차트 저장소는 index.yaml 파일과 일부 패키지 차트가 있는 기본 HTTP 서버입니다.

대부분의 기본 저장소 요구 사항을 충족하는 Charts Repository API에는 몇 가지 장점이 있지만 몇 가지 단점도 있습니다.

• 차트 저장소는 프로덕션 환경에 필요한 대부분의 보안 구현과 호환되지 않습니다. 인증 및 권한 부여를 위한 표준 API를 갖는 것은 프로덕션 시나리오에서 매우 중요합니다.
• 차트의 무결성과 출처를 서명하고 확인하는 데 사용되는 Helm의 차트 출처 도구는 차트 게시 프로세스의 선택적인 부분입니다.
• 다중 사용자 시나리오에서는 다른 사용자가 동일한 차트를 업로드할 수 있으므로 동일한 콘텐츠를 저장하는 데 필요한 공간이 두 배로 늘어납니다. 이 문제를 해결하기 위해 더 똑똑한 저장소가 개발되었지만 공식 사양의 일부는 아닙니다.
• 메타데이터 검색, 저장 및 차트 검색에 단일 인덱스 파일을 사용하면 안전한 다중 사용자 구현을 개발하기가 어려워졌습니다.

계획 도커 배포 (Docker Registry v2라고도 함)은 Docker Registry의 후속 버전이며 기본적으로 Docker 이미지를 패키징, 배송, 저장 및 전달하기 위한 도구 세트 역할을 합니다. 많은 대규모 클라우드 서비스는 배포 기반 제품을 제공합니다. 이렇게 높아진 관심 덕분에 Distribution 프로젝트는 수년간의 개선, 보안 모범 사례 및 현장 테스트를 통해 오픈 소스 세계에서 가장 성공적인 숨은 영웅 중 하나가 되었습니다.

하지만 배포 프로젝트가 컨테이너 이미지뿐만 아니라 모든 형태의 콘텐츠를 배포하도록 설계되었다는 사실을 알고 계셨나요?

노력 덕분에 오픈 컨테이너 이니셔티브 (또는 OCI) Helm 차트는 모든 배포 인스턴스에 배치될 수 있습니다. 현재 이 프로세스는 실험적입니다. 전체 Helm 3에 필요한 로그인 지원 및 기타 기능은 진행 중인 작업이지만 OCI 및 배포 팀이 수년에 걸쳐 발견한 내용을 통해 배울 수 있게 되어 기쁩니다. 그리고 그들의 멘토링과 지도를 통해 가용성이 높은 서비스를 대규모로 운영하는 것이 어떤 것인지 배웁니다.

Helm 차트 저장소에 대한 일부 향후 변경 사항에 대한 자세한 설명이 제공됩니다. 링크.

릴리스 관리

Helm 3에서 애플리케이션 상태는 객체 쌍을 통해 클러스터 내에서 추적됩니다.

• 릴리스 객체 - 애플리케이션 인스턴스를 나타냅니다.
• 릴리스 버전 비밀 - 특정 시점(예: 새 버전의 릴리스)에서 원하는 애플리케이션 상태를 나타냅니다.

도전 helm install 릴리스 객체와 릴리스 버전 비밀을 생성합니다. 부르다 helm upgrade 릴리스 개체(변경 가능)가 필요하며 새 값과 준비된 매니페스트를 포함하는 새 릴리스 버전 비밀을 생성합니다.

릴리스 개체에는 릴리스에 대한 정보가 포함되어 있습니다. 여기서 릴리스는 명명된 차트 및 값의 특정 설치입니다. 이 개체는 릴리스에 대한 최상위 메타데이터를 설명합니다. 릴리스 개체는 애플리케이션의 수명 주기 전반에 걸쳐 지속되며 모든 릴리스 버전 비밀과 Helm 차트에서 직접 생성된 모든 개체의 소유자입니다.

릴리스 버전 비밀은 릴리스를 일련의 개정(설치, 업데이트, 롤백, 삭제)과 연결합니다.

Helm 2에서는 수정본이 매우 일관성이 있었습니다. 부르다 helm install v1을 생성하고 후속 업데이트(업그레이드) - v2 등을 수행합니다. 릴리스 및 릴리스 버전 비밀은 개정이라는 단일 개체로 축소되었습니다. 개정판은 Tiller와 동일한 네임스페이스에 저장되었습니다. 이는 각 릴리스가 네임스페이스 측면에서 "전역"임을 의미합니다. 결과적으로 이름의 인스턴스는 하나만 사용할 수 있습니다.

Helm 3에서 각 릴리스는 하나 이상의 릴리스 버전 비밀과 연결됩니다. 릴리스 객체는 항상 Kubernetes에 배포된 현재 릴리스를 설명합니다. 각 릴리스 버전 비밀은 해당 릴리스의 한 버전만 설명합니다. 예를 들어, 업그레이드는 새 릴리스 버전 비밀을 생성한 다음 해당 새 버전을 가리키도록 릴리스 개체를 변경합니다. 롤백하는 경우 이전 릴리스 버전 비밀을 사용하여 릴리스를 이전 상태로 롤백할 수 있습니다.

Tiller가 폐기된 후 Helm 3은 릴리스와 동일한 네임스페이스에 릴리스 데이터를 저장합니다. 이 변경을 통해 다른 네임스페이스에 동일한 릴리스 이름을 가진 차트를 설치할 수 있으며 데이터는 etcd의 클러스터 업데이트/재부팅 사이에 저장됩니다. 예를 들어 WordPress를 "foo" 네임스페이스에 설치한 다음 "bar" 네임스페이스에 설치할 수 있으며 두 릴리스 모두 "wordpress"라는 이름을 지정할 수 있습니다.

차트 종속성 변경 사항

포장된 차트(사용 helm package) Helm 2와 함께 사용하기 위해 Helm 3과 함께 설치할 수 있지만 차트 개발 워크플로가 완전히 점검되었으므로 Helm 3을 사용하여 차트 개발을 계속하려면 일부 변경이 필요합니다. 특히 차트 종속성 관리 시스템이 변경되었습니다.

차트의 종속성 관리 시스템이 다음에서 변경되었습니다. requirements.yaml и requirements.lock 에 Chart.yaml и Chart.lock. 이는 명령을 사용한 차트를 의미합니다. helm dependency, Helm 3에서 작동하려면 일부 설정이 필요합니다.

예를 살펴보겠습니다. Helm 2의 차트에 종속성을 추가하고 Helm 3으로 이동할 때 어떤 변경 사항이 있는지 살펴보겠습니다.

헬름 2에서 requirements.yaml 다음과 같이 보였다:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Helm 3에서는 동일한 종속성이 다음 항목에 반영됩니다. Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

차트는 여전히 다운로드되어 디렉토리에 배치됩니다. charts/, 하위 차트 (하위 차트), 카탈로그에 누워 charts/, 변경 없이 계속 작동합니다.

도서관 차트 소개

Helm 3은 라이브러리 차트라는 차트 클래스를 지원합니다. (도서관 차트). 이 차트는 다른 차트에서 사용되지만 자체적으로 릴리스 아티팩트를 생성하지는 않습니다. 라이브러리 차트 템플릿은 요소만 선언할 수 있습니다. define. 다른 콘텐츠는 단순히 무시됩니다. 이를 통해 사용자는 여러 차트에서 사용할 수 있는 코드 조각을 재사용하고 공유할 수 있으므로 중복을 피하고 원칙을 준수할 수 있습니다. DRY.

도서관 차트는 섹션에 선언되어 있습니다. dependencies 파일에 Chart.yaml. 설치 및 관리는 다른 차트와 다르지 않습니다.

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

우리는 이 구성 요소가 차트 개발자에게 공개될 사용 사례와 라이브러리 차트에서 나타날 수 있는 모범 사례에 대해 기대하고 있습니다.

다음은 뭐지?

Helm 3.0.0-alpha.1은 새로운 버전의 Helm 구축을 시작하는 기반입니다. 기사에서 나는 Helm 3의 몇 가지 흥미로운 기능을 설명했습니다. 그 중 다수는 아직 개발 초기 단계에 있으며 이는 정상적인 현상입니다. 알파 릴리스의 요점은 아이디어를 테스트하고, 초기 사용자로부터 피드백을 수집하고, 가정을 확인하는 것입니다.

알파 버전이 출시되자마자 (이건 기억해두세요 이미 일어난 일이야 - 대략. 번역), 커뮤니티에서 Helm 3에 대한 패치를 받기 시작할 것입니다. 새로운 기능을 개발 및 채택하고 사용자가 티켓을 열고 수정하는 과정에 참여할 수 있도록 하는 강력한 기반을 만들어야 합니다.

나는 Helm 3의 주요 개선 사항 중 일부를 강조하려고 노력했지만 이 목록이 결코 완전한 것은 아닙니다. Helm 3의 전체 로드맵에는 향상된 업데이트 전략, OCI 레지스트리와의 심층 통합, 차트 값 검증을 위한 JSON 스키마 사용과 같은 기능이 포함되어 있습니다. 또한 코드베이스를 정리하고 지난 XNUMX년 동안 방치된 부분을 업데이트할 계획입니다.

우리가 뭔가를 놓친 것 같다면, 여러분의 생각을 듣고 싶습니다!

우리의 토론에 참여하세요 슬랙 채널:

• #helm-users 커뮤니티와의 질문 및 간단한 의사소통을 위해;
• #helm-dev 끌어오기 요청, 코드 및 버그에 대해 논의합니다.

매주 목요일 19:30 MSK에 열리는 공개 개발자 통화에서 채팅할 수도 있습니다. 회의에서는 주요 개발자와 커뮤니티가 작업 중인 문제와 이번 주의 토론 주제를 논의하는 데 전념합니다. 누구나 회의에 참여하고 참여할 수 있습니다. Slack 채널에서 사용 가능한 링크 #helm-dev.

번역가의 추신

블로그에서도 읽어보세요.

• «Kubernetes용 패키지 관리자 - Helm: 과거, 현재, 미래";
• «Helm 2에 대한 냉철한 시각: "이것이 바로 이것이다..."";
• «Kubernetes용 패키지 관리자에 대한 실제 소개 - Helm";
• «Kubernetes 팁 및 요령: 클러스터에서 실행 중인 리소스를 Helm 2 관리로 전송";
• «dapp으로 연습해보세요. 2부. Helm을 사용하여 Kubernetes에 Docker 이미지 배포".

출처 : habr.com