투구 보안

Kubernetes의 가장 인기 있는 패키지 관리자에 대한 이야기의 본질은 이모티콘을 사용하여 설명할 수 있습니다.

• 상자는 Helm(최신 Emoji 릴리스에 가장 가까운 것)입니다.
• 잠금 - 보안;
• 작은 남자가 문제의 해결책입니다.

사실 모든 것이 조금 더 복잡해질 것이며 이야기는 기술적인 세부 사항으로 가득 차 있습니다. Helm을 안전하게 만드는 방법.

• 모르거나 잊어버린 경우를 대비해 Helm이 무엇인지 간략하게 설명합니다. 어떤 문제를 해결하며 생태계의 어디에 위치합니까?
• Helm 아키텍처를 살펴보겠습니다. 구성 요소의 아키텍처를 이해하지 않으면 보안과 도구 또는 솔루션을 더욱 안전하게 만드는 방법에 대한 대화가 완료되지 않습니다.
• Helm 구성 요소에 대해 논의해 보겠습니다.
• 가장 뜨거운 질문은 미래, 즉 Helm 3의 새 버전입니다. 

이 문서의 모든 내용은 Helm 2에 적용됩니다. 이 버전은 현재 생산 중이며 현재 사용 중인 버전일 가능성이 높으며 보안 위험이 포함된 버전입니다.

연사 정보: 알렉산더 카요로프(Alexander Khayorov)알렉스)는 10년 동안 개발을 진행하여 콘텐츠 개선에 도움을 주었습니다. 모스크바 Python Conf++ 그리고 위원회에 합류했다. 헬름 서밋. 이제 그는 Chainstack에서 개발 책임자로 일하고 있습니다. 이는 개발 관리자와 최종 릴리스 제공을 담당하는 사람의 혼합체입니다. 즉, 제품의 탄생부터 운영까지 모든 일이 일어나는 전장에 위치한다.

Chainstack은 고객이 분산형 애플리케이션 운영의 인프라와 복잡성을 잊을 수 있도록 하는 것을 사명으로 하는 소규모의 활발하게 성장하는 스타트업으로, 개발 팀은 싱가포르에 있습니다. Chainstack에 암호화폐 판매 또는 구매를 요청하지 말고 엔터프라이즈 블록체인 프레임워크에 대해 이야기해 달라고 제안하면 기꺼이 답변해 드릴 것입니다.

키

Kubernetes용 패키지(차트) 관리자입니다. 애플리케이션을 Kubernetes 클러스터로 가져오는 가장 직관적이고 보편적인 방법입니다.

물론 우리는 자체 YAML 매니페스트를 만들고 작은 유틸리티를 작성하는 것보다 더 구조적이고 산업적인 접근 방식에 대해 이야기하고 있습니다.

Helm은 현재 사용 가능하고 인기 있는 최고의 제품입니다.

왜 헬름인가? 주로 CNCF에서 지원하기 때문입니다. Cloud Native는 대규모 조직이며 Kubernetes, etcd, Fluentd 등 프로젝트의 모회사입니다.

또 다른 중요한 사실은 Helm이 매우 인기 있는 프로젝트라는 것입니다. 2019년 12월에 Helm을 안전하게 만드는 방법에 대해 이야기하기 시작했을 때 이 프로젝트는 GitHub에서 수천 개의 별을 받았습니다. XNUMX월에는 그 수가 XNUMX명에 이르렀습니다.

많은 사람들이 Helm에 관심을 갖고 있으므로 아직 사용하지 않더라도 Helm의 보안에 대해 알아두면 도움이 될 것입니다. 안전은 중요합니다.

핵심 Helm 팀은 Microsoft Azure에서 지원되므로 다른 많은 팀과 달리 상당히 안정적인 프로젝트입니다. 3월 중순에 Helm 2 Alpha XNUMX가 출시된다는 것은 프로젝트에 참여하는 사람들이 상당히 많고 Helm을 개발하고 개선하려는 열망과 에너지가 있음을 나타냅니다.

Helm은 Kubernetes에서 애플리케이션 관리의 몇 가지 근본적인 문제를 해결합니다.

• 애플리케이션 패키징. WordPress의 "Hello, World"와 같은 애플리케이션도 이미 여러 서비스로 구성되어 있으므로 이를 함께 패키징하려고 합니다.
• 이러한 애플리케이션 관리에 따른 복잡성을 관리합니다.
• 애플리케이션이 설치되거나 배포된 후에도 끝나지 않는 수명 주기입니다. 계속해서 작동하고 업데이트가 필요하며 Helm은 이를 지원하고 이에 대한 올바른 조치와 정책을 가져오려고 노력합니다.

배깅 이는 명확한 방식으로 구성되어 있습니다. Linux, Windows 또는 MacOS용 일반 패키지 관리자의 작업과 완전히 일치하는 메타데이터가 있습니다. 즉, 리포지토리, 다양한 패키지에 대한 종속성, 애플리케이션에 대한 메타 정보, 설정, 구성 기능, 정보 인덱싱 등이 있습니다. Helm을 사용하면 애플리케이션에 대해 이 모든 것을 얻고 사용할 수 있습니다.

복잡성 관리. 동일한 유형의 애플리케이션이 많이 있는 경우 매개변수화가 필요합니다. 템플릿은 여기에서 나오지만 자신만의 템플릿 생성 방법을 고안할 필요가 없도록 Helm이 기본적으로 제공하는 것을 사용할 수 있습니다.

애플리케이션 수명주기 관리 - 제 생각에는 이것이 가장 흥미롭고 해결되지 않은 질문입니다. 이것이 제가 예전에 헬름에 온 이유입니다. 우리는 애플리케이션 수명주기를 주시해야 했고 CI/CD 및 애플리케이션 주기를 이 패러다임으로 옮기고 싶었습니다.

Helm을 사용하면 다음을 수행할 수 있습니다.

• 배포를 관리하고 구성 및 개정 개념을 소개합니다.
• 롤백을 성공적으로 수행했습니다.
• 다양한 이벤트에 후크를 사용하세요.
• 추가적인 애플리케이션 검사를 추가하고 그 결과에 응답합니다.

그 위에 헬름에는 "배터리"가 있습니다 - 플러그인 형태로 포함될 수 있는 수많은 맛있는 것들이 여러분의 삶을 단순화시켜 줍니다. 플러그인은 독립적으로 작성될 수 있으며, 상당히 고립되어 있고 조화로운 아키텍처가 필요하지 않습니다. 무언가를 구현하고 싶다면 플러그인으로 수행한 다음 업스트림에 포함시키는 것이 좋습니다.

Helm은 세 가지 주요 개념을 기반으로 합니다.

• 차트 저장소 — 매니페스트에 가능한 매개변수화 설명 및 배열입니다. 
• 구성 —즉, 적용될 값(텍스트, 숫자 값 등)입니다.
• 해제 두 개의 상위 구성 요소를 수집하고 함께 릴리스로 전환합니다. 릴리스의 버전을 관리할 수 있으므로 설치 시에는 작게, 업그레이드, 다운그레이드 또는 롤백 시에는 크게 라이프사이클을 체계화할 수 있습니다.

투구 아키텍처

다이어그램은 Helm의 상위 수준 아키텍처를 개념적으로 설명합니다.

Helm은 Kubernetes와 관련이 있다는 점을 상기시켜 드리겠습니다. 따라서 Kubernetes 클러스터(사각형) 없이는 할 수 없습니다. kube-apiserver 구성요소는 마스터에 있습니다. Helm이 없으면 Kubeconfig가 있습니다. Helm은 컴퓨터, 노트북, 메인프레임 등 모든 곳에 설치되는 작은 바이너리(Helm CLI 유틸리티)를 제공합니다.

그러나 이것만으로는 충분하지 않습니다. Helm에는 Tiller라는 서버 구성 요소가 있습니다. 이는 클러스터 내 Helm의 관심 사항을 나타내며, 다른 애플리케이션과 마찬가지로 Kubernetes 클러스터 내의 애플리케이션입니다.

Chart Repo의 다음 구성 요소는 차트가 있는 저장소입니다. 공식 저장소가 있을 수도 있고 회사나 프로젝트의 비공개 저장소가 있을 수도 있습니다.

상호 작용

Helm을 사용하여 애플리케이션을 설치하려고 할 때 아키텍처 구성 요소가 어떻게 상호 작용하는지 살펴보겠습니다.

• 우리는 말한다 Helm install, 저장소(Chart Repo)에 액세스하고 Helm 차트를 가져옵니다.

• Helm 유틸리티(Helm CLI)는 연결할 클러스터를 파악하기 위해 Kubeconfig와 상호작용합니다. 
• 이 정보를 받은 유틸리티는 클러스터에 있는 Tiller를 애플리케이션으로 참조합니다. 
• Tiller는 Kube-apiserver를 호출하여 Kubernetes에서 작업을 수행하고 일부 객체(서비스, 포드, 복제본, 비밀 등)를 생성합니다.

다음으로, 전체 Helm 아키텍처가 전체적으로 노출될 수 있는 공격 벡터를 확인하기 위해 다이어그램을 복잡하게 만듭니다. 그리고 우리는 그녀를 보호하려고 노력할 것입니다.

공격 벡터

첫 번째 잠재적인 약점은 특권 API-사용자. 계획의 일부로 Helm CLI에 대한 관리자 액세스 권한을 얻은 해커입니다.

권한이 없는 API 사용자 근처 어딘가에 있으면 위험할 수도 있습니다. 이러한 사용자는 다른 컨텍스트를 갖게 됩니다. 예를 들어 Kubeconfig 설정에서 하나의 클러스터 네임스페이스로 고정될 수 있습니다.

가장 흥미로운 공격 벡터는 Tiller 근처의 클러스터 내에 상주하며 이에 액세스할 수 있는 프로세스일 수 있습니다. 이는 클러스터의 네트워크 환경을 보는 웹 서버 또는 마이크로서비스일 수 있습니다.

이색적이지만 점점 인기를 얻고 있는 공격 변형에는 Chart Repo가 포함됩니다. 부도덕한 작성자가 만든 차트에는 안전하지 않은 리소스가 포함되어 있을 수 있으므로 이를 믿고 완성해 보세요. 또는 공식 저장소에서 다운로드한 차트를 대체할 수 있으며, 예를 들어 정책 형식으로 리소스를 생성하고 해당 액세스 권한을 확대할 수 있습니다.

이 네 가지 측면 모두에서 공격을 방어하고 Helm 아키텍처의 어디에 문제가 있고 어디에 문제가 없는지 알아내도록 노력해 보겠습니다.

다이어그램을 확대하고 더 많은 요소를 추가하되 기본 구성 요소는 모두 유지하겠습니다.

Helm CLI는 Chart Repo와 통신하고 Kubeconfig와 상호 작용하며 작업은 클러스터의 Tiller 구성 요소로 전송됩니다.

Tiller는 두 가지 객체로 표현됩니다.

• 특정 서비스를 노출하는 Tiller-deploy svc
• 클러스터에 액세스하는 전체 로드가 실행되는 경작자 배포 포드(다이어그램에서 하나의 복제본에 있는 단일 복사본)입니다.

상호 작용에는 다양한 프로토콜과 체계가 사용됩니다. 보안 관점에서 우리는 다음 사항에 가장 관심이 있습니다.

• Helm CLI가 차트 저장소에 액세스하는 메커니즘: 어떤 프로토콜, 인증이 있으며 이를 통해 수행할 수 있는 작업은 무엇입니까?
• kubectl을 사용하는 Helm CLI가 Tiller와 통신하는 프로토콜입니다. 클러스터 내부에 설치된 RPC 서버입니다.
• Tiller 자체는 클러스터에 상주하고 Kube-apiserver와 상호 작용하는 마이크로서비스에 액세스할 수 있습니다.

이 모든 영역을 순서대로 논의해 보겠습니다.

RBAC

RBAC가 활성화되어 있지 않으면 Helm 또는 클러스터 내의 다른 서비스에 대한 보안에 대해 이야기할 필요가 없습니다.

이것이 최신 권장사항은 아닌 것 같지만, 아직 프로덕션 환경에서도 RBAC를 활성화하지 않은 분들이 많을 거라 확신합니다. RBAC는 번거롭고 구성해야 할 사항도 많기 때문입니다. 그러나 나는 여러분이 이렇게 하도록 권장합니다.

https://rbac.dev/ — RBAC의 웹사이트 변호사. 여기에는 RBAC를 설정하는 데 도움이 되고, RBAC가 좋은 이유와 기본적으로 프로덕션 환경에서 이를 활용하는 방법을 보여주는 흥미로운 자료가 많이 포함되어 있습니다.

Tiller와 RBAC가 어떻게 작동하는지 설명하겠습니다. Tiller는 특정 서비스 계정으로 클러스터 내부에서 작동합니다. 일반적으로 RBAC가 구성되지 않은 경우 수퍼유저가 됩니다. 기본 구성에서는 Tiller가 관리자가 됩니다. 이것이 Tiller가 클러스터에 대한 SSH 터널이라고 종종 말하는 이유입니다. 실제로 이는 사실이므로 위 다이어그램의 기본 서비스 계정 대신 별도의 전용 서비스 계정을 사용할 수 있습니다.

Helm을 초기화하고 서버에 처음 설치할 때 다음을 사용하여 서비스 계정을 설정할 수 있습니다. --service-account. 이렇게 하면 최소한의 필수 권한 집합을 가진 사용자를 사용할 수 있습니다. 사실, Role 및 RoleBinding과 같은 "화환"을 만들어야 합니다.

불행하게도 Helm은 이 작업을 수행하지 않습니다. Helm을 통과하려면 귀하 또는 Kubernetes 클러스터 관리자가 서비스 계정에 대한 역할 및 RoleBinding 세트를 미리 준비해야 합니다.

질문이 생깁니다. 역할과 ClusterRole의 차이점은 무엇입니까? 차이점은 특수한 네임스페이스에서만 작동하는 일반 역할 및 RoleBinding과 달리 ClusterRole은 모든 네임스페이스에서 작동한다는 것입니다. 전체 클러스터 및 모든 네임스페이스에 대한 정책을 구성하거나 각 네임스페이스에 대해 개별적으로 개인화할 수 있습니다.

RBAC가 또 다른 큰 문제를 해결한다는 점은 언급할 가치가 있습니다. 많은 사람들은 불행하게도 Helm이 다중 테넌트를 지원하지 않는다고 불평합니다. 여러 팀이 클러스터를 사용하고 Helm을 사용하는 경우 Helm이 실행되는 특정 서비스 계정이 있고 그 아래에서 클러스터의 모든 리소스를 생성하기 때문에 이 클러스터 내에서 정책을 설정하고 액세스를 제한하는 것은 기본적으로 불가능합니다. , 때로는 매우 불편합니다. 이는 사실입니다. 프로세스와 마찬가지로 바이너리 파일 자체와 마찬가지로 Helm Tiller에는 다중 테넌트 개념이 없습니다..

그러나 클러스터에서 Tiller를 여러 번 실행할 수 있는 좋은 방법이 있습니다. 여기에는 문제가 없습니다. Tiller는 모든 네임스페이스에서 실행될 수 있습니다. 따라서 RBAC, Kubeconfig를 컨텍스트로 사용하고 특수 Helm에 대한 액세스를 제한할 수 있습니다.

다음과 같이 보일 것입니다.

예를 들어 서로 다른 팀(두 개의 네임스페이스)에 대한 컨텍스트가 있는 두 개의 Kubeconfig가 있습니다. 개발 팀을 위한 X Team과 관리자 클러스터입니다. 관리자 클러스터에는 해당 고급 서비스 계정인 Kube-system 네임스페이스에 위치한 자체적인 광범위한 Tiller가 있습니다. 그리고 개발팀을 위한 별도의 네임스페이스를 통해 특별한 네임스페이스에 서비스를 배포할 수 있습니다.

이것은 실행 가능한 접근 방식입니다. Tiller는 예산에 큰 영향을 미칠 만큼 전력을 많이 소모하지 않습니다. 이것은 빠른 솔루션 중 하나입니다.

Tiller를 별도로 구성하고 팀, 특정 개발자 또는 환경(개발, 스테이징, 프로덕션)에 대한 컨텍스트를 Kubeconfig에 제공하세요(모든 것이 동일한 클러스터에 있을지는 의심스럽지만 가능합니다).

이야기를 계속하면서 RBAC에서 전환하여 ConfigMap에 대해 이야기해 보겠습니다.

컨피그맵

Helm은 ConfigMap을 데이터 저장소로 사용합니다. 아키텍처에 대해 이야기할 때 릴리스, 구성, 롤백 등에 대한 정보를 저장할 데이터베이스가 어디에도 없었습니다. 이를 위해 ConfigMaps가 사용됩니다.

ConfigMap의 주요 문제점은 알려져 있습니다. 원칙적으로 안전하지 않습니다. 민감한 데이터를 저장하는 것은 불가능합니다. 우리는 비밀번호와 같이 서비스 범위를 넘어서는 안되는 모든 것에 대해 이야기하고 있습니다. 현재 Helm의 가장 기본적인 방법은 ConfigMap 사용에서 비밀 사용으로 전환하는 것입니다.

이것은 매우 간단하게 수행됩니다. Tiller 설정을 재정의하고 스토리지가 비밀이 되도록 지정합니다. 그런 다음 각 배포에 대해 ConfigMap이 아닌 비밀을 받게 됩니다.

비밀 자체는 이상한 개념이며 그다지 안전하지 않다고 주장할 수도 있습니다. 그러나 Kubernetes 개발자 자신이 이 작업을 수행하고 있다는 점은 이해할 가치가 있습니다. 버전 1.10부터, 즉 꽤 오랫동안, 적어도 퍼블릭 클라우드에서는 올바른 스토리지를 비밀 정보 저장에 연결하는 것이 가능했습니다. 현재 팀은 비밀, 개별 포드 또는 기타 엔터티에 대한 액세스를 더 효과적으로 분산하는 방법을 연구하고 있습니다.

Storage Helm을 비밀로 전송하는 것이 더 좋으며, 차례로 중앙에서 보호됩니다.

물론 남겠죠 1MB의 데이터 저장 제한. 여기서 Helm은 etcd를 ConfigMap의 분산 스토리지로 사용합니다. 그리고 그들은 이것이 복제 등에 적합한 데이터 청크라고 생각했습니다. Reddit에 이에 대한 흥미로운 토론이 있습니다. 주말 동안 이 재미있는 내용을 찾거나 발췌문을 읽어 보시기 바랍니다. 여기에.

차트 저장소

차트는 사회적으로 가장 취약하며 특히 스톡 솔루션을 사용하는 경우 "중간자"의 소스가 될 수 있습니다. 우선, HTTP를 통해 노출되는 저장소에 대해 이야기하고 있습니다.

반드시 HTTPS를 통해 Helm Repo를 노출해야 합니다. 이것이 최선의 선택이며 저렴합니다.

주의를 기울이십시오. 차트 서명 메커니즘. 기술은 지옥처럼 간단합니다. 이는 공개 키와 개인 키가 있는 일반 PGP 시스템인 GitHub에서 사용하는 것과 동일합니다. 필요한 키를 갖고 모든 것에 서명하여 이것이 실제로 귀하의 차트인지 확인하고 설정하십시오.

또한, Helm 클라이언트는 TLS를 지원합니다. (서버 측 HTTP 의미가 아니라 상호 TLS). 통신을 위해 서버 및 클라이언트 키를 사용할 수 있습니다. 솔직히 저는 상호 인증서를 좋아하지 않기 때문에 그러한 메커니즘을 사용하지 않습니다. 원래, 차트 박물관 - Helm 2용 Helm Repo를 설정하기 위한 기본 도구 - 기본 인증도 지원합니다. 더 편리하고 조용하다면 기본 인증을 사용할 수 있습니다.

플러그인도 있습니다 helm-gcs, 이를 통해 Google Cloud Storage에서 차트 저장소를 호스팅할 수 있습니다. 설명된 모든 메커니즘이 재활용되기 때문에 이는 매우 편리하고 훌륭하게 작동하며 매우 안전합니다.

HTTPS 또는 TLS를 활성화하고, mTLS를 사용하고, 기본 인증을 활성화하여 위험을 더욱 줄이면 Helm CLI 및 Chart Repo를 통해 안전한 통신 채널을 얻을 수 있습니다.

gRPC API

다음 단계는 매우 중요합니다. 클러스터에 위치하고 한편으로는 서버인 Tiller를 보호하는 한편, Tiller 자체는 다른 구성 요소에 액세스하고 누군가인 것처럼 가장하려고 시도합니다.

이미 말했듯이 Tiller는 gRPC를 노출하는 서비스이고 Helm 클라이언트는 gRPC를 통해 제공됩니다. 물론 기본적으로 TLS는 비활성화되어 있습니다. 이것이 왜 수행되었는지는 논쟁의 여지가 있는 질문입니다. 처음에는 설정을 단순화하는 것 같습니다.

프로덕션 및 스테이징의 경우 gRPC에서 TLS를 활성화하는 것이 좋습니다.

제 생각에는 차트용 mTLS와 달리 이는 여기에 적합하며 매우 간단하게 수행됩니다. PQI 인프라 생성, 인증서 생성, Tiller 실행, 초기화 중에 인증서 전송. 그런 다음 모든 Helm 명령을 실행하여 생성된 인증서와 개인 키를 제공할 수 있습니다.

이렇게 하면 클러스터 외부에서 Tiller에 대한 모든 요청으로부터 자신을 보호할 수 있습니다.

그래서 우리는 Tiller에 대한 연결 채널을 확보했으며, 이미 RBAC에 대해 논의하고 Kubernetes apiserver의 권한을 조정하여 상호 작용할 수 있는 도메인을 줄였습니다.

보호된 투구

최종 다이어그램을 살펴보겠습니다. 동일한 화살표가 있는 동일한 아키텍처입니다.

이제 모든 연결을 안전하게 녹색으로 그릴 수 있습니다.

• Chart Repo의 경우 TLS 또는 mTLS 및 기본 인증을 사용합니다.
• Tiller용 mTLS는 TLS를 사용하여 gRPC 서비스로 노출되며 인증서를 사용합니다.
• 클러스터는 Role 및 RoleBinding이 있는 특수 서비스 계정을 사용합니다. 

우리는 클러스터를 상당히 안전하게 보호했지만 똑똑한 누군가가 이렇게 말했습니다.

"완전히 안전한 해결책은 단 하나뿐입니다. 스위치가 꺼진 컴퓨터가 콘크리트 상자에 들어 있고 군인들이 보호하는 것입니다."

데이터를 조작하고 새로운 공격 벡터를 찾는 방법에는 여러 가지가 있습니다. 그러나 저는 이러한 권장 사항이 안전에 대한 기본적인 산업 표준을 달성할 것이라고 확신합니다.

보너스

이 부분은 보안과 직접적인 관련은 없지만, 도움이 되실 겁니다. 사람들이 잘 모르는 흥미로운 사실을 알려드리겠습니다. 예를 들어 공식 및 비공식 차트를 검색하는 방법입니다.

저장소에서 github.com/helm/charts 이제 약 300개의 차트와 두 개의 스트림(Stable 및 Incubator)이 있습니다. 기여하는 사람은 인큐베이터에서 마구간으로 이동하는 것이 얼마나 어려운지, 마구간에서 날아가는 것이 얼마나 쉬운지 잘 알고 있습니다. 그러나 이것은 Prometheus 및 기타 원하는 항목을 검색하는 데 가장 적합한 도구는 아닙니다. 한 가지 간단한 이유는 패키지를 편리하게 검색할 수 있는 포털이 아니라는 것입니다.

하지만 서비스가 있어요 허브.helm.sh, 차트를 찾는 것이 훨씬 더 편리해졌습니다. 가장 중요한 점은 더 많은 외부 저장소가 있고 거의 800개의 참을 사용할 수 있다는 것입니다. 또한 어떤 이유로 차트를 안정 버전으로 보내고 싶지 않은 경우 저장소를 연결할 수 있습니다.

Hub.helm.sh를 사용해 보고 함께 개발해 봅시다. 이 서비스는 Helm 프로젝트에 속하며, 프런트 엔드 개발자이고 단지 외관을 개선하려는 경우 UI에 기여할 수도 있습니다.

나는 또한 당신의 관심을 끌고 싶습니다 개방형 서비스 브로커 API 통합. 번거롭고 불분명하게 들리지만 모두가 직면하는 문제를 해결합니다. 간단한 예를 들어 설명하겠습니다.

클래식 애플리케이션인 WordPress를 실행하려는 Kubernetes 클러스터가 있습니다. 일반적으로 전체 기능을 위해서는 데이터베이스가 필요합니다. 다양한 솔루션이 있습니다. 예를 들어 자신만의 상태 저장 서비스를 시작할 수 있습니다. 이것은 그다지 편리하지는 않지만 많은 사람들이 그렇게 합니다.

Chainstack과 같은 다른 회사에서는 서버에 MySQL 또는 PostgreSQL과 같은 관리형 데이터베이스를 사용합니다. 이것이 바로 우리 데이터베이스가 클라우드 어딘가에 있는 이유입니다.

그러나 문제가 발생합니다. 서비스를 데이터베이스와 연결하고, 데이터베이스 버전을 생성하고, 자격 증명을 전송하고, 어떻게든 관리해야 합니다. 이 모든 작업은 일반적으로 시스템 관리자나 개발자가 수동으로 수행합니다. 그리고 응용 프로그램이 거의 없을 때 문제가 없습니다. 그 수가 많으면 콤바인이 필요합니다. 그러한 수확기가 있습니다. 바로 Service Broker입니다. 이를 통해 퍼블릭 클라우드 클러스터를 위한 특수 플러그인을 사용하고 마치 API인 것처럼 브로커를 통해 공급자로부터 리소스를 주문할 수 있습니다. 이를 위해 기본 Kubernetes 도구를 사용할 수 있습니다.

매우 간단합니다. 예를 들어 기본 계층을 사용하여 Azure에서 관리형 MySQL을 쿼리할 수 있습니다(구성 가능). Azure API를 사용하여 데이터베이스가 생성되고 사용 준비가 됩니다. 이를 방해할 필요는 없습니다. 플러그인이 이에 대한 책임을 집니다. 예를 들어 OSBA(Azure 플러그인)는 자격 증명을 서비스에 반환하고 이를 Helm에 전달합니다. 클라우드 MySQL과 함께 WordPress를 사용할 수 있으며 관리형 데이터베이스를 전혀 처리하지 않고 내부의 상태 저장 서비스에 대해 걱정할 필요가 없습니다.

Helm은 한편으로는 서비스 배포를 허용하고 다른 한편으로는 클라우드 제공업체의 리소스를 소비하는 접착제 역할을 한다고 말할 수 있습니다.

자신만의 플러그인을 작성하고 온프레미스에서 이 전체 내용을 사용할 수 있습니다. 그러면 기업 클라우드 제공업체를 위한 자체 플러그인을 갖게 됩니다. 특히 규모가 크고 기능에 대한 개발, 준비 또는 전체 인프라를 신속하게 배포하려는 경우 이 접근 방식을 시도해 볼 것을 권장합니다. 이를 통해 운영이나 DevOps의 삶이 더 쉬워질 것입니다.

제가 이미 언급한 또 다른 발견은 helm-gcs 플러그인, Google 버킷(객체 저장소)을 사용하여 Helm 차트를 저장할 수 있습니다.

사용을 시작하려면 네 가지 명령만 있으면 됩니다.

1. 플러그인을 설치하십시오.
2. 그것을 시작하십시오;
3. gcp에 있는 버킷의 경로를 설정합니다.
4. 표준 방식으로 차트를 게시합니다.

장점은 인증에 기본 gcp 방법이 사용된다는 것입니다. 서비스 계정, 개발자 계정 등 원하는 것을 사용할 수 있습니다. 매우 편리하며 운영 비용이 들지 않습니다. 나처럼 opsless 철학을 장려한다면 이는 특히 소규모 팀의 경우 매우 편리할 것입니다.

대안

Helm은 유일한 서비스 관리 솔루션이 아닙니다. 그것에 대해 많은 질문이 있기 때문에 아마도 세 번째 버전이 그렇게 빨리 나타난 이유일 것입니다. 물론 대안이 있습니다.

이는 Ksonnet 또는 Metaparticle과 같은 특수 솔루션일 수 있습니다. 앞서 설명한 것과 동일한 목적으로 클래식 인프라 관리 도구(Ansible, Terraform, Chef 등)를 사용할 수 있습니다.

마침내 해결책이 있습니다 연산자 프레임워크, 인기가 높아지고 있습니다.

Operator Framework는 고려해야 할 최고의 Helm 대안입니다.

이는 CNCF 및 Kubernetes에 더 기본적입니다. 하지만 진입장벽이 훨씬 높다., 더 많이 프로그래밍하고 매니페스트를 덜 설명해야 합니다.

Draft, Scaffold 등 다양한 애드온이 있습니다. 예를 들어 개발자가 테스트 환경을 배포할 수 있도록 Helm을 보내고 시작하는 주기를 단순화하는 등 삶을 훨씬 쉽게 만듭니다. 나는 그들을 권한 부여자라고 부를 것입니다.

모든 것이 어디에 있는지 시각적 차트는 다음과 같습니다.

x축은 현재 일어나고 있는 일에 대한 개인 제어 수준이고, y축은 Kubernetes의 기본 수준입니다. Helm 버전 2는 중간 어딘가에 위치합니다. 버전 3에서는 크게는 아니지만 제어 및 기본 수준이 모두 향상되었습니다. Ksonnet 수준의 솔루션은 Helm 2보다 여전히 열등합니다. 그러나 이 세상에 또 무엇이 있는지 알아보기 위해 살펴볼 가치가 있습니다. 물론 구성 관리자는 사용자가 제어할 수 있지만 Kubernetes에 기본적으로 제공되는 것은 아닙니다.

Operator Framework는 Kubernetes에 완전히 기본으로 제공되며 이를 훨씬 더 우아하고 꼼꼼하게 관리할 수 있게 해줍니다(단, 초보 수준에 대해 기억하세요). 오히려 Helm을 사용하여 수많은 애플리케이션을 패키징하기 위한 대량 수집기보다는 전문 애플리케이션 및 이를 위한 관리 생성에 적합합니다.

확장기는 단순히 제어 기능을 약간 개선하고, 워크플로를 보완하거나, CI/CD 파이프라인의 부분을 축소합니다.

헬름의 미래

좋은 소식은 Helm 3이 출시된다는 것입니다. Helm 3.0.0-alpha.2의 알파 버전이 이미 출시되었으므로 사용해 볼 수 있습니다. 상당히 안정적이지만 기능은 여전히 ​​제한적입니다.

헬름 3이 필요한 이유는 무엇입니까? 우선 이 이야기는 다음과 같습니다. 틸러의 실종, 구성 요소로. 이미 알고 있듯이 이것은 아키텍처 보안의 관점에서 볼 때 모든 것이 단순화되기 때문에 큰 발전입니다.

Kubernetes 2 또는 그 이전 버전인 Helm 1.8가 생성되었을 때 많은 개념이 미성숙했습니다. 예를 들어 CRD 개념은 현재 적극적으로 구현되고 있으며 Helm은 CRD 사용구조를 저장합니다. 서버 부분은 유지하지 않고 클라이언트만 사용하는 것도 가능합니다. 따라서 기본 Kubernetes 명령을 사용하여 구조 및 리소스 작업을 수행하세요. 이것은 큰 진전입니다.

나타날거야 기본 OCI 저장소 지원 (오픈 컨테이너 이니셔티브). 이는 거대한 이니셔티브이며 Helm은 주로 차트를 게시하는 데 관심이 있습니다. 예를 들어 Docker Hub는 많은 OCI 표준을 지원합니다. 추측은 아니지만 아마도 클래식 Docker 저장소 제공업체가 Helm 차트를 호스팅할 수 있는 기회를 제공하기 시작할 것입니다.

나에게 논란이 되는 이야기는 루아 지원, 스크립트 작성을 위한 템플릿 엔진입니다. 나는 Lua의 열렬한 팬은 아니지만 이것은 완전히 선택적인 기능입니다. 나는 이것을 3번 확인했습니다. Lua를 사용할 필요는 없을 것입니다. 따라서 Lua를 사용하고 싶은 사람들, Go를 좋아하는 사람들은 우리의 거대한 캠프에 참여하고 이를 위해 go-tmpl을 사용합니다.

마지막으로 제가 확실히 놓치고 있었던 것은 스키마 출현 및 데이터 유형 검증. int 또는 string에 더 이상 문제가 없으며 XNUMX을 큰따옴표로 묶을 필요가 없습니다. 값에 대해 이를 명시적으로 설명할 수 있는 JSONS 스키마가 나타납니다.

대폭 재작업 예정 이벤트 중심 모델. 이미 개념적으로 설명했습니다. Helm 3 브랜치를 보면 얼마나 많은 이벤트와 후크 및 기타 항목이 추가되었는지 확인할 수 있습니다. 이는 크게 단순화되고 배포 프로세스와 이에 대한 반응에 대한 제어를 추가합니다.

Helm 3은 더 간단하고 안전하며 더 재미있을 것입니다. 이는 우리가 Helm 2를 좋아하지 않기 때문이 아니라 Kubernetes가 더욱 발전하고 있기 때문입니다. 따라서 Helm은 Kubernetes의 개발을 활용하고 Kubernetes를 위한 우수한 관리자를 생성할 수 있습니다.

또 다른 좋은 소식은 DevOpsConf 알렉산더 카요로프(Alexander Khayorov)가 당신에게 말할 것입니다. 컨테이너는 안전할 수 있나요? 개발, 테스트 및 운영 프로세스 통합에 관한 컨퍼런스가 모스크바에서 개최될 예정임을 알려드립니다. 30월 1일과 XNUMX월 XNUMX일. 20월 XNUMX일까지 가능해요 레포트를 제출하다 솔루션에 대한 귀하의 경험을 알려주세요. 많은 것 중 하나 DevOps 접근 방식의 작업.

컨퍼런스 체크포인트와 뉴스를 팔로우하세요. 메일링 리스트 и 전보 채널.

출처 : habr.com