카우치베이스 쿠버네티스 테스트 팀의 목표는 엄격하게 자율 운영자 (AO)를 지정하고 AO가 관리하는 기본 Couchbase Server 클러스터를 인증합니다. 관리되는 CB 클러스터의 적절한 생성, 관리 및 장애 복구에 대해 AO를 테스트합니다. 또한, CB 클러스터, 서비스 및 기능 자체가 모두 올바르게 작동하는지 테스트합니다. 이전에는 온프레미스에서 사용자 정의 Kubernetes 및 Openshift 클러스터에 대한 모든 테스트를 수행했지만 이제는 클라우드의 여러 Kubernetes 서비스에서 AO를 인증하고 있습니다. 첫 번째 인증은 Azure Kubernetes Service(AKS)에 대한 인증입니다. AKS로 테스트를 실행하면서 사용자 지정 온프레미스 환경과 비교하여 테스트 환경을 만들고 구성하는 데 새로운 도전 과제가 발생했습니다. 이 게시물에서는 이러한 과제에 대한 해결책을 중점적으로 설명합니다.
*참고 - Couchbase Autonomous Operator는 아직 Azure AKS에서 개발자 프리뷰 중이며, 2019년 1분기에 예정된 1.2 릴리스에서 GA를 목표로 하고 있습니다.
쿠버네티스 테스트 프레임워크에 대한 요구 사항
테스트 프레임워크는 필요한 클러스터 생성부터 영구 볼륨을 사용한 멀티노드 장애 복구에 이르기까지 다양한 유형의 테스트를 실행합니다. 또한 두 개의 CB 클러스터가 어디에 위치하는지에 따라 정의된 3가지 토폴로지(단일 K8 클러스터, 서로 다른 두 개의 K8 클러스터, 하나의 K8에서 하나의 비-K8)에서 XDCR을 테스트합니다. 전체 테스트 스위트를 실행하려면 (1) XDCR을 허용하는 두 개의 별도 AKS 클러스터를 설정해야 합니다. (2) 테스트 프레임워크가 공용 인터넷을 통해 각 AKS 클러스터와 상호 작용할 수 있어야 합니다. (3) 또한 공용 인터넷에서 AKS 클러스터 내의 CB 클러스터에 연결할 수 있어야 합니다. (4) 퍼시스턴트 볼륨 테스트를 위해 AKS에 동적 스토리지 클래스가 하나 이상 있어야 합니다. 다음 섹션에서는 이러한 요구 사항을 충족하기 위해 취한 단계를 설명합니다.
XDCR-레디 AKS 클러스터 만들기
XDCR이 CB 클러스터 간(K8 또는 기타)에서 작동하기 위한 주요 장애물은 두 CB 클러스터 사이에 레이어 3 경로가 존재해야 한다는 것입니다. CB 노드는 AKS 클러스터의 네트워크 구성에 따라 K8s API에서 제공하는 내부 IP 주소를 사용합니다. 기본적으로 두 AKS 클러스터는 동일한 내부 주소 범위를 사용하므로 발신 XDCR 트래픽이 다른 AKS 클러스터의 목적지에 도달하지 못합니다. 해결책은 내부 네트워크가 피어링할 수 있도록 두 AKS 클러스터를 설정하는 것입니다. 피어링을 통해 각 AKS 클러스터의 CB 클러스터가 내부 IP 주소를 사용하여 올바르게 통신할 수 있습니다. AKS에서 네트워크 피어링을 설정하려면 각 AKS 클러스터에 사용할 겹치지 않는 네트워크 접두사를 결정해야 합니다. 그런 다음 이러한 접두사를 기반으로 Kubernetes 노드를 위한 클러스터 서브넷, 클러스터 서브넷과 겹치지 않는 Kubernetes 파드를 위한 서비스 서브넷, 각 서비스 서브넷의 DNS 주소 및 Docker 오버레이 네트워크를 결정해야 합니다. 다음 표는 각 AKS 클러스터에 적합한 네트워크 구성을 보여줍니다.
| 클러스터 | AKS-cluster-1 | AKS-cluster-2 |
| 접두사 | 10.0.0.0/12 | 10.16.0.0/12 |
| 클러스터 서브넷 | 10.8.0.0/16 | 10.24.0.0/16 |
| 서비스 서브넷 | 10.0.0.0/16 | 10.16.0.0/16 |
| DNS 주소 | 10.0.0.10 | 10.16.0.10 |
| 도커 브리지 주소 | 172.17.0.1/16 | 172.17.0.1/16 |
이제 적절한 네트워크 구성이 결정되었으므로 Azure 포털에서 이 두 개의 AKS 클러스터를 만들 수 있습니다. 각 클러스터를 만드는 것은 대부분 여기에서 Azure가 제공하는 지침을 따릅니다, https://docs.microsoft.com/en-us/azure/aks/kubernetes-walkthrough-portal [1]과 동일하며, 유일한 차이점은 네트워크 설정(3단계)에 있습니다. 이 단계는 AKS-cluster-1을 위한 단계이며 앞서 결정한 해당 네트워크 값을 사용합니다. AKS-cluster-2의 단계는 동일하며, AKS-cluster-2 네트워크 값을 사용합니다. 네트워킹 단계에 도달하면 HTTP 애플리케이션 라우팅을 사용 설정하고 고급 네트워크 구성을 선택합니다.
앞서 결정한 접두사 및 클러스터 서브넷을 사용하여 새 가상 네트워크를 만듭니다.
네트워킹 탭의 나머지 필드에 서비스 서브넷, DNS 주소, Docker 오버레이 값을 입력합니다.
설명서에 따라 AKS 클러스터 설정을 진행합니다. AKS-cluster-1이 배포되는 동안 동일한 단계에 따라 AKS-cluster-2를 설정합니다.
이제 적절한 네트워크 구성을 갖춘 두 개의 AKS 클러스터가 있으므로 네트워크 피어링을 설정할 수 있습니다. UI에서 AKS-cluster-1에 대해 생성한 가상 네트워크 AKS-cluster-1-vnet으로 이동하여 피어링 탭을 선택하고 추가를 클릭하여 새 피어링을 생성합니다.
피어링에 AKS-cluster-1-AKS-cluster-2와 같은 이름을 지정하고 가상 네트워크로 AKS-cluster-2-vnet을 선택합니다.
피어링하려면 두 네트워크가 모두 피어링해야 하므로 비슷한 방식으로 AKS 클러스터-2-vnet에서 AKS 클러스터-1-vnet으로의 피어링도 설정해야 합니다. 완료되면 두 AKS 클러스터는 XDCR로 CB 클러스터를 호스팅할 수 있습니다.
공용 인터넷을 통한 AKS Kubernetes API 액세스
테스트 프레임워크는 AKS 외부에서 실행되므로, 각 AKS 클러스터에 대해 Kubernetes API에 대한 외부 액세스를 설정해야 합니다. 이 과정은 비교적 간단합니다. 각 AKS 클러스터에 대한 네트워크 보안 그룹 인바운드 및 아웃바운드 규칙을 수정해야 합니다. AKS-cluster-1에 대한 네트워크 보안 그룹으로 이동하여 인바운드 보안 규칙을 선택한 다음 추가를 선택하여 새 규칙을 만듭니다. 설정을 간단하게 하려면 모든 소스 IP/포트와 대상 IP/포트를 허용하는 이 규칙을 만드세요. 이 규칙에 우선순위 번호 102를 부여합니다.
이제 아웃바운드 보안 규칙에 대해서도 동일하게 수행합니다. 그런 다음 AKS-cluster-2에 대한 인바운드 및 아웃바운드 보안 규칙을 유사하게 수정합니다.
다음 단계는 각 AKS 클러스터에 대한 kubeconfig 파일(자격 증명)을 가져오는 것입니다. 이 파일은 테스트 프레임워크에서 Kubernetes API에 액세스하고 상호 작용하는 데 사용됩니다. 여기에 설명된 대로 Azure CLI가 로컬에 설치되어 있는지 확인하세요: https://docs.microsoft.com/en-us/cli/azure/install-azure-cli?view=azure-cli-latest [2]. 또한 여기에 설명된 대로 로컬에 kubectl을 설치해야 한다: https://kubernetes.io/docs/tasks/tools/install-kubectl/ [3]. 둘 다 설치되어 작동 중이면 다음 명령을 실행하여 AKS-cluster-1 및 AKS-cluster-2에 대한 kubeconfig 파일을 내려받습니다:
|
1 2 |
az aks get-자격 증명 --리소스-그룹 AKS-클러스터-1 --이름 aks-클러스터-1 az aks get-자격 증명 --리소스-그룹 AKS-클러스터-2 --이름 aks-클러스터-2 |
클러스터 자격 증명은 ~/.kube/config 파일에 저장됩니다. 테스트 프레임워크에서는 각 클러스터의 자격 증명을 자체 파일로 분리합니다: ~/.kube/config_aks_cluster_1 및 ~/.kube/config_aks_cluster_2.
AKS에서 CB 포드 액세스
이 시점에서 테스트 프레임워크는 두 개의 AKS 클러스터의 Kubernetes API와 상호 작용할 수 있습니다. 이를 통해 테스트 프레임워크는 AO를 설치하고 테스트를 위한 AO 관리형 CB 클러스터를 생성할 수 있습니다. 그러나 테스트 프레임워크는 대부분의 테스트에서 REST 호출을 통해 CB 포드와 상호 작용해야 합니다. 이전에는 테스트 프레임워크에서 AO가 CB REST API를 Kubernetes 노드포트 서비스로 노출하도록 했습니다. 이 서비스는 쿠버네티스 노드에 포트를 생성하여 트래픽을 쿠버네티스 노드 내부의 CB 포드 REST API 포트로 전달합니다. 이러한 서비스는 Kubernetes 노드의 개인 IP 주소를 통해 액세스할 수 있었습니다. 온프레미스 Kubernetes 클러스터와 테스트 프레임워크는 동일한 사설 네트워크에 있었기 때문에 문제가 되지 않았습니다. 그러나 AKS를 사용하면 테스트 프레임워크가 AKS Kubernetes 노드와 코로케이션되지 않으며 이러한 노드의 사설 IP를 사용하는 노드 포트 서비스에 액세스할 수 없습니다. 이에 대한 해결책은 간단합니다. AO가 CB 클러스터와 노드포트 서비스를 생성한 후 테스트 프레임워크가 노드포트 서비스 사양을 변경하도록 합니다. Type 필드를 LoadBalancer로 변경합니다. 이 작업은 다음 Go 코드에서 수행됩니다:
노드포트 서비스 유형이 LoadBalancer로 변경되면 AKS는 서비스에 공인 IP를 할당합니다. 이 새로운 공인 IP를 사용하여 테스트 프레임워크는 AKS 외부에서도 CB REST API를 성공적으로 호출할 수 있습니다. 다음 주요 릴리즈인 Autonomous Operator 1.2에서는 AO가 노드포트 서비스 또는 로드 밸런서 서비스를 노출하는 옵션을 갖게 되며, AO가 배포한 서비스가 변경되면 AO가 서비스를 다시 조정하게 됩니다. 따라서 테스트 프레임워크에서 사용하는 솔루션은 일시적인 것이며, 향후에는 독립형 로드 밸런서 서비스를 생성하고 AO를 사용하여 로드 밸런서를 생성하는 방식으로 전환할 예정입니다.
동적 영구 볼륨 사용
AO를 사용하면 CB 클러스터가 동적으로 프로비저닝된 퍼시스턴트 볼륨에 바인딩할 수 있습니다. 따라서 하나 이상의 CB 포드가 다운되는 경우 데이터 손실에 대해 CB 클러스터의 복원력이 매우 뛰어납니다. 테스트 프레임워크에는 퍼시스턴트 볼륨에 데이터를 저장하는 CB 포드와 관련된 복잡한 장애 시나리오가 많이 있습니다. 일부 장애 시나리오에서는 AO가 장애가 발생한 파드의 퍼시스턴트 볼륨을 사용하여 다른 Kubernetes 노드에서 장애가 발생한 파드를 재시작합니다. 따라서 한 쿠버네티스 노드에서 다른 노드로 이동할 수 있는 퍼시스턴트 볼륨을 사용해야 합니다. AKS에서는 영구 볼륨에 두 가지 유형의 스토리지 클래스를 사용할 수 있습니다: AzureDisk와 AzureFile. AKS가 제공하는 기본 스토리지 클래스는 AzureDisk이지만, 이 스토리지 클래스는 이동 가능한 퍼시스턴트 볼륨을 생성할 수 없다. AzureFile은 이동 가능한 영구 볼륨을 허용하는 방식으로 구현되어 있으며 AKS에서 테스트하는 스토리지 클래스 솔루션이 될 것입니다. Azure는 여기에서 AzureFile 스토리지 클래스를 설정하는 지침을 제공합니다:
https://docs.microsoft.com/en-us/azure/aks/azure-files-dynamic-pv [4].
설정하려면 먼저 다음 계정으로 스토리지 계정을 만들어야 합니다:
|
1 2 3 4 |
az aks show --리소스-그룹 AKS-클러스터-1 --이름 AKS-클러스터-1 --쿼리 노드 리소스 그룹 -o tsv MC_AKS-클러스터-1_aks-클러스터-1_westus az 스토리지 계정 create --리소스-그룹 MC_AKS-클러스터-1_aks-클러스터-1_westus --이름 mystorageaccount --sku Standard_LRS |
그런 다음 스토리지 클래스, 클러스터 역할 및 클러스터 역할 바인딩 사양을 Kubernetes에 제출합니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
##azure-file-sc.yaml 종류:StorageClass apiVersion: 스토리지.k8s.io/v1 메타데이터: 이름: azurefile 프로비저너: 쿠버네티스.io/azure-파일 마운트 옵션: - dir_mode=0777 - file_mode=0777 - uid=1000 - gid=1000 매개변수: skuName: 표준_LRS 저장소 계정: mystorageaccount |
|
1 |
kubectl 신청하기 -f azure-파일-sc.yaml |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
##azure-pvc-roles.yaml --- apiVersion: rbac.권한 부여.k8s.io/v1 종류: 클러스터 역할 메타데이터: 이름: 시스템:azure-클라우드-공급자 규칙: - apiGroups: [''] 리소스: ['비밀'] 동사: ['get','create'] --- apiVersion: rbac.권한 부여.k8s.io/v1 종류: 클러스터 역할 바인딩 메타데이터: 이름: 시스템:azure-클라우드-공급자 역할 참조: 종류: 클러스터 역할 apiGroup: rbac.권한 부여.k8s.io 이름: 시스템:azure-클라우드-공급자 과목: - 종류: 서비스 계정< 이름: 지속적-볼륨-바인더 네임스페이스: kube-시스템 |
|
1 |
kubectl 신청하기 -f azure-pvc-역할.yaml |
이제 AKS-cluster-1에서 AzureFile 스토리지 클래스를 설정하고 사용할 준비가 되었습니다. AKS-cluster-2에 대해서도 동일한 프로세스를 수행해야 합니다.
연산자 테스트
이 시점에서 우리는 동적 영구 볼륨을 활성화한 상태에서 퍼블릭 인터넷(Kubernetes API 및 CB REST API)에서 액세스할 수 있는 AO: 2 XDCR 지원 Kubernetes 클러스터에 대한 전체 테스트 제품군을 실행하는 데 필요한 모든 것을 갖추었습니다. 초기 테스트 중에 몇 가지 이상한 오류가 발견되었습니다. 이러한 오류는 대부분 테스트 프레임워크의 시간 초과로 인해 발생했으며, 원인을 정확히 파악할 수 있었습니다: AKS는 온프레미스 Kubernetes 클러스터에 비해 매우 느립니다. CB 포드를 스핀업하는 데 걸리는 시간은 최대 5배 더 오래 걸릴 수 있습니다. 이 문제를 해결하기 위해 사용 중인 Kubernetes 클러스터 유형에 따라 가변 시간 제한을 만들어야 했습니다. 그 후 테스트는 모두 정상적으로 실행되었고 AO 또는 CB 클러스터와 관련된 심각한 문제는 발견되지 않았습니다.
결론
최근 Couchbase 테스트 팀은 AKS, EKS, GCP와 같은 기본 클라우드 제공 Kubernetes 서비스에서 사용하기 위해 AO를 인증하는 데 집중하고 있습니다. 우리가 집중한 첫 번째 클라우드는 AKS였으며, 클라우드별 네트워크 구성, 접근성, 스토리지 클래스 생성 등 몇 가지 플랫폼별 과제가 있었습니다. 하지만 이러한 문제를 해결하고 이제 AKS 클러스터를 사용하여 자동화된 테스트 프레임워크를 실행할 수 있게 되었습니다. 앞으로 몇 달 동안 다른 클라우드에 대한 인증 작업을 계속할 예정이지만, 그 동안은 AKS를 즐겨보세요.
참조:
[1] https://docs.microsoft.com/en-us/azure/aks/kubernetes-walkthrough-portal
[2] https://docs.microsoft.com/en-us/cli/azure/install-azure-cli?view=azure-cli-latest
[3] https://kubernetes.io/docs/tasks/tools/install-kubectl/
[4] https://docs.microsoft.com/en-us/azure/aks/azure-files-dynamic-pv
