기존 외부 Consul 서버 클러스터 조인

기존 외부 Consul 서버 클러스터 조인 (External Servers)

이미 실행 중인 Consul 클러스터가 있다면, Kubernetes의 Consul 설치가 이 기존 클러스터에 조인하도록 구성할 수 있는 방법을 설명하는 문서예요.

출처: 문서

본문

이미 실행 중인 Consul 클러스터가 있다면, Kubernetes의 Consul 설치를 구성해 이 기존 클러스터에 조인시킬 수 있어요.

아래 values.yaml 파일은 기존 Consul 서버 클러스터에 조인하도록 Consul을 설치하는 Helm 차트를 구성하는 방법을 보여줘요.

global.enabled 값은 먼저 모든 차트 구성 요소를 기본적으로 비활성화해서 각 구성 요소를 옵트인(opt-in) 방식으로 만들어요.

다음으로 externalServers를 구성해 Consul 서버를 가리키게 해요. externalServers.hosts 값은 반드시 제공해야 하며, DNS, IP, 또는 Consul IP를 반환하는 명령이 담긴 exec= 문자열로 설정해야 해요. exec= 문자열이 어떻게 동작하는지에 대한 내용은 이 문서를 참고하세요.

예를 들어 여러 개의 정적 IP를 지정하려면 exec= 문자열을 사용해요:

values.yaml

externalServers:
  hosts: ["exec=echo 192.0.2.10 192.0.2.11 192.0.2.12"]

externalServers 섹션의 다른 값들은 선택 사항이에요. 자세한 내용은 Helm 차트 구성을 참고하세요.

values.yaml

global:
  enabled: false

externalServers:
  hosts: [<consul server DNS, IP or exec= string>]

Consul Dataplane의 도입으로 Kubernetes의 Consul 설치는 Consul 클라이언트 에이전트를 제거해 더 단순해졌어요. 이를 위해서는 Helm 설치와 Kubernetes에 설치된 나머지 consul-k8s 구성 요소가 다양한 포트에서 Consul 서버와 직접 통신해야 해요. 설치를 시작하기 전에 Consul 서버가 ports.grpc = 8502 구성 옵션을 사용해 gRPC 포트 8502/tcp를 활성화하도록 구성되어 있는지 확인하세요.

TLS 구성 (Configuring TLS)

참고 Kubernetes의 Consul은 현재 Consul 서버의 HTTPS 클라이언트에 대해 상호 인증을 요구하는 외부 서버, 즉 서버가 tls.defaults.verify_incoming 또는 tls.https.verify_incoming을 true로 설정한 경우를 지원하지 않아요. 보안 모델에 명시된 대로, 모든 요청에 유효한 ACL 토큰이 포함되도록 권장되므로 해당 설정은 Consul의 위협 모델을 지원하는 데 엄격히 필요하지는 않아요.

Consul 서버에 TLS가 활성화되어 있다면 Kubernetes의 Consul이 서버와 통신할 수 있도록 CA 인증서를 제공해야 해요. 아래 예시와 같이 인증서를 Kubernetes 시크릿에 저장한 다음 Helm 값에 제공해요:

values.yaml

global:
  tls:
    enabled: true
    caCert:
      secretName: <CA certificate secret name>
      secretKey: <CA Certificate secret key>
externalServers:
  enabled: true
  hosts: [<consul server DNS, IP or exec= string>]

HTTPS 포트가 Consul의 기본값인 8501과 다르다면 externalServers.httpsPort도 설정해야 해요. Consul 서버가 TLS를 활성화하지 않고 실행 중이라면 이 구성을 사용해 서버가 구성된 HTTP 포트(기본값 8500)를 설정해요.

ACL 구성 (Configuring ACLs)

ACL이 활성화된 외부 서버를 실행 중이라면, Consul 클라이언트와 consul-k8s 구성 요소를 위한 ACL 토큰 초기화를 도와주도록 Helm 차트를 구성하는 방법이 몇 가지 있어요.

ACL 수동 부트스트랩 (Manually Bootstrapping ACLs)

ACL 부트스트랩 API를 직접 호출하고 싶거나 클러스터가 이미 ACL로 부트스트랩되었다면, 부트스트랩 토큰을 Helm 차트에 제공할 수 있어요. 그러면 Helm 차트는 이 토큰을 사용해 Consul 클라이언트와 활성화하는 모든 consul-k8s 구성 요소에 대한 ACL을 구성해요.

먼저 부트스트랩 토큰이 포함된 Kubernetes 시크릿을 만들어요:

kubectl create secret generic bootstrap-token --from-literal='token=<your bootstrap token>'

그런 다음 그 시크릿을 Helm 차트에 제공해요:

values.yaml

global:
  acls:
    manageSystemACLs: true
    bootstrapToken:
      secretName: bootstrap-token
      secretKey: token

부트스트랩 토큰에는 다음 최소 권한이 필요해요:

  • acl:write
  • Consul 네임스페이스를 활성화하는 경우 operator:write
  • 메시 게이트웨이를 통한 WAN 페더레이션을 사용하는 경우 agent:read

다음으로 외부 서버를 구성해요. Helm 차트는 이 구성을 사용해 Consul 서버의 API와 통신해 정책, 토큰, auth method를 만들어요. Consul 서비스 메시를 활성화하는 경우, Consul 서버가 Kubernetes auth method와 consul login을 사용할 때 Kubernetes 서비스 어카운트 토큰을 검증할 수 있도록 k8sAuthMethodHost를 Kubernetes API 서버의 주소로 설정해야 해요.

참고 externalServers.k8sAuthMethodHost가 설정되어 있고 WAN 페더레이션(global.federation.enabled이 true로 설정)도 사용 중이라면, global.federation.k8sAuthMethodHost가 externalServers.k8sAuthMethodHost와 동일한 값으로 설정되어 있는지 확인하세요.

values.yaml

externalServers:
  enabled: true
  hosts: [<consul server DNS, IP or exec= string>]
  k8sAuthMethodHost: 'https://kubernetes.example.com:443'

최종 Helm 구성은 대략 다음과 같을 거예요:

values.yaml

global:
  enabled: false
  acls:
    manageSystemACLs: true
    bootstrapToken:
      secretName: bootstrap-token
      secretKey: token
externalServers:
  enabled: true
  hosts: [<consul server DNS, IP or exec= string>]
  k8sAuthMethodHost: 'https://kubernetes.example.com:443'

Helm 차트를 통한 ACL 부트스트랩 (Bootstrapping ACLs via the Helm chart)

Helm 차트가 부트스트랩 API를 호출하고 서버 토큰을 대신 설정해 주길 원한다면 단계는 비슷해요. 유일한 차이는 부트스트랩 토큰을 설정할 필요가 없다는 점이에요. Helm 차트가 부트스트랩 토큰을 Kubernetes 시크릿으로 저장해요.

values.yaml

global:
  enabled: false
  acls:
    manageSystemACLs: true
externalServers:
  enabled: true
  hosts: [<consul server DNS, IP or exec= string>]
  k8sAuthMethodHost: 'https://kubernetes.example.com:443'

더 알아보기 (Learn more)