Kubernetes 아키텍처에서 Helm의 역할

실제로 헬멧은 누구 또는 무엇입니까? Helm은 반복 가능성이 높거나 여러 시나리오에서 사용될 때 일반적인 K8s 클러스터에서 애플리케이션 및 서비스를 쉽게 배포할 수 있게 해주는 Kubernetes용 패키지 관리자입니다.

Helm의 역할을 더 잘 이해하려면 먼저 애플리케이션과 서비스가 Kubernetes에 배포되는 일반적인 시나리오를 살펴봐야 합니다.

이 예에서는 전자 상거래 플랫폼을 살펴보겠습니다. 대규모 전자 상거래 플랫폼은 일반적으로 마케팅 캠페인을 사용하여 겨울 휴가를 앞두고 신규 고객을 유치합니다.

Kubernetes 클러스터에 배포할 Node.js 애플리케이션을 작성했다고 가정해 보겠습니다. 특히 성수기에는 이 기능을 사용할 수 있어야 하므로 들어오는 모든 요청을 처리할 수 있도록 두 개의 응용 프로그램 복제본을 만들었습니다.

두 Node.js 애플리케이션 아래에는 MongoDB 데이터베이스가 있습니다. 이것은 각 복제본과의 통신을 처리합니다.

이 예제에서는 애플리케이션에 액세스하기 위해 서비스를 노드 포트로 작성했습니다. “노드 포트”는 Kubernetes 클러스터 내부와 외부의 IP 간에 1:1 비율이 있음을 의미합니다.

• 복제본 2개의 JS 애플리케이션
• 몽고DB 데이터베이스
• 노드포트

설명된 스택을 제공하려면 먼저 정의하다. Kubernetes를 사용하여 스택을 정의하는 한 가지 방법은 일부 YAML 파일을 작성하는 것입니다. 이는 다음 사항을 설명합니다.

• 배포는 어떤 모습입니까?
• 서비스는 어떤 모습일까요?

이를 위해 몇 가지 핵심 요소를 살펴보겠습니다.

MongoDB 컨텍스트에서 Node.js 애플리케이션을 배포함으로써 우리는 Node와 Mongo를 모두 이미지화할 것임을 알고 있습니다. 평이한 언어로 이것은 YAML 파일이 다음과 같아야 함을 의미합니다.

우리는 서비스를 노드 포트로 결정했습니다. 이는 다음과 같이 작성됩니다.

내부 및 외부 IP 사이의 1:1 비율을 사용하면 두 개의 복제본이 있으므로 서비스를 쉽게 리디렉션할 수 있으므로 배포에 대한 부하가 줄어듭니다.

이 예에서는 서비스가 포트 8080에서 제공된다고 가정합니다. 그런 다음 이를 service.YAML 파일에 쓸 수 있습니다.

우리가 애플리케이션과 YAML 파일을 직접 작성했고 구성에 익숙하다면 애플리케이션을 직접 작업하면서 필요에 따라 변경하고 업데이트하는 것이 상대적으로 쉽습니다.

휴가 시즌이 끝날 때 애플리케이션을 줄이려면 수요 감소로 인해 더 이상 필요하지 않은 애플리케이션의 복제본을 줄임으로써 이를 수행합니다. 복제본 수를 찾을 수 있는 위치와 변경 방법을 정확히 알고 있습니다.

하지만 우리가 새로운 직업이나 프로젝트로 옮겨가서 이제 다른 사람이 우리가 중단한 부분을 이어받아야 한다면 어떻게 될까요? 우리 동료들은 각 애플리케이션의 복제본 수를 변경하기 위해 어디를 찾아야 할지 모를 수 있습니다.

전체 스택의 구성을 보다 쉽게 ​​관리할 수 있는 방법이 있다면 좋지 않을까요? 템플릿 애플리케이션에서 모든 것을 논리적으로 분리할 수 있다면 어떨까요?

Helm이 작동하는 곳입니다. Helm은 애플리케이션 스택에 대한 두 가지 구성 요소의 조합으로 생각할 수 있습니다.

• Values.YAML 파일에서 정의한 구성입니다.
• Helm에서 “차트”라고 하는 템플릿.

Helm 차트는 차트 왼쪽에서 템플릿으로 사용하는 모든 파일로 구성됩니다.

하지만 이러한 파일을 템플릿에 어떻게 가져오고 변수를 삽입하려면 어떻게 해야 할까요? 구성을 가져오고 대신 템플릿 언어를 사용하여 해당 값을 템플릿에 포함할지 또는 도표 삽입됩니다.

복제본 수를 특정 Deployment.YAML 파일에 하드코딩하는 대신 구성에 따라 결정하기를 원한다고 가정합니다. values.deployments.replicas에서 복제본을 관리하여 이를 수행할 수 있습니다.

이제 구성에서 훨씬 쉽게 찾을 수 있는 values.deployment.replicas 노드를 참조합니다. 구체적으로 말하자면 템플릿에 무엇을 하드 코딩해야 하고 무엇을 위해 Values.YAML을 참조해야 하는지 스스로 결정할 수 있음을 의미합니다.

우리의 서비스에도 동일하게 적용됩니다. 나중에 노드 포트에서 로드 밸런서로 전환하려는 경우 다음과 같이 변경할 수 있습니다.

을 위한:

즉, 프로젝트에서 작업하는 개발자나 인프라에서 작업하는 사람이 여기에서 구성을 쉽게 변경할 수 있습니다.

Kubernetes 클러스터에서 모든 것을 어떻게 결합합니까?

Helm 차트의 모든 것을 요약하려면 다음과 같이 작성합니다. 헬름 설치 myApp – 컴퓨터에 Helm CLI를 설치할 때.

그런 다음 Helm은 생성된 템플릿 다이어그램을 가져오고 구성에서 변수가 정의된 부분을 찾습니다. 그런 다음 구성 파일이 호출되고 필요한 노드가 YAML로 결정되어 템플릿 파일에 삽입됩니다.

Helm에서 모든 것이 설정되면 데이터가 Kubernetes 클러스터로 전송됩니다. 2019년 Helm 3 릴리스까지는 포함된 템플릿 파일을 Kubernetes 클러스터에 설치해야 하는 또 다른 구성 요소인 Tiller로 보냈습니다. Tiller는 Helm의 서버측 구성 요소로 다시 작성할 수 있습니다. Tiller는 Helm 클라이언트가 보낸 명령을 받아 Kubernetes 클러스터에서 이해할 수 있도록 합니다.

Helm 2는 다이어그램의 수명 주기를 Kubernetes에서 이해할 수 있는 형식으로 변환하기 위해 Tiller에 크게 의존했습니다. 그러나 Tiller는 Helm 3에서 제거되었습니다.

실제로 Tiller에는 보안 문제가 있었고 이를 생산에 투입한다는 것은 신중한 수정 작업을 수행해야 한다는 것을 의미했습니다. 이것은 DevOps에 대한 추가 학습 단계를 추가했습니다. Helm 3에서 보안 관리는 Kubernetes에 맡기고 Helm은 패키지 관리에 집중할 수 있습니다. 이는 또한 DevOps의 부담을 줄여줍니다.

전자 상거래 애플리케이션 예제에서 연휴 기간이 지난 후 단 하나의 복제본으로 제한하려는 경우 더 이상 복제본을 종료하고 새 구성으로 배포할 필요가 없습니다. 간단히 다음과 같이 작성할 수 있습니다.

헬멧 업그레이드 MyApp

Helm은 모든 것을 다시 제출하고, 모든 것이 의도한 대로 작동하는지 확인하고, 가용성이 각 스택의 가장 중요한 특성으로 관리될 수 있도록 구성을 Kubernetes로 보냅니다.

그러나 업그레이드 중에 실수를 하여 무언가 작동하지 않으면 어떻게 됩니까? Helm에 “Rollback” 명령을 내리기만 하면 됩니다. Helm은 이를 사용하여 Kubernetes로 전송된 다양한 구성의 버전 기록을 실행합니다. 이를 통해 필요한 경우 언제든지 마지막으로 알려진 작업 구성으로 되돌릴 수 있습니다.

다음 명령을 사용하여 리포지토리에 Helm 차트를 배포할 수 있습니다.

헬멧 패키지

그런 다음 Helm repo 인덱스를 사용하여 리포지토리에 게시합니다. 이는 다른 모든 직원이 동일한 Helm 차트를 사용할 수 있음을 의미합니다.

Helm이 하드 코딩된 YAML을 매개변수화하도록 함으로써 패키지를 관리하고 필요할 때 업데이트하거나 롤백하기가 더 쉽습니다. Helm은 또한 다른 모든 팀 구성원이 프로세스를 따르고, 변수를 찾아 변경하고, 저장소에 이미 포함된 차트를 사용하는 것을 더 쉽게 만듭니다.

이 블로그 게시물은 IBM이 Kubernetes에서 Helm의 역할을 설명하는 링크된 YouTube 비디오에서 영감을 받았습니다. 더 깊이 있고 접근 가능한 Helm 소개에 관심이 있는 사람을 위해 IBM은 훌륭한 Helm 기본 과정도 제공합니다.