클라우드 네이티브 운영자 2.3.0의 플랫폼 자체 인증

모든 환경은 저희의 소유입니다!

카우치베이스가 인증하는 것

커머디티 클라우드 플랫폼은 카우치베이스 자율 운영자 팀에서 모든 것이 작동하는지 테스트하는 데 사용됩니다. 이러한 플랫폼은 Kubernetes 에코시스템 내에서 어디에나 존재하며 간단하고 일반적인 방식으로 프로비저닝 및 프로비저닝 해제할 수 있기 때문에 활용됩니다. Amazon EKS, Google GKE, Microsoft AKS 및 Red Hat OpenShift(AWS 기반)가 주요 조합입니다. 이러한 플랫폼은 대부분 다음과 같은 일반적인 기술을 사용하여 온디맨드 방식으로 쉽게 생성할 수 있습니다. 해시코프 테라폼.

작은 하위 집합이죠?

짧은 대답은 '그렇다'와 '아니다'입니다. 한편으로, 이러한 빅4 플랫폼의 인증은 99%의 사용자(만들어진 숫자!)를 대상으로 합니다. 테스트는 시간과 비용 측면에서 무료로 제공되지 않기 때문에 순전히 비즈니스 관점에서 볼 때 가장 큰 효과를 얻을 수 있습니다.

반면에 수십 개의 다양한 플랫폼 공급업체를 사용할 수 있으며, 모두 인증된 CNCF 소프트웨어 적합성 프로그램. 쿠버네티스 준수는 파드가 어디에서 실행되든 파드이고 파드처럼 동작하도록 보장하므로, 벤더 종속성을 깨뜨리고 특정 정도. 실제로 이러한 제약 조건이 주어지고 운영자가 일반 리소스만 사용하는 경우 운영자가 이러한 플랫폼 중 어느 플랫폼에서든 수정할 필요 없이 실행될 것이라는 확신이 높습니다.

따라서 자체 인증은 필요하지 않겠죠?

틀렸어요. 앞서 "어느 정도"라고 말한 것은 의도적인 표현이었습니다. 쿠버네티스의 핵심은 형식과 동작이 잘 정의되어 있지만, 특정 부분, 즉 분산 데이터베이스 운영의 기본이 되는 스토리지와 네트워킹은 특정 플랫폼에 맞게 커스터마이징할 수 있습니다.

따라서 최종 사용자가 특정 플랫폼이 Couchbase에서 작동하도록 인증을 받기를 원할 때 이해할 수 있습니다. 과거에는 요청이 있을 때 플랫폼을 인증하기 위해 노력해 왔습니다. Rancher와 같은 일부 플랫폼의 경우 이는 간단합니다. $1,000,000 스토리지 어플라이언스를 처리해야 한다고 가정해 보겠습니다. 이 경우 데이터 센터, 서버, 스위치, 라우터, 전력, 냉각 등이 필요하기 때문에 재정적으로 실현 불가능합니다. 당연히 실용적이고 확장 가능한 솔루션이 아닙니다. 특히 플랫폼이 배인 경우에는 더욱 심각합니다!

자체 인증 소개

자체 인증은 플랫폼 인증의 모든 문제에 대한 해답입니다. 문제를 살펴보면, Acme Cloud를 인증하려면 이 클라우드에서 Kubernetes를 프로비저닝한 다음 네이티브 API를 사용하여 테스트 스위트를 실행해야 합니다.

논리적으로 다음 단계는 해당 테스트 스위트를 가져와서 모든 Kubernetes 플랫폼에서 누구나 사용할 수 있도록 컨테이너로 패키징하는 것입니다. 저희가 여러분에게 제공하는 것은 모든 인증 작업에 내부적으로 사용하는 것입니다. 분산 인증!

일화적으로, 그렇지 않았습니다. 그 쉬워졌습니다. 네트워크 모델을 근본적으로 변경해야 했습니다(그 과정에서 더 간단하고 빠르게 만들었습니다). 또한 Kubernetes는 메모리 제약이 있는 플랫폼이기 때문에 메모리 사용률에도 주의를 기울여야 했습니다.

그렇다면 이 기능은 무엇일까요?

경험에 따르면 대부분의 사람들이 should 이것을 블랙박스로 간주하고 그냥 실행하는 것은 컴퓨터 엔지니어의 특성이기 때문에 많은 (너무 많은?) 질문을 하는 것이므로 솔직하게 말씀드리겠습니다. 이 제품은 전체 타겟 고객층에게 모든 상자를 충족시키지 못할 수도 있습니다.

기본 수준에서 자체 인증은 테스트를 실행하고 결과를 영구 볼륨에 저장하는 Kubernetes 포드를 실행합니다. 결과는 Kubernetes에서 추출되어 수락을 위해 Couchbase에 제출됩니다.

안타깝게도 필요한 권한이 상당히 까다롭기 때문에 여기에서 자체 인증이 작동하지 않을 수도 있습니다. 테스트에는 네임스페이스, 사용자 정의 리소스 정의, 역할 및 역할 바인딩과 같은 클러스터 범위 리소스를 생성 및 삭제해야 합니다. 따라서 이 도구는 비프로덕션, 폐기용 Kubernetes 클러스터에서 실행하는 것이 좋습니다.

실행 인증

카우치베이스 오토노머스 오퍼레이터 2.3에서는 기존의 모든 도구를 하나의 도구로 통합하여 모든 것을 제어할 수 있도록 했습니다. 인증 명령은 여기에 있습니다. 도구는 다음에서 사용할 수 있습니다. 카우치베이스 다운로드 웹 페이지. 

실행은 명령줄처럼 간단합니다:

다음 내용을 검토하는 것이 좋습니다. 문서 를 클릭하여 특정 환경에 맞게 재정의가 필요한 플래그가 있는지 확인하세요.

비행 전 테스트 단계

테스트가 수행할 첫 번째 점검은 Kubernetes 클러스터의 일반적인 상태 점검입니다:

첫 번째 점검은 플랫폼 리소스 제한에 지정된 대로 카우치베이스 서버 비루트 설치 가이드. 과거에 특히 CoreOS에서 프로세스 수가 낮게 설정되어(1024) Couchbase Server가 실제로 시작되지 않는 경우를 본 적이 있습니다. 이러한 오류를 조기에 발견하면 사용자가 셀프 서비스를 할 수 있는 추가적인 이점이 있습니다.

메모리 및 CPU 리소스 확인

다음으로 플랫폼의 메모리와 CPU 리소스를 확인합니다. 플랫폼의 카우치베이스 서버 시스템 요구 사항 는 단일 Couchbase Server 인스턴스에 필요한 최소 리소스 크기를 정의합니다. 테스트 자체는 자동 메모리 예약 기능 를 활성화하면 스케줄링 문제를 더 쉽게 디버깅할 수 있습니다.

마지막으로 전체 메모리와 CPU 총합을 검사합니다. 간단히 말해, 자체 인증은 테스트를 병렬로 실행합니다. 동시성 수준과 카우치베이스 서버의 요구 사항을 알면 테스트를 실행하는 데 얼마나 많은 리소스가 필요한지 추측할 수 있습니다. 전체 계산은 자체 인증 개념 문서.

설정 단계

다음은 Kubernetes 클러스터 설정입니다. 사용자 정의 리소스 정의 설치, 동적 어드미션 컨트롤러 및 기타 플랫폼 정리 작업과 같은 일회성 설정 작업을 수행합니다:

테스트 단계

테스트는 병렬로 실행됩니다. 모든 테스트를 차례로 실행하면 모든 테스트를 실행하는 데 걸리는 시간은 며칠이 걸릴 것입니다. 동시성을 통해 3~4시간 안에 이를 달성할 수 있습니다!

Cloud 제다이 마스터라면 무엇이든 특별한 눈송이처럼 취급하는 것은 "잘못하는 것"이라는 것을 알 것입니다. 재해에 대비하고 모든 것을 처음부터 다시 만들어야 한다고 가정하면, 다른 사람들이 당황하여 문제를 해결하고 지원 조직과 소통하는 동안 순식간에 다시 가동할 수 있습니다.

따라서 테스트는 리소스 해체를 관리하는 대신 Kubernetes 네임스페이스를 사용합니다. 각 테스트는 네임스페이스를 가져오고 해당 네임스페이스에서만 리소스를 생성합니다. 테스트가 완료되면 네임스페이스가 삭제되고 모든 리소스가 자동으로 회수됩니다.

테스트는 일반적으로 이를 확인하기 위해 몇 가지 작업을 수행합니다:

• • 쿠버네티스 API가 원하는 대로 작동합니다.
  • 사용자 지정 리소스가 올바르게 작동합니다.
  • 툴링 작업
  • 운영자가 업데이트 및 복구 시나리오 중에 올바른 조치를 취합니다.
  • 여러 릴리스에서 일관되게 작동하는 Couchbase Server

최종 사용자로서 실행하는 것은 지원되는 모든 기능의 대부분을 다루는 테스트의 하위 집합이 될 것입니다.

결과 단계

모든 테스트가 완료될 때까지 실행되면 자체 인증 제품군에 결과 요약이 표시됩니다:

실패는 적을수록 좋습니다! 모든 일이 그렇듯이 특정 테스트에는 피할 수 없는 경쟁 조건이 적용됩니다. 예시로 보여드렸지만 실제로 실행하는 것은 안정적이고 예측 가능한 테스트만 포함된 축소된 버전입니다. 건너뛰기 테스트는 일반적으로 테스트하는 플랫폼의 기능이나 특정 매개변수 조합을 고려할 때 실행할 수 없는 테스트입니다.

두 번째 파드가 생성되어 퍼시스턴트 볼륨을 마운트하고 결과 아카이브가 복사됩니다. 이 파드의 이름은 다음과 비슷하게 지정됩니다. couchbase-operator-certification-20060102T150405-0700.tar.bz2 테스트 결과 요약과 문제 디버깅에 사용된 실패한 테스트 관련 로그가 포함되어 있습니다.

인증 단계

100% 합격률을 보고 계속 도전하고 싶을 수도 있지만, 아직 끝나지 않았습니다. 모든 자체 인증 결과는 다음과 같을 것으로 예상합니다. 카우치베이스에 제출 에 대한 승인을 요청합니다. 이를 통해 최종 사용자가 어떤 Kubernetes, 스토리지 및 네트워크 플랫폼을 사용하고 있는지에 대한 인사이트를 얻을 수 있습니다. 이 정보를 통해 이러한 플랫폼을 검증된 플랫폼으로 광고하고 노력의 중복을 피할 수 있습니다.

몇 번의 실패가 발생하더라도 이것이 반드시 인증 수락에 장애가 되는 것은 아닙니다. 특정 플랫폼에서 특정 기능이 지원되지 않을 수 있습니다. 이 정보를 사용하여 다른 사용자에게 이 사실을 알리고 자체 인증 컨테이너 이미지를 업데이트하여 특정 상황에서 이러한 테스트를 건너뛰어 모두가 더 쉽게 프로세스를 진행할 수 있습니다.

요약

운영자 자체 인증은 우리에게 획기적인 변화입니다. 이를 통해 더욱 다양한 플랫폼에서 카우치베이스 사용자에게 접근하고 지원할 수 있습니다. 협업 접근 방식을 사용하면 부담을 나누고 더 많은 사용자에게 수용을 알릴 수 있습니다.

여러분의 결과를 확인하고 피드백을 기다리겠습니다.

이 글에 언급된 다음 리소스에 액세스하여 후속 조치를 취하세요:

• • Couchbase 다운로드 페이지
  • 플랫폼 인증 개념(문서)
  • 카우치베이스 서버 비루트 설치 가이드
  • 카우치베이스 서버 시스템 요구 사항