웹 개발자 커뮤니티 전체가 Kubernetes(K8)에 대해 흥분하고 있습니다. 작년에 제가 참석했던 컨퍼런스와 개발자 행사에서 가장 뜨거운 주제였던 것도 당연합니다.
K8은 컨테이너를 관리하기 위한 도구일 뿐만 아니라, 실제로 다음과 같은 기능을 쉽게 추가할 수 있습니다. 로드 밸런싱 가 필요하지 않으며 서비스 검색 계층 (더 이상 유레카 예를 들어). 또한 K8은 애플리케이션 배포와 업데이트를 자동화하며, 가장 중요한 것은 인프라를 위한 맞춤형 컨트롤러를 플러그인/작성할 수 있다는 점입니다.
환상적이지 않나요? 그러나 상태 비저장 컨테이너를 관리하는 것은 그렇게 복잡하지 않습니다. 결국, 컨테이너는 본질적으로 임시적이며 별다른 부작용 없이 원하는 대로 인스턴스를 죽이고 스핀업할 수 있기 때문입니다.
그러나 이것은 이야기의 절반에 불과합니다. 일반적으로 애플리케이션은 완전히 상태 비저장일 수 없으며 대부분의 경우 상태를 아래 계층으로 푸시하기만 하면 됩니다. 그렇다면 K8에서 상태 저장 애플리케이션을 어떻게 처리할까요? 다행히도 버전 1.5부터는 StatefulSets라는 것이 있습니다.
스테이트풀 컨테이너
쿠버네티스 스테이트풀셋은 볼륨, 안정적인 네트워크 ID, 0에서 N까지의 서수 인덱스 등과 같은 스테이트풀 컨테이너를 처리할 수 있는 리소스 세트를 제공한다. 볼륨은 쿠버네티스 위에서 스테이트풀 애플리케이션을 실행할 수 있게 해주는 핵심 기능 중 하나이며, 현재 지원되는 두 가지 주요 유형을 살펴보자:
임시 저장소 volumes
임시 스토리지의 동작은 도커에서 익숙한 것과는 다른데, 쿠버네티스에서는 볼륨이 파드 내에서 실행되는 모든 컨테이너보다 오래 지속되며 컨테이너가 다시 시작될 때 데이터가 보존된다. 그러나 파드가 종료되면 볼륨은 자동으로 제거된다.
영구 스토리지 볼륨
퍼시스턴트 스토리지에서, 이름에서 알 수 있듯이 데이터 수명은 파드의 수명과 독립적이다. 따라서, 파드가 죽거나 다른 노드로 이동하더라도 사용자가 명시적으로 삭제하지 않는 한 해당 데이터는 계속 유지됩니다. 이러한 종류의 볼륨에서 데이터는 일반적으로 다음과 같이 저장된다. 원격으로.
우리는 다음과 같은 Kubernetes 지원을 기대하고 있습니다. 로컬 영구 저장소 가 데이터베이스를 실행하는 데 가장 적합할 것이 분명하지만, 그 동안에는 기본적으로 임시 저장소를 사용합니다. 이쯤 되면 왜 영구 저장소가 아닌 임시 저장소를 사용하는지 궁금하실 것입니다. 당연히 여러 가지 이유가 있습니다:
- 임시 저장소는 영구 저장소보다 빠르고 저렴하지만, 데이터를 주고받아야 하므로 영구 저장소를 사용하려면 더 많은 인프라/네트워킹이 필요합니다.
- K8s 1.9 도입 원시 블록 지원를 사용하여 VM 인스턴스의 물리적 디스크에 액세스하여 애플리케이션에서 사용할 수 있습니다.
- 네트워크 스토리지 시스템의 유지 관리는 간단하지 않습니다.
- 전체 파드를 죽이는 대신 언제든지 컨테이너를 먼저 재부팅할 수 있습니다:
1kubectl exec POD_NAME -c 컨테이너 이름 재부팅 - 데이터를 자동으로 복제하도록 Couchbase를 구성할 수 있으므로 N 파드가 죽더라도 데이터가 손실되지 않습니다.
- K8의 임무 중 하나는 대규모 장애를 피하기 위해 여러 랙에서 파드를 실행하는 것입니다.
그러나 리밸런싱 프로세스를 완료하는 데 몇 분이 걸리는 대규모 데이터베이스와 같이 원격 영구 저장소를 사용하는 것이 추가 대기 시간 비용을 감수할 만한 가치가 있는 몇 가지 시나리오가 있습니다. 그렇기 때문에 원격 영구 저장소에 대한 지원도 추가할 예정입니다.
스테이트풀셋의 단점 중 하나는 관리가 제한적이라는 점입니다.스테이트풀셋이나 디플로이먼트와 유사하지만 카우치베이스 인스턴스 관리를 위해 특별히 설계된 사용자 정의 리소스 정의(CRD)를 사용하여 Kubernetes에서 사용자 정의 네이티브 리소스를 생성할 수 있는 Kubernetes API를 확장할 수 있습니다.
훌륭합니다! StatefulSets/CRD를 사용하면 모든 하드웨어 작업이 준비되었으니, 여기서 빠진 "작은" 것이 하나 있는데, 애플리케이션 자체의 상태는 어떨까요? 예를 들어, 데이터베이스의 경우 클러스터에 새 노드를 추가하는 것만으로는 충분하지 않으며, 일부 데이터를 새로 추가된 노드로 이동/복제하기 위한 리밸런싱과 같은 일부 프로세스를 트리거하여 완전히 작동하도록 만들어야 합니다. 이것이 바로 K8 운영자가 게임에 참여한 이유입니다.
쿠버네티스 오퍼레이터
쿠버네티스 1.7 라는 중요한 기능이 추가되었습니다. 사용자 지정 컨트롤러. 요약하면 다음과 같습니다. 개발자가 새로운 기능을 확장 및 추가하고, 기존 기능을 대체(예: kube-proxy 교체)하며, 관리 작업을 자동화할 수 있습니다. 를 마치 네이티브 쿠버네티스 컴포넌트인 것처럼 사용할 수 있습니다.
오퍼레이터는 애플리케이션별 커스텀 컨트롤러 세트에 불과합니다. 그렇다면 왜 이것이 게임 체인저일까요? 컨트롤러는 쿠버네티스 API에 직접 액세스할 수 있으므로, 컨트롤러 내부에 작성된 사용자 정의 규칙에 따라 클러스터 모니터링, 파드/서비스 변경, 스케일 업/다운, 실행 중인 애플리케이션의 엔드포인트 호출이 모두 가능합니다.
이 동작을 설명하기 위해, 파드가 죽었을 때 카우치베이스의 오퍼레이터가 어떻게 작동하는지 살펴보자:
운영자에 대해 자세히 알아볼 수 있습니다. 여기
위 그림에서 볼 수 있듯이 운영자는 클러스터를 모니터링 및 분석하고 일련의 매개변수를 기반으로 원하는 상태를 달성하기 위해 일련의 작업을 트리거합니다. 이 조정 프로세스는 K8의 모든 곳에서 이루어집니다. 그러나 모든 작업이 동일한 것은 아니며, 이 예에서는 두 가지 범주가 있습니다:
- 인프라 - 새 노드 추가: 운영자는 쿠버네티스 API를 통해 카우치베이스 서버를 실행하는 새 파드를 시작하도록 요청한다.
- 도메인 특정 - 클러스터에 노드를 추가하거나 데이터 재조정을 트리거합니다: 운영자는 Couchbase의 작동 방식을 알고 올바른 나머지 엔드포인트를 호출하여 클러스터에 새 노드를 추가하고 데이터 리밸런싱을 트리거합니다.
이것이 바로 오퍼레이터의 진정한 힘입니다, 다른 애플리케이션을 완전히 관리할 수 있는 애플리케이션을 작성할 수 있습니다.그리고 어떤 종류의 상태 저장 애플리케이션이 가장 관리하기 어려운지 맞히세요? 정답입니다: 데이터베이스입니다.
개발자들은 항상 데이터베이스가 바로 작동할 것이라고 기대해 왔지만 실제로는 정반대였습니다. 심지어 데이터베이스를 관리하는 책임자, 즉 우리가 사랑하는 DBA에 대한 구체적인 이름도 있습니다.
이러한 시나리오를 바꾸고 특정 클라우드 공급업체에 종속되지 않고 데이터베이스를 쉽게 관리할 수 있도록 하기 위한 노력의 일환으로 Couchbase의 Operator가 만들어졌습니다. 현재는 자동화된 클러스터 프로비저닝, 탄력적인 확장성, 자동 복구, 로깅 및 웹 콘솔 액세스를 지원하지만, 앞으로 더 많은 기능이 추가될 예정입니다. 이에 대해 자세히 알아보려면 다음을 참조하세요. 이 문서 또는 Couchbase의 공식 문서를 참조하세요. 여기.
또한 데이터베이스용으로 출시된 최초의 공식 오퍼레이터이며, 이미 몇몇 소규모 커뮤니티 프로젝트에서 MySQL용 오퍼레이터를 구축하려고 시도하고 있다는 점도 언급해야 합니다, Postrgres 및 기타 데이터베이스.
운영자의 에코시스템은 빠르게 성장하고 있습니다, rook 를 사용하면 AWS S3와 매우 유사한 것을 배포할 수 있습니다. 아파치 카프카 쿠버네티스 운영자도 곧 출시될 예정이며, 그 외에도 많은 이니셔티브가 있습니다. 모든 주요 클라우드 제공업체가 K8을 지원하므로 앞으로 몇 달 안에 운영자 수가 크게 늘어날 것으로 예상됩니다.
마지막으로, Kubernetes는 클라우드에 구애받지 않는 애플리케이션 배포 및 관리를 제공합니다. 클라우드 제공업체 간에 자유롭게 마이그레이션할 수 있기 때문에 클라우드 제공업체를 거의 상품처럼 취급할 수 있을 정도로 강력합니다.
앞으로는 어떤 클라우드 제공업체가 최고의 성능/비용을 제공하는지에 따라 클라우드 제공업체를 선택하게 될 것입니다. 이러한 급격한 변화가 시장에 미칠 영향은 아직 불분명하지만, 개발자로서 우리는 분명 가장 큰 승자가 될 것입니다.
업데이트: 이 글이 작성된 지 얼마 되지 않았지만 이미 많은 부분이 변경되었습니다. 이제 카우치베이스 자율 운영자 1.2, 로컬 영구 스토리지 는 GA이고 운영자 허브 를 사용하여 모든 오픈소스 운영자를 중앙 집중화합니다.
질문이 있으시면 언제든지 다음 주소로 트윗해 주세요. @deniswsrosa
매우 유익하고 간결한 블로그!