데이터베이스 클러스터를 관리하기 위한 Kubernetes의 운영자입니다. 블라디슬라프 클리멘코(알티니티, 2019)

이 보고서는 Kubernetes에서 연산자를 개발하고 아키텍처와 기본 운영 원칙을 설계하는 실제 문제를 다루고 있습니다.

보고서의 첫 번째 부분에서는 다음을 고려할 것입니다.

• Kubernetes의 운영자란 무엇이며 왜 필요한가요?
• 운영자가 복잡한 시스템의 관리를 얼마나 단순화하는지;
• 운영자가 할 수 있는 것과 할 수 없는 것.

다음으로 연산자의 내부 구조에 대해 논의해 보겠습니다. 연산자의 아키텍처와 작동을 단계별로 살펴보겠습니다. 자세히 살펴 보겠습니다.

• 운영자와 Kubernetes 간의 상호 작용
• 운영자가 수행하는 기능과 Kubernetes에 위임하는 기능은 무엇입니까?

Kubernetes에서 샤드와 데이터베이스 복제본을 관리하는 방법을 살펴보겠습니다.
다음으로 데이터 저장 문제에 대해 논의하겠습니다.

• 운영자의 관점에서 영구 저장소로 작업하는 방법
• 로컬 저장소 사용의 함정.

보고서의 마지막 부분에서는 실제 적용 사례를 고려할 것입니다. 클릭하우스 운영자 Amazon 또는 Google 클라우드 서비스에서. 이 보고서는 ClickHouse 운영자의 개발 및 운영 경험의 사례를 기반으로 합니다.

비디오 :

내 이름은 블라디슬라프 클리멘코(Vladislav Klimenko)입니다. 오늘은 데이터베이스 클러스터를 관리하는 전문 운영자인 운영자를 개발하고 운영한 경험에 대해 이야기하고 싶었습니다. 예를 들어 ClickHouse 운영자 ClickHouse 클러스터를 관리합니다.

운영자와 클릭하우스에 대해 이야기할 기회가 있는 이유는 무엇인가요?

• ClickHouse를 지원하고 개발합니다.
• 현재 우리는 ClickHouse의 발전에 천천히 기여하려고 노력하고 있습니다. 그리고 ClickHouse의 변경량 측면에서 Yandex에 이어 XNUMX위를 차지했습니다.
• ClickHouse 생태계를 위한 추가 프로젝트를 진행하려고 합니다.

저는 이러한 프로젝트 중 하나에 대해 말씀드리고 싶습니다. Kubernetes용 ClickHouse-operator에 관한 내용입니다.

내 보고서에서는 다음 두 가지 주제를 다루고 싶습니다.

• 첫 번째 주제는 ClickHouse 데이터베이스 관리 연산자가 Kubernetes에서 작동하는 방식입니다.
• 두 번째 주제는 운영자가 작동하는 방식, 즉 Kubernetes와 상호작용하는 방식입니다.

하지만 이 두 질문은 내 보고서 전반에 걸쳐 교차할 것입니다.

내가 말하려는 것을 누가 듣고 싶어할까요?

• 운영자를 운영하는 사람들이 가장 관심을 가질 것입니다.
• 또는 내부적으로 작동하는 방식, 운영자가 Kubernetes와 상호 작용하는 방식, 나타날 수 있는 함정을 이해하기 위해 직접 만들고 싶은 사람들을 위한 것입니다.

오늘 논의할 내용을 가장 잘 이해하려면 Kubernetes의 작동 방식을 알고 기본적인 클라우드 교육을 받는 것이 좋습니다.

클릭하우스란 무엇인가요? 이는 분석 쿼리의 온라인 처리를 위한 특정 기능을 갖춘 컬럼형 데이터베이스입니다. 그리고 그것은 완전히 오픈 소스입니다.

그리고 우리가 두 가지만 아는 것이 중요합니다. 이것이 데이터베이스라는 것을 알아야 합니다. 따라서 제가 말씀드릴 내용은 거의 모든 데이터베이스에 적용 가능합니다. 그리고 ClickHouse DBMS의 확장성이 매우 뛰어나다는 사실은 거의 선형적인 확장성을 제공합니다. 따라서 클러스터 상태는 ClickHouse의 자연스러운 상태입니다. 그리고 우리는 Kubernetes에서 ClickHouse 클러스터를 제공하는 방법에 대해 논의하는 데 가장 관심이 있습니다.

왜 거기에 그가 필요한가요? 왜 우리는 계속해서 스스로 운영할 수 없나요? 그리고 대답은 부분적으로는 기술적이고 부분적으로는 조직적입니다.

• 실제로 대기업에서는 거의 모든 구성 요소가 이미 Kubernetes에 있는 상황이 점점 더 많이 발생하고 있습니다. 데이터베이스는 외부에 남아 있습니다.
• 그리고 “이것을 안에 넣을 수 있나요?”라는 질문이 점점 더 많아지고 있습니다. 따라서 대기업에서는 데이터 웨어하우스를 신속하게 관리할 수 있도록 최대한의 관리 통일성을 달성하려고 노력하고 있습니다.
• 이는 특히 새로운 장소에서 동일한 작업을 반복할 수 있는 최대한의 기회, 즉 최대의 이식성이 필요한 경우에 도움이 됩니다.

얼마나 쉽나요, 아니면 어렵나요? 물론 이것은 손으로 할 수 있습니다. 하지만 Kubernetes 자체를 관리하는 데 복잡성이 추가되면서 동시에 ClickHouse의 세부 사항이 겹쳐지기 때문에 그렇게 간단하지는 않습니다. 그리고 그러한 집계 결과가 나타납니다.

그리고 이 모든 것이 합쳐져 꽤 큰 기술 세트를 제공하는데, Kubernetes는 운영에 자체적인 일상적인 문제를 가져오고 ClickHouse는 일상적인 작업에 자체적인 문제를 가져오기 때문에 관리하기가 상당히 어려워집니다. 특히 ClickHouse가 여러 개 있고 이를 통해 지속적으로 작업을 수행해야 하는 경우에는 더욱 그렇습니다.

동적 구성을 사용하는 ClickHouse에는 DevOps에 지속적인 로드를 생성하는 상당히 많은 문제가 있습니다.

• 예를 들어 복제본이나 샤드를 추가하는 등 ClickHouse에서 무언가를 변경하려면 구성을 관리해야 합니다.
• 그런 다음 ClickHouse에는 특정 샤딩 방법이 있으므로 데이터 스키마를 변경하세요. 거기에서 데이터 다이어그램을 배치하고 구성을 배치해야 합니다.
• 모니터링을 설정해야 합니다.
• 새 샤드, 새 복제본에 대한 로그를 수집합니다.
• 복원에 신경쓰세요.
• 그리고 다시 시작하세요.

이는 제가 정말로 사용하기 쉽게 만들고 싶은 일상적인 작업입니다.

Kubernetes 자체는 운영에 도움이 되지만 기본적인 시스템 문제에는 도움이 됩니다.

Kubernetes는 다음과 같은 작업을 촉진하고 자동화하는 데 능숙합니다.

• 회복.
• 재시작.
• 스토리지 시스템 관리.

좋습니다. 올바른 방향이지만 그는 데이터베이스 클러스터를 운영하는 방법에 대해 전혀 모릅니다.

우리는 더 많은 것을 원하며 전체 데이터베이스가 Kubernetes에서 작동하기를 원합니다.

나는 큰 마법의 빨간 버튼을 누르면 해결해야 할 일상적인 작업이 포함된 클러스터가 전체 수명 주기 동안 배포 및 유지 관리되는 것을 원합니다. Kubernetes의 ClickHouse 클러스터.

그리고 우리는 작업을 더 쉽게 만드는 데 도움이 되는 솔루션을 만들려고 노력했습니다. Altinity의 Kubernetes용 ClickHouse 운영자입니다.

운영자는 다른 프로그램을 관리하는 것이 주요 임무인 프로그램, 즉 관리자입니다.

그리고 여기에는 행동 패턴이 포함되어 있습니다. 이를 주제 영역에 대한 성문화된 지식이라고 부를 수 있습니다.

그리고 그의 주요 임무는 DevOps의 삶을 더 쉽게 만들고 마이크로 관리를 줄여 그(DevOps)가 이미 높은 수준의 용어로 생각하도록 하는 것입니다. 즉, 그(DevOps)가 마이크로 관리에 관여하지 않도록 구성하지 않도록 하는 것입니다. 모든 세부 사항을 수동으로 수행합니다.

그리고 운영자는 미세 작업을 처리하고 DevOps를 돕는 로봇 보조자입니다.

왜 운영자가 필요합니까? 그는 특히 두 가지 영역에서 좋은 성과를 냈습니다.

• ClickHouse를 다루는 전문가가 경험이 부족하지만 이미 ClickHouse를 작동해야 하는 경우, 운영자는 작동 방식을 너무 자세히 설명하지 않고도 작동을 용이하게 하고 다소 복잡한 구성으로 ClickHouse 클러스터를 작동할 수 있도록 해줍니다. 내부에. 그에게 높은 수준의 작업을 주기만 하면 작동합니다.
• 그리고 가장 잘 수행되는 두 번째 작업은 많은 수의 일반적인 작업을 자동화해야 할 때입니다. 시스템 관리자로부터 마이크로태스크를 제거합니다.

이는 이제 막 여행을 시작하는 사람이나 많은 자동화가 필요한 사람에게 가장 필요합니다.

운영자 기반 접근 방식은 다른 시스템과 어떻게 다릅니까? 헬름이 있습니다. 또한 ClickHouse를 설치하는 데 도움이 되며 전체 ClickHouse 클러스터를 설치하는 조타 차트를 그릴 수도 있습니다. 그러면 연산자와 Helm과 같은 연산자의 차이점은 무엇입니까?

주요 근본적인 차이점은 Helm이 패키지 관리이고 Operator가 한 단계 더 나아간다는 것입니다. 이는 전체 수명주기에 대한 지원입니다. 이는 설치뿐만 아니라 확장, 샤딩, 즉 수명 주기 동안 수행해야 하는 모든 작업(필요한 경우 삭제도 포함)을 포함하는 일상적인 작업입니다. 이는 모두 운영자가 결정합니다. 전체 소프트웨어 수명주기를 자동화하고 유지하려고 시도합니다. 이것이 제시된 다른 솔루션과의 근본적인 차이점입니다.

이상으로 소개 부분이었습니다. 계속 진행하겠습니다.

연산자를 어떻게 구축합니까? ClickHouse 클러스터를 단일 리소스로 관리하기 위해 문제에 접근하려고 합니다.

그림의 왼쪽에는 입력 데이터가 있습니다. 이는 kubectl을 통해 전통적인 방식으로 Kubernetes에 전달되는 클러스터 사양이 포함된 YAML입니다. 그곳에서 우리 교환원이 그것을 집어 들고 마법을 부립니다. 그리고 출력에서 ​​우리는 다음과 같은 구성표를 얻습니다. 이는 Kubernetes에서 ClickHouse를 구현한 것입니다.

그런 다음 운영자가 정확히 어떻게 작동하는지, 어떤 일반적인 작업을 해결할 수 있는지 천천히 살펴보겠습니다. 시간이 제한되어 있으므로 일반적인 작업만 고려하겠습니다. 그리고 운영자가 결정할 수 있는 모든 사항이 논의되는 것은 아닙니다.

연습부터 시작해보자. 우리 프로젝트는 완전히 오픈 소스이므로 GitHub에서 어떻게 작동하는지 확인할 수 있습니다. 그리고 그냥 시작하고 싶다면 빠른 시작 가이드로 시작할 수 있다는 고려 사항을 바탕으로 진행할 수 있습니다.

자세히 이해하고 싶다면 문서를 어느 정도 괜찮은 형태로 유지하려고 노력합니다.

실용적인 문제부터 시작해 보겠습니다. 우리 모두가 시작하고 싶은 첫 번째 작업은 첫 번째 예제를 어떻게든 실행하는 것입니다. 어떻게 작동하는지 잘 모르는 경우에도 연산자를 사용하여 ClickHouse를 어떻게 시작할 수 있나요? 우리는 선언문을 작성하고 있습니다. 왜냐면... k8s와의 모든 통신은 매니페스트를 통한 통신입니다.

이것은 매우 복잡한 선언문입니다. 빨간색으로 강조한 부분이 우리가 집중해야 할 부분입니다. 우리는 운영자에게 데모라는 이름의 클러스터를 생성해 달라고 요청합니다.

이는 현재로서는 기본적인 예입니다. 스토리지에 대해서는 아직 설명하지 않았지만 조금 후에 스토리지에 대해 다시 설명하겠습니다. 지금은 클러스터 개발의 역학을 관찰하겠습니다.

우리는 이 선언문을 만들었습니다. 우리는 그것을 운영자에게 공급합니다. 그는 일했고 마술을 만들었습니다.

우리는 콘솔을 봅니다. 관심 있는 세 가지 구성 요소는 Pod, 두 개의 서비스, StatefulSet입니다.

운영자가 작업했으며 그가 정확히 무엇을 생성했는지 확인할 수 있습니다.

그는 이런 것을 만듭니다. 각 복제본에는 StatefulSet, Pod, ConfigMap이 있고 전체 클러스터에는 ConfigMap이 있습니다. 클러스터에 대한 진입점으로 서비스가 필요합니다.

서비스는 중앙 로드 밸런서 서비스이며 각 복제본, 각 샤드에 사용될 수도 있습니다.

기본 클러스터는 다음과 같습니다. 하나의 단일 노드에서 발생합니다.

더 나아가서 일을 복잡하게 만들어 봅시다. 클러스터를 샤딩해야 합니다.

우리의 임무가 성장하고 있으며 역학이 시작되고 있습니다. 샤드를 추가하고 싶습니다. 우리는 개발을 따릅니다. 사양을 변경하고 있습니다. 우리는 두 개의 샤드를 원한다고 나타냅니다.

이는 시스템의 성장에 따라 동적으로 개발되는 동일한 파일입니다. 저장소 아니요, 저장소에 대해서는 추가로 논의하겠습니다. 이는 별도의 주제입니다.

YAML 연산자에 정보를 제공하고 무슨 일이 일어나는지 확인합니다.

운영자는 다음과 같은 개체를 생각하고 만들었습니다. 이미 Pod 2개, 서비스 2개, 그리고 갑자기 StatefulSet XNUMX개가 생겼습니다. 왜 StatefulSet이 XNUMX개인가?

다이어그램에서는 다음과 같았습니다. 이는 포드가 하나 있을 때의 초기 상태입니다.

이렇게 되었습니다. 지금까지 모든 것이 간단하고 복제되었습니다.

그리고 왜 두 개의 StatefulSet이 생겼나요? 여기서는 Kubernetes에서 포드가 어떻게 관리되는지에 대한 질문을 논하고 논의해야 합니다.

템플릿에서 포드 세트를 생성할 수 있는 StatefulSet이라는 객체가 있습니다. 여기서 핵심 요소는 템플릿입니다. 또한 하나의 StatefulSet에서 하나의 템플릿을 사용하여 여러 Pod를 시작할 수 있습니다. 여기서 핵심 문구는 '하나의 템플릿에 여러 포드'입니다.

그리고 전체 클러스터를 하나의 StatefulSet으로 묶고 싶은 큰 유혹이 있었습니다. 작동할 겁니다. 아무 문제가 없습니다. 그러나 한 가지주의 사항이 있습니다. 즉, 여러 버전의 ClickHouse에서 이기종 클러스터를 조립하려는 경우 질문이 시작됩니다. 예, StatefulSet은 롤링 업데이트를 수행할 수 있으며 새 버전을 출시할 수 있으며 동시에 너무 많은 노드를 시도하면 안 된다는 점을 설명합니다.

그러나 작업을 추정하여 완전히 이종 클러스터를 만들고 싶고 롤링 업데이트를 사용하여 이전 버전에서 새 버전으로 변경하고 싶지 않고 단순히 이종 클러스터를 만들고 싶다고 말하면 두 측면 모두에서 다양한 버전의 ClickHouse와 다양한 저장 공간을 제공합니다. 예를 들어, 일반적으로 이기종 클러스터를 완전히 구축하기 위해 별도의 디스크, 느린 디스크에 일부 복제본을 만들고 싶습니다. 그리고 StatefulSet은 하나의 템플릿으로 표준화된 솔루션을 만들기 때문에 이를 수행할 방법이 없습니다.

고민 끝에 이렇게 하기로 결정했습니다. 자체 StatefulSet에 각 복제본이 있습니다. 이 솔루션에는 몇 가지 단점이 있지만 실제로는 운영자가 모든 것을 완전히 캡슐화합니다. 그리고 많은 장점이 있습니다. 예를 들어 완전히 이질적인 클러스터와 같이 우리가 원하는 정확한 클러스터를 구축할 수 있습니다. 따라서 하나의 복제본과 두 개의 샤드가 있는 클러스터에서는 이기종 클러스터를 구축할 수 있도록 위에서 언급한 이유로 이 접근 방식을 선택했기 때문에 정확하게 2개의 StatefulSet과 2개의 포드를 갖게 됩니다.

실제 문제로 돌아가 보겠습니다. 우리 클러스터에서는 사용자를 구성해야 합니다. Kubernetes에서 ClickHouse를 일부 구성해야 합니다. 운영자는 이에 대한 모든 가능성을 제공합니다.

원하는 것을 YAML에 직접 작성할 수 있습니다. 모든 구성 옵션은 이 YAML에서 ClickHouse 구성으로 직접 매핑된 다음 클러스터 전체에 배포됩니다.

이렇게 쓰시면 됩니다. 예를 들면 다음과 같습니다. 비밀번호는 암호화될 수 있습니다. 모든 ClickHouse 구성 옵션이 지원됩니다. 여기에 단지 예가 있습니다.

클러스터 구성은 ConfigMap으로 배포됩니다. 실제로 ConfigMap 업데이트는 즉시 발생하지 않으므로 클러스터가 큰 경우 구성을 푸시하는 프로세스에 다소 시간이 걸립니다. 하지만 이 모든 것은 사용하기 매우 편리합니다.

작업을 복잡하게 만들어 봅시다. 클러스터가 발전하고 있습니다. 우리는 데이터를 복제하고 싶습니다. 즉, 이미 두 개의 샤드(각각 하나의 복제본)가 있고 사용자가 구성되어 있습니다. 우리는 성장하고 있으며 복제를 원합니다.

복제를 위해서는 무엇이 필요합니까?

ZooKeeper가 필요합니다. ClickHouse에서는 ZooKeeper를 사용하여 복제가 구축됩니다. 서로 다른 ClickHouse 복제본이 어떤 ClickHouse에 어떤 데이터 블록이 있는지에 대한 합의를 가지려면 ZooKeeper가 필요합니다.

ZooKeeper는 누구나 사용할 수 있습니다. 기업에 외부 ZooKeeper가 있는 경우 이를 사용할 수 있습니다. 그렇지 않은 경우 저장소에서 설치할 수 있습니다. 이 모든 것을 더 쉽게 만들어주는 설치 프로그램이 있습니다.

그리고 전체 시스템의 상호작용 다이어그램은 다음과 같습니다. Kubernetes를 플랫폼으로 사용하고 있습니다. ClickHouse 연산자를 실행합니다. 나는 ZooKeeper를 여기에서 묘사했습니다. 그리고 운영자는 ClickHouse 및 ZooKeeper와 상호 작용합니다. 즉 상호작용 결과이다.

ClickHouse가 k8s에서 데이터를 성공적으로 복제하려면 이 모든 것이 필요합니다.

이제 작업 자체를 살펴보고 복제 매니페스트의 모양을 살펴보겠습니다.

매니페스트에 두 개의 섹션을 추가하고 있습니다. 첫 번째는 Kubernetes 내부 또는 외부에 있을 수 있는 ZooKeeper를 얻을 수 있는 위치입니다. 이것은 단지 설명일 뿐입니다. 그리고 우리는 복제품을 주문합니다. 저것들. 우리는 두 개의 복제본을 원합니다. 전체적으로 출력에는 4개의 포드가 있어야 합니다. 우리는 스토리지에 대해 기억하고 있으며 조금 후에 다시 올 것입니다. 저장은 별도의 이야기입니다.

이랬습니다.

이렇게 됩니다. 복제본이 추가됩니다. 네 번째 것은 맞지 않았습니다. 우리는 거기에 많은 것이 있을 수 있다고 믿습니다. 그리고 ZooKeeper가 측면에 추가되었습니다. 계획은 더욱 복잡해지고 있습니다.

그리고 이제 다음 작업을 추가할 시간입니다. 영구 저장소를 추가하겠습니다.

영구 스토리지의 경우 다양한 옵션이 있습니다.

예를 들어 Amazon, Google을 사용하는 클라우드 공급자에서 실행 중인 경우 클라우드 스토리지를 사용하려는 큰 유혹이 있습니다. 매우 편리하고 좋습니다.

그리고 두 번째 옵션이 있습니다. 이는 각 노드에 로컬 디스크가 있는 경우 로컬 스토리지용입니다. 이 옵션은 구현하기가 훨씬 어렵지만 동시에 생산성도 더 높습니다.

클라우드 스토리지에 관해 무엇을 가지고 있는지 살펴보겠습니다.

장점이 있습니다. 구성하는 것은 매우 쉽습니다. 우리는 클라우드 제공자에게 그러한 용량, 그러한 클래스의 스토리지를 제공하도록 주문하기만 하면 됩니다. 수업은 제공자가 독립적으로 일정을 정합니다.

그리고 단점이 있습니다. 일부의 경우 이는 중요하지 않은 단점입니다. 물론 성능상의 문제가 있을 수 있습니다. 사용하기 매우 편리하고 안정적이지만 몇 가지 잠재적인 성능 단점이 있습니다.

때문에 ClickHouse는 특히 생산성에 중점을 두고 있으며 가능한 모든 것을 짜낸다고 말할 수도 있습니다. 이것이 바로 많은 고객이 최대 생산성을 짜내려고 노력하는 이유입니다.

그리고 이를 최대한 활용하려면 로컬 스토리지가 필요합니다.

Kubernetes는 Kubernetes에서 로컬 스토리지를 사용하기 위한 세 가지 추상화를 제공합니다. 이것:

• 비어있는 디렉터리
• 호스트 경로.
• 지방의

어떻게 다른지, 어떻게 비슷한지 살펴보겠습니다.

첫째, 세 가지 접근 방식 모두 스토리지가 있습니다. 이는 동일한 물리적 k8s 노드에 위치한 로컬 디스크입니다. 그러나 그들은 약간의 차이점이 있습니다.

가장 간단한 것, 즉 emptyDir부터 시작해 보겠습니다. 실제로 이것은 무엇입니까? 우리 사양에서는 컨테이너화 시스템(주로 Docker)에 로컬 디스크의 폴더에 대한 액세스 권한을 제공하도록 요청합니다.

실제로 Docker는 자체 경로를 따라 임시 폴더를 생성하고 이를 긴 해시라고 부릅니다. 그리고 이에 접근할 수 있는 인터페이스를 제공합니다.

이것이 성능 측면에서 어떻게 작동할까요? 이는 로컬 디스크 속도에서 작동합니다. 이는 나사에 대한 전체 액세스 권한입니다.

하지만 이 경우에는 단점이 있습니다. 이 문제에 있어서 지속성은 매우 모호합니다. Docker가 컨테이너와 함께 처음으로 이동하면 지속성이 손실됩니다. Kubernetes가 어떤 이유로든 이 Pod를 다른 디스크로 이동하려고 하면 데이터가 손실됩니다.

이 접근 방식은 이미 정상적인 속도를 보여주기 때문에 테스트에는 적합하지만 심각한 작업에는 이 옵션이 적합하지 않습니다.

따라서 두 번째 접근 방식이 있습니다. 이것은 호스트패스입니다. 이전 슬라이드와 이번 슬라이드를 보면 차이점이 한 가지밖에 없습니다. 폴더가 Docker에서 Kubernetes 노드로 직접 이동되었습니다. 여기서는 조금 더 간단합니다. 데이터를 저장하려는 로컬 파일 시스템의 경로를 직접 지정합니다.

이 방법에는 장점이 있습니다. 이것은 이미 진정한 지속성이며 고전적인 것입니다. 디스크의 일부 주소에 데이터가 기록됩니다.

단점도 있습니다. 이것이 관리의 복잡성입니다. Kubernetes는 Pod를 다른 물리적 노드로 이동하려고 할 수 있습니다. DevOps가 활용되는 곳이 바로 여기입니다. 그는 이러한 포드가 이러한 경로를 따라 마운트된 노드로만 이동할 수 있으며 한 번에 하나의 노드 이상으로 이동할 수 없다는 것을 전체 시스템에 올바르게 설명해야 합니다. 꽤 어렵습니다.

특히 이러한 목적을 위해 우리는 이러한 모든 복잡성을 숨기기 위해 연산자에서 템플릿을 만들었습니다. 그리고 간단히 이렇게 말할 수 있습니다. "각 물리적 노드와 이러한 경로를 따라 하나의 ClickHouse 인스턴스를 갖고 싶습니다."

그러나 이러한 요구가 필요한 사람은 우리뿐만이 아니므로 Kubernetes의 신사들도 사람들이 물리적 디스크에 액세스하기를 원한다는 것을 이해하고 세 번째 계층을 제공합니다.

현지라고 합니다. 이전 슬라이드와 거의 차이가 없습니다. 이전에는 이러한 Pod를 로컬 물리적 디스크의 일부 경로를 따라 연결해야 하기 때문에 이러한 Pod를 노드에서 노드로 전송할 수 없다는 것을 수동으로 확인해야 했지만 이제는 이 모든 지식이 Kubernetes 자체에 캡슐화되어 있습니다. 그리고 구성하기가 훨씬 더 쉬운 것으로 나타났습니다.

실제 문제로 돌아가 보겠습니다. YAML 템플릿으로 돌아가겠습니다. 여기에 실제 저장 공간이 있습니다. 우리는 다시 돌아 왔습니다. k8s에서와 같이 클래식 VolumeClaim 템플릿을 설정했습니다. 그리고 우리는 어떤 종류의 스토리지를 원하는지 설명합니다.

그 후 k8s는 스토리지를 요청합니다. StatefulSet에서 우리에게 할당할 것입니다. 그리고 결국 그것은 ClickHouse의 처분이 될 것입니다.

우리는 이런 계획을 가지고 있었습니다. 우리의 영구 저장소는 빨간색으로 표시되어 있어 완료해야 한다는 것을 암시하는 것 같았습니다.

그리고 녹색으로 변합니다. 이제 k8s 클러스터 구성의 ClickHouse가 완전히 완성되었습니다. 우리는 샤드, 복제본, ZooKeeper를 가지고 있으며 어떤 방식으로든 구현되는 실제 지속성을 갖고 있습니다. 이 계획은 이미 완전히 운영되고 있습니다.

우리는 계속해서 살아갑니다. 우리 클러스터는 발전하고 있습니다. 그리고 Alexey는 ClickHouse의 새 버전을 시도하고 출시합니다.

클러스터에서 ClickHouse의 새 버전을 테스트하는 실용적인 작업이 발생합니다. 그리고 당연히 모든 것을 출시하고 싶지 않고 먼 구석 어딘가에 하나의 복제본에 새 버전을 넣고 싶을 수도 있고, 새 버전이 자주 나오기 때문에 한 번에 두 개가 나올 수도 있습니다.

이것에 대해 무엇을 말할 수 있습니까?

여기에 우리에게는 그러한 기회가 있습니다. 이는 포드 템플릿입니다. 우리 운영자가 이기종 클러스터를 구축하는 것을 완벽하게 허용한다고 쓸 수 있습니다. 저것들. 한 묶음의 모든 복제본에서 시작하여 각 개인 복제본으로 끝나는 ClickHouse를 원하는 버전, 저장하려는 버전을 구성합니다. 필요한 구성으로 클러스터를 완전히 구성할 수 있습니다.

좀 더 안쪽으로 들어가 보겠습니다. 이전에 ClickHouse의 세부 사항과 관련하여 ClickHouse-operator가 어떻게 작동하는지에 대해 이야기했습니다.

이제 저는 오퍼레이터가 일반적으로 작동하는 방식과 K8과 상호 작용하는 방식에 대해 몇 마디 말씀드리고 싶습니다.

먼저 K8s와의 상호작용부터 살펴보겠습니다. kubectl을 적용하면 어떻게 되나요? 우리 객체는 API를 통해 etcd에 나타납니다.

예를 들어 기본 Kubernetes 객체(Pod, StatefulSet, 서비스 등)가 목록에 있습니다.

동시에 아직 물리적인 일은 일어나지 않습니다. 이러한 객체는 클러스터에서 구체화되어야 합니다.

이를 위해 컨트롤러가 나타납니다. 컨트롤러는 이러한 설명을 구체화할 수 있는 특수 k8s 구성 요소입니다. 그는 육체적으로 무엇을 어떻게 해야 하는지 알고 있습니다. 그는 컨테이너를 실행하는 방법과 서버가 작동하려면 컨테이너에서 구성해야 할 사항을 알고 있습니다.

그리고 그것은 K8s에서 우리의 물체를 구체화합니다.

그러나 우리는 Pod 및 StatefulSet으로만 작동하는 것이 아니라 단일 전체로 작동하기 위해 ClickHouseInstallation, 즉 ClickHouse 유형의 개체를 생성하려고 합니다. 지금까지는 그러한 가능성이 없습니다.

그런데 K8s에는 다음과 같은 좋은 점이 있습니다. 우리는 클러스터가 포드와 StatefulSet에서 조립될 이 복잡한 엔터티와 같은 어딘가를 갖기를 원합니다.

그리고 이를 위해 무엇을 해야 합니까? 먼저, 사용자 정의 리소스 정의가 등장합니다. 그것은 무엇입니까? 이는 내부가 복잡해질 StatefulSet 포드에 사용자 지정 리소스를 추가하려는 데이터 유형이 하나 더 있다는 K8s에 대한 설명입니다. 데이터 구조에 대한 설명입니다.

또한 kubectl apply를 통해 그곳으로 보냅니다. Kubernetes는 이를 기꺼이 받아들였습니다.

이제 스토리지에서 etcd의 객체는 ClickHouseInstallation이라는 사용자 지정 리소스를 기록할 수 있습니다.

그러나 지금은 더 이상 아무 일도 일어나지 않을 것입니다. 즉, 이제 샤드와 복제본을 설명하는 YAML 파일을 생성하고 "kubectl Apply"라고 말하면 Kubernetes는 이를 수락하고 etcd에 넣은 다음 "좋습니다. 하지만 어떻게 해야 할지 모르겠습니다"라고 말합니다. 그것으로. ClickHouseInstallation을 유지 관리하는 방법을 모르겠습니다.”

따라서 Kubernetes가 새로운 데이터 유형을 제공하도록 도와줄 사람이 필요합니다. 왼쪽에는 기본 데이터 유형과 작동하는 기본 Kubernetes 컨트롤러가 있습니다. 그리고 오른쪽에는 사용자 정의 데이터 유형으로 작업할 수 있는 사용자 정의 컨트롤러가 있어야 합니다.

그리고 다른 말로는 연산자라고 합니다. K8s 외부에서도 실행될 수 있기 때문에 여기에 Kubernetes로 특별히 포함했습니다. 물론 대부분의 경우 모든 연산자는 Kubernetes에서 실행되지만 외부에 서 있는 것을 방해하는 것은 없으므로 여기서는 특별히 외부로 이동합니다.

그리고 연산자라고도 알려진 사용자 지정 컨트롤러는 API를 통해 Kubernetes와 상호 작용합니다. API와 상호작용하는 방법을 이미 알고 있습니다. 그리고 그는 우리가 만들고 싶은 복잡한 회로를 맞춤형 리소스로 구체화하는 방법을 이미 알고 있습니다. 이것이 바로 운영자가 하는 일입니다.

운영자는 어떻게 일하나요? 그가 어떻게 하는지 오른쪽을 살펴보겠습니다. 운영자가 이 모든 것을 어떻게 구체화하고 K8과의 추가 상호 작용이 어떻게 발생하는지 알아 보겠습니다.

연산자는 프로그램입니다. 그녀는 이벤트 지향적입니다. 운영자는 Kubernetes API를 사용하여 이벤트를 구독합니다. Kubernetes API에는 이벤트를 구독할 수 있는 진입점이 있습니다. 그리고 K8s에서 무언가 변경되면 Kubernetes는 모든 사람에게 이벤트를 보냅니다. 이 API 포인트를 구독한 사람은 누구나 알림을 받게 됩니다.

운영자는 이벤트를 구독하고 일종의 반응을 취해야 합니다. 그 임무는 새로운 이벤트에 대응하는 것입니다.

특정 업데이트에 의해 이벤트가 생성됩니다. ClickHouseInstallation에 대한 설명이 포함된 YAML 파일이 도착합니다. 그는 kubectl Apply를 통해 etcd로 이동했습니다. 거기에서 이벤트가 트리거되었고 결과적으로 이 이벤트가 ClickHouse 운영자에게 전달되었습니다. 교환원은 이 설명을 받았습니다. 그리고 그는 뭔가를 해야 합니다. ClickHouseInstallation 개체에 대한 업데이트가 도착하면 클러스터를 업데이트해야 합니다. 그리고 운영자의 임무는 클러스터를 업데이트하는 것입니다.

그는 무엇을 하고 있나요? 먼저, 이번 업데이트를 통해 무엇을 할 것인지에 대한 실행 계획을 수립해야 합니다. 업데이트는 매우 작을 수 있습니다. YAML 실행에서는 작지만 클러스터에 매우 큰 변경이 수반될 수 있습니다. 따라서 운영자는 계획을 세우고 이를 고수합니다.

이 계획에 따르면 그는 포드, 서비스를 구체화하기 위해 내부에서 이 구조를 요리하기 시작합니다. 그의 주요 임무를 수행하십시오. Kubernetes에서 ClickHouse 클러스터를 구축하는 방법입니다.

이제 흥미로운 점을 다루겠습니다. 이는 Kubernetes와 운영자 간의 책임 분할입니다. Kubernetes가 수행하는 작업, 운영자가 수행하는 작업 및 서로 상호 작용하는 방법.

Kubernetes는 시스템 관련 작업을 담당합니다. 시스템 범위로 해석될 수 있는 기본 개체 집합입니다. Kubernetes는 포드를 시작하는 방법, 컨테이너를 다시 시작하는 방법, 볼륨을 마운트하는 방법, ConfigMap을 사용하는 방법 등을 알고 있습니다. 시스템이라고 부를 수 있는 모든 것.

운영자는 도메인에서 운영됩니다. 각 연산자는 자체 주제 영역에 맞게 만들어졌습니다. ClickHouse를 위해 해냈습니다.

그리고 운영자는 복제본 추가, 다이어그램 작성, 모니터링 설정 등 주제 영역 측면에서 정밀하게 상호 작용합니다. 이로 인해 분열이 발생합니다.

복제본 추가 작업을 수행할 때 이러한 책임 분할이 어떻게 발생하는지에 대한 실제 예를 살펴보겠습니다.

운영자는 복제본을 추가하는 작업을 받습니다. 운영자는 무엇을 하나요? 운영자는 이러한 템플릿, 볼륨 청구가 설명되어야 하는 새로운 StatefulSet을 생성해야 한다고 계산합니다.

다 준비해서 K8s에 넘겨줬어요. 그는 ConfigMap, StatefulSet, Volume이 필요하다고 말합니다. 쿠버네티스가 작동 중입니다. 그는 자신이 운영하는 기본 단위를 구체화합니다.

그런 다음 ClickHouse 운영자가 다시 작동합니다. 그는 이미 무언가를 할 수 있는 물리적 포드를 가지고 있습니다. 그리고 ClickHouse-operator는 다시 도메인 용어로 작동합니다. 저것들. 특히 ClickHouse의 경우 클러스터에 복제본을 포함하려면 먼저 이 클러스터에 존재하는 데이터 스키마를 구성해야 합니다. 그리고 둘째, 이 복제본을 모니터링에 포함시켜 명확하게 추적할 수 있도록 해야 합니다. 운영자가 이미 이를 구성했습니다.

그 후에야 ClickHouse 자체가 작동하게 됩니다. 또 다른 상위 레벨 엔터티. 이것은 이미 데이터베이스입니다. 여기에는 클러스터에 참여할 준비가 된 또 다른 구성된 복제본인 자체 인스턴스가 있습니다.

복제본을 추가할 때 실행 체인과 책임 분할이 상당히 긴 것으로 나타났습니다.

우리는 실질적인 업무를 계속합니다. 클러스터가 이미 있는 경우 구성을 마이그레이션할 수 있습니다.

클릭하우스가 이해하는 기존 xml을 통해 붙여넣을 수 있도록 만들었습니다.

ClickHouse를 미세 조정할 수 있습니다. Just Zoned Deployment는 제가 로컬 스토리지인 호스트패스(hostPath)를 설명할 때 말씀드렸던 것입니다. 이것이 구역화된 배포를 올바르게 수행하는 방법입니다.

다음 실제 작업은 모니터링입니다.

클러스터가 변경되면 정기적으로 모니터링을 구성해야 합니다.

다이어그램을 살펴 보겠습니다. 우리는 이미 여기서 녹색 화살표를 살펴보았습니다. 이제 빨간색 화살표를 살펴보겠습니다. 이것이 우리가 클러스터를 모니터링하는 방법입니다. ClickHouse 클러스터의 측정항목이 Prometheus로 유입된 다음 Grafana로 유입되는 방식입니다.

모니터링에 있어서 어려운 점은 무엇인가요? 이것이 일종의 성과로 제시되는 이유는 무엇입니까? 어려움은 역학에 있습니다. 하나의 클러스터가 있고 정적이면 모니터링을 한 번만 설정하면 더 이상 귀찮게 하지 않아도 됩니다.

그러나 클러스터가 많거나 무언가가 지속적으로 변화하는 경우 프로세스는 동적입니다. 그리고 지속적으로 모니터링을 재구성하는 것은 자원과 시간 낭비입니다. 그냥 게으름이라도요. 이는 자동화되어야 합니다. 어려움은 프로세스의 역학에 있습니다. 그리고 운영자는 이를 아주 잘 자동화합니다.

우리 클러스터는 어떻게 발전했나요? 처음에 그는 그랬다.

그랬더니 그 사람이 이러더군요.

결국 그는 이렇게 됐다.

그리고 모니터링은 운영자가 자동으로 수행됩니다. 단일 진입점.

그리고 출구에서 Grafana 대시보드를 보고 클러스터의 수명이 내부에서 어떻게 끓고 있는지 확인합니다.

그건 그렇고, Grafana 대시보드는 소스 코드에서 직접 운영자와 함께 배포됩니다. 연결하여 사용하실 수 있습니다. 우리 DevOps 팀에서 이 스크린샷을 제공했습니다.

다음에는 어디로 가고 싶나요? 이것:

• 테스트 자동화를 개발하세요. 주요 작업은 새 버전의 자동화된 테스트입니다.
• 우리는 또한 ZooKeeper와의 통합을 자동화하고 싶습니다. 그리고 ZooKeeper-operator와 통합할 계획도 있습니다. 저것들. ZooKeeper를 위한 연산자가 작성되었으며 보다 편리한 솔루션을 구축하기 위해 두 연산자가 통합되기 시작하는 것이 논리적입니다.
• 우리는 더 복잡한 활력징후를 만들고 싶습니다.
• 템플릿 상속에 가까워지고 있음을 녹색으로 강조했습니다. 완료(DONE), 즉 다음 연산자 릴리스에서는 이미 템플릿 상속을 갖게 됩니다. 이는 여러 조각으로 복잡한 구성을 구축할 수 있는 강력한 도구입니다.
• 그리고 우리는 복잡한 작업의 자동화를 원합니다. 가장 중요한 것은 Re-sharding입니다.

몇 가지 중간 결과를 살펴보겠습니다.

결과적으로 우리는 무엇을 얻습니까? 그리고 할 가치가 있습니까, 없습니까? 데이터베이스를 Kubernetes로 끌어서 일반적으로 연산자를 사용하고 특히 Alitnity 연산자를 사용해야 합니까?

출력에서 우리는 다음을 얻습니다:

• 구성, 배포, 유지 관리가 크게 단순화되고 자동화됩니다.
• 즉시 내장된 모니터링.
• 복잡한 상황에 바로 사용할 수 있는 코드화된 템플릿도 제공됩니다. 복제본 추가와 같은 작업을 수동으로 수행할 필요가 없습니다. 운영자가 이런 일을 합니다.

마지막 질문만 남았습니다. 우리는 이미 Kubernetes, 가상화에 데이터베이스를 보유하고 있습니다. 특히 ClickHouse가 성능에 최적화되어 있으므로 이러한 솔루션의 성능은 어떻습니까?

대답은 모든 것이 괜찮다는 것입니다! 자세한 내용은 다루지 않겠으며 이는 별도 보고서의 주제입니다.

하지만 TSBS와 같은 프로젝트가 있습니다. 주요 임무는 무엇입니까? 데이터베이스 성능 테스트입니다. 이는 따뜻함과 따뜻함, 부드러움과 부드러움을 비교하려는 시도입니다.

그는 어떻게 일합니까? 하나의 데이터 세트가 생성됩니다. 그런 다음 이 데이터 세트는 동일한 테스트 세트를 사용하여 다른 데이터베이스에서 실행됩니다. 그리고 각 데이터베이스는 자신이 알고 있는 방식으로 하나의 문제를 해결합니다. 그런 다음 결과를 비교할 수 있습니다.

이미 많은 양의 데이터베이스를 지원합니다. 저는 크게 세 가지를 알아냈습니다. 이것:

• TimescaleDB.
• 인플럭스DB.
• 클릭하우스.

다른 유사한 솔루션과도 비교했습니다. RedShift와 비교. 비교는 아마존에서 했습니다. ClickHouse는 이 문제에 있어서도 모든 사람보다 훨씬 앞서 있습니다.

내가 말한 내용에서 어떤 결론을 내릴 수 있습니까?

• Kubernetes의 DB가 가능합니다. 아마도 무엇이든 가능할 것 같지만 전반적으로 가능해 보입니다. Kubernetes의 ClickHouse는 운영자의 도움으로 확실히 가능합니다.
• 운영자는 프로세스를 자동화하고 실제로 삶을 더 쉽게 만듭니다.
• 성능은 정상입니다.
• 그리고 이것이 사용될 수 있고 사용해야 하는 것 같습니다.

오픈 소스 - 우리와 함께하세요!

아까 말했듯이 오퍼레이터는 완전 오픈소스 제품이라 최대한 많은 인원이 이용하면 참 좋을 것 같아요. 우리와 함께하세요! 우리는 여러분 모두를 기다리고 있습니다!

Всем спасибо!

질문

신고해 주셔서 감사합니다! 내 이름은 안톤이에요. 저는 SEMrush 출신입니다. 로깅이 어떻게 되는지 궁금합니다. 모니터링에 대해서는 듣지만 전체 클러스터에 대해 이야기하면 로깅에 대해서는 전혀 듣지 못합니다. 예를 들어 하드웨어에서 클러스터를 키웠습니다. 그리고 우리는 중앙 집중식 로깅을 사용하여 표준 수단을 사용하여 공통 힙에 수집합니다. 그리고 거기에서 우리는 관심 있는 데이터를 얻습니다.

좋은 질문입니다. 예를 들어 할 일 목록에 로그인하는 것입니다. 우리 운영자는 아직 이것을 자동화하지 않습니다. 아직 개발 중이고 프로젝트가 아직 초기 단계입니다. 우리는 로깅의 필요성을 이해합니다. 이것은 또한 매우 중요한 주제입니다. 그리고 아마도 모니터링보다 덜 중요하지 않을 것입니다. 하지만 구현 목록의 첫 번째는 모니터링이었습니다. 로깅이 있을 것입니다. 당연히 우리는 클러스터 생활의 모든 측면을 자동화하려고 노력합니다. 따라서 대답은 불행히도 현재 운영자는 이 작업을 수행하는 방법을 모르지만 계획에 있으므로 수행할 것이라는 것입니다. 가입을 원하시면 Pull Request를 눌러주세요.

안녕하세요! 신고해 주셔서 감사합니다! 영구 볼륨과 관련된 표준 질문이 있습니다. 이 연산자를 사용하여 구성을 생성할 때 연산자는 특정 디스크나 폴더가 연결된 노드를 어떻게 결정합니까? 먼저 디스크가 있는 노드에 ClickHouse를 배치해 달라고 설명해야 합니다.

내가 이해하는 한, 이 질문은 로컬 저장소, 특히 그것의 호스트 경로 부분의 연속입니다. 이는 물리적으로 연결된 디스크가 있고 이러한 경로를 따라 마운트되는 이러한 노드에서 포드를 시작해야 한다는 것을 전체 시스템에 설명하는 것과 같습니다. 이것은 답변이 상당히 크기 때문에 제가 매우 피상적으로 다루었던 전체 섹션입니다.

간략히 보면 이렇습니다. 당연히 이러한 볼륨을 프로비저닝해야 합니다. 현재 로컬 스토리지에는 동적 프로비저닝이 없으므로 DevOps는 디스크 자체, 즉 이러한 볼륨을 잘라야 합니다. 그리고 그러한 노드에 위치하는 그러한 클래스의 영구 볼륨을 갖게 될 것이라는 Kubernetes 프로비저닝을 설명해야 합니다. 그런 다음 이러한 로컬 스토리지 클래스가 필요한 포드는 레이블을 사용하여 해당 노드로만 연결되어야 한다는 점을 Kubernetes에 설명해야 합니다. 이러한 목적을 위해 운영자는 일종의 레이블과 호스트 인스턴스당 하나를 할당할 수 있습니다. 그리고 Pod는 간단히 말해서 요구 사항, 레이블을 충족하는 노드에서만 실행되도록 Kubernetes에 의해 라우팅되는 것으로 나타났습니다. 관리자는 수동으로 레이블을 할당하고 디스크를 프로비저닝합니다. 그런 다음 확장됩니다.

그리고 이를 좀 더 쉽게 만드는 데 도움이 되는 것이 세 번째 옵션인 로컬입니다. 이미 강조했듯이 이는 튜닝에 대한 힘든 작업이며 궁극적으로 최대 성능을 얻는 데 도움이 됩니다.

이와 관련된 두 번째 질문이 있습니다. Kubernetes는 노드 손실 여부가 중요하지 않도록 설계되었습니다. 이 경우 샤드가 정지된 노드를 잃어버린 경우 어떻게 해야 합니까?

예, Kubernetes는 처음에는 Pod와의 관계가 소와 같다는 입장을 취했지만 여기서는 각 디스크가 애완동물과 같습니다. 그냥 버릴 수 없는 문제가 있습니다. 그리고 쿠버네티스의 발전은 완전히 버려진 자원처럼 철학적으로 완전히 다루기가 불가능한 방향으로 나아가고 있다.

이제 실용적인 질문이 있습니다. 디스크가 있던 노드를 분실한 경우 어떻게 해야 합니까? 여기서 문제는 더 높은 수준에서 해결됩니다. ClickHouse의 경우 더 높은 수준에서 작동하는 복제본이 있습니다. ClickHouse 수준에서.

그 결과 처분은 무엇입니까? DevOps는 데이터가 손실되지 않도록 할 책임이 있습니다. 그는 복제를 올바르게 설정해야 하며 복제가 실행 중인지 확인해야 합니다. ClickHouse 수준의 복제본에는 중복된 데이터가 있어야 합니다. 이는 운영자가 해결하는 문제가 아닙니다. Kubernetes 자체가 해결하는 문제는 아닙니다. 이것은 ClickHouse 수준에 있습니다.

철 노드가 떨어지면 어떻게 해야 합니까? 그리고 두 번째 디스크를 설치하고 디스크를 적절하게 프로비저닝하고 레이블을 적용해야 한다는 것이 밝혀졌습니다. 그 후에는 Kubernetes가 인스턴스 포드를 시작할 수 있는 요구 사항을 충족하게 됩니다. Kubernetes가 이를 시작합니다. 포드 수가 지정된 수를 충족하기에 충분하지 않습니다. 제가 보여드린 사이클을 거치게 됩니다. 그리고 가장 높은 수준에서 ClickHouse는 우리가 복제본을 입력했지만 여전히 비어 있으므로 데이터 전송을 시작해야 한다는 것을 이해합니다. 저것들. 이 프로세스는 아직 제대로 자동화되지 않았습니다.

신고해 주셔서 감사합니다! 온갖 불쾌한 일이 일어나면 오퍼레이터가 크래쉬나 재시작을 하고, 그 순간 이벤트가 도착하는데 어떻게든 처리해주실 수 있나요?

운영자가 충돌하고 다시 시작하면 어떻게 되나요?

예. 그리고 그 순간 이벤트가 도착했습니다.

이 경우 수행할 작업은 운영자와 Kubernetes 간에 부분적으로 공유됩니다. Kubernetes에는 발생한 이벤트를 재생할 수 있는 기능이 있습니다. 그는 다시 재생합니다. 그리고 운영자의 임무는 이벤트 로그가 자신에게 재생될 때 이러한 이벤트가 멱등성을 갖는지 확인하는 것입니다. 동일한 이벤트가 반복적으로 발생하더라도 시스템이 중단되지 않도록 하기 위함입니다. 그리고 우리 운영자는 이 작업에 대처합니다.

안녕하세요! 신고해 주셔서 감사합니다! 드미트리 Zavyalov, 회사 스메도바. 운영자에게 haproxy를 구성하는 기능을 추가할 계획이 있나요? 저는 표준형 밸런서 외에 다른 밸런서에 관심이 있어서 ClickHouse가 실제로 거기에 있다는 것을 똑똑하게 이해할 수 있습니다.

인그레스 말씀하시는 건가요?

예, Ingress를 haproxy로 교체하세요. haproxy에서는 복제본이 있는 클러스터의 토폴로지를 지정할 수 있습니다.

우리는 아직 그것에 대해 생각하지 않았습니다. 그것이 필요하고 그것이 왜 필요한지 설명할 수 있다면, 특히 참여를 원하는 경우 이를 구현하는 것이 가능할 것입니다. 우리는 옵션을 기꺼이 고려해 보겠습니다. 간단히 대답하자면 '아니요'입니다. 현재로서는 그러한 기능이 없습니다. 팁을 주셔서 감사합니다. 이 문제를 조사해 보겠습니다. 그리고 예를 들어 GitHub에서 문제를 생성하는 등 사용 사례와 실제로 필요한 이유를 설명한다면 좋을 것입니다.

이미 가지고있다.

괜찮은. 우리는 어떤 제안에도 열려 있습니다. 그리고 haproxy가 할일 목록에 추가됩니다. 할 일 목록은 아직 줄어들지 않고 늘어나고 있습니다. 하지만 이것은 좋다. 즉, 제품에 대한 수요가 있다는 뜻이다.

출처 : habr.com