Kubernetes 클러스터를 준비하는 것이 쉽고 편리합니까? 애드온 운영자 발표

다음의 쉘 연산자 우리는 그의 형을 소개합니다 - 애드온 연산자. 이는 추가 기능이라고 할 수 있는 Kubernetes 클러스터에 시스템 구성 요소를 설치하는 데 사용되는 오픈 소스 프로젝트입니다.

왜 추가 사항이 있습니까?

Kubernetes가 이미 만들어진 올인원 제품이 아니며 "성인용" 클러스터를 구축하려면 다양한 추가 기능이 필요하다는 것은 비밀이 아닙니다. 애드온 운영자는 이러한 애드온을 최신 상태로 설치, 구성 및 유지하는 데 도움을 줍니다.

클러스터의 추가 구성 요소에 대한 필요성은 다음에 공개되어 있습니다. 보고 동료들 드리우샤. 간단히 말해서, 현재 Kubernetes의 상황은 간단한 "놀이" 설치의 경우 구성 요소를 즉시 사용할 수 있고, 개발자 및 테스트의 경우 Ingress를 추가할 수 있지만 전체 설치의 경우에는 다음과 같습니다. "프로덕션이 준비되었습니다"라고 말하면 모니터링용, 로깅용, 수신 및 인증서 관리자를 잊지 마세요, 노드 그룹 선택, 네트워크 정책 추가, 시즌 등 다양한 추가 기능을 추가해야 합니다. sysctl 및 pod autoscaler 설정을 사용하면...

그들과 함께 일하는 구체적인 내용은 무엇입니까?

실습에서 알 수 있듯이 문제는 하나의 설치에만 국한되지 않습니다. 클러스터에서 편안하게 작업하려면 추가 기능을 업데이트하고 비활성화(클러스터에서 제거)해야 하며 프로덕션 클러스터에 설치하기 전에 일부를 테스트해야 합니다.

그렇다면 여기서는 Ansible만으로 충분할까요? 아마도. 하지만 일반적으로 본격적인 추가 기능은 설정 없이는 작동하지 않습니다.. 이러한 설정은 클러스터 변형(aws, gce, azure, bare-metal, do 등)에 따라 다를 수 있습니다. 일부 설정은 미리 지정할 수 없으며 클러스터에서 가져와야 합니다. 그리고 클러스터는 정적이지 않습니다. 일부 설정의 경우 변경 사항을 모니터링해야 합니다. 그리고 여기에는 Ansible이 이미 없습니다. 클러스터에 존재하는 프로그램이 필요합니다. 쿠버네티스 운영자.

직장에서 시도해 본 사람들 쉘 연산자, 그들은 추가 기능 설치 및 업데이트 및 모니터링 설정 작업을 다음을 사용하여 완전히 해결할 수 있다고 말합니다. 후크 쉘 오퍼레이터의 경우. 조건을 수행하는 스크립트를 작성할 수 있습니다 kubectl apply 예를 들어 설정이 저장될 ConfigMap을 모니터링합니다. 이것은 대략 addon-operator에서 구현되는 것입니다.

addon-operator에서는 이것이 어떻게 구성되어 있나요?

새로운 솔루션을 만들 때 우리는 다음 원칙에 따라 진행했습니다.

• 추가 기능 설치 프로그램은 다음을 지원해야 합니다. 템플릿 및 선언적 구성. 우리는 애드온을 설치하는 마법 스크립트를 만들지 않습니다. 애드온 운영자는 Helm을 사용하여 애드온을 설치합니다. 설치하려면 차트를 작성하고 구성에 사용할 값을 선택해야 합니다.
• 설정은 다음과 같습니다. 설치 시 생성, 그들은 할 수있다 클러스터에서 가져오기또는 업데이트 받기, 클러스터 리소스 모니터링. 이러한 작업은 후크를 사용하여 구현할 수 있습니다.
• 설정은 다음과 같습니다. 클러스터에 저장. 클러스터에 설정을 저장하기 위해 ConfigMap/애드온 운영자가 생성되고 애드온 운영자는 이 ConfigMap에 대한 변경 사항을 모니터링합니다. 애드온 연산자는 간단한 규칙을 사용하여 설정에 대한 액세스를 후크에 제공합니다.
• 추가는 설정에 따라 다름. 설정이 변경된 경우 Addon-operator는 새로운 값으로 Helm 차트를 롤아웃합니다. 우리는 Helm 차트, 그에 대한 값 및 모듈 후크의 조합을 호출했습니다(자세한 내용은 아래 참조).
• 각색. 마법의 릴리스 스크립트는 없습니다. 업데이트 메커니즘은 일반 애플리케이션과 유사합니다. 추가 기능과 추가 기능 연산자를 이미지로 수집하고 태그를 지정하고 롤아웃합니다.
• 결과 관리. 애드온 운영자는 Prometheus에 대한 측정항목을 제공할 수 있습니다.

addon-operator의 패딩이란 무엇입니까?

추가는 클러스터에 새로운 기능을 추가하는 모든 것으로 간주될 수 있습니다. 예를 들어 Ingress 설치는 추가 기능의 좋은 예입니다. 자체 CRD(prometheus-operator, cert-manager, kube-controller-manager 등)가 있는 모든 연산자 또는 컨트롤러가 될 수 있습니다. 또는 작지만 사용하기 쉬운 것(예: 레지스트리 비밀을 새 네임스페이스에 복사하는 비밀 복사기 또는 새 노드에서 sysctl 매개변수를 구성하는 sysctl 튜너).

추가 기능을 구현하기 위해 Addon-operator는 몇 가지 개념을 제공합니다.

• 투구 차트 Prometheus, Grafana, nginx-ingress와 같은 다양한 소프트웨어를 클러스터에 설치하는 데 사용됩니다. 필요한 구성 요소에 Helm 차트가 있는 경우 Addon-operator를 사용하여 설치하는 것은 매우 간단합니다.
• 가치 저장. Helm 차트에는 일반적으로 시간이 지남에 따라 변경될 수 있는 다양한 설정이 있습니다. Addon-operator는 이러한 설정 저장을 지원하며 Helm 차트를 새로운 값으로 다시 설치하기 위해 변경 사항을 모니터링할 수 있습니다.
• 후크 애드온 운영자가 이벤트에서 실행하고 값 저장소에 액세스하는 실행 파일입니다. 후크는 클러스터의 변경 사항을 모니터링하고 값 저장소의 값을 업데이트할 수 있습니다. 저것들. 후크를 사용하면 클러스터 시작 시 또는 일정에 따라 클러스터에서 값을 수집하는 검색을 수행할 수도 있고, 클러스터의 변경 사항에 따라 클러스터에서 값을 수집하는 지속적인 검색을 수행할 수도 있습니다.
• 기준 치수 Helm 차트, 값 저장소 및 후크의 조합입니다. 모듈을 활성화하거나 비활성화할 수 있습니다. 모듈을 비활성화한다는 것은 모든 Helm 차트 릴리스를 삭제하는 것을 의미합니다. 모듈은 예를 들어 필요한 모든 모듈이 활성화되거나 검색이 후크에서 필요한 매개변수를 찾은 경우 동적으로 활성화할 수 있습니다. 이는 보조 활성화 스크립트를 사용하여 수행됩니다.
• 글로벌 후크. 이들은 "자체적으로" 후크이며, 모듈에 포함되지 않으며 전역 값 저장소에 액세스할 수 있으며, 그 값은 모듈의 모든 후크에서 사용할 수 있습니다.

이 부분들은 어떻게 함께 작동합니까? 문서의 그림을 살펴보겠습니다.

두 가지 작업 시나리오가 있습니다.

1. 글로벌 후크는 이벤트(예: 클러스터의 리소스가 변경되는 경우)에 의해 트리거됩니다. 이 후크는 변경 사항을 처리하고 새 값을 전역 값 저장소에 씁니다. 애드온 운영자는 전역 저장소가 변경되었음을 확인하고 모든 모듈을 시작합니다. 각 모듈은 후크를 사용하여 활성화해야 하는지 여부를 결정하고 값 저장소를 업데이트합니다. 모듈이 활성화된 경우 Addon-operator는 Helm 차트 설치를 시작합니다. 이 경우 Helm 차트는 모듈 저장소와 전역 저장소의 값에 액세스할 수 있습니다.
2. 두 번째 시나리오는 더 간단합니다. 모듈 후크는 이벤트에 의해 트리거되고 모듈 값 저장소의 값을 변경합니다. 애드온 운영자는 이를 인지하고 업데이트된 값으로 Helm 차트를 시작합니다.

추가는 하나의 단일 후크 또는 하나의 Helm 차트로 구현될 수 있습니다. 여러 종속 모듈이더라도 - 이는 클러스터에 설치되는 구성 요소의 복잡성과 원하는 구성 유연성 수준에 따라 달라집니다. 예를 들어 저장소(/예시) 후크와 Helm 차트가 있는 간단한 모듈로 구현되고 값 저장소를 사용하여 ConfigMap을 편집하여 설정을 추가할 수 있는 sysctl-tuner 추가 기능이 있습니다.

업데이트 전달

Addon-operator가 설치하는 구성 요소 업데이트 구성에 대한 몇 마디입니다.

클러스터에서 Addon-operator를 실행하려면 다음이 필요합니다. 추가 사항으로 이미지 구축 Hook, Helm 차트 파일 형태로 바이너리 파일 추가 addon-operator 후크에 필요한 모든 것: bash, kubectl, jq, python 등. 그런 다음 이 이미지를 일반 애플리케이션으로 클러스터에 롤아웃할 수 있으며 대부분 하나 또는 다른 태그 지정 체계를 구성하려고 할 것입니다. 클러스터 수가 적은 경우 애플리케이션과 동일한 접근 방식이 적합할 수 있습니다. 새 릴리스, 새 버전, 모든 클러스터로 이동하여 포드 이미지를 수정합니다. 그러나 상당수의 클러스터로 롤아웃하는 경우 채널에서 자체 업데이트하는 개념이 우리에게 더 적합했습니다.

방법은 다음과 같습니다.

• 채널은 기본적으로 무엇이든 설정할 수 있는 식별자입니다(예: dev/stage/ea/stable).
• 채널 이름은 이미지 태그입니다. 채널에 업데이트를 출시해야 하는 경우 새 이미지가 수집되고 채널 이름으로 태그가 지정됩니다.
• 새 이미지가 레지스트리에 나타나면 Addon-operator가 다시 시작되고 새 이미지로 시작됩니다.

이것은 다음에 쓰여진 것처럼 모범 사례가 아닙니다. 쿠버네티스 문서. 이 작업을 수행하는 것은 권장되지 않지만 우리는 동일한 클러스터에 있는 일반 애플리케이션. Addon-operator의 경우 애플리케이션은 클러스터에 분산된 많은 배포이며, 자동 업데이트는 많은 도움이 되고 삶을 더 쉽게 만듭니다.

채널 도움말 및 테스트 중: 보조 클러스터가 있는 경우 채널에 구성할 수 있습니다. stage 채널에 배포하기 전에 업데이트를 배포하세요. ea и stable. 채널에 클러스터가 있는 경우 ea 오류가 발생했습니다. 다음으로 전환할 수 있습니다. stable, 이 클러스터의 문제를 조사하는 중입니다. 클러스터가 활성 지원에서 제외되면 "동결" 채널로 전환됩니다. 예를 들어 다음과 같습니다. freeze-2019-03-20.

후크 및 Helm 차트를 업데이트하는 것 외에도 다음이 필요할 수 있습니다. 업데이트 및 타사 구성 요소. 예를 들어, 조건부 노드 내보내기에서 버그를 발견하고 이를 패치하는 방법까지 알아냈습니다. 다음으로 PR을 열고 새 릴리스가 모든 클러스터를 통과하여 이미지 버전을 높이기를 기다리고 있습니다. 무기한 기다리지 않으려면 PR을 수락하기 전에 node-exporter를 구축하고 전환할 수 있습니다.

일반적으로 이 작업은 Addon-operator 없이 수행할 수 있지만 Addon-operator를 사용하면 node-exporter 설치용 모듈이 하나의 저장소에 표시되고 이미지 구축을 위한 Dockerfile이 바로 거기에 보관될 수 있으므로 모든 참가자가 더 쉽게 작업할 수 있습니다. 무슨 일이 일어나는지 이해하는 프로세스... 클러스터가 여러 개인 경우 PR을 테스트하고 새 버전을 출시하는 것이 더 쉬워집니다!

이러한 구성 요소 업데이트 구성은 우리에게 성공적으로 작동하지만 다른 적합한 체계도 구현할 수 있습니다. 이 경우 Addon-operator는 간단한 바이너리 파일입니다..

결론

Addon-operator에 구현된 원칙을 사용하면 일반 애플리케이션의 개발 프로세스와 유사하게 클러스터에서 추가 기능을 생성, 테스트, 설치 및 업데이트하기 위한 투명한 프로세스를 구축할 수 있습니다.

모듈 형식(Helm 차트 + 후크)의 애드온 연산자용 애드온을 공개적으로 사용할 수 있습니다. Flant 회사는 여름 동안 이러한 추가 사항의 형태로 개발 내용을 게시할 계획입니다. GitHub에서 개발에 참여하세요(쉘 연산자, 애드온 연산자), 다음을 기반으로 직접 추가해 보세요. 예제들 и 선적 서류 비치, Habré와 우리의 소식을 기다려주세요 유튜브 채널!

PS

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

• «Kubernetes 확장 및 보완(개요 및 동영상 보고서)";
• «Shell-Operator 소개: Kubernetes용 연산자 생성이 더욱 쉬워졌습니다.".

출처 : habr.com