소개
캘리포니아주 샌프란시스코 시내에서 중요한 고객을 만나러 가는데 사무실 로비에 도착했을 때 누구에게 전화해야 하는지에 대한 세부 정보가 담긴 이메일이 있다고 가정해 보겠습니다. 로비에 도착했지만 모바일 네트워크 수신이 완전히 다운되었습니다. 이메일 클라이언트를 열려고 하지만 애플리케이션을 시작할 때마다 네트워크 연결이 필요합니다. 연결이 되지 않으면 이메일을 읽을 수 없어 사용자 경험이 불편할 것입니다.
이러한 상황을 방지하기 위해 이제 애플리케이션은 다음과 같이 빌드됩니다. 오프라인 우선 패러다임. 이는 애플리케이션 기능이 간헐적인 네트워크 연결 부족에 영향을 받지 않는다는 것을 의미합니다. 또한 오프라인 우선은 일반적으로 엣지 디바이스 간 데이터를 백엔드 데이터베이스에 동기화하는 기능을 의미합니다.
많은 관계형 또는 비관계형 데이터베이스 솔루션은 모바일과 백엔드를 별개의 문제로 취급하므로 이러한 포인트 솔루션으로 오프라인 우선 애플리케이션을 구축하는 것은 거의 불가능에 가깝습니다.
반면에 Couchbase는 완전히 통합된 엣지 투 클라우드 솔루션을 제공하는 선도적인 업체입니다. 카우치베이스 라이트 제품은 에지 디바이스용 임베디드 데이터베이스(디바이스에서 로컬로 선언적 쿼리를 실행할 수 있는 곳)입니다, 동기화 게이트웨이 는 엣지 디바이스에서 데이터 동기화를 가능하게 하는 젤 기술입니다. 카우치베이스 클러스터.
이 글에서는 쿠버네티스 플랫폼에 Couchabse 클러스터와 동기화 게이트웨이를 배포하는 데 중점을 두겠습니다. 목표는 이러한 기술을 직접 경험하고 각 기술 뒤에 숨겨진 메커니즘을 이해하는 것입니다.
이 글에서 한 가지 더 알려드리고 싶은 것은 프라이빗 또는 퍼블릭 클라우드에 이 솔루션을 배포할 때 유용한 몇 가지 모범 사례입니다.
모범 사례
많은 엔터프라이즈 고객들로부터 이러한 질문을 들으면서, 저는 먼저 Kubernetes 플랫폼에 Couchbase를 배포하는 데 있어 몇 가지 모범 사례에 대해 이야기함으로써 이러한 질문을 해결하기로 결정했습니다.
- 항상 수행 사이징 분석 를 먼저 확인하여 클러스터에 필요한 EC2 인스턴스, 저장 장치 유형 및 공간을 계획합니다. 크기 추정치는 온프레미스 클러스터에서와 마찬가지로 Kubernetes 클러스터에서도 동일하게 유지됩니다.
그러나 K8에서는 Couchbase 파드가 실행될 Kubernetes 노드에 대한 크기 조정을 수행한다는 점을 기억하세요. 여기서 두 번째 모범 사례가 등장합니다. - 사용
spec.anti-Affinity=truein couchbase-cluster.yaml 파일에 추가할 수 있습니다. 이 필드는 이 클러스터의 두 파드를 동일한 쿠버네티스 노드에 배포할 수 있는지 여부를 지정합니다. 고가용성 관점에서 볼 때, 단일 노드 장애가 단일 포드만 다운되도록 각 K8 노드에 두 개 이상의 파드를 배치하고 싶지 않습니다. - 쿠버네티스 환경에서는 클러스터 배포 또는 자동 복구 시점에 원하는 리소스를 보장할 수 있도록 미리 정의된 노드 유형(대형, 대형, 4x 대형 등)으로 파드 배치를 관리할 것을 권장합니다. 다음을 사용할 수 있습니다.
spec.servers[].pod.spec.nodeSelector필드( 카우치베이스-클러스터.yaml), 이는 파드의 노드 배치에 대한 제약 조건의 키-값 맵을 지정한다. 노드에서 파드를 실행할 수 있으려면 노드에 레이블로 지정된 키-값 쌍이 각각 있어야 한다. - 재미있게 시작하기 전에 마지막으로 한 가지 더: K8 클러스터에 동종 노드가 있고 다음을 사용하지 않으려는 경우
노드 선택기메서드를 사용하여 파드 배치를 결정한 다음 spec.servers[].resources 를 정의하려면요청그리고제한. 이 역시 미리 정의된 리소스 풀로 파드를 배치하는 데 도움이 됩니다.
참고: 아래 예제에서는 다음을 사용합니다.
노드 선택기기술을 사용하여 각 포드 유형을노드 그룹를 사용하여 원하는 리소스를 보장합니다.
전제 조건
AWS 계정을 설정하고(이 블로그에서 설명하지 않은 지침) 이 지침을 성공적으로 시도하는 데 필요한 모든 도구가 준비되어 있는지 확인하세요. 다음은 필요한 것들의 목록입니다:
- 최신 다운로드 카우치베이스 자율 운영자 패키지를 다운로드하고 로컬 컴퓨터에 압축을 풉니다. 오퍼레이터 패키지에는 오퍼레이터를 설치하는 데 사용할 명령줄 도구가 포함되어 있습니다.
- 설치 및 설정 kubectl 로컬 머신에서 - kubectl은 쿠버네티스 클러스터에 대한 명령을 실행하기 위한 명령줄 인터페이스입니다.
- 최신 설치 AWS CLI - AWS CLI는 명령줄 셸에서 명령을 사용하여 AWS 서비스와 상호 작용할 수 있는 통합 도구입니다. 여기서는 AWS에서 실행 중인 Kubernetes 클러스터와 안전하게 통신하기 위해 AWS CLI를 사용하겠습니다.
일단 aws cli 설정에서 계정 자격 증명을 사용하여 Kubernetes 클러스터 만들기 섹션으로 이동할 수 있습니다.
1단계: 멀티 노드그룹 K8s 클러스터 만들기
Kubernetes(K8s)는 다양한 크기(vCPU, RAM, 디스크 크기)의 컴퓨팅 머신을 하나의 단일 Kubernetes 클러스터로 프로비저닝할 수 있는 유연성을 제공하므로 다양한 관리형 서비스의 리소스 요구 사항을 단일 K8s 클러스터에서 충족할 수 있습니다.
동일한 유연성을 활용하고 세 가지 조항을 제공할 예정입니다. 노드 그룹를 사용하여 나중에 특정 Couchbase 서비스 집합을 호스팅하는 데 사용할 것입니다.
1.1. 원하는 지역에 EKS 클러스터 만들기
먼저, 다음 위치에 K8s 클러스터를 배포해 보겠습니다. us-west-2 지역과 두 개의 가용 영역에서 US-WEST-2A/B. 다른 VPC-CIDR 블록을 사용하지만 이 예제에서는 172.16.0.0/204K 이상의 범위를 제공합니다(212) IP 주소로 충분할 것입니다.
|
1 2 3 4 5 6 |
$ eksctl create 클러스터 --이름 k8sEKS \ --버전 1.18 \ --지역 우리-west-2 \ --영역 우리-west-2a,우리-west-2b \ --vpc-cidr 172.16.0.0/20 \ --없이-노드그룹 |
1.2. 별도의 노드 그룹 만들기
만들어 봅시다 노드그룹 카우치베이스를 호스팅할 수 있도록 EKS 클러스터 내에서 데이터 서비스 인스턴스입니다. 이 예제에서는 m5.large(2 vCPU 및 8GB RAM) EC2 머신을 노드 유형로 설정할 수 있지만, 실제 EC2 노드의 크기는 워크로드에 따른 용량 및 성능 계획에 따라 달라집니다. 따라서 프로덕션 배포에 적합한 종류의 노드를 선택해야 합니다.
|
1 2 3 4 5 6 7 8 |
$ eksctl create 노드그룹 --클러스터=k8sEKS \ --이름=m5l-pool \ --노드-유형 m5.large \ --지역 우리-west-2 \ --노드 2 \ --노드-분 2 \ --노드-최대 4 \ --노드-ami 자동 |
호스팅하려면 색인/쿼리 서비스에서는 더 많은 컴퓨팅과 RAM을 갖춘 별도의 노드 그룹을 만들 것입니다. 이 예제에서는 r5.large(vCPU 2개 및 16GB RAM) 기계.
|
1 2 3 4 5 6 7 8 |
$ eksctl create 노드그룹 --클러스터=k8sEKS \ --이름=r5l-pool \ --노드-유형 r5.large \ --지역 우리-west-2 \ --노드 2 \ --노드-분 2 \ --노드-최대 4 \ --노드-ami 자동 |
마지막으로 다음을 사용합니다. t2.xlarge(4 vCP 및 16GB RAM) 호스트 동기화 게이트웨이 인스턴스입니다.
|
1 2 3 4 5 6 7 8 |
$ eksctl create 노드그룹 --클러스터=k8sEKS \ --이름=t2xl-pool \ --노드-유형 t2.xlarge \ --지역 우리-west-2 \ --노드 1 \ --노드-분 1 \ --노드-최대 2 \ --노드-ami 자동 |
세 가지가 모두 완료되면 노드 그룹 가 준비되면 노드 그룹의 각 노드에 레이블을 지정하거나 기존 레이블을 사용할 수 있지만 먼저 모든 노드 그룹 가 준비되었습니다:
|
1 2 3 4 5 6 |
$ eksctl get 노드 그룹 --클러스터=k8sEKS --지역=우리-west-2 LUSTER 노드그룹 생성됨 MIN 크기 MAX 크기 DESIRED 용량 인스턴스 유형 이미지 ID k8sEKS m5l-pool 2020-07-24T18:58:02Z 2 4 2 m5.largeami-04387C277E83865B2 k8sEKS r5l-pool 2020-07-24T18:58:09Z 2 4 2 r5.largeami-04387C277E83865B2 k8sEKS t2xl-pool 2020-07-24T19:09:09Z 1 2 1 t2.xlargeami-04387C277E83865B2 |
1.3. EKS 노드에 레이블 지정
호스팅할 세 가지 유형의 EC2 머신을 선택했습니다. 데이터, 색인/쿼리및 동기화 게이트웨이 특정 카우치베이스 서비스를 전용으로 사용하기 위해 노드그룹 유형으로 설정합니다. 기존 레이블을 사용하겠습니다. beta.kubernetes.io/instance-type 노드 선택에 사용할 수 있습니다. 이 레이블은 기본적으로 사용 가능하므로 새 레이블을 만들 필요가 없습니다. 이 cmd를 실행하여 노드 레이블을 간단히 확인할 수 있습니다:
|
1 2 3 4 5 6 7 8 |
$ kubectl get 노드 --show-레이블 이름 상태 역할 AGE 버전 라벨 IP-172-16-0-12.us-west-2.compute.internal 준비 <없음> 21m v1.14.9-eks-a0a484 ...,베타.쿠버네티스.io/인스턴스-유형=t2.xlarge,... IP-172-16-0-127.us-west-2.compute.internal 준비 <없음> 32m v1.14.9-eks-a0a484 ...,베타.쿠버네티스.io/인스턴스-유형=m5.large,... IP-172-16-3-234.us-west-2.compute.internal 준비 <없음> 32m v1.14.9-eks-a0a484 ...,베타.쿠버네티스.io/인스턴스-유형=m5.large,... IP-172-16-1-29.us-west-2.compute.internal 준비 <없음> 32m v1.14.9-eks-a0a484 ...,베타.쿠버네티스.io/인스턴스-유형=r5.large,... IP-172-16-3-119.us-west-2.compute.internal 준비 <없음> 32m v1.14.9-eks-a0a484 ...,베타.쿠버네티스.io/인스턴스-유형=r5.large,... |
이 예제에서는 다음을 호스팅합니다. 데이터 서비스 켜기 m5.large 기계, 인덱스/쿼리 on r5.large 기계 및 동기화 게이트웨이 on t2.xlarge 기계.
실제 프로덕션 환경에서는 여러 유형의 머신이 있지만 본질적으로 한 가지 유형의 카우치베이스 서비스 전용 머신이 아닐 수도 있습니다. 이 경우 각 노드 유형에 대해 상호 배타적인 레이블을 만들 수 있습니다.
다음을 사용합니다. kubectl 레이블 cmd를 사용하여 데이터 노드에만 사용할 모든 노드에 이와 같은 레이블을 지정할 수 있습니다:
|
1 |
$ kubectl 레이블 노드 'ec2-node-ip' 인스턴스 유형=데이터 |
모든 인덱스(쿼리 또는 다른) 노드에 동일한 방식으로 레이블을 지정합니다:
|
1 |
$ kubectl 레이블 노드 'ec2-node-ip' 인스턴스 유형=색인 |
모든 노드에 레이블을 지정하면 다음 섹션으로 이동할 준비가 된 것입니다.
참고: 우리는 다음을 사용하고 있습니다. beta.kubernetes.io/instance-type 를 레이블로 사용하므로 노드에 대한 레이블을 새로 만들 필요가 없습니다.
2단계: 사용자 정의 리소스 정의 설치
운영자 설치의 첫 번째 단계는 사용자 정의 리소스 정의(CRD)를 설치하는 것입니다. 카우치베이스 리소스 유형. Operator 패키지 디렉토리에서 아래 명령을 실행하면 됩니다:
|
1 |
kubectl create -f crd.yaml |
3단계: 네임스페이스 만들기
네임스페이스는 클러스터 리소스를 여러 사용자 간에 나누는 방법입니다.
네임스페이스는 클러스터 리소스를 여러 사용자 간에 나누는 방법입니다.
- 다음 명령을 실행하여 네임스페이스를 만듭니다.
|
1 2 3 |
$ kubectl create 네임스페이스 cbdb 네임스페이스/cbdb 생성 |
- 네임스페이스가 성공적으로 생성되었는지 확인합니다.
|
1 2 3 4 5 |
$ kubectl get 네임스페이스 이름 상태 AGE cbdb 활성 34s 기본값 활성 5시간 20분 |
4단계: 운영자 설치
운영자는 다음 두 가지 구성 요소로 구성됩니다. 클러스터별 동적 입학 컨트롤러 (DAC)와 네임스페이스별 연산자. 를 참조하세요. 운영자 아키텍처 를 참조하여 필요한 사항 및 보안 고려 사항에 대한 자세한 내용을 확인하세요.
4.1. 동적 입학 컨트롤러(DAC) 설치하기
DAC를 사용하면 리소스를 수락하고 etcd에 커밋하기 전에 사용자 정의 리소스를 수정하고 조사할 수 있습니다. DAC를 실행하면 Couchbase 클러스터 구성에 합리적인 기본값을 추가하여 사양의 크기를 최소화할 수 있습니다. 또한 새로운 속성이 추가되어 채워야 할 때 이전 버전과의 호환성을 유지할 수 있습니다. 따라서 기본 리소스 유형과 유사한 Couchbase 리소스 사용 환경을 만들 수 있습니다.
이제 동적 입장 컨트롤러를 설치해 보겠습니다.
- 터미널 창을 열고 Operator 패키지의 압축을 푼 디렉토리로 이동합니다. 다음 명령어를 실행하여 DAC를
기본값네임스페이스.
|
1 2 3 4 5 6 7 8 9 10 11 |
$ bin/cbopcfg 생성 입학 --네임스페이스 기본값 | kubectl create -f - 서비스 계정/카우치베이스-연산자-입학 생성 클러스터 역할.rbac.권한 부여.k8s.io/카우치베이스-연산자-입학 생성 클러스터 역할 바인딩.rbac.권한 부여.k8s.io/카우치베이스-연산자-입학 생성 비밀/카우치베이스-연산자-입학 생성 배포.앱/카우치베이스-연산자-입학 생성 서비스/카우치베이스-연산자-입학 생성 돌연변이웹훅 구성.입학등록.k8s.io/카우치베이스-연산자-입학 생성 웹훅 구성 유효성 검사.입학등록.k8s.io/카우치베이스-연산자-입학 생성 |
- 입장 컨트롤러가 성공적으로 배포되었는지 확인합니다.
|
1 2 3 4 |
$ kubectl get 배포 이름 READY UP-TO-날짜 사용 가능 AGE 카우치베이스-연산자-입학 1/1 1 1 48s |
4.2. 카우치베이스 운영자 설치
이제 오퍼레이터를 워크샵 네임스페이스에 추가합니다.
|
1 2 3 4 5 6 7 |
$ bin/cbopcfg 생성 연산자 --네임스페이스 cbdb | kubectl create -f - 서비스 계정/카우치베이스-연산자 생성 역할.rbac.권한 부여.k8s.io/카우치베이스-연산자 생성 역할 바인딩.rbac.권한 부여.k8s.io/카우치베이스-연산자 생성 배포.앱/카우치베이스-연산자 생성 서비스/카우치베이스-연산자 생성 |
위 명령을 실행하면 오퍼레이터 도커 이미지가 다운로드되고 배포를 사용하여 오퍼레이터의 단일 인스턴스를 관리한다. 오퍼레이터는 배포를 사용하여 파드가 죽으면 다시 시작할 수 있습니다.
실행한 후 kubectl 생성 명령어를 사용하면 일반적으로 쿠버네티스가 오퍼레이터를 배포하고 오퍼레이터를 실행할 준비가 되는 데 1분도 채 걸리지 않습니다.
4.3. 배포 상태 확인
다음 명령을 사용하여 배포 상태를 확인할 수 있습니다:
|
1 2 3 4 |
$ kubectl get 배포 -n cbdb 이름 READY UP-TO-날짜 사용 가능 AGE 카우치베이스-연산자 1/1 1 1 73s |
4.4. 운영자 상태 확인
다음 명령을 실행하여 운영자가 성공적으로 시작되었는지 확인합니다:
|
1 2 3 4 |
$ kubectl get 포드 -l 앱=카우치베이스-연산자 -n cbdb 이름 READY 상태 다시 시작 AGE 카우치베이스-연산자-558fd8486c-788jr 1/1 실행 중 0 2m9초 |
오퍼레이터가 실행 중이면 이 명령은 출력을 반환하며, 여기서 READY 필드 표시 1/1와 같이:
5단계. 카우치베이스 클러스터 배포
시스템의 성능과 SLA가 가장 중요한 프로덕션 환경에서는 항상 퍼시스턴트 볼륨을 사용하여 Couchbase 클러스터를 배포하는 것이 도움이 되기 때문에 이를 계획해야 합니다:
- 데이터 복구 가능성: 퍼시스턴트 볼륨을 사용하면 파드가 종료되는 경우 파드와 관련된 데이터를 복구할 수 있다. 이는 데이터 손실을 방지하고 데이터 또는 인덱스 서비스를 사용할 때 시간이 많이 소요되는 인덱스 생성을 방지하는 데 도움이 됩니다.
- 파드 재배치: 쿠버네티스는 CPU 및 메모리 제한과 같은 리소스 임계값에 도달한 파드를 퇴출할 수 있다. 퍼시스턴트 볼륨으로 백업되는 파드는 다운타임이나 데이터 손실 없이 다른 노드에서 종료 및 재시작할 수 있습니다.
- 동적 프로비저닝: 운영자는 클러스터 확장에 따라 필요에 따라 퍼시스턴트 볼륨을 생성하므로 배포 전에 클러스터 스토리지를 사전 프로비저닝할 필요성이 줄어듭니다.
- 클라우드 통합: 쿠버네티스는 AWS 및 GCE와 같은 주요 클라우드 공급업체에서 제공되는 네이티브 스토리지 프로비저닝과 통합됩니다.
5.1. 카우치베이스 관리 콘솔용 시크릿 만들기
가장 먼저 해야 할 일은 로그인하는 동안 관리 웹 콘솔에서 사용할 비밀 자격 증명을 만드는 것입니다. 편의를 위해 오퍼레이터 패키지에 샘플 시크릿이 제공됩니다. 이 시크릿을 쿠버네티스 클러스터에 푸시하면 사용자 이름은 관리자로, 비밀번호는 비밀번호로 설정됩니다.
를 누르려면 secret.yaml 를 쿠버네티스 클러스터에 설치한 후 다음 명령을 실행합니다:
|
1 2 3 |
$ kubectl create -f 비밀.yaml -n cbdb 비밀/cb-관리자-auth 생성 |
5.2 k8s 클러스터용 스토리지 클래스 만들기
퍼시스턴트볼륨을 카우치베이스 서비스(데이터, 인덱스, 검색 등)에 사용하려면 스토리지 클래스(sc-nas.yaml). kubectl을 실행하여 새 SSD 기반 스토리지 클래스를 생성한다:
|
1 2 3 4 |
$ kubectl create -f sc-nas.yaml -n cbdb 스토리지 클래스.스토리지.k8s.io/nas 생성 |
5.3. 카우치베이스 클러스터 배포
퍼시스턴트 볼륨을 사용하여 3개의 서로 다른 영역에 Couchbase 클러스터를 배포하기 위한 전체 사양은 다음 문서에서 확인할 수 있습니다. couchbase-cluster.yaml 파일을 생성합니다. 이 파일과 이 문서에 사용된 다른 샘플 YAML 파일은 이 git 리포지토리에서 다운로드할 수 있습니다.
방금 다운로드한 YAML 파일을 열고 다음과 같이 사용 중인 것을 확인합니다. 노드 선택기 의 특정 값을 갖는 노드에 파드를 배치하기 위해 beta.kubernetes.io/instance-type 라벨.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
서버: - 이름: 데이터-서비스-2a 크기: 1 서비스: - 데이터 볼륨 마운트: 기본값: pvc-기본값 # /opt/couchbase/var/lib/couchbase 데이터: pvc-데이터 # /mnt/data pod: 사양: 노드 선택기: 베타.쿠버네티스.io/인스턴스-유형: m5.large - 이름: 색인-quer-서비스-2a 크기: 1 서비스: - 색인 - 쿼리 볼륨 마운트: 기본값: pvc-기본값 색인: pvc-색인 pod: 사양: 노드 선택기: 베타.쿠버네티스.io/인스턴스-유형: r5.large |
이제 사용 kubectl 를 사용하여 클러스터를 배포하되, 반드시 couchbase-cluster.yaml 파일이 아닌 현재 작업 디렉터리에 있는 동일한 이름의 파일을 저장합니다.
|
1 2 3 |
$ kubectl create -f 카우치베이스-클러스터.yaml -n cbdb --저장-구성 카우치베이스 클러스터.카우치베이스.com/도심 데모 생성 |
그러면 Couchbase 클러스터 배포가 시작되고 모든 것이 정상적으로 진행되면 위의 구성 파일에 따라 서비스를 호스팅하는 4개의 Couchbase 클러스터 파드가 생성됩니다. 진행 상황을 확인하려면 다음 명령을 실행하여 파드 생성 진행 상황을 감시(-w 인수)합니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
$ kubectl get 포드 -n cbdb -w 이름 READY 상태 다시 시작 AGE 도심 데모-0000 0/1 실행 중 0 1m 도심 데모-0001 0/1 실행 중 0 53s 도심 데모-0002 0/1 실행 중 0 20s 카우치베이스-연산자-558fd8486c-788jr 1/1 실행 중 0 21m 도심 데모-0003 0/1 보류 중 0 3s 도심 데모-0003 0/1 보류 중 0 3s 도심 데모-0003 0/1 컨테이너 생성 0 3s 도심 데모-0003 0/1 실행 중 0 18s 도심 데모-0001 1/1 실행 중 0 2m 도심 데모-0000 1/1 실행 중 0 2m 도심 데모-0002 1/1 실행 중 0 1m 도심 데모-0003 1/1 실행 중 0 1m |
어떤 노드에서 어떤 파드가 실행 중인지 확인하려면:
|
1 2 3 4 5 6 7 8 |
$ kubectl get 포드 -o와이드 -n cbdb 이름 READY 상태 다시 시작 AGE IP NODE 추천 NODE 준비 상태 GATES 도심 데모-0000 1/1 실행 중 0 10m 172.16.2.134 IP-172-16-3-234.us-west-2.compute.internal <없음> <없음> 도심 데모-0001 1/1 실행 중 0 10m 172.16.1.116 IP-172-16-0-127.us-west-2.compute.internal <없음> <없음> 도심 데모-0002 1/1 실행 중 0 9m51초 172.16.1.5 IP-172-16-1-29.us-west-2.compute.internal <없음> <없음> 도심 데모-0003 1/1 실행 중 0 9m3s 172.16.2.98 IP-172-16-3-119.us-west-2.compute.internal <없음> <없음> 카우치베이스-연산자-558fd8486c-r2tcc 1/1 실행 중 0 31m 172.16.1.230 IP-172-16-0-12.us-west-2.compute.internal <없음> <없음> |
다음과 같은 사실을 알 수 있습니다. 색인/쿼리 서비스가 포드에서 실행 중입니다. cbdemo-0002 그리고 cbdemo-0003 레이블이 있는 EKS 노드에서 호스팅됩니다. beta.kubernetes.io/인스턴스 유형: r5.large 그리고 데이터 서비스 파드(cbdemo-0000, cbdemo-0001) 레이블을 사용하여 EKS 노드에 배치됩니다. beta.kubernetes.io/인스턴스 유형: m5.large. 이는 다음을 의미합니다. 노드 선택기 에 정의된 couchbase-cluster.yaml 는 원하는 리소스가 있는 노드에 파드를 성공적으로 배치했습니다.
이 시점에서 다음과 같이 포트 포워딩을 수행할 수 있습니다:
|
1 2 3 4 |
$ kubectl 포트-앞으로 도심 데모-0000 18091:18091 -n cbdb 전달 에서 127.0.0.1:18091 -> 18091 전달 에서 [::1]:18091 -> 18091 |
브라우저에 https://localhost:18091 을 입력하여 웹 콘솔에 액세스합니다.
6단계. 동기화 게이트웨이 클러스터 배포
지금까지 영구 스토리지 볼륨을 사용하여 다중 영역의 고가용성 Couchbase 클러스터를 배포하는 데 큰 진전이 있었습니다. 이제 동기화 게이트웨이 배포를 시작하기 전에 두 가지를 더 확인해야 합니다:
6.1 동기화 게이트웨이 전제 조건
- 클라이언트 애플리케이션과 동기화 게이트웨이가 데이터를 쓸 수 있는 버킷이 있습니다. 아직 쓸 수 있는 버킷이 없으므로 데이터를 쓸 수 있는
스테이징버킷에서웹 콘솔.
그림 2: 스테이징 버킷을 2GB 공간으로 만들었습니다.
참고: 이 버킷에는 2GB의 RAM을 사용했지만 프로덕션 환경에서는 사용자 또는 Couchbase 솔루션 아키텍트가 비즈니스 사용 사례에 대해 수행한 크기 추정치를 기반으로 RAM을 할당할 것입니다.
- 저희는 RBAC 사용자와 함께
애플리케이션 액세스버킷 수준에서 역할을 수행합니다.
우리는 간단히 카우치베이스 User를 사용하지만 좀 더 흥미롭게 만들기 위해 외부 (일명 LDAP) 사용자입니다. 에서 couchbase-cluster.yaml 타사의 세부 정보를 찾을 수 있습니다. LDAP 테스트 서버 이 예제에서 사용했습니다.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
보안: 관리자 비밀: cb-관리자-auth rbac: 관리: false ldap: 호스트: - ldap.포럼시스.com 포트: 389 bindDN: "CN=읽기 전용 관리자,DC=예시,DC=COM" bindSecret: cb-관리자-auth 인증 사용: true userDNMapping: 템플릿: "uid=%u,dc=example,dc=com" 권한 부여 사용: false |
다른 LDAP 서버에 연결하려는 경우 간단히 업데이트하면 됩니다. ldap 서버 세부 정보에서 couchbase-cluster.yaml 를 클릭하고 변경 사항을 적용합니다. 이제 다시 사용자 만들기와 버킷 수준 할당으로 돌아가 보겠습니다. 애플리케이션 액세스 역할.
그림 3: 사용 newton 를 외부 사용자로 설정하면 자동으로 다음과 같이 확인됩니다. 존재.
그림 4: 사용자 세부 정보 사용자 추가 버튼을 클릭합니다.
지금까지는 괜찮습니다. 이제 버킷과 RBAC 사용자가 준비되었으므로 계속해서 동기화 게이트웨이.
6.2 동기화 게이트웨이 구성
다음을 수행하려면 동기화 게이트웨이 와 통신하려면 데이터베이스, 버킷 및 자격 증명 세부 정보를 제공해야 합니다. 우리는 데이터베이스 연결 문자열을 couchbase://cbdemo-srv.cbdb.svc.cluster.local 아래 스니펫에서 볼 수 있듯이:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
... }, "데이터베이스": { "cbdemo": { "서버": "couchbase://cbdemo-srv.cbdb.svc.cluster.local", "bucket": "스테이징", "username": "newton", "비밀번호": "비밀번호", "허용_갈등": false, "revs_limit": 20, "enable_shared_버킷_액세스": true, "import_docs": true, "동기화": `함수(doc, oldDoc) { 채널(doc.채널); }`, } ... |
한 가지 강조하고 싶은 점은 동기화 게이트웨이 2.7 (또는 그 이상) 엔터프라이즈 고객은 이제 여러 동기화 게이트웨이 노드를 가져오기 노드로 지정하여(Couchbase Server 쓰기를 처리하기 위해) 복원력을 강화할 수 있습니다. 따라서 저희는 import_docs: true 를 설정 파일에 추가합니다.
다른 모든 구성 속성은 다음에서 찾을 수 있습니다. sgw-config.yaml 파일을 만듭니다. 이 파일을 사용하여 비밀번호를 생성하고 구성도 저장합니다.
|
1 2 3 |
$ kubectl create -f sgw-구성.yaml -n cbdb --저장-구성 비밀/동기화-게이트웨이 생성 |
보려면 sgw-config 아래에 비밀을 실행합니다:
|
1 2 3 4 5 6 7 |
$ kubectl get 비밀 -n cbdb 이름 유형 데이터 AGE cb-관리자-auth 불투명 2 4h 카우치베이스-연산자-토큰-p4qzb 쿠버네티스.io/서비스-계정-토큰 3 4h 기본값-토큰-x7cvw 쿠버네티스.io/서비스-계정-토큰 3 4h sgw-구성 불투명 1 30s |
6.3 배포 컨트롤러
비밀 번호와 구성을 설정하고 나면 배포 준비가 거의 완료됩니다. 동기화 게이트웨이 프로세스를 실행합니다. 쿠버네티스 클러스터의 복제본 그리고 GOMAXPROCS 프로덕션 요구 사항에 따라 다르지만 이 예제에서는 복제본당 최대 단일 vCPU를 사용하는 두 개의 복제본을 배포하겠습니다.
|
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 |
apiVersion: 앱/v1 종류: 배포 메타데이터: 이름: 동기화-게이트웨이 사양: 복제본: 2 선택기: matchLabels: 앱: 동기화-게이트웨이 템플릿: 메타데이터: 레이블: 앱: 동기화-게이트웨이 사양: 컨테이너: - 이름: 동기화-게이트웨이 이미지: 카우치베이스/동기화-게이트웨이:2.7.3-엔터프라이즈 볼륨 마운트: - 이름: 구성 마운트 경로: /등/동기화 게이트웨이 읽기 전용: true 환경: - 이름: GOMAXPROCS 값: "1" 볼륨: - 이름: 구성 비밀: 비밀 이름: 동기화-게이트웨이 |
배포 sgw-deployment.yaml 파일을 통해 kubectl cmd:
|
1 2 3 |
$ kubectl create -f sgw-배포.yaml -n cbdb --저장-구성 배포.확장 프로그램/동기화-게이트웨이 생성 |
실행하여 배포 진행 상황을 확인할 수 있습니다:
|
1 2 3 4 5 |
$ kubectl get 배포 동기화-게이트웨이 -n cbdb $ kubectl get 배포 동기화-게이트웨이 -n cbdb 이름 READY UP-TO-날짜 사용 가능 AGE 동기화-게이트웨이 2/2 2 2 98s |
위에서 볼 수 있듯이 두 복제 인스턴스가 모두 실행 중이며 이제 로드밸런서를 전면에 배치하기만 하면 됩니다.
6.4 로드 밸런서 배포하기
프로덕션 배포에서는 하나 이상의 동기화 게이트웨이 노드 앞에 로드 밸런서.
로드 밸런서를 배포하려면 쿠버네티스 로드 밸런서 서비스. 로드 밸런서 서비스는 외부에서 액세스할 수 있는 IP 주소를 제공하고 클러스터의 올바른 포트로 트래픽을 라우팅합니다.
- 라는 새 파일을 만듭니다. sgw-lb.yaml 를 다음 속성으로 전달합니다. 4984(공개 액세스 포트)와 4985(관리자 포트)를 모두 포워딩하고 있다는 점에 유의하세요.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
종류: 서비스 apiVersion: v1 메타데이터: 이름: sgw-lb 사양: 유형: 로드밸런서 선택기: 앱: 동기화-게이트웨이 포트: - 이름: http 프로토콜: TCP 포트: 4984 대상 포트: 4984 - 이름: http2 프로토콜: TCP 포트: 4985 대상 포트: 4985 |
참고 로드밸런서를 통해 4984(공용 액세스 포트)와 4985(관리자 포트)를 모두 포워딩하고 있습니다.
- 다음을 사용하여 로드밸런서를 배포합니다. sgw-lb.yaml 파일을 만듭니다.
|
1 2 3 |
$ kubectl create -f sgw-lb.yaml -n cbdb 서비스/sgw-load-밸런서 생성 |
- 로드 밸런서가 타겟팅하는 파드를 확인합니다.
모두 제대로 배포되었다면 다음과 비슷한 내용이 표시될 것입니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
$ kubectl 설명 서비스 sgw-load-밸런서 -n cbdb 이름: sgw-load-밸런서 네임스페이스: cbdb 레이블: <없음> 주석: <없음> 선택기: 앱=동기화-게이트웨이 유형: 로드밸런서 IP: 10.100.106.138 로드밸런서 인그레스: a8ce.우리-west-2.elb.amazonaws.com 포트: <unset> 4984/TCP TargetPort: 4984/TCP NodePort: <unset> 31066/TCP 엔드포인트: 172.16.11.2:4984, 172.16.11.3:4984 세션 선호도: 없음 외부 트래픽 정책: 클러스터 이벤트: 유형 이유 나이 에서 메시지 ---- ------ ---- ---- ------- 보통 보장로드밸런서 3m 서비스-컨트롤러 보장 load 밸런서 보통 보장 로드 밸런서 3m 서비스-컨트롤러 보장됨 load 밸런서 |
다음 사항을 메모해 두십시오. 로드밸런서 인그레스 값입니다.
6.5 설치 테스트
로드밸런서가 온라인 상태가 되면 다음을 통해 동기화 게이트웨이 클러스터 접근성을 확인할 수 있습니다. 로드밸런서 인그레스 엔드포인트(위 출력에서 언급했듯이)를 사용합니다. 그냥 curl cmd:
|
1 |
curl http://a8ce.us-west-2.elb.amazonaws.com:4984 |
다음을 반환해야 합니다.
|
1 2 |
{"couchdb":"환영","vendor":{"name":"카우치베이스 동기화 \. 게이트웨이","버전":"2.7"},"버전":"카우치베이스 동기화 게이트웨이/2.7.3(3;33d352f) EE"} |
짜잔! 동기화 게이트웨이가 완벽하게 작동하며 클라이언트(Couchbase Lite) 애플리케이션에서 워크로드를 가져올 준비가 되었습니다.
6.5.1 문서 읽기/쓰기 테스트
별도의 블로그에서 다음을 사용하여 에지 디바이스용 애플리케이션을 개발하는 방법에 대해 설명하겠습니다. 카우치베이스 라이트 하지만 엔드투엔드 설정의 정상성을 테스트하기 위해 다음을 사용하여 간단한 POST 및 GET 작업을 빠르게 수행할 수 있습니다. 동기화 게이트웨이 공개 REST API.
curl 명령을 사용하여 몇 개의 문서를 삽입해 보겠습니다:
|
1 2 3 4 5 |
$ curl -u 관리자:비밀번호 -X POST "http://a8ce.us-west-2.elb.amazonaws.com:4984/cbdemo/" -H "수락: 신청/제이슨" -H "콘텐츠 유형: 애플리케이션/json" -d "{\"id\":\"doc3\",\"channels\":\"newton\"}" 출력 {"id":"c4988cff19c632a724e13d4390b23b82","ok":true,"rev":"1-f99195111681fe7361b74eb5ebca23d4"} |
첫 번째 문서가 삽입되고 문서 키가 자동으로 다음과 같이 생성되었습니다. c4988cff19c632a724e13d4390b23b82.
|
1 2 3 4 5 |
$ curl -u 관리자:비밀번호 -X POST "http://a8ce.us-west-2.elb.amazonaws.com:4984/cbdemo/" -H "수락: 신청/제이슨" -H "콘텐츠 유형: 애플리케이션/json" -d "{\"id\":\"doc4\",\"channels\":\"newton\"}" 출력 {"id":"8f02cab34faa17d61ca89aa05ade372e","ok":true,"rev":"1-68b03bf8df34c5854d852e3b549d0572"} |
두 번째 문서도 관리자 자격 증명을 사용하여 성공적으로 삽입되었으며 자동 생성된 문서 키는 다음과 같습니다. 8f02cab34faa17d61ca89aa05ade372e.
이제 동기화 게이트웨이를 사용하여 GET 작업을 수행하여 문서를 가져올 수 있습니다. 공개 REST API:
|
1 2 3 4 5 |
$ curl -u 관리자:비밀번호 -X GET "http://a8ce.us-west-2.elb.amazonaws.com:4984/cbdemo/c4988cff19c632a724e13d4390b23b82" -H "수락: 신청/제이슨" -H "콘텐츠 유형: 애플리케이션/json" 출력 {"_id":"c4988cff19c632a724e13d4390b23b82","_rev":"1-f99195111681fe7361b74eb5ebca23d4","채널":"foo","id":"doc3"} |
결론
Couchbase 동기화 게이트웨이는 애플리케이션 개발자가 에지 투 클라우드 솔루션을 구축할 수 있도록 하는 중요한 데이터 동기화 기술입니다. 이 글에서는 최신 버전의 Couchbase Autonomous Operator를 사용하여 퍼블릭 클라우드 Kubernetes 플랫폼에 Couchbase 클러스터와 Sync Gateway를 설치했습니다. 다음 글에서는 이 글을 기반으로 암호화, LDAP, Couchbase Lite 개발 등 더 많은 엔터프라이즈급 작업을 수행할 수 있는 방법을 보여드리겠습니다. 그때까지 즐거운 배움 되세요.