카우치베이스 자율 운영자 1.0.0은 불과 8개월 전에 출시되었습니다. 그 후 곧바로 1.1.0이 출시되었습니다. 이 기간 동안 저희는 사용자 커뮤니티로부터 엄청난 피드백을 받았습니다. 무엇보다도 도움을 주신 모든 분들께 감사드리며, 앞으로도 이 제품을 계속 발전시켜 나가겠습니다.
운영자 버전 1.2.0은 첫 번째 주요 업데이트로, 수많은 변경 요청을 해결합니다.
이 글에서는 이번 릴리즈의 모든 주요 새 기능과 사용성 개선 사항을 살펴봅니다. 새로운 네트워킹 및 배포 옵션(헬름 사용)은 별도의 포스팅을 통해 확인할 수 있다. 링크는 페이지 하단에 제공된다.
클라우드 인증
Kubernetes는 단순한 애플리케이션 배포 프레임워크가 아니라 추상화 계층입니다. 비즈니스의 필요에 따라 클라우드 제공업체 간에 이동하는 것은 간단하고 비용 효율적이어야 합니다. "모든 달걀을 한 바구니에 담지 말라"는 옛 격언처럼, 실제로는 멀티클라우드 배포 전략을 채택하는 것이 현명합니다. Kubernetes는 이를 촉진하는 완벽한 매개체입니다.
하지만 클라우드 제공업체 간에는 미묘한 차이가 존재합니다. 스토리지와 네트워킹이 가장 큰 문제입니다. 차이가 있는 곳에는 불확실성과 예측 불가능성이 존재합니다.
Operator 1.2.0 릴리스는 Amazon EKS, Google GKE 및 Microsoft Azure AKS에서 완전히 인증된 최초의 릴리스입니다. 내부 회귀 테스트 스위트는 이제 클라우드 우선입니다. 모든 테스트는 이러한 주요 플랫폼에서 실행됩니다. 이를 통해 당사와 고객은 클라우드 제공업체 간에 존재하는 차이에 관계없이 운영자가 어떤 환경에서도 예측 가능하고 안정적으로 실행될 것이라는 확신을 가질 수 있습니다.
클라우드 환경에서의 실행에 대한 자세한 내용은 관련 도움말을 참조하세요. 빠른 시작 가이드.
스토리지 개선 사항
운영자가 지원하는 Kubernetes 플랫폼도 확장되어 Redhat Openshift의 경우 1.11~1.13 및 3.11 버전이 포함됩니다.
쿠버네티스 1.12 이전에는 가용성 영역 간에 퍼시스턴트 볼륨 스케줄링에 매우 주의해야 했습니다. 스케줄링에 인텔리전스가 없었기 때문에 한 가용 영역에서 퍼시스턴트 볼륨을 생성하는 동안 해당 볼륨에 액세스하려는 파드가 다른 가용 영역에 생성되는 것이 가능했습니다. 볼륨은 소비자와 동일한 데이터센터에 존재해야 하므로 이 방식은 작동하지 않습니다.
이러한 제약 조건을 고려한 Couchbase 클러스터를 만들 수는 있지만, 동일한 구성은 매우 장황하고 이해하고 유지 관리하기가 어렵습니다.
새로운 볼륨 바인딩 모드 - WaitForFirstConsumer - 는 동적으로 프로비저닝된 스토리지 클래스에 적용할 수 있도록 쿠버네티스 1.12에 도입되었다. 퍼시스턴트 볼륨 클레임을 생성할 때, 기본 퍼시스턴트 볼륨을 바로 생성하지 않는다. 퍼시스턴트 볼륨 클레임이 파드에 연결되면, 그 다음에만 파드가 스케줄된 것과 동일한 가용성 영역에 퍼시스턴트 볼륨이 생성된다.
1.12 이상의 Kubernetes 버전을 사용하고 이 새로운 지연 바인딩 모드로 Couchbase 클러스터를 프로비저닝할 것을 강력히 권장합니다. 클러스터 구성 파일이 크게 간소화되고 관리 및 유지 관리가 더 쉬워집니다. 이 영구 볼륨 방식은 모든 내부 테스트에서 사용되었으므로 사용 사례에 맞게 작동한다는 확신을 가질 수 있습니다.
카우치베이스 업그레이드
자동 업그레이드는 운영자 출시 이후 가장 많은 요청이 있었던 기능 중 하나였습니다. 이제 Operator 1.2.0에서 이 기능이 완전히 지원됩니다.
업그레이드 프로세스는 이 절차를 수동으로 수행하기 위한 표준 모범 사례를 따릅니다. 이전 버전의 Couchbase 데이터 플랫폼을 실행하는 파드가 업그레이드를 위해 선택되고 새 Couchbase 인스턴스가 생성됩니다. 고성능 스왑 재조정을 통해 기존 데이터가 새 노드로 이동하고 이전 노드는 삭제됩니다. 이 작업은 모든 파드가 목표 버전에 도달할 때까지 계속됩니다.
이러한 방식으로 운영하면 성능 저하나 클라이언트 중단 없이 안전한 온라인 업그레이드가 가능합니다.
표준 업그레이드 경로가 적용되므로 포인트 릴리스 업그레이드(5.5.3에서 5.5.4로)와 메이저 릴리스 업그레이드(5.5.3에서 6.0.1로)가 허용됩니다. 주요 릴리스(5.5.3~7.0.0)를 건너뛰는 업그레이드 및 다운그레이드는 허용되지 않으며 거부됩니다.
업그레이드 작업 도중에 롤백이 허용되지만 원래 버전으로만 롤백할 수 있습니다. 5.5.3에서 6.0.1로 업그레이드를 수행 중이고 8개 파드 중 3개가 업그레이드된 경우 5.5.3으로 되돌릴 수 있습니다.
업그레이드를 트리거하는 방법은 spec.version 필드에 입력합니다.
Kubernetes 업그레이드
많은 클라우드 플랫폼은 전체 Kubernetes 클러스터의 원클릭 업그레이드를 제공합니다. 이는 Couchbase 데이터 플랫폼과 같은 스테이트풀 애플리케이션에 위험하며 데이터 손실로 이어질 수 있습니다. 이 시나리오를 방지하기 위해, 오퍼레이터 1.2.0 릴리즈는 파드를 안전하게 종료할 수 있는 시기를 관리하기 위해 몇 가지 추가 리소스를 생성합니다. Couchbase 클러스터는 다음과 같아야 합니다. 먼저 업그레이드 를 사용하여 이 기능을 활용할 수 있습니다.
자세한 내용은 이전 기사 주제에 대해 설명합니다.
TLS 인증서 순환 및 확인
이 기능을 통해 관리자는 루트 CA 인증서와 함께 와일드카드 인증서 체인 및 개인 키를 제공하여 운영자가 Couchbase 데이터 플랫폼에 설치할 수 있습니다.
이 기능은 변경되지 않았지만 이제 서버 인증서 또는 전체 PKI의 로테이션을 지원합니다. 이를 통해 인증서 만료 또는 개인 키 손상을 처리할 수 있는 메커니즘을 제공합니다. 로테이션 작업을 트리거하려면 TLS 비밀을 업데이트해야 하며 나머지는 운영자가 처리합니다. 저희의 TLS 문서 에서 자세한 내용을 확인하세요.
TLS는 쉽지 않습니다. 네트워킹과 X.509 표준에 대한 충분한 지식이 있어야 작동할 수 있으며, TLS 구성이 잘못되어 클러스터 프로비저닝에 실패하는 경우가 많이 발생합니다. 오류 메시지는 기껏해야 난해하기 때문에 이 분야의 사용자 경험을 개선하기 위해 노력해 왔습니다.
이제 클러스터가 생성될 때 TLS 시크릿이 존재하면 콘텐츠의 유효성이 검사됩니다. 이를 통해 인증서와 키가 올바른 형식인지, 인증서가 특정 Couchbase 클러스터 및 Kubernetes 네임스페이스에 유효한지, 서버 인증서가 루트 CA에 대해 유효성을 검사하는지 등을 확인합니다. 이 모든 것은 간단하고 이해하기 쉬운 메시지로 사용자에게 다시 보고됩니다. 이 작업을 수행하는 방법은 다음 섹션에서 설명합니다...
동적 입장 제어
쿠버네티스 API는 핵심 유형에 대한 YAML 매니페스트의 오류를 다시 보고한다. 오퍼레이터 1.2.0 이전에는 다음과 관련된 JSON 스키마를 사용했습니다. 카우치베이스클러스터 사용자 정의 리소스 정의를 사용하여 간단한 서식 지정 오류를 잡아낼 수 있습니다. Couchbase 배포와 관련된 다른 보다 복잡한 유효성 검사를 위해 별도의 바이너리를 배포하여 YAML의 유효성을 검사합니다.
이 방법은 효과가 있었지만 최종 사용자가 사용하지 않았을 수도 있습니다. 확실히 기존 워크플로와 잘 맞지 않았습니다. kubectl 또는 oc 클라이언트를 지원합니다. 동적 어드미션 컨트롤러를 사용하면 이 심층 유효성 검사를 Kubernetes API에 직접 연결할 수 있습니다.
이제 다음을 사용하여 Couchbase 클러스터를 생성할 때 kubectl, 예를 들어, API는 요청을 오퍼레이터 1.2.0의 일부로 배포된 동적 허용 컨트롤러로 전달합니다. 그러면 동적 허용 컨트롤러는 요청을 허용할지 여부를 응답하기 전에 사용자 지정 리소스의 유효성을 검사하고 수정할 수 있습니다. 요청이 거부되면 그 이유가 클라이언트에 직접 전달됩니다. 배포가 작동하지 않는 이유를 찾기 위해 로그 파일을 살펴봐야 하는 일은 이제 과거의 일이 되었습니다.
사용자 정의 리소스를 수정하면 사용자 정의 리소스 유형에 필요한 새 필드를 자동으로 채울 수 있는 메커니즘이 제공됩니다. 이렇게 하면 이전 Couchbase 클러스터 YAML 파일과의 하위 호환성을 유지하는 데 도움이 됩니다.
동적 입장 컨트롤러의 작동 및 설치 방법에 대한 자세한 내용은 다음을 참조하세요. 문서.
로깅 개선 사항
Operator 1.1.0을 출시하면서 지원 도구가 일부 개선되었습니다. 이러한 개선 사항은 특히 상태 비저장 Couchbase 파드와 함께 사용할 때 로그 볼륨 사용을 처리하기 위한 것이었습니다. 로그 볼륨 컬렉션은 사용자에게 선택 및 로컬 다운로드가 가능한 대화형 메뉴를 제공했습니다. 이것은 환영할 만한 추가 기능이었지만, 실행 중인 포드에서 로그를 수집하는 방식과 정반대였습니다. 실행 중인 포드 로그는 무조건 수집되어 포드 자체에 남겨졌고, 최종 사용자는 다운로드와 정리에 대한 책임이 있었습니다.
운영자 1.2.0 릴리즈에서는 실행 중인 모든 파드와 로그 볼륨이 통합된 대화형 메뉴에 표시됩니다. 사용자는 수집할 로그를 정확히 선택할 수 있습니다. 이제 지원 도구는 요청된 모든 로그를 로컬로 자동 다운로드하고 실행 중인 포드에서 모든 중간 파일을 제거합니다.
또한 사용 가능한 로그를 폴링하고 수집을 자동화할 수 있도록 CLI 플래그를 통해 동일한 기능을 제공합니다. 자세한 내용은 cbopinfo 문서.
운영자가 파드를 생성하려고 시도했다가 실패하면 해당 파드를 삭제하고 실패의 원인이 일시적인 오류인 경우 다시 생성하려고 시도합니다. 컨테이너 이미지가 잘못 지정되었거나 스케줄러가 파드를 실행할 노드를 찾지 못하는 일반적인 경우에는 이를 나타낼 수 있는 방법이 없습니다.
Operator 1.2.0 릴리즈에서는 이러한 경우에 대응하고 간단한 문제 판단을 할 수 있도록 Operator 로그를 확장했습니다. 파드 생성에 실패하면 파드 상태 및 관련 이벤트 컬렉션이 트리거되어 로그 스트림에 출력됩니다.
쿠버네티스 RBAC
오퍼레이터는 쿠버네티스 리소스를 생성하고 조작하는 방식으로 작동한다. 이를 수행하려면 오퍼레이터에 권한을 부여해야 합니다. 예를 들어, 1.2.0 이전 버전에서는 단순히 "파드에 대한 모든 권한을 부여"라고 말합니다. 간결하고 이해하기 쉽지만, 운영에 꼭 필요하지 않은 권한을 오퍼레이터에게 부여했습니다.
오퍼레이터 버전 1.2.0부터 카우치베이스에서 배포하는 모든 예제 쿠버네티스 역할은 어떤 리소스 유형에 대해 어떤 작업이 필요한지 정확히 명시한다. 명시된 모든 권한은 필수이며, 오퍼레이터는 해당 권한이 없으면 작동할 수 없다. 어떤 권한이 필요하고 왜 필요한지에 대한 자세한 내용은 RBAC 문서.
이제 운영자가 클러스터 역할이 아닌 역할로 기능할 수 있는 기능이 완전히 지원됩니다. 클러스터 리소스에 대한 액세스가 필요했던 이전의 확인 및 건전성 검사는 이제 동적 허용 컨트롤러에서만 처리됩니다.
다음 단계
카우치베이스 자율 운영자 1.2.0은 많은 새로운 기능이 포함된 대규모 릴리스입니다. 주요 초점은 업그레이드 가능성과 사용 편의성입니다. 저희가 만든 즐거움만큼이나 여러분도 멋진 새 기능을 사용해 보시기 바랍니다. 언제나 그렇듯이 여러분의 피드백이 가장 중요합니다!
- 사용해 보세요: https://www.couchbase.com/downloads
- 지원 포럼: https://www.couchbase.com/forums/c/couchbase-server/Kubernetes
- 문서화: https://docs.couchbase.com/operator/1.2/whats-new.html
자세히 보기
- 자율 운영자 1.2.0 네트워킹: https://www.couchbase.com/blog/autonomous-operator-1-2-0-networking
