저희는 최근 Couchbase CAO(자율 운영자) 2.0 베타 버전. 이번 릴리즈는 Couchbase Autonomous Operator의 중요한 업데이트입니다. Couchbase Autonomous Operator 2.0은 보안, 모니터링, 고가용성, 관리 용이성 등 완전한 자율 기능을 갖춘 몇 가지 새로운 엔터프라이즈급 기능을 도입했습니다. 이 블로그에서는 이러한 기능 중 하나가 어떻게 작동하는지 자세히 살펴보겠습니다.
프로메테우스 메트릭 컬렉션
최신 운영자는 Couchbase 서버 메트릭을 수집하고 노출하기 위해 Couchbase Prometheus Exporter와의 기본 통합을 제공합니다. 이렇게 내보낸 메트릭은 Prometheus에서 스크랩한 다음 Grafana와 같은 도구에서 시각화할 수 있습니다.
Couchbase Prometheus Exporter를 사용하여 클러스터를 배포하는 단계를 설명하고 Grafana를 통해 몇 가지 메트릭을 살펴보겠습니다. 이것은 간단한 단일 클러스터 테스트 배포이며 프로덕션 수준 배포에 필요한 다른 모든 단계를 자세히 설명하지는 않습니다.
우리는 다음 사항을 면밀히 따를 것입니다. 카우치베이스 자율 운영자 2.0 베타 튜토리얼 에 설치하는 것이 좋습니다.
전제 조건
이미 Amazon 가상 사설 클라우드 (VPC)를 사용해야 합니다. 다음 설명서를 따르세요. Amazon EKS 시작하기 를 클릭하고 다음을 설치합니다:
배포 아키텍처
배포 아키텍처에 대한 간략한 개요입니다.
위의 다이어그램을 참조하세요:
1: Amazon EKS에서 Kubernetes 클러스터를 생성합니다. 이 클러스터는 Kubernetes 리소스 및 서비스를 관리합니다.
2: 카우치베이스 사용자 정의 리소스 정의를 설치하여 카우치베이스 리소스를 추가합니다.
3: 카우치베이스 오토노머스 오퍼레이터를 설치한다. 이렇게 하면 기본 네임스페이스에 오퍼레이터와 어드미션 컨트롤러라는 두 개의 파드가 생성됩니다.
4: 기본 네임스페이스에 3노드 Couchbase 클러스터를 배포합니다. 이렇게 하면 3개의 포드가 생성되며, 각 포드에는 Couchbase 6.5.0 컨테이너와 Couchbase Metrics Exporter 컨테이너가 있습니다.
5: Prometheus가 스크랩하는 엔드포인트를 정의하는 서비스 리소스를 모니터링하도록 지시하는 ServiceMonitor를 생성합니다.
6: 서비스 생성은 앞서 기본 네임스페이스의 ServiceMonitor에서 설명한 포트를 정의합니다.
7: Prometheus 사용자 정의 리소스 정의를 설치하여 Prometheus 리소스를 추가합니다.
8: 모니터링 네임스페이스에 Prometheus/Grafana 파드를 생성합니다.
클러스터 생성 및 kubectl 구성하기
|
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 |
$ eksctl create cluster \ --name prasadCAO2 \ --region us-east-1 \ --zones us-east-1a,us-east-1b,us-east-1c \ --nodegroup-name standard-workers \ --node-type t3.medium \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --ssh-access \ --ssh-public-key ~/couchbase-prasad.pub \ --managed [ℹ] eksctl version 0.16.0 [ℹ] using region us-east-1 [ℹ] subnets for us-east-1a - public:192.168.0.0/19 private:192.168.96.0/19 [ℹ] subnets for us-east-1b - public:192.168.32.0/19 private:192.168.128.0/19 [ℹ] subnets for us-east-1c - public:192.168.64.0/19 private:192.168.160.0/19 [ℹ] using SSH public key "/Users/krishna.doddi/couchbase-prasad.pub" as "eksctl-prasadCAO2-nodegroup-standard-workers-42:57:cd:cb:28:33:4a:d9:59:4e:73:3b:c0:e8:a3:fe" [ℹ] using Kubernetes version 1.14 [ℹ] creating EKS cluster "prasadCAO2" in "us-east-1" region with managed nodes [ℹ] will create 2 separate CloudFormation stacks for cluster itself and the initial managed nodegroup [ℹ] if you encounter any issues, check CloudFormation console or try 'eksctl utils describe-stacks --region=us-east-1 --cluster=prasadCAO2' [ℹ] CloudWatch logging will not be enabled for cluster "prasadCAO2" in "us-east-1" [ℹ] you can enable it with 'eksctl utils update-cluster-logging --region=us-east-1 --cluster=prasadCAO2' [ℹ] Kubernetes API endpoint access will use default of {publicAccess=true, privateAccess=false} for cluster "prasadCAO2" in "us-east-1" [ℹ] 2 sequential tasks: { create cluster control plane "prasadCAO2", create managed nodegroup "standard-workers" } [ℹ] building cluster stack "eksctl-prasadCAO2-cluster" [ℹ] deploying stack "eksctl-prasadCAO2-cluster" [ℹ] building managed nodegroup stack "eksctl-prasadCAO2-nodegroup-standard-workers" [ℹ] deploying stack "eksctl-prasadCAO2-nodegroup-standard-workers" [✔] all EKS cluster resources for "prasadCAO2" have been created [✔] saved kubeconfig as "/Users/krishna.doddi/.kube/config" [ℹ] nodegroup "standard-workers" has 3 node(s) [ℹ] node "ip-192-168-13-207.ec2.internal" is ready [ℹ] node "ip-192-168-62-181.ec2.internal" is ready [ℹ] node "ip-192-168-93-184.ec2.internal" is ready [ℹ] waiting for at least 1 node(s) to become ready in "standard-workers" [ℹ] nodegroup "standard-workers" has 3 node(s) [ℹ] node "ip-192-168-13-207.ec2.internal" is ready [ℹ] node "ip-192-168-62-181.ec2.internal" is ready [ℹ] node "ip-192-168-93-184.ec2.internal" is ready [ℹ] kubectl command should work with "/Users/krishna.doddi/.kube/config", try 'kubectl get nodes' [✔] EKS cluster "prasadCAO2" in "us-east-1" region is ready |
|
1 2 3 4 5 6 7 8 9 10 11 12 |
$ kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.100.0.1 <none> 443/TCP 15m $ kubectl get nodes NAME STATUS ROLES AGE VERSION ip-192-168-13-207.ec2.internal Ready <none> 4d4h v1.14.9-eks-1f0ca9 ip-192-168-62-181.ec2.internal Ready <none> 4d4h v1.14.9-eks-1f0ca9 ip-192-168-93-184.ec2.internal Ready <none> 4d4h v1.14.9-eks-1f0ca9 |
kubectl 구성
이 명령은 다음에서 관련 Amazon 리소스 이름(ARN) 변수를 설정하므로 매우 중요합니다. ~/.kube/config. 선택적으로 다음을 추가할 수 있습니다. --지역 지역 이름 를 사용하여 기본값과 다른 리전에 클러스터를 지정할 수 있습니다. (기본 리전은 AWS CLI를 처음 설정할 때 다음을 통해 지정되었을 것입니다. AWS 구성명령)
|
1 2 3 |
$ aws eks update-kubeconfig --name prasadCAO2 Added new context arn:aws:eks:us-east-1:429712224361:cluster/prasadCAO2 to /Users/krishna.doddi/.kube/config |
사용자 지정 리소스 정의(CRD) 설치
참고: MacOS용 오퍼레이터를 다운로드하여 다음에서 패키지 이름을 변경했습니다. 카우치베이스-자율운영자-쿠버네티스_2.0.0-macos-x86_64 에 cao-2 를 클릭하고 이 디렉토리에 복사합니다.
운영자 설치의 첫 번째 단계는 Couchbase 리소스 유형을 설명하는 사용자 정의 리소스 정의(CRD)를 설치하는 것입니다.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
cao-2 $ kubectl create -f crd.yaml customresourcedefinition.apiextensions.k8s.io/couchbasebuckets.couchbase.com created customresourcedefinition.apiextensions.k8s.io/couchbaseephemeralbuckets.couchbase.com created customresourcedefinition.apiextensions.k8s.io/couchbasememcachedbuckets.couchbase.com created customresourcedefinition.apiextensions.k8s.io/couchbasereplications.couchbase.com created customresourcedefinition.apiextensions.k8s.io/couchbaseusers.couchbase.com created customresourcedefinition.apiextensions.k8s.io/couchbasegroups.couchbase.com created customresourcedefinition.apiextensions.k8s.io/couchbaserolebindings.couchbase.com created customresourcedefinition.apiextensions.k8s.io/couchbaseclusters.couchbase.com created customresourcedefinition.apiextensions.k8s.io/couchbasebackups.couchbase.com created customresourcedefinition.apiextensions.k8s.io/couchbasebackuprestores.couchbase.com created |
자율 운영자 2.0 설치하기
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
cao-2 $ bin/cbopcfg | kubectl create -f - serviceaccount/couchbase-operator-admission created clusterrole.rbac.authorization.k8s.io/couchbase-operator-admission created clusterrolebinding.rbac.authorization.k8s.io/couchbase-operator-admission created secret/couchbase-operator-admission created deployment.apps/couchbase-operator-admission created service/couchbase-operator-admission created mutatingwebhookconfiguration.admissionregistration.k8s.io/couchbase-operator-admission created validatingwebhookconfiguration.admissionregistration.k8s.io/couchbase-operator-admission created serviceaccount/couchbase-operator created role.rbac.authorization.k8s.io/couchbase-operator created rolebinding.rbac.authorization.k8s.io/couchbase-operator created deployment.apps/couchbase-operator created service/couchbase-operator created |
운영자의 상태 확인
|
1 2 3 4 5 |
cao-2 $ kubectl get deployments NAME READY UP-TO-DATE AVAILABLE AGE couchbase-operator 1/1 1 1 96s couchbase-operator-admission 1/1 1 1 97s |
운영자는 동적 어드미션 컨트롤러(couchbase-operator-admission) 및 운영자(couchbase-operator) 배포가 모두 완전히 준비되고 사용 가능할 때 CouchbaseCluster 리소스를 배포할 준비가 된 것입니다.
Couchbase 클러스터 구성 준비하기
3노드 Couchbase Server 6.5.0 클러스터를 Prometheus Couchbase Exporter와 함께 배포하겠습니다. 이를 위해 다음을 생성했습니다. my-cluster.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 61 62 63 64 65 66 67 68 69 70 71 72 73 74 |
apiVersion: v1 kind: Secret metadata: name: cb-example-auth type: Opaque data: username: QWRtaW5pc3RyYXRvcg== # Administrator password: cGFzc3dvcmQ= # password --- apiVersion: couchbase.com/v2 kind: CouchbaseCluster metadata: name: cb-example spec: image: couchbase/server:6.5.0 security: adminSecret: cb-example-auth paused: false antiAffinity: true softwareUpdateNotifications: true serverGroups: - us-east-1a - us-east-1b - us-east-1c securityContext: runAsUser: 1000 runAsNonRoot: true fsGroup: 1000 platform: aws cluster: clusterName: cb-example dataServiceMemoryQuota: 512Mi indexServiceMemoryQuota: 256Mi searchServiceMemoryQuota: 256Mi indexStorageSetting: memory_optimized autoFailoverTimeout: 120s autoFailoverMaxCount: 3 autoFailoverOnDataDiskIssues: true autoFailoverOnDataDiskIssuesTimePeriod: 120s autoFailoverServerGroup: false autoCompaction: databaseFragmentationThreshold: percent: 30 size: 1Gi viewFragmentationThreshold: percent: 30 size: 1Gi parallelCompaction: false timeWindow: start: 02:00 end: 06:00 abortCompactionOutsideWindow: true tombstonePurgeInterval: 72h servers: - size: 3 name: all_services services: - data - index - query - search buckets: managed: false selector: matchLabels: cluster: cb-example monitoring: prometheus: enabled: true image: couchbase/exporter:1.0.1 resources: requests: cpu: 100m memory: 100Mi |
참고:
- 최소한의 구성 매개변수만 사용했습니다. 최소한의 구성 매개변수만 사용했으니 카우치베이스 클러스터 리소스 문서 에서 전체 목록을 확인하세요.
- 비밀 섹션을 같은 파일에 포함시켜 작업을 단순화했습니다.
- 데이터, 쿼리, 색인 및 검색 서비스만 사용합니다.
- 운영자에게 맡기지 않고 내가 직접 버킷을 관리합니다.
- 클러스터 레이블을 메모해 두세요. cb-예시 나중에 Prometheus가 서비스를 검색하는 데 사용되기 때문입니다.
팁: buckets.managed가 false로 설정되어 있는지 확인합니다. 그렇지 않으면 클러스터가 실행되고 나서 버킷을 수동으로 생성하면 Kubernetes가 자동으로 버킷을 삭제합니다.
Couchbase 클러스터 배포
|
1 2 3 4 |
cao-2 $ kubectl create -f my-cluster.yaml secret/cb-example-auth created couchbasecluster.couchbase.com/cb-example created |
비밀과 클러스터가 모두 생성되었습니다. 그렇다고 해서 아직 실행 중이라는 의미는 아니므로 다음 단계에서 설명하는 대로 확인해야 합니다.
배포 확인
|
1 2 3 4 5 6 7 8 |
cao-2 $ kubectl get pods NAME READY STATUS RESTARTS AGE cb-example-0000 2/2 Running 0 9m5s cb-example-0001 2/2 Running 0 8m53s cb-example-0002 2/2 Running 0 8m42s couchbase-operator-5c4bd54bbf-fcj9m 1/1 Running 0 10m couchbase-operator-admission-6789cd5847-w9rfd 1/1 Running 0 10m |
모든 파드가 다음과 같은 상태인지 확인합니다. 준비 그리고 실행 중. 문제가 있는 경우 운영자로부터 로그를 받을 수 있습니다.
선택 사항입니다: 로그 가져오기
이전 단계에서 문제가 발생하면 아래와 같이 로그를 확인할 수 있습니다.
|
1 2 3 4 5 6 7 8 |
cao-2 $ kubectl logs couchbase-operator-5c4bd54bbf-fcj9m {"level":"info","ts":1586879846.061044,"logger":"main","msg":"couchbase-operator","version":"2.0.0","revision":"release"} ...... {"level":"info","ts":1586879986.2216492,"logger":"cluster","msg":"Pod added to cluster","cluster":"default/cb-example","name":"cb-example-0002"} {"level":"info","ts":1586879987.0798743,"logger":"couchbaseutil","msg":"Rebalancing","cluster":"default/cb-example","progress":0} {"level":"info","ts":1586879993.087347,"logger":"cluster","msg":"Rebalance completed successfully","cluster":"default/cb-example"} {"level":"info","ts":1586879993.124682,"logger":"cluster","msg":"Reconcile completed","cluster":"default/cb-example"} |
여기에서는 Couchbase 클러스터가 오류 없이 배포되었습니다.
선택 사항입니다: 카우치베이스 파드를 검토합니다.
Couchbase 포드를 설명하여 실행 중인 내용을 확인해 보겠습니다.
|
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 |
cao-2 $ kubectl describe pod cb-example-0000 Name: cb-example-0000 Namespace: default ... Labels: app=couchbase couchbase_cluster=cb-example ... {"containers":[{"name":"couchbase-server","image":"couchbase/server:6.5.0","ports":[{"name":"admin","containerPort":8091,"protocol":"TCP"} ... server.couchbase.com/version: 6.5.0 Status: Running ... Controlled By: CouchbaseCluster/cb-example Containers: couchbase-server: Container ID: docker://7b0e5df433582ad432114248fdce922fd92f63435b110265b823c013fea8c2ac Image: couchbase/server:6.5.0 ... State: Running ... metrics: Container ID: docker://b4406ec41d2119978971c8fa41fb8077ace782611298ba23d254a0d4383ab5ca Image: couchbase/exporter:1.0.0 Image ID: ... Port: 9091/TC ... State: Running |
위의 출력에서 각 Couchbase 파드가 2개의 컨테이너를 실행하고 있음을 알 수 있습니다. 첫 번째는 Couchbase Server 6.5.0을 실행하고 있고 다른 하나는 포트 9091을 사용하는 Couchbase Prometheus Exporter를 실행하고 있습니다.
Couchbase 관리 UI에 액세스
실제 프로덕션 환경에서는 일반적으로 DNS와 프록시 역할을 하는 LoadBalancer를 사용하여 배포하고 DNS SRV 레코드를 사용하는 SSL을 통해 Couchbase UI에 안전하게 액세스할 수 있습니다. 테스트 환경이므로 포트 8091에서 직접 Couchbase UI에 액세스하겠습니다. 이를 위해서는 포트 포워딩이라는 한 단계가 더 필요합니다.
포트 포워딩
|
1 2 3 4 |
cao-2 $ kubectl port-forward cb-example-0000 8091 & [1] 11375 cao-2 $ Forwarding from 127.0.0.1:8091 -> 8091 Forwarding from [::1]:8091 -> 8091 |
현재 3개의 포드를 배포했지만, 하나의 포드에서 포트 포워딩하여 Couchbase 관리자 UI에 액세스하는 것으로 충분합니다.
UI에 액세스
https://localhost:8091
버킷 만들기
샘플 버킷 추가 및 베개 버킷 생성
워크로드를 실행하여 몇 가지 메트릭 생성하기
우리는 다음을 사용할 것입니다. cbc-pillowfight 를 사용하여 워크로드를 생성해야 합니다. 다행히도 이것은 Operator와 함께 번들로 제공되므로 배포할 수 있습니다. 먼저 데이터를 로드하는 데 그치지 않고 버킷에서 작업을 수행할 수 있도록 YAML 파일을 약간 수정해 보겠습니다. 방금 만든 pillow 버킷을 사용하겠습니다.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
apiVersion: batch/v1 kind: Job metadata: name: pillowfight spec: template: metadata: name: pillowfight spec: containers: - name: pillowfight image: sequoiatools/pillowfight:v5.0.1 command: ["cbc-pillowfight", "-U", "couchbase://cb-example-0000.cb-example.default.svc/pillow?select_bucket=true", "-I", "10000", "-B", "1000", "-c", "10000", "-t", "1", "-u", "Administrator", "-P", "password"] restartPolicy: Never |
버킷을 기본값에서 베개로 변경하고 -c(루프 수) 옵션을 10에서 10,000으로 변경합니다.
그러면
|
1 2 |
cao-2 $ kubectl create -f pillowfight-data-loader.yaml job.batch/pillowfight created |
로컬에서 Prometheus 및 Grafana 테스트하기
이제 Prometheus Couchbase Exporter가 포함된 3노드 Couchbase 클러스터가 생겼습니다. 내보내기는 포트 9091로 Couchbase 메트릭을 스크랩하고 있습니다. 이제 데스크톱에서 Couchbase 웹 콘솔 UI에 액세스하기 위해 포트 8091을 포워딩한 것처럼 이 포트를 포워딩할 수 있습니다. 이렇게 포워딩된 포트를 사용하면 데스크톱의 Docker 컨테이너에서 Prometheus와 Grafana를 실행하고, 포워딩된 9091 포트를 사용하여 메트릭을 Prometheus로 가져와서 Grafana에서 시각화할 수 있습니다.
위의 접근 방식에는 다음과 같은 한계가 있습니다.. 먼저, 3개의 노드 모두에서 포트 9091을 포워딩해야 하며 해당 노드 이름은 하드코딩됩니다. 노드 이름을 하드코딩하는 것은 Kubernetes 환경에서 큰 문제입니다. 게다가, 일반적으로 DNS를 사용하여 배포하고 DNS SRV를 사용하여 클러스터에 연결하는 프로덕션 환경에서는 포트 포워딩을 하지 않을 것입니다. 마지막으로, 클라우드 네이티브 패러다임에 따라 Kubernetes 자체에서 Prometheus와 Grafana를 실행하는 것이 모범 사례입니다.
다음 단계
In 파트 2빠른 테스트를 위해 가능한 한 간단하게 유지하고 싶기 때문에 DNS를 제외하고는 그렇게 할 것입니다.
리소스:
- 쿠버네티스용 카우치베이스 자율 운영자 2.0 베타 다운로드
- 카우치베이스 자율 운영자 2.0 베타 시작하기
- 튜토리얼 - 자습서 EKS의 카우치베이스 자율 운영자
- 에 대한 의견을 공유하세요. 카우치베이스 포럼
공유해 주셔서 감사합니다. 클러스터 확장 시기를 결정하기 위해 모니터링해야 할 주요 메트릭은 무엇이며 K8에서 카우치베이스 클러스터의 자동 확장을 구성할 수 있는지 질문해도 될까요?
안부