코맥 호건은 VMware의 스토리지 및 가용성 사업부(SABU) CTO실의 이사 겸 최고 기술 책임자입니다.
바이오: 저는 2005년 4월에 VMware에 입사했으며, 이전에는 VMware의 엔지니어링, 기술 마케팅, 기술 지원 조직에서 근무했습니다. 스토리지 관련 백서를 다수 집필했으며 스토리지 모범 사례와 vSphere 스토리지 기능에 대한 프레젠테이션을 여러 차례 진행했습니다. 또한 "Essential Virtual SAN" 및 "vSAN 6.7 심층 분석" 책의 공동 저자이기도 합니다.
카우치베이스 자율 운영자에 대한 첫 번째 살펴보기
몇 주 전의 일입니다, 아크라고 알려진 헵티오 벨레로를 살펴봤습니다.. Velero는 클라우드 네이티브 애플리케이션을 위한 백업 및 복원 기능을 제공합니다. 이 연구를 하는 동안 저는 백업/복원을 위해 선택한 애플리케이션으로 Couchbase 데이터베이스를 사용했습니다. 이 블로그 게시물과 관련하여 Couchbase 팀과 이야기를 나눈 후, 그들은 제가 애플리케이션에 사용하던 StatefulSet 방식이 아닌 새로운 Couchbase Autonomous Operator를 사용해 볼 것을 강력히 추천했습니다. Couchbase 이야기 스테이트풀셋에 비해 오퍼레이터 접근 방식의 장점은 여기에서 확인할 수 있습니다..
이제 Couchbase는 운영자와 함께 Couchbase를 배포하는 방법에 대한 단계를 제공하지만 기본 K8s 네임스페이스에 생성합니다. 제 테스트에서는 Couchbase를 자체 네임스페이스에 배치하려고 합니다. 여기에 제공된 단계는 자체 Kubernetes 네임스페이스에서 vSphere 및 vSAN 인프라에서 실행되는 새로운 Couchbase Operator를 시작하기 위해 제공됩니다. 또한 베개싸움이라는 번들 로드 생성 도구의 몇 가지 문제에 대해서도 설명합니다.
카우치베이스는 다음에 대한 규범적인 지침을 제공합니다. 여기에서 운영자와 함께 시작하는 방법. 여기에는 필요한 모든 구성 파일이 포함되어 있습니다. 운영자에 대한 몇 가지 사항:
- 로드되면, 오퍼레이터 도커 이미지는 operator.yaml 파일을 생성한다. 이 파일은 배포 구조를 사용하므로 실행 중인 파드가 죽으면 다시 시작할 수 있습니다.
- CouchbaseCluster 사용자 정의 리소스 정의(CRD)를 생성합니다.
- 카우치베이스클러스터 이벤트를 수신하기 시작합니다.
Couchbase를 자체 네임스페이스에서 실행할 수 있도록 몇 가지 수정 작업을 수행했습니다:
- 우선 (당연히) couchbase라는 새로운 네임스페이스를 만들었습니다.
- 클러스터 역할이 생성되었을 때 새 카우치베이스 네임스페이스에 서비스 계정을 만든 다음 클러스터 역할 바인딩을 사용하여 해당 서비스 계정에 클러스터 역할을 할당했습니다.
- 나는 operator.yaml 파일을 포함하도록 메타데이터.네임스페이스=카우치베이스 설정을 변경하여 카우치베이스 네임스페이스에 적용하도록 합니다.
카우치베이스 운영자 파드의 로그를 모니터링하면 다음과 같은 시작 메시지를 관찰할 수 있습니다:
|
1 2 3 4 5 6 7 8 9 10 |
$ kubectl 로그 카우치베이스-연산자-6fcfbd8599-zqsh2 -n 카우치베이스 시간="2019-03-20T09:27:41Z" 레벨=정보 msg="카우치베이스-운영자 v1.1.0 (릴리스)" 모듈=메인 시간="2019-03-20T09:27:41Z" 레벨=정보 msg="리소스 잠금 얻기" 모듈=메인 시간="2019-03-20T09:27:41Z" 레벨=정보 msg="이벤트 레코더 시작" 모듈=메인 시간="2019-03-20T09:27:41Z" 레벨=정보 msg="카우치베이스 운영자 리더 선출 시도" 모듈=메인 시간="2019-03-20T09:27:41Z" 레벨=정보 msg="Event(v1.ObjectReference{Kind:\"Endpoints\", Namespace:\"couchbase\", Name:\"couchbase-operator\", UID:\"68fece18-4af2-11e9-be9b-005056a24d92\", APIVersion:\"v1\", ResourceVersion:\"1596774\", FieldPath:\"\"}): type: 'Normal' reason: 'LeaderElection' couchbase-operator-6fcfbd8599-zqsh2가 리더가 됨" 모듈=이벤트_기록기 시간="2019-03-20T09:27:41Z" 레벨=정보 msg="내가 리더입니다, 운영자 시작 시도" 모듈=메인 시간="2019-03-20T09:27:41Z" 레벨=정보 msg="카우치베이스 운영자 컨트롤러 만들기" 모듈=메인 시간="2019-03-20T09:27:46Z" 레벨=정보 msg="CRD 초기화, 이벤트 수신 중..." 모듈=컨트롤러 시간="2019-03-20T09:27:46Z" 레벨=정보 msg="카우치베이스 클러스터 컨트롤러 시작" |
이제 저는 새로운 cbopctl CLI 도구. 또한 기본 클러스터 구성 파일을 몇 가지 변경해야 했습니다(카우치베이스-클러스터-sc.yaml).
- 저는 이것을 카우치베이스 네임스페이스에 배치하고 메타데이터.네임스페이스 항목
- 설정했습니다. spec.disableBucketManagement 를 true로 설정하면 UI/CLI를 통해 버킷을 변경할 수 있습니다(그렇지 않으면 YAML 파일을 편집하여 모든 변경을 수행해야 합니다).
- 기본 및 데이터 마운트를 위해 퍼시스턴트 볼륨을 추가했습니다(이를 위해 볼륨클레임템플릿에 사용할 StorageClass를 새로 만들어야 했습니다 - 아래 참조).
다음은 변경 사항이 강조 표시된 전체 CouchbaseCluster YAML 파일입니다.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 |
apiVersion: 카우치베이스.com/v1 종류: 카우치베이스클러스터 메타데이터: 이름: cb-예제 네임스페이스: 카우치베이스 사양: 보안 컨텍스트: fsGroup: 1000 baseImage: 카우치베이스/서버 버전: 엔터프라이즈-5.5.2 authSecret: cb-예제-auth 노출 관리자 콘솔: true 비활성화 버킷 관리: true 관리자 콘솔 서비스: - 데이터 클러스터: 데이터서비스메모리쿼터: 256 인덱스서비스메모리쿼터: 256 검색서비스메모리쿼터: 256 이벤트 서비스 메모리 할당량: 256 분석서비스메모리쿼터: 1024 인덱스 스토리지 설정: memory_optimized 자동 페일오버 타임아웃: 120 자동 장애 조치 최대 횟수: 3 자동 페일오버 온 데이터 디스크 문제: true 자동 페일오버 온 데이터 디스크 이슈 시간 기간: 120 자동 페일오버 서버 그룹: false 버킷: - 이름: 기본값 유형: 카우치베이스 메모리 쿼터: 128 복제본: 1 ioPriority: 높은 퇴거 정책: 전체 퇴거 충돌 해결: seqno 활성화Flush: true enableIndexReplica: false 서버: - 크기: 3 이름: 모든 서비스 서비스: - 색인 - 쿼리 - 검색 - 이벤트 - 분석 - <강한>데이터 pod: 볼륨 마운트: 기본값: 카우치베이스 데이터: 카우치베이스 볼륨클레임템플릿: - 메타데이터: 이름: 카우치베이스 사양: 저장소 클래스 이름: "couchbasec" 리소스: 요청: 스토리지: 1Gi </강한> |
인증 및 사용자 요구 사항은 모두 Couchbase 사이트에 문서화되어 있으므로 생략하겠습니다. 그러나 애플리케이션이 배포되면 Couchbase 운영자 포드 로그에서 다음을 볼 수 있습니다:
|
1 2 3 4 5 6 7 8 9 10 |
$ kubectl 로그 카우치베이스-연산자-6fcfbd8599-zqsh2 -n 카우치베이스 . . 시간="2019-03-20T09:48:34Z" 레벨=정보 msg="새 클러스터 보기" 클러스터-이름=cb-예제 모듈=클러스터 시간="2019-03-20T09:48:34Z" 레벨=정보 msg="청소부 프로세스 시작" 클러스터-이름=cb-예제 모듈=클러스터 시간="2019-03-20T09:48:34Z" 레벨=정보 msg="클러스터와 운영자 통신을 위한 클라이언트 설정" 클러스터-이름=cb-예제 모듈=클러스터 시간="2019-03-20T09:48:34Z" 레벨=정보 msg="클러스터가 존재하지 않으므로 운영자가 클러스터를 만들려고 시도 중입니다." 클러스터-이름=cb-예제 모듈=클러스터 시간="2019-03-20T09:48:34Z" 레벨=정보 msg="데이터 노드를 위한 헤드리스 서비스 만들기" 클러스터-이름=cb-예제 모듈=클러스터 시간="2019-03-20T09:48:34Z" 레벨=정보 msg="데이터 노드용 NodePort UI 서비스(cb-example-ui) 생성하기" 클러스터-이름=cb-예제 모듈=클러스터 시간="2019-03-20T09:48:34Z" 레벨=정보 msg="카우치베이스 엔터프라이즈-5.5.2를 실행하는 포드(cb-example-0000) 생성하기" 클러스터-이름=cb-예제 모듈=클러스터 |
그리고 모든 것이 성공적으로 작동하면 초기화할 때 파드, 퍼시스턴트 볼륨 및 서비스를 쿼리할 수 있습니다.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
$ kubectl get po -n 카우치베이스 이름 READY 상태 다시 시작 AGE cb-예제-0000 1/1 실행 중 0 7m8초 cb-예제-0001 1/1 실행 중 0 6m7초 cb-예제-0002 1/1 실행 중 0 5m14초 카우치베이스-연산자-6fcfbd8599-zqsh2 1/1 실행 중 0 28m $ kubectl get pv -n 카우치베이스 이름 용량 액세스 모드 RECLAIM 정책 상태 클레임 스토리지 클래스 이유 AGE pvc-100e3c17-40e3-11e9-be9b-005056a24d92 10Gi RWO 삭제 Bound 벨레로/미니오-pv-클레임-1 미니오-sc 12d pvc-53c6962f-4af5-11e9-be9b-005056a24d92 1Gi RWO 삭제 Bound 카우치베이스/pvc-카우치베이스-cb-예제-0000-00-기본값 카우치베이스 7m51초 pvc-5b30f298-4af5-11e9-be9b-005056a24d92 1Gi RWO 삭제 Bound 카우치베이스/pvc-카우치베이스-cb-예제-0000-01-데이터 카우치베이스 7m44초 pvc-795bcf7b-4af5-11e9-be9b-005056a24d92 1Gi RWO 삭제 Bound 카우치베이스/pvc-카우치베이스-cb-예제-0001-00-기본값 카우치베이스 6m51초 pvc-7edc6a4d-4af5-11e9-be9b-005056a24d92 1Gi RWO 삭제 Bound 카우치베이스/pvc-카우치베이스-cb-예제-0001-01-데이터 카우치베이스 6m43초 pvc-97e9f6a9-4af5-11e9-be9b-005056a24d92 1Gi RWO 삭제 Bound 카우치베이스/pvc-카우치베이스-cb-예제-0002-00-데이터 카우치베이스 6m2s pvc-9bcc3d4d-4af5-11e9-be9b-005056a24d92 1Gi RWO 삭제 Bound 카우치베이스/pvc-카우치베이스-cb-예제-0002-01-기본값 카우치베이스 5m50s $ kubectl get svc -n 카우치베이스 이름 유형 클러스터-IP 외부-IP PORT(S) AGE cb-예제 ClusterIP 없음 8091/TCP,18091/TCP 8m55초 |
요약하면 다음과 같습니다:
- 문서화된 단계에 따라 카우치베이스 ClusterRole을 설정하세요.
- 카우치베이스 네임스페이스 만들기 - -. kubectl NS 카우치베이스 생성
- 카우치베이스 네임스페이스에서 카우치베이스 운영자 서비스 계정을 만듭니다. kubectl 서비스 계정 생성 -네임스페이스 카우치베이스 운영자 -네임스페이스 카우치베이스
- 오퍼레이터 생성(카우치베이스 네임스페이스에 맞게 수정) - kubectl create -f operator.yaml
- 필요한 비밀 생성(카우치베이스 네임스팩에 맞게 수정됨) - - kubectl create -f secret.yaml
- cbopctl을 사용하여 카우치베이스 클러스터를 생성합니다. cbopctl create -f couchbase-cluster-sc.yaml
마지막 출력인 서비스에는 http와 https 모두에 대한 Couchbase UI의 포트 매핑이 있습니다. 해당 포트로 K8 슬레이브 노드에 연결하면 구성에 제공된 관리자/암호 자격 증명을 사용하여 Couchbase 배포에 액세스할 수 있어야 합니다.
처음에는 버킷이 생성되지 않습니다. 클러스터 구성에 버킷이 하나 정의되어 있지만 고급 설정으로 재정의했습니다. 임시 버킷을 몇 개 만들어서 이 문제를 빠르게 해결할 수 있습니다. 두 개를 추가하겠습니다. 첫 번째는 기본값 그리고 두 번째는 cormac. 현재 두 버킷 모두에 항목이 없습니다.
카우치베이스는 또한 다음과 같은 유틸리티를 번들로 제공합니다. 베개 싸움 버킷을 채우는 데 매우 유용한 방법입니다. 어떤 이유에서인지 번들로 제공되는 "sequioatools" 버전의 베개 싸움에 몇 가지 문제가 있었습니다. "couchbaseutils" 버전으로 되돌리고 나니 모든 것이 정상으로 돌아왔습니다. 이 작업을 수행하려면 적절한 사용자 자격 증명을 설정해야 하지만 다시 한 번 이 모든 것이 기본 Couchbase 운영자 사이트에 문서화되어 있습니다. 다음은 이 작업을 수행하기 위한 샘플 YAML 파일입니다. 기본값 버킷:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
apiVersion: 배치/v1 종류: Job 메타데이터: 이름: 베개 싸움 네임스페이스: 카우치베이스 사양: 템플릿: 메타데이터: 이름: 베개 싸움 사양: 컨테이너: - 이름: 베개 싸움 이미지: 카우치베이스/베개 싸움:v2.9.3 명령: ["cbc-pillowfight", "-U", "couchbase://cb-example-0000.cb-example.couchbase.svc.cluster.local/default?select_bucket=true", "-I", "10000", "-B", "1000", "-c", "10", "-t", "1", "-P", "비밀번호"] restartPolicy: 절대로 |
유일한 차이점은 cormac 버킷은 명령 구문이 약간 다릅니다:
|
1 2 3 4 5 6 7 8 9 |
$ kubectl get po -n 카우치베이스 이름 READY 상태 다시 시작 AGE cb-예제-0000 1/1 실행 중 0 20m cb-예제-0001 1/1 실행 중 0 19m cb-예제-0002 1/1 실행 중 0 18m 카우치베이스-연산자-6fcfbd8599-ggv98 1/1 실행 중 0 24m create-사용자-dk6xg 0/1 완료 0 89s 베개 싸움-fqvgp 0/1 완료 0 70s 베개 싸움 코맥-dmqnf 0/1 완료 0 7s |
더 중요한 것은 Couchbase UI를 살펴보면 각 버킷에 1,000개의 항목이 있다는 것을 알 수 있습니다:
여기까지입니다. 이제 Couchbase 운영자가 가동되고 실행됩니다. 마지막으로, 이는 VMware PKS, vSphere 및 vSAN 인프라 위에 K8s 클러스터에서 프로비저닝되었습니다. 참고로 베개 싸움 문제는 여기에서 보고되었습니다(문제 해결).
