아니요, 정신을 잃지 않았습니다. 유니콘은 카우치베이스 자율 운영자 2.0.0의 내부 코드명입니다. 이렇게 큰 범위의 릴리스에는 엄청난 노력과 열정을 담아낼 수 있는 신화적이고 환상적인 이름을 붙이고 싶었습니다. 또한 경영진에게 다음과 같은 플랫폼을 제공하는 것도 약간은 재미있습니다. 가지고 유니콘과 픽시에 대해 이야기해 보겠습니다! 이번 릴리즈의 난이도를 강조하기 위해, 오퍼레이터의 한 가지 핵심 측면에 초점을 맞추겠습니다: 바로 쿠버네티스 커스텀 리소스입니다. 커스텀 리소스는 오퍼레이터가 수행하는 모든 작업을 뒷받침합니다.
이 게시물은 오퍼레이터의 내부 작동을 자세히 살펴보는 기술 블로그 시리즈의 일부입니다. 이 블로그에서는 다음 사항을 중점적으로 다룹니다. A에서 B로 이동하기. 간단해 보이지 않나요? (혹은 막연하게...) 보시다시피 전혀 그렇지 않았습니다. 우리는 이것이 의미하는 바를 정의하고, 기술적 과제를 살펴보고, 마지막으로 우리가 왜 이 작업을 선택했는지에 도달할 것입니다.
개발팀부터 최종 사용자인 여러분까지, 저희의 개발 과정만큼이나 좋은 사용 경험을 하시길 바랍니다.
CRD로 A에서 B로?
그렇다면 이것이 의미하는 바는 무엇일까요? 먼저 왜 B가 필요한지 먼저 살펴보겠습니다. Operator 1.x는 단일 구성 오브젝트인 사용자 지정 리소스 를 의미합니다. 이 접근 방식은 모든 것이 중앙 집중식으로 제어된다는 장점이 있지만 클러스터의 모든 측면에 액세스하여 클러스터를 변경할 수 있다는 단점도 있습니다.
저는 첫 번째 접근 방식이 마음에 들어서 팀원들에게 항상 이야기합니다:
하지만 저희는 무엇보다도 엔터프라이즈 서비스를 제공하고 있습니다. 네트워킹 계층부터 클러스터의 수명 기간 동안 존재하는 비즈니스 프로세스에 이르기까지 보안을 최우선으로 고려해야 합니다.
우려 사항 분리
명확한 비즈니스 요구사항은 사용자가 비공개 데이터 버킷을 생성하고 사용할 수 있어야 한다는 것이었습니다. 같은 사용자에게 다른 작업을 할 수 있는 권한이 주어져서는 안 됩니다. 클러스터를 확장할 수 있는 기능도 허용되지 않아야 했습니다. 다른 사용자들에게 방해가 될 수 있기 때문입니다. 따라서 저희의 목표는 다음과 같았습니다:
- 쿠버네티스 내에서 역할 정의하기
- 사용자는 다른 사용자에게 영향을 주지 않고 버킷을 관리하고 데이터를 처리할 수 있습니다.
- 관리자는 필요에 따라 클러스터 토폴로지를 수정할 수 있습니다.
역할은 강력한 보안을 보장할 뿐만 아니라 우려 사항을 분리합니다. 최종 사용자는 문서 조작과 N1QL 쿼리 실행에 대한 지식만 있으면 됩니다. 관리자의 주요 관심사는 보안 규정 준수, 리소스 사용률 및 비용입니다. 하지만 절충점이 있습니다. 지식을 특정 도메인으로 제한하면 해당 도메인 간에 장벽이 생길 수도 있습니다. 솔루션은 다음을 선택할 수 있는 기능을 제공하려면 유연성이 필요합니다. 어디 어떤 장벽도 존재하지 않습니다.
사용자 지정 리소스 분해
목표를 달성하기 위한 핵심은 Kubernetes RBAC입니다. Kubernetes RBAC는 특정 사용자가 특정 리소스 유형에 대해 특정 작업을 수행할 수 있도록 합니다. 우리는 모놀리식 카우치베이스 클러스터 리소스를 별도의 코어 클러스터와 버킷 리소스 유형으로 분할하여 목표를 향해 나아갑니다. 각 리소스 유형에는 이를 사용할 수 있는 별도의 사용자 집합이 있을 수 있습니다.
클러스터의 한 측면을 구성하는 것이 다른 측면을 손상시킬 수 있다는 점도 고려해야 할 사항입니다. Operator 2.0에서는 데이터 센터 간 복제(XDCR) 관리가 도입되었습니다. 버킷 사용자가 직접 복제 전략을 설정할 수 있도록 하면 좋을 것 같습니다. 복제를 구성하려면 원격 클러스터에 연결해야 합니다. 이를 위해서는 Kubernetes 시크릿으로 구성된 자격 증명이 필요합니다. 사용자에게 시크릿에 대한 액세스 권한을 부여하면 네임 스페이스의 모든 비밀번호와 TLS 개인 키가 공개됩니다.
따라서 다음과 같은 사항을 고려합니다. any 비밀에 대한 액세스를 '관리자 전용' 작업으로 설정합니다. 이렇게 하면 지식 영역 간의 범위를 최대한 제한하는 데 도움이 됩니다.
사용자 지정 리소스 집계
이제 Couchbase 클러스터의 구성은 여러 리소스에 분산되어 있습니다. 이러한 리소스는 특정 역할을 맡은 여러 사람이 제어합니다. 하지만 운영자는 전체 그림 를 사용하여 클러스터를 만들고 관리할 수 있습니다.
기본적으로 Operator 2.0은 자체적인 잘못 없이 순진하게 작동합니다. 카우치베이스 클러스터 모니터링을 시작하면 발견되는 모든 버킷 리소스도 모니터링합니다. 이러한 클러스터와 버킷 리소스의 집합에서 단일 논리적 클러스터가 생성됩니다. 다른 클러스터를 만들면 이 클러스터도 동일한 버킷 리소스를 찾아서 집계합니다. 이 동작을 원치 않을 수도 있지만, 쿠버네티스는 다시 방법을 제공합니다.
집계되는 각 리소스 유형에 대해 구성할 수 있는 해당 레이블 선택기가 있습니다. 이 레이블 선택기를 사용하면 어떤 리소스가 집계되는지 정확하게 제어할 수 있습니다. 운영자는 일치하는 레이블이 있는 리소스만 선택합니다.
출발
이제 Couchbase 클러스터 리소스를 분해하는 것이 좋은 일이라는 것을 알게 되었습니다. 물론 단점이 없는 것은 아니지만, 단점보다 장점이 더 큽니다.
쿠버네티스는 RBAC 및 레이블 선택으로 목표를 달성하는 데 도움이 되는 프리미티브를 제공합니다. A에서 B로 가는 여정은 쉬울 것 같죠? 다시 생각해 보세요.
플랫폼 제약 조건
완벽한 세상이라면 오퍼레이터는 사용 가능한 모든 쿠버네티스 버전에서 실행될 것입니다. 이것은 아마도 는 이전 버전과의 호환성을 유지하는 향후 버전의 쿠버네티스에서도 마찬가지입니다. 나는 아마도 릴리스 이전에 작성된 애플리케이션과 호환되지 않는 확장이 도입될 수 있기 때문입니다. 이러한 이유로, 각 Operator 릴리스에는 인증된 Kubernetes 버전 창이 있습니다.
인증된 쿠버네티스 버전에는 상한과 하한이 있습니다. 그 한계는 저희가 통제할 수 없습니다. 클라우드 공급업체가 특정 버전을 지원하는 경우에만 인증할 수 있습니다. 이 글을 쓰는 시점에 Google Kubernetes Engine(GKE)은 Kubernetes 버전 1.14와 1.15만 허용합니다. 이 운영자는 Amazon Elastic Kubernetes Service(EKS), Microsoft Azure Kubernetes Service(AKS) 및 Red Hat OpenShift Container Platform(OCP)에서 인증되었습니다. 이 세 가지 플랫폼에서 지원되는 공통된 Kubernetes 버전은 다음과 같습니다. 모두 플랫폼.
CAO 2.0.0의 하한은 Kubernetes 1.13이었습니다.
사용자 지정 리소스 버전 관리
쿠버네티스 1.13은 버전화된 커스텀 리소스 정의(CRD)를 도입했다. 이를 통해 쿠버네티스는 여러 가지 사용자 정의 리소스 형식을 인식할 수 있습니다. 이것은 우리의 필요에 완벽해 보이지만 악마는 세부 사항에 있습니다.
CRD 버전 관리는 리소스를 단일 버전으로만 저장한다. 리소스 유형의 v1과 v2를 정의하면, 모든 리소스는 쿠버네티스에 의해 단일 버전(예: v2)으로 저장됩니다. 사용자 정의 리소스 변환 훅은 클라이언트가 v1 API로 리소스에 액세스할 때 저장된 v2에서 v1 리소스로 변환할 수 있는 방법을 제공합니다. 변환은 하나의 리소스를 가져와 하나의 리소스를 반환하도록 설계되어 간단한 연산만 수행합니다. 운영자 입장에서는 모놀리식 클러스터 구성과 모듈식 클러스터 구성 간에 변환하는 것은 너무 많은 작업이 필요합니다.
또 다른 우려는 Kubernetes 1.13에서 CRD 변환이 알파급 기능이라는 점이었습니다. 저는 보다 원활한 사용자 경험(UX)을 제공하는 기능이라면 무엇이든 좋아합니다. 그러나 사용자들은 침입적인 Kubernetes API 재구성을 통해 알파 등급 기능을 활성화하는 것에 대해서는 그다지 열광하지 않습니다. 일반적으로 일반적으로 사용할 수 있는 API가 베타 단계에 있을 때만 기능을 사용하기 시작합니다.
마지막 문제는 Kubernetes 1.13의 CRD 버전 관리가 단일 JSON 스키마만 지원한다는 것이었습니다. 즉, 설치 시 v2 Couchbase 클러스터 CRD는 v1 및 v2 사용자 정의 리소스 유형을 모두 지원할 수 있지만 단일 v2 스키마에 대한 유효성 검사가 실패하기 때문에 v1 리소스에 대한 모든 업데이트가 실패하게 됩니다.
비가 내리지 않고 쏟아집니다
겉으로 보기에는 우리가 막혀 있는 것처럼 보입니다. 좋은 아이디어는 처음부터 다시 시작하지 않고는 달성할 수 없습니다. CRD 변환은 사용할 수 없고 원하는 용도로 설계되지 않았기 때문에 사용할 수 없습니다. 단일 스키마만 지원되므로 여러 버전의 오퍼레이터를 동시에 실행할 수 없습니다. 하지만 저는 영국인입니다:
사용자 지정 리소스의 단일 버전만 지원되는 경우에는 모든 것을 한 번에 업그레이드하면 됩니다. 변환 프로세스가 남습니다.
거의 다 왔나요?
사실, 그렇습니다. 성공의 열쇠는 간단합니다. 유효성이 검사되지 않은 오래된 v1 Couchbase 클러스터 리소스를 읽은 다음, 새로운 v2 Couchbase 클러스터 리소스와 여기에 필요한 모든 버킷 리소스를 쓰면 유효성이 검사됩니다.
앞서 언급했듯이 UX는 매우 중요하므로, 저희는 도구를 사용하여 변환을 수행합니다. 를 사용하세요. 예상대로 레이블 선택기를 사용하며 안전하게 작동합니다. 새로운 기능이 활성화되지 않으며 모든 새로운 기능은 옵트인 방식이므로 기존 XDCR 및 Couchbase RBAC 설정은 업그레이드 프로세스의 영향을 받지 않습니다.
도착
드디어 B에 도달했습니다! 역경을 딛고 모놀리식 구성 모델에서 모듈식 구성 모델로 전환할 수 있었습니다. 거의 완벽하게 원활한 온라인 업그레이드 프로세스를 정의할 수 있었습니다. 이제 CAO 2.0이 제공하는 가능성을 탐색할 수 있는 권한은 여러분의 손에 달려 있습니다.
언제나 그렇듯이 여러분께서 저희의 방향을 선택해 주셨고, 앞으로도 여러분께서 저희의 방향을 선택해 주실 것입니다. 여러분의 피드백과 제안, 그리고 감히 말씀드리자면 비판을 기다리겠습니다!
목적지가 아니라 여정입니다.
저는 거대한 이 릴리스에 대한 기술 문서를 작성하는 데 많은 시간을 할애했습니다. 즐기기). 지나치게 기술적인 건조한 블로그보다는 변화가 필요하다고 생각했기 때문에 끝없는 비유를 사용했습니다. 제가 표현하려고 노력한 것은 이러한 이정표를 달성하기 위해 팀으로서 직면한 모든 기술적 도전과 절충안입니다. 제품 마케팅 관점에서 보면 단순한 새 기능처럼 보일 수 있지만, 내부(보닛)를 들여다보면 훨씬 더 복잡합니다.
여러분을 대신하여 이러한 복잡한 작업을 수행하고 이에 대해 솔직하게 이야기함으로써 여러분이 그 작업에 들어가는 노력에 대해 감사하는 마음을 갖게 되기를 진심으로 바랍니다. 우리의 이야기가 다른 분들에게도 공감을 불러일으키길 바랍니다. 쿠버네티스는 이러한 아이디어가 개선되고 통합될수록 모두에게 더 나은 도구가 될 수 있습니다. 아직 갈 길이 멀지만 이 여정에 동행해 주셔서 감사합니다.
