다양한 데이터 센터의 Kubernetes 클러스터를 연결하는 방법

Kubernetes Quick Start 시리즈에 오신 것을 환영합니다. 이것은 우리가 온라인과 교육에서 받는 가장 흥미로운 질문을 담은 정기 칼럼입니다. Kubernetes 전문가가 답변합니다.

오늘의 전문가는 다니엘 폴렌칙(Daniel Polenchik)입니다.다니엘레 폴렌시치). Daniel은 강사이자 소프트웨어 개발자로 일하고 있습니다. Learnk8s.

다음 포스팅에서 궁금하신 점을 해결하고 싶으시다면 이메일로 문의하세요 또는 트위터: @learnk8s.

이전 게시물을 놓치셨나요? 여기서 찾아보세요.

서로 다른 데이터 센터에 있는 Kubernetes 클러스터를 어떻게 연결하나요?

간단히: Kubefed v2 출시 예정, 다음 내용도 읽어 보시기 바랍니다. 하주 и 멀티 클러스터 스케줄러 프로젝트.

인프라는 특히 통제된 환경에서 여러 지역에 걸쳐 복제 및 분산되는 경우가 많습니다.

한 지역을 사용할 수 없는 경우 중단을 방지하기 위해 트래픽이 다른 지역으로 리디렉션됩니다.

Kubernetes를 사용하면 유사한 전략을 사용하고 여러 지역에 워크로드를 분산할 수 있습니다.

팀, 지역, 환경 또는 이러한 요소의 조합별로 하나 이상의 클러스터를 가질 수 있습니다.

클러스터는 다양한 클라우드와 온프레미스에서 호스팅될 수 있습니다.

하지만 그러한 지리적 확산을 위한 인프라를 어떻게 계획합니까?
단일 네트워크를 통해 여러 클라우드 환경에 대해 하나의 대규모 클러스터를 생성해야 합니까?
아니면 작은 클러스터가 많이 있고 이를 제어하고 동기화하는 방법을 찾고 계십니까?

하나의 리더십 클러스터

단일 네트워크를 통해 하나의 클러스터를 만드는 것은 그리 쉬운 일이 아닙니다.

사고가 발생하여 클러스터 세그먼트 간의 연결이 끊어졌다고 상상해 보십시오.

마스터 서버가 하나인 경우 리소스의 절반은 마스터에 접속할 수 없기 때문에 새 명령을 받을 수 없습니다.

동시에 오래된 라우팅 테이블도 있습니다(kube-proxy 새 항목을 다운로드할 수 없음) 및 추가 Pod가 없습니다(kubelet은 업데이트를 요청할 수 없음).

설상가상으로 Kubernetes가 노드를 인식하지 못하면 해당 노드를 고아로 표시하고 누락된 Pod를 기존 노드에 배포합니다.

결과적으로 포드 수는 두 배로 늘어납니다.

지역별로 하나의 마스터 서버를 만들 경우 etcd 데이터베이스의 합의 알고리즘에 문제가 발생하게 됩니다. (대략. 에드. — 실제로 etcd 데이터베이스가 반드시 마스터 서버에 위치할 필요는 없습니다. 동일한 지역에 있는 별도의 서버 그룹에서 실행할 수 있습니다. 사실, 동시에 클러스터의 실패 지점을 얻는 것입니다. 하지만 빨리.)

etcd 사용 뗏목 알고리즘값을 디스크에 쓰기 전에 협상합니다.
즉, 상태를 etcd에 기록하기 전에 대부분의 인스턴스가 합의에 도달해야 합니다.

서로 다른 지역에 있는 XNUMX개의 etcd 인스턴스의 경우처럼 etcd 인스턴스 간의 대기 시간이 급격하게 증가하면 값을 협상하고 디스크에 쓰는 데 오랜 시간이 걸립니다.
이는 Kubernetes 컨트롤러에 반영됩니다.

컨트롤러 관리자가 변경 사항을 파악하고 데이터베이스에 응답을 작성하려면 더 많은 시간이 필요합니다.

그리고 컨트롤러가 하나가 아닌 여러개가 있기 때문에, 연쇄 반응이 발생하고 전체 클러스터가 매우 느리게 작동하기 시작합니다..

etcd는 지연 시간에 매우 민감하므로 공식 문서에서는 일반 하드 드라이브 대신 SSD 사용을 권장합니다..

현재 단일 클러스터에 대한 대규모 네트워크의 좋은 예는 없습니다.

기본적으로 개발자 커뮤니티와 SIG 클러스터 그룹은 Kubernetes가 컨테이너를 조정하는 것과 동일한 방식으로 클러스터를 조정하는 방법을 찾으려고 노력하고 있습니다.

옵션 1: kubefed를 사용한 클러스터 페더레이션

SIG-cluster의 공식 답변 - kubefed2, 원래 kube 페더레이션 클라이언트 및 운영자의 새 버전.

처음으로 우리는 kube 페더레이션 도구를 사용하여 클러스터 모음을 단일 개체로 관리하려고 시도했습니다.

시작은 좋았지만 결국 Kube Federation은 모든 리소스를 지원하지 않아 인기를 얻지 못했습니다.

예를 들어 연합 전달 및 서비스는 지원했지만 StatefulSet은 지원하지 않았습니다.
또한, 연합 구성이 주석 형태로 전송되어 유연성이 없었습니다.

주석만 사용하여 페더레이션의 각 클러스터에 대한 복제본 파티셔닝을 어떻게 설명할 수 있는지 상상해 보세요.

그것은 완전히 엉망이었습니다.

SIG-cluster는 kubefed v1 이후 많은 작업을 수행했으며 다른 각도에서 문제에 접근하기로 결정했습니다.

주석 대신 클러스터에 설치된 컨트롤러를 출시하기로 결정했습니다. CRD(사용자 정의 리소스 정의)를 사용하여 사용자 정의할 수 있습니다.

페더레이션의 일부가 될 각 리소스에 대해 세 가지 섹션이 있는 사용자 정의 CRD 정의가 있습니다.

• 자원의 표준 정의(예: 배포)
• 섹션 placement, 페더레이션에서 리소스가 배포되는 방법을 정의합니다.
• 섹션 override, 특정 리소스의 경우 배치의 가중치와 매개변수를 재정의할 수 있습니다.

다음은 배치 및 재정의 섹션이 포함된 결합 게재의 예입니다.

apiVersion: types.federation.k8s.io/v1alpha1
kind: FederatedDeployment
metadata:
  name: test-deployment
  namespace: test-namespace
spec:
  template:
    metadata:
      labels:
        app: nginx
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
            - image: nginx
              name: nginx
  placement:
    clusterNames:
      - cluster2
      - cluster1
  overrides:
    - clusterName: cluster2
      clusterOverrides:
        - path: spec.replicas
          value: 5

보시다시피 공급은 두 클러스터에 분산됩니다. cluster1 и cluster2.

첫 번째 클러스터는 5개의 복제본을 제공하고 두 번째 클러스터는 XNUMX로 설정됩니다.

복제본 수를 더 많이 제어해야 하는 경우 kubefed2는 복제본에 가중치를 부여할 수 있는 새로운 ReplicaSchedulingPreference 개체를 제공합니다.

apiVersion: scheduling.federation.k8s.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:
  name: test-deployment
  namespace: test-ns
spec:
  targetKind: FederatedDeployment
  totalReplicas: 9
  clusters:
    A:
      weight: 1
    B:
      weight: 2

CRD 구조와 API는 아직 준비되지 않았으며 공식 프로젝트 저장소에서 활발한 작업이 진행 중입니다.

kubefed2를 주시하세요. 하지만 아직 프로덕션에는 적합하지 않다는 점을 기억하세요.

kubefed2에 대해 자세히 알아보세요. kubefed2에 관한 공식 기사 Kubernetes에 대한 블로그와 kubefed 프로젝트의 공식 저장소.

옵션 2: Booking.com 스타일로 클러스터 결합

Booking.com 개발자는 kubefed v2에서는 작업하지 않았지만 여러 클러스터, 여러 지역 및 여러 클라우드에서 배송을 제공하는 운영자인 Shipper를 생각해냈습니다.

하주 kubefed2와 다소 유사합니다.

두 도구 모두 다중 클러스터 배포 전략(사용되는 클러스터 및 보유한 복제본 수)을 사용자 정의할 수 있습니다.

하지만 배송업체의 목표는 배송 중 오류 위험을 줄이는 것입니다.

Shipper에서는 이전 배포와 현재 배포 간의 복제본 분할과 수신 트래픽 볼륨을 설명하는 일련의 단계를 정의할 수 있습니다.

클러스터에 리소스를 푸시하면 Shipper 컨트롤러는 조인된 모든 클러스터에 해당 변경 사항을 점진적으로 롤아웃합니다.

또한 배송업체도 매우 제한되어 있습니다.

예를 들어, 조타 차트를 입력으로 허용합니다. 바닐라 리소스를 지원하지 않습니다.
일반적으로 Shipper는 다음과 같이 작동합니다.

표준 제공 대신 Helm 차트를 포함하는 애플리케이션 리소스를 생성해야 합니다.

apiVersion: shipper.booking.com/v1alpha1
kind: Application
metadata:
  name: super-server
spec:
  revisionHistoryLimit: 3
  template:
    chart:
      name: nginx
      repoUrl: https://storage.googleapis.com/shipper-demo
      version: 0.0.1
    clusterRequirements:
      regions:
        - name: local
    strategy:
      steps:
        - capacity:
            contender: 1
            incumbent: 100
          name: staging
          traffic:
            contender: 0
            incumbent: 100
        - capacity:
            contender: 100
            incumbent: 0
          name: full on
          traffic:
            contender: 100
            incumbent: 0
    values:
      replicaCount: 3

Shipper는 여러 클러스터를 관리하는 데 좋은 옵션이지만 Helm과의 긴밀한 관계는 방해가 될 뿐입니다.

우리 모두가 Helm에서 Helm으로 전환하면 어떨까요? 커스터마이제이션 또는 카피 탄?

Shipper와 그 철학에 대해 자세히 알아보세요. 이번 공식 보도자료.

코드를 자세히 알아보고 싶다면, 공식 프로젝트 저장소로 이동.

옵션 3: "마법의" 클러스터 병합

Kubefed v2 및 Shipper는 클러스터 페더레이션과 함께 작동하여 사용자 정의 리소스 정의를 통해 클러스터에 새로운 리소스를 제공합니다.

하지만 병합할 모든 전달, StatefulSet, DaemonSet 등을 다시 작성하고 싶지 않다면 어떻게 해야 할까요?

YAML을 변경하지 않고 페더레이션에 기존 클러스터를 포함하는 방법은 무엇입니까?

다중 클러스터 스케줄러는 Admirality 프로젝트입니다., 클러스터의 작업 부하 예약을 다룹니다.

그러나 클러스터와 상호 작용하고 리소스를 사용자 정의 정의로 래핑하는 새로운 방법을 찾는 대신 다중 클러스터 스케줄러가 표준 Kubernetes 수명 주기에 내장되어 포드를 생성하는 모든 호출을 가로챕니다.

생성된 각 포드는 즉시 더미로 교체됩니다.

다중 클러스터 스케줄러 사용 액세스 수정을 위한 웹훅통화를 가로채고 유휴 더미 포드를 생성합니다.

원래 포드는 전체 페더레이션을 폴링한 후 배치 결정이 내려지는 또 다른 계획 주기를 거칩니다.

마지막으로 Pod가 대상 클러스터에 전달됩니다.

결과적으로 아무 작업도 하지 않고 공간만 차지하는 추가 포드가 생겼습니다.

장점은 소모품을 결합하기 위해 새로운 리소스를 작성할 필요가 없다는 것입니다.

포드를 생성하는 각 리소스는 자동으로 병합할 준비가 되어 있습니다.

이것은 흥미롭습니다. 갑자기 여러 지역에 걸쳐 보급품이 분산되었는데도 눈치 채지 못했기 때문입니다. 그러나 여기의 모든 것이 마법에 달려 있기 때문에 이것은 매우 위험합니다.

그러나 Shipper는 배송의 영향을 대부분 완화하려고 노력하는 반면, 다중 클러스터 스케줄러는 보다 일반적인 작업을 처리하며 아마도 일괄 작업에 더 적합할 것입니다.

고급 점진적 전달 메커니즘이 없습니다.

다중 클러스터 스케줄러에 대한 자세한 내용은 다음에서 확인할 수 있습니다. 공식 저장소 페이지.

다중 클러스터 스케줄러의 실제 작동에 대해 읽고 싶다면 Admiralty에서 Argo의 흥미로운 사용 사례 — 워크플로, 이벤트, CI 및 CD Kubernetes.

기타 도구 및 솔루션

여러 클러스터를 연결하고 관리하는 것은 복잡한 작업이며 보편적인 솔루션은 없습니다.

이 주제를 더 자세히 살펴보고 싶다면 다음 리소스를 참조하세요.

• Rancher의 잠수함 다양한 Kubernetes 클러스터의 오버레이 네트워크를 연결하는 도구입니다.
• 소매 체인 Target 용도 Unimatrix는 Spinnaker와 결합되어 여러 클러스터에 걸쳐 배포를 조정합니다..
• IPV6을 사용해보십시오. 여러 지역의 단일 네트워크.
• 예를 들어 서비스 메시를 사용할 수 있습니다. 여러 클러스터를 연결하기 위한 Istio.
• 컨테이너 네트워크 인터페이스 플러그인인 Cilium은 다음을 제공합니다. 클러스터 메시 기능, 여러 클러스터를 결합할 수 있습니다.

오늘은 그게 다야

끝까지 읽어주셔서 감사합니다!

여러 클러스터를 보다 효율적으로 연결하는 방법을 알고 있다면 우리에게 말해.

귀하의 방법을 링크에 추가하겠습니다.

Chris Nesbitt-Smith(크리스 네스빗-스미스) 및 Vincent de Sme(빈센트 드 스멧) (신뢰성 엔지니어 swatmobile.io) 기사를 읽고 연맹이 어떻게 운영되는지에 대한 유용한 정보를 공유해 주셔서 감사합니다.

출처 : habr.com