카우치베이스 자율 운영자 개념 증명 구축 방법

고객의 첫 경험에 대한 이야기를 들을 때마다 를 사용하여 카우치베이스 자율 운영자(CAO) 쿠버네티스의 경우 첫 번째 질문은 "얼마인가요?"인 경향이 있습니다.

대답은 엔터프라이즈 에디션 구독에 이미 포함되어 있다는 것입니다. 이 소식을 듣고 기쁜 마음으로 대부분의 고객은 Couchbase Autonomous Operator를 사용하여 소규모 개념 증명(PoC)을 수행하는 다음 단계로 넘어갑니다.

이미 사용 중인 경우 카우치베이스를 통해 서비스 노드 관리, 버전 업그레이드 등 필요한 유지 관리 방법을 알고 있습니다. OS 업그레이드와 같이 Couchbase 외부에서 필요한 유지 관리도 있습니다. 이러한 모든 유지 관리 단계에는 인력이 필요합니다.

CAO는 이러한 인력 리소스 부담을 덜어주어 Couchbase 클러스터의 구성, 생성, 확장 및 복구와 같은 일반적인 Couchbase 작업의 관리를 자동화할 수 있게 해줍니다. Couchbase 클러스터 실행의 복잡성을 줄임으로써 수동 배포 및 수명 주기 관리의 세부 사항에 대해 걱정하지 않고 원하는 구성에 집중할 수 있습니다.

고객들은 종종 최선의 의도를 가지고 PoC에 뛰어들기도 하고, 때로는 Kubernetes(또는 멋지다면 K8)를 처음 경험하기도 합니다. 하지만 카우치베이스 자율 운영자는 복잡한 도구입니다: 일반적으로 숙련된 엔지니어로 구성된 팀이 24시간 내내 Couchbase 클러스터를 지속적으로 관리해야 하는 작업을 오케스트레이션합니다. 따라서 신중하게 접근해야 합니다.

이 경우, Kubernetes와 CAO에 대한 기본적인 이해가 중요합니다. 이를 바탕으로 성공적인 개념 증명을 구축할 수 있습니다. 이러한 배경 지식이 없으면 새로운 PoC의 문제를 해결하기 어렵거나 불가능할 것입니다.

이 블로그 게시물에서는 Couchbase 자율 운영자 및 Couchbase 클러스터를 신속하게 배포하는 방법을 안내합니다.

자세히 알아보기 전에

이 블로그 게시물은 CAO에 초점을 맞추고 있으며 일정 수준의 Kubernetes 지식이 있다고 가정합니다. 처음 사용하시거나 녹슬었다면 이 글을 참고하세요, 쿠버네티스에 대한 간략한 복습은 다음과 같습니다..

Kubernetes는 방대하고 복잡한 에코시스템이므로 이 글에서는 가능한 한 쉽게 클러스터를 실행할 수 있도록 하려고 합니다. CAO는 클라우드에 구애받지 않으므로 자체 Kubernetes 클러스터든 퍼블릭 클라우드 제공업체의 Kubernetes 서비스든 다양한 클라우드 환경에서 실행됩니다.

이 블로그 게시물에서는 다음을 사용하겠습니다. 도커의 쿠버네티스, 일명 "종류"를 사용하여 로컬 컨테이너로 Kubernetes 노드를 실행하려면 Docker가 설치되어 실행 중이어야 합니다.

저희는 여러 가지 이유로 친절함을 사용하고 있습니다:

• 설치는 빠르고 쉽습니다.
• 각 쿠버네티스 버전에 사용할 기본 이미지가 있습니다.
• 환경을 최대한 빠르게 실행할 수 있습니다.

심지어 친절하게도(알겠어요?)는 Kubernetes 클러스터와 상호 작용하는 방법과 완료 시 클러스터를 삭제하는 방법을 알려줍니다. 이 모든 것이 단일 페이지에서 시각화되어 있으며, 지속적인 통합 및 배포/클라우드 배포(CI/CD), 코드형 인프라(IaC)와 같은 다양한 사용 사례에 적합합니다. 초보자도 쉽게 클러스터를 프로비저닝하고 파괴할 수 있습니다.

종류 설치 방법

먼저 Docker가 설치되어 있는지 확인합니다. 그런 다음 OS에 따라 다음 단계를 따라 종류를 설치합니다:

Linux에서:

홈브루를 통해 macOS에서:

Windows에서:

클러스터 만들기

클러스터 생성을 시작하기 전에, 해당 종류는 Kubernetes 노드에 Docker를 사용하므로 시작하기 전에 Docker가 실행 중인지 확인하세요.

클러스터를 현물로 생성하는 방법은 간단합니다. 종류 클러스터 생성 로 설정하고 기본 클러스터를 시작합니다. 종류는 매우 사용자 정의할 수 있지만 이 문서에서는 대부분 기본값을 사용하고 워커 노드 구성만 수정하겠습니다.

YAML이란 무엇인가요?

YAML 는 쿠버네티스 에코시스템 전반의 구성 파일에서 일반적으로 사용되는 마크업 언어입니다.

YAML을 처음 접하신다면 의도적으로 최소한의 구문을 사용하며 기본 구조는 맵입니다. YAML은 중첩을 나타내기 위해 들여쓰기에 의존합니다. Python에서와 마찬가지로 이 들여쓰기의 형식은 매우 중요합니다. 편집기에서 탭이 아닌 공백을 사용하는지 확인하세요..

첫 번째 YAML 구성 파일: 맞춤형 클러스터

라는 이름의 다음 구성 파일을 만듭니다. kind-config.yaml를 생성할 때 사용할 것입니다:

다음 명령어로 클러스터를 생성합니다:

클러스터가 생성된 후 다음 명령을 실행합니다: kubectl 클러스터-정보 --컨텍스트 종류-카우치베이스. 다음과 유사한 출력이 표시되어 실행 중인 Kubernetes 클러스터가 있음을 알려줍니다:

"무엇 kubectl?" 울부짖는 소리가 들립니다. 이 명령은 Kubernetes 클러스터와 상호 작용하는 데 사용되는 명령입니다. 이것은 Couchbase나 특정 종류에 국한된 것이 아닙니다. "컨텍스트"를 변경하여 다른 클러스터와 상호 작용합니다. 쿠버네티스 자체에서 kubectl에 대해 자세히 알아보기.

이 용감한 신세계에 대해 더 자세히 알아보기 위해 질문을 하나 제안해 보겠습니다: 우리 클러스터가 카우치베이스 현물을 사용하는 이유는 무엇입니까? 종류-카우치베이스 kubectl을 사용하시나요? 그 이유는 다음과 같다. 종류-카우치베이스 는 클러스터와 상호 작용하는 데 사용하는 컨텍스트의 이름입니다.

다음 명령을 실행하면 구성한 모든 컨텍스트가 표시됩니다:

다음이 있어야 합니다. * 옆의 현재 열에 종류-카우치베이스 항목.

쿠버네티스 클러스터에 카우치베이스 자율 운영자 설치하기

이제 실행 중인 Kubernetes 클러스터가 생겼습니다, CAO를 설치할 시간입니다..

설치 전제 조건

필수 요구 사항을 실행하여 CAO를 다운로드하고 터미널에서 다운로드 디렉터리로 이동하여 압축을 풀고 폴더로 이동합니다.

사용자 정의 리소스 정의 설치

문서의 다음 단계는 Couchbase 사용자 정의 리소스 정의(CRD)를 설치하는 것입니다. 이것이 무엇인지 자세히 살펴보겠습니다.

계속해서 crd 파일을 살펴보세요. crd.yaml 를 압축 해제합니다. 수천 줄의 정의된 Couchbase 리소스를 볼 수 있습니다. 이 리소스를 설치해야 하는 이유는 쿠버네티스 애플리케이션 전반에서 관리할 수 있도록 쿠버네티스 API를 확장하고 특정 Couchbase 리소스를 정의하기 위해서입니다.

예를 들어, 이러한 리소스를 사용하여 CAO 배포 구성의 유효성을 검사할 수 있습니다. 다음은 사용자 정의 리소스에 대한 Kubernetes의 문서입니다..

운영자와 함께 제공되는 CRD를 설치하려면 다음 명령을 사용하세요:

운영자 설치

운영자는 두 가지 구성 요소로 이루어져 있습니다. 여기에서는 설치 대상과 설치 이유를 정확히 알 수 있도록 조금 더 간략하게 설명해드리고자 합니다.

동적 입장 컨트롤러(DAC)

사용자 정의 리소스를 사용하기 때문에 Kubernetes는 기본 리소스 유형과 달리 어떤 값이 허용되는지 알 수 없습니다.

DAC(동적 어드미션 컨트롤러)는 리소스의 유효성을 확인하고 필요한 기본값을 적용한 후 커밋하기 전에 etcd (클러스터 데이터를 위한 키-값 저장소.)

Couchbase 문서 팀은 다음과 같이 훌륭하게 설명해 주었습니다. 동적 입학 컨트롤러를 사용하면 얻을 수 있는 많은 이점을 여기에서 확인하세요..

다음은 DAC가 요청을 조사하는 방법에 대한 그래픽이 포함된 카우치베이스 문서에서 발췌한 내용입니다:

1. 클라이언트가 쿠버네티스 API에 연결하여 리소스 생성 요청을 전송합니다. 리소스 사양은 JSON으로 인코딩됩니다.
2. API는 JSON을 동적 입학 컨트롤러의 변경 엔드포인트로 전달합니다. 뮤팅 웹훅은 리소스 변경(예: 기본값 적용 등)을 담당합니다. 선택적으로 생성 요청을 수락하거나 거부하도록 선택할 수 있습니다.
3. API는 JSON을 동적 입학 컨트롤러의 유효성 검사 엔드포인트로 전달합니다. 유효성 검사 웹후크는 사용자 지정 리소스 정의에서 제공하는 JSON 스키마 유효성 검사에서 제공하는 것 이상의 사양 제약 조건을 유효성 검사할 책임이 있습니다. 선택적으로 생성 요청을 수락하거나 거부하도록 선택할 수 있습니다.
4. 모든 승인 확인이 통과되면 리소스는 데이터베이스에 유지됩니다(etcd).
5. API는 생성 요청이 수락되었음을 클라이언트에 응답합니다.

2단계와 3단계의 승인 검사에서 리소스가 허용되지 않는다고 응답하면 API는 5단계로 바로 이동하여 DAC가 반환한 모든 오류를 반환합니다.

다음 명령을 사용하여 동적 입학 컨트롤러를 설치합니다:

운영자

제가 직접 더 잘 표현할 수 없으니 Couchbase 문서를 다시 인용하겠습니다:

카우치베이스 클러스터의 수명 동안 오퍼레이터는 쿠버네티스 리소스의 상태를 지속적으로 카우치베이스클러스터 리소스에서 요청된 내용과 현실이 일치하도록 필요에 따라 조정합니다.

좀 더 자세히 살펴봅시다. 오퍼레이터는 사용자가 원하는 클러스터 상태를 선언하면 나머지는 오퍼레이터가 알아서 처리합니다. 클러스터의 상태를 변경해야 하는 경우(예: Couchbase 노드 추가, 사용 가능한 서비스 확장 등), 이를 선언하기만 하면 Operator가 새로운 상태를 구현합니다.

이러한 작업은 움직이는 모든 부품을 관리하기 위해 정밀성과 전문성이 요구되는 복잡한 작업입니다. You could 는 이러한 모든 작업을 수동으로 수행하지만, 운영자는 이 모든 작업을 자동화하고 Couchbase의 모범 사례를 염두에 두고 모든 작업을 수행합니다.

이 섹션을 마무리하면서, 이제 구성 요소를 무턱대고 설치하는 것이 아니라 CAO 배포를 구성하는 요소에 대해 조금 더 알게 되었습니다. 이는 몇 달 후에 CAO를 사용하여 멀티클라우드 Couchbase 클러스터를 실행할 때 필요한 지식입니다.

이제 무엇을 설치하는지 알았으니 다음 명령을 사용하여 운영자를 설치합니다:

DAC 확인

배포를 가져와서 Couchbase 자율 운영자의 상태를 확인할 수 있으며, 또한 구체적으로 카우치베이스클러스터 실행하여 배포합니다:

위와 비슷한 출력이 표시될 것입니다. 이제 실제로 Couchbase 클러스터(!)를 배포하는 단계로 넘어갈 수 있습니다.

대체 배포 방법

헬름 는 쿠버네티스용 패키지 관리자로, brew/apt 등과 다소 유사합니다.

Helm의 공동 창립자 중 한 명인 Matt Faina에 따르면 패키지 관리자는 다음과 같습니다:

"애플리케이션과 플랫폼에 대한 지식이 있는 사람이 애플리케이션을 패키지화하여 플랫폼이나 플랫폼에서 실행해야 하는 방식에 대한 광범위한 지식이 없는 다른 사람도 사용할 수 있도록 하는 도구"입니다.

헬름의 패키지는 다음과 같이 불린다. 차트. 쿠버네티스 기반 애플리케이션을 위한 배포 가능한 유닛입니다.

다음을 수행할 수 있습니다. 이 문서에 따라 헬름을 사용하여 CouchBase 자율 운영자를 쉽게 설정하고 CouchBase 클러스터를 배포할 수 있다.. 기본적으로 공식 Couchbase Helm 차트는 Couchbase 자율 운영자, 동적 어드미션 컨트롤러 및 완전히 구성된 Couchbase 클러스터를 배포합니다.

CAO에 Couchbase 클러스터 배포하기

다음 문서를 사용하겠습니다. 카우치베이스 배포를 만드는 방법 를 이 섹션의 진실의 원천으로 삼고 있지만, 차근차근 설명해 드리겠습니다.

카우치베이스 클러스터는 위에서 설명한 것처럼 오퍼레이터에 대해 정의되며, 이 정의는 현재 상태를 확인하는 데 사용됩니다. 카우치베이스클러스터 리소스입니다.

이 YAML 정의는 문서에서 가져온 것이지만, 여러분의 종류의 노드에서 좀 더 쉽게 사용할 수 있도록 몇 가지 변경을 했습니다. (노트북에 컨테이너가 너무 많으면 나빠집니다.) 변경 사항에는 데이터 서비스만 배포하되 고가용성과 성능을 제공하기 위해 노드 수를 3개로 유지하고 이름을 데이터 서비스 를 사용하여 코드 부패를 방지합니다.

라는 파일을 만듭니다. data_cluster.yaml 를 클릭하고 이 텍스트를 복사합니다:

다음 명령을 사용하여 구성을 배포합니다:

배포를 생성한 직후(위) 다음을 실행하여 운영자가 파드를 생성하고 사양에 따라 클러스터를 프로비저닝하는 것을 볼 수 있습니다. 그러면 운영자가 파드를 생성하는 것을 볼 수 있습니다:

포드 cb-example-0000 가 준비됨으로 표시되지 않았습니다(0/1) 및 상태 컨테이너 생성. 배포가 완료되면 반드시 확인해야 합니다.

계속 실행 kubectl 파드 가져오기 세 개가 표시될 때까지 cb-example-**** 상태의 파드를 실행 중 그리고 1/1 아래 준비 열입니다. 이 상태가 만족될 때까지 진행하지 마세요. 이 상태는 회원님의 data_cluster.yaml.

다음 명령을 사용하여 클러스터에서 데이터 서비스를 사용할 수 있는지 추가로 확인합니다:

위의 예와 비슷한 결과가 표시되어야 하지만 클러스터 배포에 따라 결과가 달라질 수 있습니다.

포트 포워딩 및 Couchbase GUI 액세스

PoC를 위해 다른 Couchbase 서비스에 액세스하려면 Couchbase GUI에 액세스해야 합니다.

이 가이드에서는 포트 포워딩을 설정하는 방법을 설명합니다.. 포트 포워딩은 개념 증명에서 Couchbase GUI에 액세스해야 하므로 유용합니다. 또한 다음을 사용해야 할 때 유용할 수 있습니다. cbc-pillowfight 로드 테스트 또는 cbimport 를 사용하여 클러스터에 샘플 문서를 가져올 수 있습니다.

이전 명령의 출력을 사용하면 데이터 서비스를 실행 중인 파드가 제공됩니다. 그런 다음 이 포드 이름을 사용하여 Couchbase GUI의 포트를 전달할 수 있습니다.

다음 명령을 실행합니다:

이 명령은 위에 나열된 것과 유사한 출력을 제공합니다. 명령을 실행한 후 다음을 통해 Couchbase GUI에 액세스할 수 있습니다. http:localhost:8091.

카우치베이스 배포 수정하기

PoC에 반드시 포함해야 할 한 가지는 다음과 같은 기능입니다. YAML 파일을 통해 Couchbase 클러스터를 수정합니다.. 이를 통해 클러스터를 유연하게 구성하고 확장할 수 있습니다.

다음을 사용하지 않는지 확인하세요. kubectl 생성 를 더 이상 사용하지 않습니다. 이전 정의를 다음을 사용하여 새 정의로 바꿉니다. kubectl 적용 또는 kubectl replace.

실행할 한 가지 테스트는 현재 클러스터에 다른 Couchbase 서비스를 추가하는 것입니다. 저는 노트북을 사용하고 있기 때문에 추가 서비스인 이벤트만 추가하겠습니다.

변경을 완료하면 운영자에게 구성을 배포할 수 있습니다: kubectl apply -f. 를 사용하여 새 서비스가 추가되었는지 확인합니다. 포드 가져오기 목록에 추가합니다. 마지막으로 GUI용 포트를 다시 전달하고 새 서비스가 클러스터에 포함되었는지 확인하는 단계를 따르세요.

이 시점에서 중요한 점은 운영자에게 기능이 점진적으로 추가된다는 것입니다. 구성 는 어느 정도 모범 사례입니다. 배포에 기능과 구성을 반복적으로 추가하면 각 단계에서 클러스터를 테스트하여 구성이 유효한지 확인할 수 있습니다.

결론

결론적으로, 이 글에서는 특히 개념 증명(PoC) 프로젝트의 경우 Couchbase 자율 운영자의 구성과 이를 오케스트레이션하여 Couchbase 클러스터를 프로비저닝하는 방법에 대해 자세히 알아보았습니다.

CAO는 Couchbase 클러스터의 상태를 지속적으로 확인하여 정의된 사양을 충족하는지 확인합니다. 또한, 모든 Kubernetes 환경에 CAO 사양을 배포할 수 있습니다. 이는 환상적인 수준의 자유를 제공하며 퍼블릭 클라우드 벤더 종속성을 제거합니다. 운영자를 통해 사양에 따라 클러스터 상태를 유지할 수 있으며, 클러스터 업그레이드와 같은 기능을 수행해야 하는 경우 YAML 파일을 통해 쉽게 수행할 수 있습니다.

앞으로 더 많은 블로그 포스팅을 통해 Couchbase 자율 운영자의 더 많은 사용 사례를 배포하는 방법을 설명할 예정입니다. 그때까지 기다리시기 바랍니다, CAO 설명서를 자세히 살펴보고 탐색을 시작하세요.. 여러분이 만든 결과물을 빨리 듣고 싶습니다.