Kubernetes 클러스터 피어링 기술 사양

Kubernetes 클러스터 피어링 기술 사양 (Cluster Peering on Kubernetes Technical Specifications)

이 참조 주제는 Kubernetes 배포에서 클러스터 피어링을 사용할 때 필요한 기술 사양을 설명해요. 필수 Helm 값, 커스텀 리소스 정의(CRD), 그리고 필요한 Consul 구성 요소와 그 구성을 다뤄요.

출처: 문서

본문

이 참조 주제는 Kubernetes 배포에서 클러스터 피어링을 사용할 때 필요한 기술 사양을 설명해요. 이러한 사양에는 필수 Helm 값과 필수 커스텀 리소스 정의(CRD), 그리고 필요한 Consul 구성 요소와 그 구성이 포함돼요. Consul의 클러스터 피어링 기능에 대해 더 알아보려면 클러스터 피어링 개요를 참고해요.

비 Kubernetes 배포의 클러스터 피어링 요구 사항은 클러스터 피어링 기술 사양을 참고해요.

일반 요구 사항 (General requirements)

Consul 환경이 다음 사전 요구 사항을 충족하는지 확인해요:

• Consul v1.14 이상
• Kubernetes용 Consul v1.0.0 이상
• 최소 두 개의 Kubernetes 클러스터

클러스터 피어링 연결을 수립하려면 다음 서비스 메시 구성 요소도 구성해야 해요:

• Helm
• 커스텀 리소스 정의(CRD)
• 메시 게이트웨이
• 내보낸 서비스(Exported services)
• ACL

Helm 사양 (Helm specifications)

Consul의 기본 구성은 클러스터 간 직접 클러스터 피어링 연결을 지원해요. 프로덕션 환경에서는 클러스터 피어링 연결로 파티션 간 서비스 메시 트래픽을 안전하게 라우팅하기 위해 메시 게이트웨이를 사용할 것을 권장해요. 메시 게이트웨이를 활성화하려면 Helm 차트에서 다음 값을 설정해야 해요:

• global.tls.enabled = true
• meshGateway.enabled = true

다음 예시 Helm 구성은 다음과 같아요:

values.yaml:

global:
  name: consul
  image: "hashicorp/consul:1.16.0"
  peering:
    enabled: true
  tls:
    enabled: true
meshGateway:
  enabled: true

Helm 차트에서 메시 게이트웨이가 활성화된 후에는 별도로 Mesh CRD를 구성할 수 있어요.

CRD 사양 (CRD specifications)

피어링 연결을 수립하려면 다음 CRD를 생성해야 해요:

• PeeringAcceptor: 피어링 토큰을 생성하고 들어오는 피어링 연결을 수락해요.
• PeeringDialer: 피어링 토큰을 사용해 토큰을 생성한 클러스터와의 아웃바운드 피어링 연결을 만들어요.

다음 예시 CRD를 참고해요:

acceptor.yaml:

apiVersion: consul.hashicorp.com/v1alpha1
kind: PeeringAcceptor
metadata:
  name: cluster-02 ## The name of the peer you want to connect to
spec:
  peer:
    secret:
      name: "peering-token"
      key: "data"
      backend: "kubernetes"

dialer.yaml:

apiVersion: consul.hashicorp.com/v1alpha1
kind: PeeringDialer
metadata:
  name: cluster-01 ## The name of the peer you want to connect to
spec:
  peer:
    secret:
      name: "peering-token"
      key: "data"
      backend: "kubernetes"

메시 게이트웨이 사양 (Mesh gateway specifications)

Consul의 기본 구성을 변경하고 메시 게이트웨이를 통한 클러스터 피어링을 활성화하려면 mesh 구성 항목을 사용해 네트워크의 서비스 메시 프록시를 전역으로 업데이트해요:

1. cluster-01에서 peeringThroughMeshGateways를 true로 설정한 Mesh 커스텀 리소스를 생성해요.

mesh.yaml:

apiVersion: consul.hashicorp.com/v1alpha1
kind: Mesh
metadata:
  name: mesh
spec:
  peering:
    peerThroughMeshGateways: true

2. mesh CRD를 cluster-01에 적용해요.

$ kubectl --context $CLUSTER1_CONTEXT apply -f mesh.yaml 

3. mesh CRD를 cluster-02에 적용해요.

$  kubectl --context $CLUSTER2_CONTEXT apply -f mesh.yaml 

참고 (Note)

이 예시에서 사용된 클러스터 컨텍스트 변수 설정에 대한 도움은 환경 변수에 클러스터 ID 할당을 참고해요.

메시 게이트웨이를 통한 클러스터 피어링 시 다음 배포 요구 사항을 고려해요:

• Consul 클러스터는 다른 리전 또는 클라우드 제공자의 피어에게 서비스를 내보내려면 등록된 메시 게이트웨이가 필요해요.
• 메시 게이트웨이는 내보낸 서비스 및 해당 exported-services 구성 항목과 동일한 관리 파티션에 등록되어야 해요. 단일 Consul 서버 클러스터에서 여러 관리 파티션을 사용하려면 엔터프라이즈 라이선스가 필요해요.
• local 메시 게이트웨이 모드를 사용하려면 가져오는(importing) 클러스터에 메시 게이트웨이를 등록해야 해요.
• 프록시와 호환되는 불투명 매개변수를 사용해 Proxy.Config 설정을 정의해요. 추가 Envoy 프록시 구성 정보는 Gateway 옵션과 Escape-hatch 재정의를 참고해요.

메시 게이트웨이 모드 (Mesh gateway modes)

기본적으로 모든 클러스터 피어링 연결은 원격 모드(remote mode)의 메시 게이트웨이를 사용해요. 메시 게이트웨이의 모드를 변경할 때 다음 추가 요구 사항을 유의해요.

• 피어링된 클러스터를 연결하는 메시 게이트웨이의 경우 mode를 remote 또는 local로 설정할 수 있어요.
• 클러스터 피어링 연결이 있는 메시 게이트웨이에는 none 모드가 유효하지 않아요.

Kubernetes 배포에서 메시 게이트웨이 모드를 local로 변경하는 방법은 서비스 간 트래픽에 대한 메시 게이트웨이 모드 구성을 참고해요.

내보낸 서비스 사양 (Exported service specifications)

서비스가 클러스터 피어링 연결로 파티션 간 통신하려면 exported-services CRD가 필요해요. exported-services 구성 항목 사용에 대한 기본 지침은 클러스터 피어링 연결 수립에 포함되어 있어요.

자세한 내용은 exported-services 구성 항목을 참고해요.

더 알아보기 (Learn more)

• 클러스터 피어링 개요
• exported-services 구성 항목 참조
• 메시 게이트웨이