1. 소개
기업 고객은 데이터 로컬리티와 고성능, 재해 복구 및/또는 단순한 데이터 백업을 위해 대기 데이터베이스 클러스터를 보유하는 것이 바람직할 때가 많습니다. 고객들은 오랫동안 이 기능을 사용하여 자신의 환경에서 이러한 목표를 달성해 왔기 때문에 Couchbase XDCR(교차 데이터 센터 복제)을 도입할 필요가 없습니다.
그러나 최근 Kubernetes용 Couchbase CAO(자율 운영자)를 사용하여 클라우드에 Couchbase를 배포하는 경우가 점점 더 많아지면서 고객들은 클라우드 플랫폼의 네트워킹 설정에 대한 지침을 요청해 왔습니다.
이 문서에서는 단계별 접근 방식을 사용하여 서로 다른 두 지역에 있는 Couchbase 클러스터 간의 네트워크를 구성하는 방법에 대해 자세히 설명합니다. Amazon EKS 환경에서 Couchbase 클러스터를 배포하기 위해 Amazon AWS 플랫폼을 사용했지만, 어떤 플랫폼을 선택하든 큰 틀의 접근 방식은 거의 동일할 것으로 생각합니다.
2. 전제 조건
이전 블로그에서 다음과 같은 내용을 읽어보시기 바랍니다. EKS에 카우치베이스 클러스터를 배포하는 방법. 이 문서에서는 데이터센터 간 복제를 설정하기 위한 네트워킹 측면에 집중할 수 있도록 Couchbase Autonomous Operator 배포에 대한 대부분의 세부 단계를 참조할 것입니다.
3. 두 지역에 EKS 클러스터 배포하기
먼저 두 개의 별도 지역(버지니아와 오하이오)에 두 개의 Amazon Elastic 컨테이너 서비스(Amazon EKS)를 배포하는 것으로 시작하겠습니다.
그림 1: 오하이오 및 버지니아 지역에 배포된 EKS 클러스터.
각 Amazon EKS 클러스터에는 최소 3개의 워커 노드가 있으며, 섹션 4에 설명된 대로 Couchbase 포드를 호스팅하는 데 사용됩니다. 이 글의 마지막 목표는 이 두 개의 Amazon EKS 클러스터에 두 개의 Couchbase 클러스터를 배포하고 네트워킹을 구성하고 소스에서 대상 클러스터로 활성 XDCR을 설정하는 것입니다.
3.1. 버지니아 지역에 EKS 배포
우리는 다음을 사용할 것입니다. eksctl 명령을 실행하여 Amazon EKS를 배포하고, 여기서 다음과 같은 새 노드 그룹을 생성합니다. bluegroup 최소 3개 m5.large 인스턴스, 최대 6개까지 가능합니다.
$ eksctl create cluster \
--name blueEKS \
--version 1.14 \
--region us-east-1 \
--zones us-east-1a,us-east-1b,us-east-1c \
--nodegroup-name bluegroup \
--node-type m5.large \
--nodes 3 \
--nodes-min 3 \
--nodes-max 6 \
--node-ami auto \
--vpc-cidr 172.16.0.0/24
[ℹ] using region us-east-1
...
[✔] EKS cluster "blueEKS" in "us-east-1" region is ready한 번 eksctl Kubernestes(K8s) 클러스터 배포가 완료되면, AWS 콘솔에 로그인하여 VPC-ID와 CIDR 블록을 기록합니다. 이러한 세부 정보를 알아내는 단계는 다음과 같으며, 나중에 VPC 피어를 설정할 때 사용됩니다.
그림 2: 지역별 리소스 대시보드를 보여주는 EKS 콘솔.
- 선택
Virginia지역으로 이동합니다. - VPC 대시보드가 표시되면 다음을 클릭합니다.
VPC옵션을 클릭합니다. 다른 페이지가 열려 있는 경우에는 먼저 VPC 서비스를 검색한 다음VPC옵션을 선택합니다.
그림 3: VPC 상세 페이지.
- 위에서 볼 수 있듯이, 방금 생성된 VPC를 선택한 다음 다음을 복사해야 합니다.
VPC ID를 아래 표에 입력합니다:
표 1. 파란색 EKS 클러스터 속성
| 속성 | 블루 클러스터 | 그린 클러스터 |
|---|---|---|
| 지역 | Virginia | Ohio |
| CIDR 블록 | 172.16.0.0/24 | |
| VPC-ID | vpc-0c8d3d5919e79659d |
3.2. 오하이오 지역에 EKS 배포
다음으로, 오하이오 리전에 3개의 워커 노드로 구성된 Kubernetes 클러스터를 배포합니다. m5.large 유형으로 설정합니다. 이러한 작업자 노드의 수와 유형은 클러스터의 크기에 따라 다를 수 있지만 이 설정에서는 이 3개의 작업자 노드에 3노드 카우치베이스 클러스터를 배포할 것입니다.
$ eksctl create cluster \
--name greenEKS \
--version 1.14 \
--region us-east-2 \
--zones us-east-2a,us-east-2b,us-east-2c \
--nodegroup-name greengroup \
--node-type m5.large \
--nodes 3 \
--nodes-min 3 \
--nodes-max 6 \
--node-ami auto \
--vpc-cidr 10.0.0.0/24
[ℹ] using region us-east-2
...
[✔] EKS cluster "greenEKS" in "us-east-2" region is readyGreen 클러스터가 준비되면 새 브라우저 탭을 열고 AWS 콘솔에 로그인합니다.
그림 4: 오하이오 리전에 연결된 AWS 콘솔.
- 지역을 오하이오로 변경
그림 5: 오하이오 클러스터 세부 정보를 보여주는 VPC 세부 정보 페이지입니다.
- VPC 대시보드에서 다음을 선택합니다.
VPC탭을 클릭합니다. - 그린 클러스터의 VPC ID를 아래 표에 복사하여 붙여넣어 기록을 남깁니다:
표 2. 녹색 EKS 클러스터 속성
| 속성 | 블루 클러스터 | 그린 클러스터 |
|---|---|---|
| 지역 | Virginia | Ohio |
| CIDR 블록 | 172.16.0.0/24 | 10.0.0.0/24 |
| VPC-ID | vpc-0c8d3d5919e79659d | vpc-08d025c8ae697bf34 |
현재 버지니아와 오하이오 리전 모두에 Kubernetes 클러스터가 배포되어 있으며, VPC 피어링에 사용될 VPC 세부 정보가 있습니다.
3.3. 클러스터 컨텍스트 전환
이 두 리전에 Couchbase 클러스터를 배포하기 전에 클러스터 컨텍스트를 쉽게 전환하기 위해 기억해야 할 한 가지 편리한 명령이 있습니다:
$ kubectl config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* x.y@domain.com@blueEKS.us-east-1.eksctl.io blueEKS.us-east-1.eksctl.io x.y@domain.com@blueEKS.us-east-1.eksctl.io
x.y@domain.com@greenEKS.us-east-2.eksctl.io greenEKS.us-east-2.eksctl.io x.y@domain.com@greenEKS.us-east-2.eksctl.io위에서 볼 수 있듯이 두 개의 서로 다른 클러스터가 등록됩니다. kubectl 구성. 현재 컨텍스트는 다음과 같이 설정되어 있습니다. blueEKS.us-east-1.eksctl.io 클러스터로 전환하려면 greenEKS.us-east-2.eksctl.io 클러스터를 사용하면 간단하게 할 수 있습니다:
$ kubectl config use-context x.y@domain.com@greenEKS.us-east-2.eksctl.io
Switched to context "x.y@domain.com@greenEKS.us-east-2.eksctl.io".
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
ip-10-0-0-11.us-east-2.compute.internal Ready <none> 20m v1.14.8-eks-b8860f
ip-10-0-0-61.us-east-2.compute.internal Ready <none> 20m v1.14.8-eks-b8860f
ip-10-0-0-72.us-east-2.compute.internal Ready <none> 20m v1.14.8-eks-b8860f여기서부터 모든 kubectl 명령을 실행하면 다음과 같은 컨텍스트가 됩니다. greenEKS.us-east-2.eksctl.io 클러스터에 있는 동부-2(오하이오) 지역.
4. 두 지역에 카우치베이스 클러스터 배포하기
지난 블로그에서 퍼시스턴트 볼륨을 사용하여 EKS에 카우치베이스 클러스터를 배포하는 방법에서 각 단계를 자세히 다루었습니다. 따라서 여기에서도 단계를 반복하는 대신 간단하게 설명하기 위해 단계를 따르도록 하겠습니다.
4.1 그린 클러스터 설정
다음에서 첫 번째 Couchbase 클러스터 배포를 시작하겠습니다. east-2 지역 일명 녹색 이 경우 따라서 마지막 단계에 따라 블로그를 클릭하세요:
- 2.1 ~ 2.8 단계에 따라 Couchbase Autonomous Operator를 배포합니다.
- 3.1~3.2단계를 수행하여 비밀 및 저장소 클래스를 만듭니다.
여기서 언급된 클러스터 배포 스크립트를 사용하지 않고 대신 다음을 사용하겠습니다. couchbase-green-cluster.yaml 세 개의 서로 다른 가용성 영역(east-2a/2b/2c)에 분산된 3노드 Couchbase 클러스터를 생성합니다.
$ kubectl create -f couchbase-green-cluster.yaml -n emart --save-config
couchbasecluster.couchbase.com/green created참고: 다음과 같은 모범 사례를 사용하는 것이 좋습니다.
spec.anti-Affinityin couchbase-green-cluster.yaml 를 사용하여 각 Kubernetes 노드가 하나의 포드만 가져가도록 합니다. 이렇게 하면 노드에 장애가 발생해도 Couchbase 포드 하나만 다운됩니다.
$ kubectl logs couchbase-operator-7654d844cb-tz7k5 -n emart -f
time="2020-02-22T08:22:02Z" level=info msg="Node status:" cluster-name=green module=cluster
time="2020-02-22T08:22:02Z" level=info msg="┌────────────┬──────────────────┬──────────────┬────────────────┐" cluster-name=green module=cluster
time="2020-02-22T08:22:02Z" level=info msg="│ Server │ Version │ Class │ Status │" cluster-name=green module=cluster
time="2020-02-22T08:22:02Z" level=info msg="├────────────┼──────────────────┼──────────────┼────────────────┤" cluster-name=green module=cluster
time="2020-02-22T08:22:02Z" level=info msg="│ green-0000 │ enterprise-6.0.3 │ data-east-2a │ managed+active │" cluster-name=green module=cluster
time="2020-02-22T08:22:02Z" level=info msg="└────────────┴──────────────────┴──────────────┴────────────────┘" cluster-name=green module=cluster
time="2020-02-22T08:22:02Z" level=info msg="Scheduler status:" cluster-name=green module=cluster
time="2020-02-22T08:22:02Z" level=info msg="┌──────────────┬────────────┬────────────┐" cluster-name=green module=cluster
time="2020-02-22T08:22:02Z" level=info msg="│ Class │ Zone │ Server │" cluster-name=green module=cluster
time="2020-02-22T08:22:02Z" level=info msg="├──────────────┼────────────┼────────────┤" cluster-name=green module=cluster
time="2020-02-22T08:22:02Z" level=info msg="│ data-east-2a │ us-east-2a │ green-0000 │" cluster-name=green module=cluster
time="2020-02-22T08:22:02Z" level=info msg="└──────────────┴────────────┴────────────┘" cluster-name=green module=cluster
time="2020-02-22T08:22:02Z" level=info cluster-name=green module=cluster
time="2020-02-22T08:22:08Z" level=info msg="Creating a pod (green-0001) running Couchbase enterprise-6.0.3" cluster-name=green module=cluster
time="2020-02-22T08:23:21Z" level=info msg="added member (green-0001)" cluster-name=green module=cluster
time="2020-02-22T08:23:21Z" level=info msg="Creating a pod (green-0002) running Couchbase enterprise-6.0.3" cluster-name=green module=cluster
time="2020-02-22T08:24:31Z" level=info msg="added member (green-0002)" cluster-name=green module=cluster
time="2020-02-22T08:24:39Z" level=info msg="Rebalance progress: 0.000000" cluster-name=green module=cluster
time="2020-02-22T08:24:43Z" level=info msg="reconcile finished" cluster-name=green module=cluster이제 포트 포워딩을 통해 Couchbase 관리 콘솔을 볼 수 있습니다:
$ kubectl port-forward green-0000 8092:8091 -n emart
Forwarding from 127.0.0.1:8092 -> 8091
Forwarding from [::1]:8092 -> 8091다음으로 브라우저를 열고 https://localhost:8092/ 을 입력하여 다음 주소의 Couchbase 웹 콘솔에 연결합니다. 녹색 클러스터:
그림 6: 3개의 가용 영역(AZ)에 분산된 3개의 노드 그린 클러스터
빈 버킷 만들기 기본값를 생성하면 나중에 XDCR을 설정할 때 대상 버킷으로 사용할 수 있습니다.
그림 7: 문서가 없는 대상 버킷
4.2 블루 클러스터 설정
다음과 같은 컨텍스트를 변경해야 합니다. kubectl 구성 를 추가해야 합니다.
$ kubectl config use-context x.y@domain.com@blueEKS.us-east-1.eksctl.io
Switched to context "x.y@domain.com@blueEKS.us-east-1.eksctl.io".
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
ip-172-16-0-25.ec2.internal Ready <none> 2h v1.14.8-eks-b8860f
ip-172-16-0-42.ec2.internal Ready <none> 2h v1.14.8-eks-b8860f
ip-172-16-0-76.ec2.internal Ready <none> 2h v1.14.8-eks-b8860f컨텍스트를 전환한 후 위에서 설명한 것과 동일한 단계를 따릅니다. 우리는 couchbase-blue-cluster.yaml 를 사용하여 최종적으로 3노드 클러스터를 배포합니다.
$ kubectl create -f couchbase-blue-cluster.yaml -n emart --save-config
couchbasecluster.couchbase.com/green created이제 운영자 로그를 살펴보고 진행 상황을 확인해 보겠습니다:
$ kubectl get pods -n emart
NAME READY STATUS RESTARTS AGE
couchbase-operator-7654d844cb-58gch 1/1 Running 0 4m22s
couchbase-operator-admission-7ff868f54c-57rhc 1/1 Running 0 5m21s
$ kubectl logs couchbase-operator-7654d844cb-58gch -n emart -f
time="2020-02-22T08:52:07Z" level=info msg="┌───────────┬──────────────────┬──────────────┬────────────────┐" cluster-name=blue module=cluster
time="2020-02-22T08:52:07Z" level=info msg="│ Server │ Version │ Class │ Status │" cluster-name=blue module=cluster
time="2020-02-22T08:52:07Z" level=info msg="├───────────┼──────────────────┼──────────────┼────────────────┤" cluster-name=blue module=cluster
time="2020-02-22T08:52:07Z" level=info msg="│ blue-0000 │ enterprise-6.0.3 │ data-east-1a │ managed+active │" cluster-name=blue module=cluster
time="2020-02-22T08:52:07Z" level=info msg="└───────────┴──────────────────┴──────────────┴────────────────┘" cluster-name=blue module=cluster
time="2020-02-22T08:52:07Z" level=info msg="Scheduler status:" cluster-name=blue module=cluster
time="2020-02-22T08:52:07Z" level=info msg="┌──────────────┬────────────┬───────────┐" cluster-name=blue module=cluster
time="2020-02-22T08:52:07Z" level=info msg="│ Class │ Zone │ Server │" cluster-name=blue module=cluster
time="2020-02-22T08:52:07Z" level=info msg="├──────────────┼────────────┼───────────┤" cluster-name=blue module=cluster
time="2020-02-22T08:52:07Z" level=info msg="│ data-east-1a │ us-east-1a │ blue-0000 │" cluster-name=blue module=cluster
time="2020-02-22T08:52:07Z" level=info msg="└──────────────┴────────────┴───────────┘" cluster-name=blue module=cluster
time="2020-02-22T08:52:07Z" level=info cluster-name=blue module=cluster
time="2020-02-22T08:52:13Z" level=info msg="Creating a pod (blue-0001) running Couchbase enterprise-6.0.3" cluster-name=blue module=cluster
time="2020-02-22T08:53:27Z" level=info msg="added member (blue-0001)" cluster-name=blue module=cluster
time="2020-02-22T08:53:27Z" level=info msg="Creating a pod (blue-0002) running Couchbase enterprise-6.0.3" cluster-name=blue module=cluster
time="2020-02-22T09:00:45Z" level=info msg="added member (blue-0002)" cluster-name=blue module=cluster
time="2020-02-22T09:00:54Z" level=info msg="Rebalance progress: 0.000000" cluster-name=blue module=cluster
time="2020-02-22T09:00:58Z" level=info msg="reconcile finished" cluster-name=blue module=clusterCouchbase 관리 콘솔을 포트 8091로 포트 포워딩합니다:
$ kubectl port-forward green-0000 8091:8091 -n emart
Forwarding from 127.0.0.1:8091 -> 8091
Forwarding from [::1]:8091 -> 8091브라우저에서 다른 탭을 열고 https://localhost:8091/ 을 입력하여 다음 주소의 Couchbase 웹 콘솔에 연결합니다. 파란색 클러스터:
그림 8: 3개의 가용 영역(AZ)에 분산된 3개의 노드 블루 클러스터
4.2.1 여행 샘플 버킷 만들기
우리는 여행 샘플 버킷을 소스 데이터로 지정하고, 이를 타깃에 복제합니다. 녹색 클러스터로 이동합니다. 샘플 버킷을 만들려면 설정>샘플 버킷으로 이동한 다음 옆의 확인란을 클릭합니다. 여행 샘플. 그러면 필요한 버킷이 생성되고 버킷에 여러 문서가 채워집니다.
그림 9: 샘플 데이터가 있는 소스 버킷
이 트래블 샘플 버킷을 Green(일명 오하이오) 지역의 대상 클러스터에 복제하겠습니다.
5. 네트워크 구성
재미는 네트워크 구성 섹션에서 시작됩니다. 이미 AWS 콘솔을 사용하여 두 리전 또는 두 개의 개별 VPC 간에 VPC 피어링을 설정한 적이 있다면 이 섹션은 매우 쉬울 것입니다. 그리고 VPC 피어링을 구성하는 방법을 배우고 싶으시다면 이 섹션은 훌륭한 학습 경험이 될 것입니다.
5.1 VPC 피어링 설정
3단계 프로세스의 첫 번째 단계는 요청자 VPC에서 수락자 VPC로 VPC 피어링을 설정하는 것입니다. 이 단계에서는 AWS 콘솔을 사용하여 버지니아 리전에 로그인하고 피어링 요청을 시작합니다. 그런 다음 오하이오 리전에 로그인하여 이 요청을 수락합니다.
5.1.1 블루 리전에서 VPC 요청 시작하기
버지니아 리전에 연결하여 VPC 피어링 시작 프로세스를 시작하겠습니다.
그림 10: 버지니아 지역의 리소스 요약을 표시하는 AWS 콘솔
- AWS 콘솔에서 요청자 지역을 선택했는지 확인합니다(이 경우 버지니아).
- VPC 대시보드 페이지를 불러옵니다.
그림 11: VPC 대시보드의 VPC 피어링 옵션
- 를 선택하고
피어링 연결옵션을 클릭합니다. - 클릭
피어링 연결 만들기버튼을 클릭합니다.
버튼을 클릭하면 대화 상자 페이지가 표시됩니다:
- 이 피어링 연결에 고유한 이름을 입력합니다. 여기서는
파란색에서 녹색으로 피어링버지니아 지역에서는 블루 클러스터를, 오하이오 지역에서는 그린 클러스터를 호스팅하고 있기 때문입니다.
그림 12: VPC 피어링 요청자 및 수락자 구성.
- 요청자인 Blue 클러스터의 VPC ID를 선택합니다.
- 대상 클러스터가 다른 지역에 있으므로 다음을 선택하겠습니다.
다른 지역에 대한 옵션으로지역. - 다음으로 대상 지역인 오하이오를 선택합니다.
- 표 2에 두 VPC의 VPC ID를 기록해 두었습니다. 따라서 Green 클러스터의 VPC ID를 사용하겠습니다.
- 히트
피어링 연결 만들기버튼을 클릭합니다.
그림 13: 피어링 요청이 설정되었습니다.
그러면 확인 페이지가 표시됩니다. 클릭하기만 하면 됩니다. 확인 버튼을 누르면 요청이 시작되었다는 메시지가 표시됩니다.
5.1.2 녹색 영역에서 VPC 요청 수락하기
이제 AWS 콘솔에서 지역을 오하이오(일명 그린 리전)로 변경한 다음 VPC 대시보드를 선택합니다.
그림 14: 미국 동부-2(오하이오) 지역 선택
- 를 선택하기 전과 동일하게
피어링 연결옵션을 선택하면 피어링 요청을 수락하여 피어링 요청을 완료할 수 있습니다.
그림 15: 선택 피어링 연결 VPC 대시보드의 옵션
- 위에서 볼 수 있듯이 목록에 보류 중인 요청이 하나 있습니다. 이 요청을 먼저 선택하겠습니다.
그림 16: VPC 피어링 요청 수락
- 그런 다음
작업드롭다운 버튼을 선택하면요청 수락.
그림 17: 팝업에서 VPC 피어링 요청을 확인합니다.
- 확인 페이지가 팝업됩니다. 선택
예, 수락버튼을 클릭합니다.
그림 18: 소스-대상에서 VPC 피어링 연결이 설정되었습니다.
이로써 피어링 상태는 다음과 같이 VPC 피어링 1단계가 완료됩니다. 활성.
5.2 라우팅 테이블 업데이트
두 번째 단계는 라우트 테이블에 대상 클러스터의 CIDR 블록을 추가하여 통신 채널을 설정하는 것입니다. 이를 위해서는 세 개의 EC2 인스턴스가 각각 어느 서브넷에 있는지 알아내야 합니다.
쿠버네티스 워커 노드가 실행 중인 세 개의 AZ(1a, 1b, 1c) 각각에 있는 서브넷 목록이 있으면, 세 개의 서브넷 각각과 연결된 라우팅 테이블을 찾아야 합니다. 이 라우팅 테이블에 라우팅 테이블 항목을 추가하여 VPC 피어링을 통해 다른 VPC에서 오는 트래픽을 허용하려고 합니다. 단계별로 살펴보겠습니다.
5.2.1 블루 클러스터에서 사용되는 서브넷
- AWS 콘솔에 로그인하고 버지니아 리전(일명 블루 리전)을 선택합니다. 그런 다음 EC2 서비스를 선택하여 Kubernetes 노드로 사용되는 모든 EC2 인스턴스를 표시합니다.
그림 19: 각 EC2 인스턴스에 연결된 서브넷입니다.
- 다음으로 EC2 인스턴스 중 하나를 선택합니다. 위 그림에서는 us-east-1a 지역의 인스턴스를 선택했으며 설명 탭에 이 인스턴스에 대한 모든 세부 정보가 표시됩니다.
- 이 인스턴스가 상주하는 서브넷 이름(괄호 안에 언급)을 기록해 두세요. 위의 인스턴스가 배포된 것처럼
eksctl-blueEKS-클러스터/서브넷퍼블릭USEAST1A서브넷. - 클러스터에서 사용되는 모든 서브넷 목록이 나올 때까지 동일한 과정을 반복합니다. 저희의 경우 클러스터 내에서 이 세 개의 서브넷이 사용되고 있습니다:
| 속성 | US-EAST-1A | US-EAST-1B | US-EAST-1C |
|---|---|---|---|
| 서브넷 이름 | eksctl-blueEKS-클러스터/서브넷퍼블릭USEAST1A | eksctl-blueEKS-클러스터/서브넷퍼블릭USEAST1B | eksctl-blueEKS-cluster/SubnetPublicUSEAST1C |
5.2.2 서브넷에 연결된 라우팅 테이블
다음 단계는 각 서브넷과 연결된 라우팅 테이블을 찾아서 Green 클러스터의 트래픽을 허용하도록 라우팅 규칙을 추가하는 것입니다.
그림 20: 클러스터의 각 서브넷과 연결된 라우팅 테이블
- 사용된 라우팅 테이블을 찾으려면 다음을 클릭합니다.
서브넷탭을 클릭합니다. - 다음으로 목록에서 서브넷 중 하나를 선택합니다.
eksctl-blueEKS-클러스터/서브넷퍼블릭USEAST1A - 아래에서 라우팅 테이블을 확인하여 사용된 라우팅 테이블을 기록해 두십시오.
설명탭을 클릭합니다. - 각 서브넷에 대해 위의 세 단계를 반복하고 사용된 라우팅 테이블을 기록합니다:
| 속성 | US-EAST-1A | US-EAST-1B | US-EAST-1C |
|---|---|---|---|
| 서브넷 이름 | eksctl-blueEKS-클러스터/서브넷퍼블릭USEAST1A | eksctl-blueEKS-클러스터/서브넷퍼블릭USEAST1B | eksctl-blueEKS-cluster/SubnetPublicUSEAST1C |
| 경로 테이블 이름 | eksctl-blueEKS-cluster/PublicRouteTable | eksctl-blueEKS-cluster/PublicRouteTable | eksctl-blueEKS-cluster/PublicRouteTable |
우리의 경우 하나의 경로 테이블이 있음을 알 수 있습니다. eksctl-blueEKS-cluster/PublicRouteTable 세 개의 서브넷 모두에 연결된 라우트 테이블이 있으므로 하나의 라우트 테이블만 업데이트하겠습니다.
5.2.3 라우팅 규칙 추가하기
이제 다음을 추가하겠습니다. 10.0.0.0/24 허용된 라우팅에 대상 지역의 CIDR 블록을 추가합니다. 경로 를 소스 라우팅 테이블에 추가합니다.
그림 21: 파란색 영역에 존재하는 라우팅 테이블 목록을 보여주는 라우팅 테이블 탭
- 를 클릭합니다.
라우팅 테이블탭을 클릭합니다. - 경로 항목을 추가할 경로 테이블을 선택합니다.
eksctl-blueEKS-cluster/PublicRouteTable. - 그런 다음
경로버튼을 누르면 요약 탭 옆에 두 개의 경로 항목만 표시됩니다. - 허용하려면
10.0.0.0/24CIDR 블록을 클릭합니다.경로 편집버튼을 클릭합니다.
그림 22: 경로 편집 대화 상자 페이지.
- 위의 대화 상자에서 GREEN 클러스터의 CIDR 블록을 추가하고 VPC-Peering을 대상으로 선택합니다. 다음 히트
경로 저장버튼을 클릭합니다. - 대상 CIDR 블록이 표시됩니다.
10.0.0.0/24는 이제경로선택한 경로 테이블에 사용할 수 있습니다:eksctl-blueEKS-cluster/PublicRouteTable
그림 23: 허용된 경로로 대상 CIDR 블록을 표시하는 경로 테이블입니다.
참고: 오하이오(일명 녹색) 클러스터에 대해 동일한 프로세스를 반복하고 버지니아(일명 파란색)의 CIDR 블록을 경로 테이블에 추가합니다.
그림 24: 녹색 클러스터 경로 테이블에 파란색 클러스터 CIDR 블록을 표시하는 경로 테이블입니다.
5.3 보안 그룹 업데이트
소스 및 대상 클러스터 모두에서 네트워킹을 설정하는 마지막 단계는 K8의 워커 노드가 서로 통신할 수 있는 다양한 포트를 여는 것입니다. 이 포트는 다음 용도로 사용됩니다. XDCR 커뮤니케이션 따라서 30000-32767 범위의 포트를 개방하거나 6.0 섹션에서 설명한 대로 오버레이 네트워킹에 사용되는 단일 포트로 더 제한합니다.
5.3.1 인바운드 규칙 설정
간단하게 하기 위해 K8의 워커 노드로 사용되는 노드 그룹에서 포트 범위를 개방할 수 있도록 허용하겠습니다. 방화벽 설정을 변경하려면 다음 단계를 따르세요:
그림 25: 버지니아(일명 블루) 클러스터에 보안 그룹을 설정합니다.
- 를 클릭합니다.
보안 그룹탭을 버지니아 지역의 AWS 콘솔 왼쪽 창에서 클릭합니다. - 다음으로 다음을 사용하여 보안 그룹(SG)을 찾습니다.
-노드그룹-블루그룹를 문자열로 지정합니다. 이 SG는 쿠버네티스 노드 그룹의 모든 워커 노드에 대한 방화벽 설정으로 사용됩니다. - 클릭
인바운드 규칙탭을 클릭하면 해당 리소스에 대해 열려 있는 포트의 범위가 표시됩니다. - 다음 클릭
규칙 편집버튼을 클릭하여 새 규칙을 목록에 추가합니다.
그림 26: 소스 클러스터와 대상 클러스터가 서로 통신할 수 있도록 방화벽 규칙을 추가합니다.
- 위 이미지에 설명된 대로 포트 범위 30000-32767에 대한 새 TCP 규칙을 추가하고 CIDR 블록을 사용합니다.
10.0.0.0/24대상 클러스터, 즉 오하이오(일명 그린) 클러스터로 설정합니다. 이것으로 인바운드 트래픽에 대한 설정이 완료되었습니다.
5.3.2 아웃바운드 규칙 설정
- 이제 아웃바운드 커뮤니케이션에 대해서도 유사한 규칙을 만들어 보겠습니다. 이렇게 하려면
아웃바운드 규칙버튼을 클릭합니다.
그림 27: 선택한 보안 그룹에 대한 아웃바운드 규칙 설정입니다.
- 를 클릭합니다.
규칙 편집버튼을 클릭하여 새 규칙을 추가합니다.
그림 28: 추가 규칙으로 아웃바운드 경로가 업데이트되었습니다.
- 이전과 마찬가지로 새로운
사용자 지정 TCP 규칙에서 포트 범위를 허용합니다.30000-32767을 사용하여 대상 CIDR 블록과 통신할 수 있습니다.10.0.0.0/24.
참고: 블루 클러스터의 노드 그룹에 방화벽 규칙을 추가한 것처럼, 그린 클러스터의 노드 그룹에도 동일한 작업을 수행해야 합니다.
소스와 타깃 모두 네트워크 설정을 완료하면 클러스터는 우리가 사용한 포트 범위에서 통신할 수 있어야 하며, 데이터를 리전 전체에서 소스에서 타깃 버킷으로 복제할 수 있도록 실제로 XDCR을 설정하는 다음 단계로 넘어가도 좋습니다.
6.0 오버레이 네트워킹을 통한 XDCR 복제
아래 다이어그램을 살펴보면, 별도의 Kubernetes 클러스터에 있는 두 노드가 서로 통신할 수 있다고 가정합니다. 표시된 라우터는 스위치, 라우터, VPN 연결 또는 레이어 3 통신을 허용하는 기타 인프라가 될 수 있습니다.
그림 29: 오버레이 네트워킹을 통해 다른 쿠버네티스 클러스터로 XDCR 전송하기
다이어그램에서, 클러스터 1의 파드는 클러스터 2에 노출된 노드 포트(31202)에만 연결할 수 있다. 또한 해당 포트는 파드가 실행 중인 노드에만 노출됩니다. XDCR 대상 클러스터에서 올바른 연결 문자열을 확인하려면 다음 절차를 따르세요:
- 대상 클러스터에 배포된 Couchbase 파드를 나열합니다. Blue 클러스터에서 XDCR 복제를 설정하려면 다음 명령어를
녹색클러스터:
$ kubectl get pods -n emart
NAME READY STATUS RESTARTS AGE
green-0000 1/1 Running 0 7m39s
green-0001 1/1 Running 0 6m19s
green-0002 1/1 Running 0 5m8s- Couchbase 포드 중 하나를 선택하고 기본 GKE 노드의 IP 주소를 얻습니다:
$ kubectl get pod green-0000 -o yaml -n emart | grep hostIP
hostIP: 10.0.0.5- 관리자 포트(8091)에 매핑되는 포트 번호를 가져옵니다.
$ kubectl get service green-0000-exposed-ports -n emart
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
green-0000-exposed-ports NodePort 172.20.55.204 <none> 11210:32262/TCP,11207:31500/TCP,8093:32209/TCP,18093:31965/TCP,8091:30964/TCP,18091:30093/TCP,8092:31555/TCP,18092:30041/TCP 7m3sBlue 클러스터에서 Couchbase Server 웹 콘솔에 로그인하고 Green 클러스터에 XDCR 연결을 설정하는 경우, 연결 문자열을 사용합니다. 10.0.0.5:30964 의 예시를 기반으로 합니다.
6.1. 파란색 클러스터에서 녹색 클러스터로 XDCR 전환
에서 단방향 복제를 구성하겠습니다. 파란색 를 녹색 클러스터로 이동합니다. 자세한 내용은 XDCR 문서.
먼저 Couchbase 웹 콘솔에 연결해 보겠습니다. 파란색 클러스터에 포트 포워드 방법을 사용합니다.
참고: 이미 포트 포워딩을 사용하여 두 Green 클러스터 모두에 대해 포트
8092및 블루 클러스터를 사용하는 포트8091.
파란색 클러스터에서 https://localhost:8091:
- 의 클러스터 참조를 추가합니다. 녹색 클러스터.
그림 30: 파란색 클러스터에서 녹색 클러스터로 XDCR 연결.
- 원격 클러스터 참조가 추가되었습니다.
그림 31: 복제가 설정되었습니다.
- 다음에서 버킷 복제 추가 여행 샘플 버킷에 기본값 버킷에 저장합니다.
그림 32: 소스에서 대상으로 버킷 복제 설정.
- 이제 버킷이 다음에서 복제되고 있습니다.
파란색에녹색클러스터.
그림 33: 버지니아에서 오하이오 클러스터로 버킷의 활성 복제.
7. 결론
이 문서에서는 네트워킹 설정이 얼마나 쉬운지 보여드리기 위해 네트워킹 세부 정보를 공개했습니다. VPC 피어링 의 맥락에서 여러 지역에 걸쳐 Couchbase 자율 운영자. 저희는 클라우드 플랫폼 중 하나를 사용하여 지역적으로 분산된 Couchbase 클러스터의 배포를 추진했지만, 강조하고 싶은 것은 개념을 이해하면 다른 클라우드 플랫폼에 적용하는 것이 간단하다는 것입니다.
