브랜트 버넷은 카우치베이스 전문가, 시스템 설계자이자 데스크톱 및 웹 풀스택 개발 경험이 풍부한 .NET 개발자입니다. 지난 12년 동안 그는 노스캐롤라이나주 록스보로에 본사를 둔 가족 엔터테인먼트 소프트웨어 회사인 CenterEdge Software에서 근무해 왔습니다. Brant는 소프트웨어 제품군의 모든 부문을 위한 애플리케이션을 개발한 경험이 있습니다. 지난 4년 동안 그는 회사의 클라우드 인프라를 Microsoft SQL 플랫폼에서 순수 Couchbase NoSQL 데이터 플랫폼으로 전환하기 위해 노력해 왔습니다. CenterEdge에서 일하면서 Brant는 재미있는 비즈니스를 위한 진지한 소프트웨어 솔루션을 만드는 데 집중할 수 있었습니다.
Couchbase는 확장 가능한 클라우드 애플리케이션을 위한 훌륭한 데이터 저장소로, 다음을 사용하여 구축된 애플리케이션을 포함합니다. 마이크로서비스 아키텍처. Kubernetes 는 컨테이너화된 마이크로서비스를 실행하고 DevOps 관리를 용이하게 하며 개발자의 마찰을 줄이기 위한 매우 강력한 플랫폼입니다. 그렇다면 어떻게 함께 사용하여 전체 시스템에서 마찰과 관리 오버헤드를 줄일 수 있을까요?
한 가지 옵션은 쿠버네티스 내에서 카우치베이스를 스테이트풀셋. 그러나 스테이트풀셋은 아직 베타 버전입니다. 또한 프로덕션 카우치베이스 클러스터는 상당한 부하를 발생시키므로 전용 노드에서 실행하는 것이 강력히 권장됩니다. 이는 틴트를 사용하여 Kubernetes에서 수행할 수 있지만, 다음에서 CenterEdge 소프트웨어 단순하게 유지하고 독립 실행형 EC2 인스턴스에서 Couchbase 클러스터를 실행하기로 결정했습니다.
이 포스팅은 AWS의 EC2에서 실행되는 Couchbase 클러스터에 원활하게 연결하기 위해 AWS(Amazon Web Services)에서 Kubernetes를 구성하는 방법에 대한 자습서입니다. 또한, 이 접근 방식은 클러스터를 교체하거나 개발 또는 QA 환경을 위해 Kubernetes 내에서 더 작은 클러스터를 실행할 수 있을 만큼 유연합니다.
TL;DR
Kubernetes에서 Couchbase에 대한 액세스를 구성하는 이 접근 방식에는 몇 가지 주요 이점이 있습니다:
- 하나의 간단한 URL로 더 쉽게 마이크로서비스 구성하기
- 모든 마이크로서비스를 재구성할 필요 없이 인프라를 변경하세요.
- Couchbase 업그레이드 중 클러스터를 투명하게 교체할 수 있도록 지원
- 개발 또는 QA Kubernetes 클러스터의 동일한 URL을 다른 Couchbase 클러스터로 쉽게 가리키기
단계:
- 카우치베이스와 쿠버네티스 클러스터가 네트워크를 통해 서로 연결될 수 있는지 확인하세요.
- 만들기 애플리케이션 로드 밸런서(ALB) 단일 URL을 사용하는 부트스트랩의 경우
- 마이크로서비스에서 클러스터를 확인하기 위해 외부 이름 유형의 쿠버네티스 서비스를 생성한다.
전제 조건
이 게시물은 다음 전제 조건이 완료되었다고 가정합니다:
- AWS에서 실행 중인 Kubernetes 클러스터가 있습니다. 공식적으로 지원되는 클러스터를 사용하여 클러스터를 배포했습니다. kops 유틸리티를 사용하세요. 좋은 가이드가 있습니다. 여기.
- AWS on EC2 인스턴스에서 실행 중인 Couchbase 클러스터가 있습니다. 우리는 이 사용자 데이터 스크립트 를 사용하여 시작 시 인스턴스를 구성하고, NVMe SSD 인스턴스 스토리지와 함께 i3 인스턴스 유형을 사용합니다. 면책 조항: 이 사용자 데이터 스크립트는 프로덕션 사용에 대해 완전히 검증되지 않았습니다.
- 이 두 클러스터는 모두 동일한 AWS 리전에 있습니다.
- 카우치베이스가 상주하는 VPC에는 최소 두 개의 가용 영역에 서브넷이 있어야 합니다(카우치베이스가 하나만 사용하더라도).
VPC 피어링 설정
VPC 피어링 를 사용하면 하나의 VPC 를 사용하여 동일한 AWS 리전에 있는 다른 VPC의 인스턴스와 마치 동일한 LAN에 있는 것처럼 투명하게 통신할 수 있습니다.
참고: 이 단계는 카우치베이스 VPC가 쿠버네티스 VPC와 분리되어 있는 경우에만 필요합니다. 둘 다에 동일한 VPC를 사용하는 경우 이 단계를 건너뛸 수 있습니다.
참고: VPC는 IP 주소 충돌을 방지하기 위해 서로 다른 사설 서브넷을 사용해야 합니다.
- 열기 피어링 연결 AWS 콘솔의 VPC 내
- 피어링 연결 만들기
- 요청자의 경우, 쿠버네티스 VPC를 선택합니다.
- 수용자의 경우, Couchbase VPC를 선택합니다.
- 연결이 '수락 대기 중' 상태가 되면 마우스 오른쪽 버튼을 클릭하고 요청 수락을 선택합니다.
이제 피어링 연결이 생성되었으므로 트래픽을 서로 라우팅하도록 VPC를 구성해야 합니다. 이 작업은 경로 테이블 에 대한 두 VPC 를 사용하여 올바른 서브넷을 위해 트래픽을 다른 서브넷으로 라우팅합니다.
이 예제에서는 Kubernetes가 10.100.0.0/16에서 실행 중이고 Couchbase가 10.200.0.0/16에서 실행 중이라고 가정하겠습니다.
- 쿠버네티스 VPC의 각 경로 테이블에 대해:
- 경로 탭으로 이동하여 편집을 클릭합니다.
- 다른 경로 추가를 클릭합니다.
- 카우치베이스 서브넷(10.200.0.0/16)을 입력합니다.
- 피어링 연결을 대상으로 선택합니다(pcx-로 시작).
- 저장을 클릭합니다.
- 이제 Couchbase VPC의 각 경로 테이블에 대해 반대 방향으로 반복합니다:
- 경로 탭으로 이동하여 편집을 클릭합니다.
- 다른 경로 추가를 클릭합니다.
- 쿠버네티스 서브넷(10.100.0.0/16)을 입력합니다.
- 피어링 연결을 대상으로 선택합니다(pcx-로 시작).
- 저장을 클릭합니다.
- 또한, 카우치베이스 인스턴스에 대한 EC2 보안 그룹이 쿠버네티스 서브넷에서 올바른 포트를 허용하는지 확인하세요. 필요한 포트는 다음 목록에 나열된 노드-클라이언트 간 포트입니다. 이 문서.
부트스트랩을 위한 애플리케이션 로드 밸런서 만들기
Couchbase 클라이언트 SDK는 여러 가지 프로토콜을 통해 서버에 대한 연결을 부트스트랩할 수 있습니다. Kubernetes에서 클러스터를 쉽게 사용하기 위해 포트 8091의 HTTP 프로토콜을 통한 부트스트랩에 중점을 두겠습니다. 부트스트랩 프로세스를 보호하기 위해 TLS를 사용하려는 경우, 대신 포트 18091을 사용하여 이 작업을 수행할 수 있습니다.
이러한 종류의 부트스트랩을 지원하기 위해 AWS에서 애플리케이션 로드 밸런서(ALB)를 생성합니다. 이렇게 하면 Couchbase 클러스터의 변경 사항에 관계없이 재사용할 수 있는 단일 엔드포인트를 제공할 수 있습니다. 또한 클러스터 업그레이드 중에 한 클러스터에서 다른 클러스터로 교체하는 데 도움이 될 수 있습니다.
- EC2 내에서 로드 밸런서로 이동하여 로드 밸런서 생성을 클릭합니다.
- 애플리케이션 로드 밸런서를 선택하고 계속을 클릭합니다.
- "1단계: 로드 밸런서 구성"의 경우:
- 로드 밸런서의 이름(예: "couchbase-primary")을 입력합니다.
- 스키마는 "내부"여야 합니다. 참고: 내부를 선택하는 것은 보안을 위해 매우 중요합니다.
- 포트를 80에서 8091로 변경합니다.
- 카우치베이스가 실행 중인 VPC와 서브넷을 선택합니다. Couchbase가 단일 가용 영역에만 있는 경우 ALB 요구 사항을 충족하기 위해 AZ를 하나 더 선택합니다.
- "다음"을 클릭합니다: 보안 설정 구성"을 클릭합니다.
- 2단계에는 설정이 없습니다. "다음: 보안 그룹 구성"을 클릭합니다.
- 들어오는 트래픽에 대해 TCP 포트 8091을 열어 ALB에 대한 새 보안 그룹을 생성하고 "다음"을 클릭합니다: 라우팅 구성"을 클릭합니다.
- ALB용으로 생성된 새 EC2 보안 그룹의 트래픽에 대해 포트 8091을 열도록 Couchbase EC2 보안 그룹을 편집해야 할 수도 있습니다.
- 이 값으로 새 타겟 그룹을 만듭니다:
- 이름: "couchbase-primary"
- 프로토콜: "HTTP"
- 포트: "8091"
- 상태 확인 프로토콜: "HTTP"
- 상태 확인 경로: "/ui/index.html"
- "다음"을 클릭합니다: 대상 등록"
- '5단계: 대상 등록'의 경우:
- 클러스터의 모든 Couchbase 인스턴스를 선택합니다.
- '등록에 추가'를 클릭하여 상단의 목록에 추가합니다.
- "다음: 검토"를 클릭합니다.
- 만들기를 클릭합니다.
- ALB가 생성되면 나중에 사용할 'DNS 이름'을 얻을 수 있습니다.
그렇다면 ALB의 비용과 성능은 어떨까요?
사실 이 구성의 비용은 비용과 성능 측면에서 무시할 수 있는 수준입니다. 로드 밸런서는 클러스터 구성을 클라이언트와 통신하는 데만 사용됩니다. 이 구성에는 클러스터의 모든 노드에 대한 정보와 노드에 연결하는 방법이 포함됩니다.
부트스트랩이 완료되면 클라이언트는 클러스터 노드에 직접 연결됩니다. 모든 키/값 및 쿼리 작업은 로드 밸런서를 우회하여 노드로 직접 전달됩니다. 즉, 이러한 작업에 대한 재정적 비용이나 성능 비용이 발생하지 않습니다.
쿠버네티스에서 부트스트랩을 더욱 쉽게 만들기
이제 구성에서 단일 서버 URL을 사용하여 마이크로서비스를 부트스트랩할 수 있습니다. 이는 클러스터가 변경됨에 따라 각 서버가 시간이 지남에 따라 변경될 수 있는 여러 서버를 구성에 나열하는 것보다 훨씬 쉽습니다.
하지만 우리가 사용해야 하는 URL은 여전히 번거롭습니다: 내부 카우치베이스-123456789.us-east-1.elb.amazonaws.com. 이 과정을 더 간소화할 수 있는 방법이 있을까요? 정답은 '예'입니다!
쿠버네티스는 DNS를 사용하여 서비스 검색을 지원할 수도 있다. 이 경우, 우리는 서비스 을 외부 이름 유형으로 설정합니다. 이렇게 하면 트래픽을 외부 DNS 이름으로 전달하는 CNAME 레코드가 효과적으로 생성됩니다. 이 레코드는 쿠버네티스 클러스터 내의 파드에만 존재하므로 클러스터 외부에는 영향을 미치지 않습니다.
- 다음과 같은 내용으로 "couchbase-primary.yaml"이라는 파일을 만듭니다:종류: 서비스
API 버전: v1
메타데이터:
# 클러스터에 액세스하기 위한 DNS 이름입니다.
이름: 카우치베이스-기본
사양:
유형: 외부이름
#는 아래 ALB의 DNS 이름을 대체합니다.
외부 이름: 내부 카우치베이스-123456789.us-east-1.elb.amazonaws.com - yaml 파일에서 서비스 생성:kubectl apply -f couchbase-primary.yaml
다 끝났습니다! 이제 클러스터에서 실행 중인 모든 마이크로서비스를 하나의 간단한 URL로 부트스트랩할 수 있습니다:
http://couchbase-primary:8091/. 다른 네임스페이스의 파드에서 액세스해야 하는 경우, 예를 들어 다음과 같이 네임스페이스를 추가하면 된다. http://couchbase-primary.default:8091/. 다른 도메인 이름을 사용하여 필요한 만큼 클러스터를 등록할 수도 있습니다.
