1.2.0 이전 버전에서는 클라이언트와 상호 작용하는 기능이 제한적이었습니다. 카우치베이스 데이터 플랫폼은 동일한 Kubernetes 클러스터에 있는 SDK에서만 사용할 수 있었습니다. 데이터센터 간 복제(XDCR)는 동일한 Kubernetes 클러스터 내에서 또는 보안 터널을 통해서만 사용할 수 있었습니다. 가상 사설 네트워크(VPN)는 이러한 터널의 한 예입니다. 또한, 사용자 인터페이스(UI)에 대한 액세스는 Kubernetes 포트 포워딩을 사용해야 합니다.
자율 운영자 버전 1.2.0은 이러한 한계를 해결하기 위해 새로운 네트워크 기능을 도입했습니다. 최종 목표는 더 다양한 네트워크 아키텍처를 지원하여 사용자를 확대하는 것입니다. 애플리케이션이 서버리스 기능으로 실행될 수 있으므로 인터넷을 통해 Couchbase 서버와 통신해야 할 수 있습니다. 이러한 유형의 사용 사례가 바로 저희가 지원하고 있는 것입니다.
쿠버네티스 네트워크 아키텍처
쿠버네티스 네트워킹에 사용할 수 있는 옵션은 다양합니다. 인터페이스는 쿠버네티스가 제공하는 모든 것이므로 써드파티가 자체 구현을 제공합니다. 그 결과 각 솔루션에는 장단점이 있습니다. 네트워킹 선택은 모든 제공자에서 작동해야 하므로 솔루션을 살펴보기 전에 일반적인 네트워크 유형을 설명하겠습니다.
라우팅된 네트워크
라우팅된 네트워크는 쿠버네티스의 관점에서 가장 간단하게 설명할 수 있는 개념입니다. 호스트는 동일한 서브넷 내에서 실행되고 대상 하드웨어 주소를 직접 지정할 수 있기 때문에 서로 통신할 수 있습니다. 이를 레이어 2 네트워킹.
파드는 일반적으로 실행되는 호스트와 별도의 서브넷에서 실행된다. 이 서브넷은 각 호스트 간에 더 세분화됩니다.
한 호스트의 파드에서 보낸 메시지는 동일한 서브넷에 존재하지 않기 때문에 다른 호스트에서 대상 파드를 찾는 방법을 알 수 없습니다. 한 서브넷의 메시지는 라우터를 통해 한 서브넷에서 다른 서브넷으로 이동할 수 있습니다. 호스트의 메시지는 일반적으로 대상 주소가 직접 연결된 서브넷에 있지 않을 때 서브넷의 라우터로 전송됩니다.
라우팅
라우터는 두 가지 방법 중 하나로 메시지를 처리합니다. 직접 연결된 서브넷의 경우 메시지는 올바른 네트워크 포트로만 전송되고 나머지는 레이어 2 네트워킹이 처리합니다. 직접 연결되지 않은 서브넷의 경우, 서브넷이 직접 연결된 다른 라우터로 메시지를 전달할 수 있습니다. 이를 레이어 3 네트워킹.
라우터는 라우팅 테이블에서 이 라우팅 정보를 관리합니다. 라우팅 테이블은 단순히 서브넷에서 직접 연결된 네트워크의 물리적 인터페이스 또는 다른 라우터로의 매핑 목록입니다.
다른 파드로 보내는 메시지가 파드가 실행 중인 호스트에 의해 포착될 수 있습니다. 메시지 대상 주소를 알 수 없으므로 라우터로 전달됩니다. 라우터는 라우팅 테이블에서 대상 주소를 알고 있으므로 메시지를 올바른 호스트로 전달합니다. 마지막으로, 메시지가 대상 파드로 전송됩니다. 쿠버네티스 클러스터 외부에서 보낸 메시지는 라우터로 전송되기만 하면 대상 파드에 도달할 수 있습니다.
라우팅된 네트워크는 매우 간단합니다. 또한 라우터로 이동한 다음 대상 호스트로 이동하는 과정에서 약간의 성능 저하가 발생할 수 있습니다. 보다 지능적인 솔루션은 iBGP 그리고 경로 리플렉터 을 사용하여 이 추가 홉을 제거합니다. 파드를 서로 격리하는 것은 방화벽 규칙을 사용하여 수행해야 합니다.
오버레이 네트워크
오버레이 네트워크는 다음과 같은 프로토콜로 파드 간 메시지를 캡슐화한다. GRE 또는 VXLAN. 각 호스트는 자신의 파드 서브넷을 광고한다. 그러면 호스트는 이러한 광고를 구독하고 대상 파드에 도달하기 위해 메시지를 직접 보낼 호스트를 알 수 있습니다. 라우터로 전송하는 것보다 빠르지만 캡슐화 오버헤드로 인해 이점이 상쇄될 수 있습니다.
또한 캡슐화를 통해 서로 다른 파드를 서로 다른 가상 네트워크. 이는 파드 그룹을 물리적으로 분리할 수 있는 강력한 보안 모델을 제공합니다. 그러나 오버레이 네트워크 간에 라우터가 여전히 필요하다는 것을 의미합니다. 이러한 라우터에는 자체 방화벽 규칙이 필요합니다.
클러스터 외부에서 파드를 주소 지정하는 것은 매우 어렵습니다. 라우팅된 네트워크에서는 라우터로 포워딩만 하면 나머지는 라우터가 처리합니다. 오버레이에서는 오버레이로 터널링할 수 있는 간단한 메커니즘이 없습니다.
노드 포트
두 네트워크 유형 모두에서 파드와 외부 통신을 위한 한 가지 공통 메커니즘은 쿠버네티스 노드 포트이다. 자율 운영자가 생성하는 모든 파드에 대해 노드 포트 서비스도 생성합니다. 서비스에 대해 정의한 모든 포트에는 기본 호스트에 임의의 포트가 할당됩니다.
두 개의 파드가 동일한 포트 번호를 노출할 수 있으므로 노드 포트는 무작위여야 한다. 두 파드에서 이 포트를 노드 포트로 사용하는 경우 충돌이 발생할 수 있습니다. 기본 호스트와 호스트 포트를 주소 지정하여 특정 파드의 포트를 주소 지정할 수 있습니다. 호스트는 메시지를 처리합니다. 리디렉션 를 올바른 목적지로 이동합니다.
노드 포트는 오버레이 네트워크를 사용하는지 여부에 관계없이 파드를 주소 지정하는 일반적인 메커니즘을 제공합니다. 기본 노드에 주소를 지정하고 있기 때문에, 쿠버네티스 외부에서 여기에 연결하는 것은 단순히 쿠버네티스 노드가 상주하는 라우팅된 네트워크로 패킷을 라우팅하는 경우입니다.
XDCR 설정
노드 포트는 서로 다른 두 개의 쿠버네티스 클러스터에 있는 두 개의 Couchbase 클러스터 간에 XDCR 연결을 설정하는 기초를 형성합니다. 노드 포트가 할당되면 자율 운영자는 이를 Couchbase 서버에 알립니다. 외부에서 접속하는 클라이언트는 노드 포트에 연결하고 Couchbase 서버는 서비스별 노드 IP 주소와 노드 포트 맵으로 응답합니다. XDCR 클라이언트는 이 맵을 사용하여 문서를 스트리밍할 때 개별 vBuckets에 액세스합니다.
자율 운영자가 할 수 없는 유일한 일은 두 개의 Kubernetes 호스트 네트워크 간에 레이어 3 연결을 제공하는 것입니다. 두 네트워크 간에 피어링(VPN)을 생성하고 경로와 방화벽 규칙을 추가하는 것은 대부분의 클라우드 제공자에게 필요한 전부입니다.
새로운 자율 운영자 개선 사항
저희는 Kubernetes 네트워크 모델의 범위 내에서 작업하는 견고한 기반을 갖추고 있습니다. VPN을 통해 안전하지만 개선할 수 있는 부분이 있습니다.
외부 클라이언트 액세스
VPN 터널을 활용하여 원격 Kubernetes 호스트 네트워크에 액세스하는 것은 불가능하거나 바람직하지 않을 수 있습니다. 특히 네트워크를 제어할 수 없는 관리형 서비스의 경우 더욱 그렇습니다.
이 문제를 해결하려면 인터넷에 파드를 배치해야 합니다. 오픈시프트 경로와 일반 인그레스는 HTTP 트래픽에 대해서만 작동하며 구성하기가 어렵습니다. 대신 Couchbase 서버 포드별로 로드 밸런서 서비스를 생성하는 방법을 선택했습니다. 모든 TCP 연결을 지원할 수 있으며, 또한 로드 밸런서 IP 주소가 포드별로 고유하므로 기본 포트 번호를 사용할 수 있습니다. 모든 주요 클라우드 제공업체는 로드 밸런서 서비스를 제공합니다.
기존 노드 포트 기반 XDCR 연결은 계속 지원되며 기본값으로 사용됩니다.
외부 UI 액세스
이제 개별 파드와 마찬가지로 UI도 로드 밸런서 서비스를 통해 공개적으로 처리할 수 있습니다. 따라서 Couchbase 데이터 플랫폼 배포를 훨씬 더 간편하게 관리할 수 있습니다.
엔드투엔드 암호화
퍼블릭 인터넷에 무엇이든 올리는 것은 위험이 따릅니다. 특히 데이터베이스의 경우 더욱 그러하므로 TLS 사용을 의무화합니다. 일반 텍스트 포트는 노출될 수 없습니다. 이렇게 하면 사용자 자격 증명과 데이터가 도청기로부터 안전하게 보호됩니다.
서버 인증서가 연결 클라이언트에 제공되면 연결한 주소가 해당 인증서에 유효한지 확인합니다. 이 작업은 다음을 사용하여 수행됩니다. 제목 대체 이름. 와일드카드 DNS 기반 대체 이름만 지원하며 IP 기반은 지원하지 않습니다. 또한 로드밸런서 서비스의 IP 기반 주소는 복구 시 주소가 안정적이지 않기 때문에 사용할 수 없습니다.
클러스터의 유효한 이름은 다음과 같습니다. *.my-cluster.example.com. 이것은 와일드카드이며 다음 경우에 유효합니다. server0.my-cluster.example.com 그리고 server1.my-cluster.example.com. 인증서는 자율 운영자가 클러스터 수명 주기에서 생성하는 모든 노드에 유효합니다.
클라이언트가 볼 수 있도록 DNS 이름을 로드 밸런서 IP 주소에 매핑하는 DNS 리소스 레코드를 만들어야 합니다. 필요한 DNS 이름은 자율 운영자에 의해 로드 밸런서 서비스에 주석이 추가됩니다. 이러한 이름은 타사에 의해 클라우드 DNS 공급업체에 동기화됩니다. 컨트롤러.
예
다이어그램은 이러한 모든 기능이 어떻게 상호 연결되는지 보여줍니다.
- 클라이언트는 SDK든 XCDR이든 DNS 주소를 사용하여 연결을 초기화합니다. https://cb0.cb0.us-east-1.example.com:18091. 이는 로드밸런서 IP 주소인 185.64.232.18. 이 DNS 주소는 로드 밸런서 서비스 사양과 해당 공용 IP 주소에서 생성됩니다.
- 그런 다음 클라이언트는 Couchbase 클러스터에 대한 TCP 연결을 엽니다. 이렇게 하면 먼저 인터넷을 통해 고객 엣지 라우터로 연결됩니다.
- 그런 다음 패킷은 다음 주소의 로드밸런서로 전달됩니다. 185.64.232.18.
- 그런 다음 로드밸런서는 패킷을 포트에 해당하는 노드 포트로 SNAT합니다. 18091 를 설정합니다. 그런 다음 노드는 패킷을 포트에 SNAT합니다. 18091 포드 자체에 있습니다.
- TCP 연결이 설정되면 클라이언트는 서버와 TLS 핸드셰이크를 시작합니다. 서버는 인증서를 클라이언트에 반환합니다. 클라이언트는 인증서가 의도한 수신자에게 유효한지 확인합니다. 주소 cb0.cb0.us-east-1.example.com 와일드카드 제목 대체 이름과 일치합니다. *.cb0.us-east-1.example.com. 클라이언트 부트스트랩은 평소와 같이 계속됩니다.
다이어그램에는 포함되어 있지 않지만, 카우치베이스 서버는 대상 파드를 다음과 같이 참조한다는 점을 언급할 필요가 있다. cb0.cb0.default.svc내부 DNS 이름입니다. 클라이언트는 클러스터 멤버를 멤버 주소에 매핑할 때 이 이름을 확인할 수 없습니다. 운영자는 확인할 수 있는 대체 멤버 주소를 채웁니다.
클라이언트는 대체 주소를 알고 있어야 합니다. 호환되는 SDK는 운영자 문서에 설명되어 있습니다. XDCR은 카우치베이스 서버 버전 5.5.3+ 및 6.0.1+에서 지원됩니다.
결론
Couchbase 서버 인스턴스를 공개적으로 주소 지정할 수 있는 기능은 강력한 도구입니다. 네트워크 구성을 간소화합니다. 클라우드 제공업체 간에 VPN 터널을 설정하는 것이 어렵거나 불가능할 수 있는데, 이를 완전히 피할 수 있습니다. UI 콘솔에 액세스하는 프로세스를 간소화할 뿐만 아니라 XDCR을 포함한 클라이언트가 전 세계 어디에서나 연결할 수 있습니다.
이로 인해 Kubernetes 기반 Couchbase 배포를 외부 서비스와 통합할 수 있는 흥미롭고 새로운 가능성이 열리게 됩니다. 이러한 예로는 기본 네트워크 아키텍처를 제어할 수 없는 서비스형 플랫폼이 포함될 수 있습니다.
- 사용해 보세요: https://www.couchbase.com/downloads
- 지원 포럼: https://www.couchbase.com/forums/c/couchbase-server/Kubernetes
- 문서화: https://docs.couchbase.com/operator/1.2/whats-new.html
자세히 보기
자율 운영자 1.2.0 심층 분석: https://www.couchbase.com/blog/deep-dive-couchbase-autonomous-operator-1-2-0
회로 VPN