🥇Helm 장치와 그 함정

Typhon 화물 운송차 컨셉, Anton Swanepoel

제 이름은 Dmitry Sugrobov이고 Leroy Merlin의 개발자입니다. 이 기사에서는 Helm이 필요한 이유, Helm이 Kubernetes 작업을 단순화하는 방법, 세 번째 버전에서 변경된 사항, 이를 사용하여 가동 중지 시간 없이 프로덕션에서 애플리케이션을 업데이트하는 방법을 설명합니다.

이것은 회의에서의 연설을 바탕으로 한 요약입니다. @Kubernetes 컨퍼런스 by Mail.ru 클라우드 솔루션 - 읽기 싫으시면 영상을 시청해주세요.

프로덕션에서 Kubernetes를 사용하는 이유

Leroy Merlin은 러시아와 유럽 DIY 소매 시장의 선두주자입니다. 우리 회사에는 33명 이상의 개발자, 000명의 내부 직원, 대형마트와 웹사이트를 방문하는 수많은 사람들이 있습니다. 모두를 만족시키기 위해 우리는 업계 표준 접근 방식을 따르기로 결정했습니다. 마이크로서비스 아키텍처를 사용하여 새로운 애플리케이션을 개발합니다. 컨테이너를 사용하여 환경을 격리하고 적절한 전달을 보장합니다. 오케스트레이션을 위해 Kubernetes를 사용하세요. 오케스트레이터 사용 가격은 빠르게 저렴해지고 있습니다. 해당 기술에 능숙한 엔지니어의 수가 시장에서 증가하고 있으며 서비스 제공업체가 Kubernetes를 서비스로 제공하는 것으로 나타나고 있습니다.

물론 Kubernetes가 수행하는 모든 작업은 다른 방식으로 수행될 수 있습니다. 예를 들어 일부 Jenkins 및 docker-compose를 스크립트로 처리하는 등의 작업을 수행할 수 있지만 기성되고 안정적인 솔루션이 있다면 왜 삶을 복잡하게 만들까요? 이것이 우리가 Kubernetes를 선택하고 현재 XNUMX년 동안 프로덕션 환경에서 사용해 온 이유입니다. 현재 우리는 XNUMX개의 Kubernetes 클러스터를 보유하고 있으며 그 중 가장 오래된 클러스터는 약 XNUMX개의 포드를 포함하여 XNUMX년 이상 된 클러스터입니다.

Kubernetes의 대용량 YAML 파일의 저주

Kubernetes에서 마이크로서비스를 시작하기 위해 배포, 서비스, Ingress, ConfigMap, Secrets용으로 최소 XNUMX개의 YAML 파일을 생성하여 클러스터로 보냅니다. 다음 애플리케이션에서는 동일한 jambs 패키지를 작성하고 세 번째 애플리케이션에서는 다른 애플리케이션을 작성하는 식으로 계속됩니다. 문서 수에 환경 수를 곱하면 이미 수백 개의 파일을 얻게 되며 이는 아직 동적 환경을 고려하지 않은 것입니다.

Helm의 핵심 관리자인 Adam Reese는 "Kubernetes의 개발 주기"는 다음과 같습니다.

YAML 복사 - YAML 파일을 복사합니다.
YAML 붙여넣기 - 붙여넣습니다.
들여쓰기 수정 - 들여쓰기를 수정합니다.
반복 - 다시 반복합니다.

이 옵션은 작동하지만 YAML 파일을 여러 번 복사해야 합니다. 이 주기를 바꾸기 위해 Helm이 발명되었습니다.

헬름이란 무엇입니까?

먼저 헬름 - 패키지 관리자, 필요한 프로그램을 찾고 설치하는 데 도움이 됩니다. 예를 들어 MongoDB를 설치하려면 공식 웹 사이트로 이동하여 바이너리를 다운로드할 필요가 없으며 다음 명령을 실행하기만 하면 됩니다. helm install stable/mongodb.

둘째, 헬름 - 템플릿 엔진, 파일을 매개변수화하는 데 도움이 됩니다. Kubernetes의 YAML 파일 상황으로 돌아가 보겠습니다. 동일한 YAML 파일을 작성하고 Helm이 값을 대체할 자리 표시자를 추가하는 것이 더 쉽습니다. 즉, 대규모 비계 세트 대신 필요한 값이 적시에 대체되는 템플릿 세트가 있습니다.

셋째, 헬름 - 배포 마스터. 이를 통해 애플리케이션을 설치, 롤백 및 업데이트할 수 있습니다. 이를 수행하는 방법을 알아 보겠습니다.

Helm을 사용하여 자체 애플리케이션을 배포하는 방법

공식 지침에 따라 컴퓨터에 Helm 클라이언트를 설치해 보겠습니다. 명령. 다음으로 YAML 파일 세트를 생성하겠습니다. 특정 값을 지정하는 대신 Helm이 나중에 정보로 채울 자리 표시자를 남겨 두겠습니다. 이러한 파일 세트를 Helm 차트라고 합니다. 다음 세 가지 방법으로 Helm 콘솔 클라이언트로 보낼 수 있습니다.

템플릿이 있는 폴더를 나타냅니다.
아카이브를 .tar로 압축하고 이를 가리킵니다.
템플릿을 원격 저장소에 넣고 Helm 클라이언트의 저장소에 대한 링크를 추가합니다.

또한 value.yaml 값이 있는 파일이 필요합니다. 거기의 데이터가 템플릿에 삽입됩니다. 그것도 만들어 봅시다.

Helm의 두 번째 버전에는 Tiller라는 추가 서버 애플리케이션이 있습니다. Kubernetes 외부에 매달려 Helm 클라이언트의 요청을 기다리고, 호출되면 필요한 값을 템플릿에 대체하여 Kubernetes로 보냅니다.

Helm 3은 더 간단합니다. 서버에서 템플릿을 처리하는 대신 이제 정보가 Helm 클라이언트 측에서 완전히 처리되어 Kubernetes API로 직접 전송됩니다. 이러한 단순화로 인해 클러스터 보안이 향상되고 롤아웃 계획이 쉬워집니다.

어떻게 작동하나요?

명령을 실행하십시오. helm install. 애플리케이션 릴리스의 이름을 표시하고 value.yaml에 대한 경로를 제공하겠습니다. 마지막에는 차트가 있는 저장소와 차트 이름을 표시합니다. 이 예에서는 각각 "lmru"와 "bestchart"입니다.

helm install --name bestapp --values values.yaml lmru/bestchart

명령은 한 번만 실행될 수 있으며 대신 다시 실행될 때 install 사용할 필요가 upgrade. 단순화를 위해 두 개의 명령 대신 다음 명령을 실행할 수 있습니다. upgrade 추가 키 포함 --install. 처음 실행되면 Helm은 릴리스를 설치하라는 명령을 보내고 나중에 업데이트할 것입니다.

helm upgrade --install bestapp --values values.yaml lmru/bestchart

Helm을 사용하여 새 버전의 애플리케이션을 배포할 때의 함정

이야기의 이 시점에서 저는 청중과 함께 백만장자가 되고 싶은 사람을 연기하고 있으며 Helm이 앱 버전을 업데이트하도록 하는 방법을 알아내고 있습니다. 비디오 보기.

Helm의 작동 방식을 배울 때 실행 중인 애플리케이션의 버전을 업데이트하려고 할 때 이상한 동작에 놀랐습니다. 애플리케이션 코드를 업데이트하고, Docker 레지스트리에 새 이미지를 업로드하고, 배포 명령을 보냈지만 아무 일도 일어나지 않았습니다. 다음은 응용 프로그램을 업데이트하는 데 완전히 성공하지 못한 몇 가지 방법입니다. 각각을 더 자세히 연구하면 기기의 내부 구조와 이것이 명확하지 않은 동작의 이유를 이해하기 시작합니다.

방법 1. 마지막 실행 이후 정보를 변경하지 마세요.

소문대로 공식 사이트 Helm, "Kubernetes 차트는 크고 복잡할 수 있으므로 Helm은 아무것도 너무 많이 건드리지 않으려고 노력합니다." 따라서 docker 레지스트리에서 최신 버전의 애플리케이션 이미지를 업데이트하고 다음 명령을 실행하면 helm upgrade, 그러면 아무 일도 일어나지 않을 것입니다. Helm은 아무것도 변경되지 않았으며 애플리케이션을 업데이트하기 위해 Kubernetes에 명령을 보낼 필요가 없다고 생각할 것입니다.

여기와 아래에는 최신 태그가 예시로만 표시됩니다. 이 태그를 지정하면 Kubernetes는 imagePullPolicy 매개변수에 관계없이 매번 docker 레지스트리에서 이미지를 다운로드합니다. 최신 제품을 사용하는 것은 바람직하지 않으며 부작용을 유발합니다.

방법 2. 이미지의 LABEL 업데이트

같은 글에 적힌대로 선적 서류 비치, "Helm은 마지막 릴리스 이후 변경된 애플리케이션만 업데이트합니다." 이에 대한 논리적 옵션은 도커 이미지 자체에서 LABEL을 업데이트하는 것 같습니다. 그러나 Helm은 애플리케이션 이미지를 조사하지 않으며 해당 이미지의 변경 사항에 대해 전혀 모릅니다. 따라서 이미지의 레이블을 업데이트할 때 Helm은 이에 대해 알지 못하며 애플리케이션 업데이트 명령은 Kubernetes로 전송되지 않습니다.

방법 3: 키 사용 --force

설명서를 살펴보고 필요한 키를 찾아보겠습니다. 열쇠가 가장 의미가 있습니다 --force. 명백한 이름에도 불구하고 동작은 예상과 다릅니다. 애플리케이션 업데이트를 강제하는 대신 실제 목적은 FAILED 상태인 릴리스를 복원하는 것입니다. 이 키를 사용하지 않으면 명령을 순차적으로 실행해야 합니다. helm delete && helm install --replace. 대신 키를 사용하는 것이 좋습니다 --force, 이러한 명령의 순차적 실행을 자동화합니다. 자세한 내용은 여기를 참조하세요. 풀 리퀘스트. 안타깝게도 Helm에 애플리케이션 버전을 업데이트하라고 지시하려면 이 키가 작동하지 않습니다.

방법 4. Kubernetes에서 직접 레이블 변경

명령을 사용하여 클러스터에서 직접 레이블 업데이트 kubectl edit - 나쁜 생각. 이 작업을 수행하면 실행 중인 애플리케이션과 원래 배포를 위해 전송된 애플리케이션 간의 정보 불일치가 발생합니다. 이 경우 배포 중 Helm의 동작은 해당 버전과 다릅니다. Helm 2는 아무 작업도 수행하지 않으며 Helm 3은 새 버전의 애플리케이션을 배포합니다. 그 이유를 이해하려면 Helm의 작동 방식을 이해해야 합니다.

헬름은 어떻게 작동하나요?

마지막 릴리스 이후 애플리케이션이 변경되었는지 확인하기 위해 Helm은 다음을 사용할 수 있습니다.

Kubernetes에서 애플리케이션 실행
새로운 value.yaml 및 현재 차트
Helm의 내부 릴리스 정보입니다.

더 궁금한 점: Helm은 릴리스에 대한 내부 정보를 어디에 저장합니까?명령을 실행하여 helm history, Helm을 사용하여 설치된 버전에 대한 모든 정보를 얻습니다.

전송된 템플릿 및 값에 대한 자세한 정보도 있습니다. 우리는 그것을 요청할 수 있습니다:

Helm의 두 번째 버전에서 이 정보는 "OWNER=TILLER" 레이블로 표시된 ConfigMap의 Tiller가 실행 중인 동일한 네임스페이스(기본적으로 kube-system)에 있습니다.

Helm의 세 번째 버전이 등장했을 때 정보는 비밀 및 애플리케이션이 실행되고 있던 동일한 네임스페이스로 이동되었습니다. 덕분에 동일한 릴리스 이름을 가진 서로 다른 네임스페이스에서 여러 애플리케이션을 동시에 실행할 수 있게 되었습니다. 두 번째 버전에서는 네임스페이스가 격리되어 있지만 서로 영향을 미칠 수 있다는 점이 심각한 문제였습니다.

두 번째 Helm은 업데이트가 필요한지 이해하려고 할 때 현재 제공되는 정보와 ConfigMap에 있는 릴리스에 대한 내부 정보라는 두 가지 정보 소스만 사용합니다.

세 번째 Helm은 XNUMX방향 병합 전략을 사용합니다. 해당 정보 외에도 현재 Kubernetes에서 실행 중인 애플리케이션도 고려합니다.

이러한 이유로 이전 버전의 Helm은 클러스터의 애플리케이션 정보를 고려하지 않기 때문에 아무 작업도 수행하지 않지만 Helm 3은 변경 사항을 수신하고 배포를 위해 새 애플리케이션을 보냅니다.

방법 5. --recreate-pods 스위치 사용

열쇠로 --recreate-pods 키를 사용하여 원래 달성하려고 계획한 것을 달성할 수 있습니다. --force. 컨테이너가 다시 시작되고 최신 태그에 대한 imagePullPolicy: Always 정책(위의 각주에서 자세히 설명)에 따라 Kubernetes는 이미지의 새 버전을 다운로드하고 실행합니다. 이는 최선의 방법으로 수행되지는 않습니다. 배포의 StrategyType을 고려하지 않으면 모든 기존 애플리케이션 인스턴스가 갑자기 꺼지고 새 인스턴스가 시작되기 시작합니다. 다시 시작하는 동안 시스템은 작동하지 않으며 사용자는 어려움을 겪게 됩니다.

Kubernetes 자체에서도 비슷한 문제가 오랫동안 존재했습니다. 그리고 이제 오픈 4년차 발행물, 문제가 해결되었으며 Kubernetes 버전 1.15부터 Pod를 롤 재시작하는 기능이 나타납니다.

Helm은 단순히 모든 애플리케이션을 끄고 근처에서 새 컨테이너를 시작합니다. 애플리케이션 가동 중지 시간이 발생하지 않도록 프로덕션 환경에서는 이 작업을 수행할 수 없습니다. 이는 개발 요구에만 필요하며 무대 환경에서만 수행할 수 있습니다.

Helm을 사용하여 애플리케이션 버전을 업데이트하는 방법은 무엇입니까?

Helm으로 전송되는 값을 변경하겠습니다. 일반적으로 이미지 태그 대신에 대체되는 값입니다. 비생산적인 환경에서 자주 사용되는 최신의 경우 변경 가능한 정보는 주석으로 Kubernetes 자체에는 쓸모가 없으며 Helm에서는 애플리케이션 업데이트가 필요하다는 신호로 작용합니다. 주석 값 입력 옵션:

임의의 값 표준 기능 사용 - {{ randAlphaNum 6 }}.
주의 사항이 있습니다. 이러한 변수가 포함된 차트를 사용하여 배포할 때마다 주석 값은 고유하며 Helm은 변경 사항이 있다고 가정합니다. 버전을 변경하지 않았더라도 항상 애플리케이션을 다시 시작한다는 것이 밝혀졌습니다. 가동 중지 시간이 없으므로 이는 중요하지 않지만 여전히 불쾌합니다.
현재 붙여넣기 날짜와 시간 - {{ .Release.Date }}.
변형은 영구적으로 고유한 변수가 있는 무작위 값과 유사합니다.
보다 정확한 방법은 다음과 같습니다. 체크섬. 이는 이미지의 SHA 또는 git의 마지막 커밋의 SHA입니다. {{ .Values.sha }}.
예를 들어 Jenkins에서 호출 측의 Helm 클라이언트로 계산하여 전송해야 합니다. 애플리케이션이 변경되면 체크섬도 변경됩니다. 따라서 Helm은 필요할 때만 애플리케이션을 업데이트합니다.

우리의 시도를 요약해보자

Helm은 최소한의 침입 방식으로 변경하므로 Docker 레지스트리의 애플리케이션 이미지 수준에서 변경해도 업데이트가 발생하지 않습니다. 명령이 실행된 후에는 아무 일도 일어나지 않습니다.
열쇠 --force 문제가 있는 릴리스를 복원하는 데 사용되며 강제 업데이트와 관련이 없습니다.
열쇠 --recreate-pods 애플리케이션을 강제로 업데이트하지만 파괴적인 방식으로 업데이트합니다. 모든 컨테이너가 갑자기 꺼집니다. 사용자는 이로 인해 어려움을 겪게 되므로 프로덕션 환경에서는 이 작업을 수행하면 안 됩니다.
명령을 사용하여 Kubernetes 클러스터를 직접 변경합니다. kubectl edit 하지 마세요: 일관성을 깨뜨릴 것이며 Helm 버전에 따라 동작이 달라질 것입니다.
Helm의 새 버전이 출시되면서 많은 뉘앙스가 나타났습니다. Helm 저장소의 문제는 명확한 언어로 설명되어 세부 사항을 이해하는 데 도움이 됩니다.
차트에 편집 가능한 주석을 추가하면 차트가 더욱 유연해집니다. 이렇게 하면 가동 중지 시간 없이 애플리케이션을 올바르게 출시할 수 있습니다.

삶의 모든 영역에 적용되는 "세계 평화" 사상: 사용 후가 아닌 사용 전에 지침을 읽으십시오. 완전한 정보가 있어야만 신뢰할 수 있는 시스템을 구축하고 사용자를 행복하게 만들 수 있습니다.

기타 관련 링크:

이 보고서는 에서 처음 발표되었습니다. @Kubernetes 컨퍼런스 Mail.ru 클라우드 솔루션 제공. 바라보다 비디오 기타 공연 및 텔레그램 이벤트 공지사항 구독 Mail.ru 그룹의 Kubernetes 관련.

출처 : habr.com

Helm 장치와 그 함정