VM과 Kubernetes WAN 페더레이션

VM과 Kubernetes WAN 페더레이션

이 페이지는 VM과 Kubernetes 런타임에 별도로 배포된 Consul 클러스터를 페더레이션하는 방법을 설명해요. Kubernetes에서 실행되는 데이터센터를 VM이나 베어메탈 같은 비 Kubernetes 플랫폼의 데이터센터와 페더레이션할 수 있어요. 이 기능은 Consul 1.8.0+에서 사용할 수 있어요.

출처: 문서

본문

1.8.0+: 이 기능은 Consul 버전 1.8.0 이상에서 사용할 수 있습니다.

이 주제는 Mesh Gateways와 WAN Federation Via Mesh Gateways에 대한 친숙함이 필요합니다.

이 페이지는 VM과 Kubernetes 런타임에 별도로 배포된 Consul 클러스터를 페더레이션하는 방법을 설명합니다. 자세한 내용은 Multi-Cluster Overview을 참조하세요. Kubernetes networking requirements도 포함됩니다.

VM이나 베어메탈 같은 비 Kubernetes 플랫폼에서 실행되는 Consul 데이터센터는 Kubernetes 데이터센터와 페더레이션할 수 있습니다.

Kubernetes를 기본(Primary)으로 사용

하나의 Consul 데이터센터가 primary여야 합니다. 기본 데이터센터가 Kubernetes에서 실행된다면 Primary Datacenter 섹션의 Helm 구성을 사용해 Consul을 설치하세요.

Kubernetes에 설치하고 ProxyDefaults 리소스를 생성한 후에는 기본 Kubernetes 클러스터에서 다음 정보를 내보내야 합니다.

  • 인증 기관 인증서와 키(VM용 SSL 인증서를 만들기 위해)
  • Kubernetes 메시 게이트웨이의 외부 주소
  • 복제 ACL 토큰
  • Gossip 암호화 키

다음 섹션은 이 데이터를 내보내는 방법을 자세히 설명합니다.

인증서 (Certificates)

  1. 인증 기관 인증서를 검색합니다. 
    kubectl get secrets/consul-ca-cert --namespace consul --template='{{index .data "tls.crt" | base64decode }}' > consul-agent-ca.pem
  2. 그리고 인증 기관 서명 키도 검색합니다. 
    kubectl get secrets/consul-ca-key --namespace consul --template='{{index .data "tls.key" | base64decode }}' > consul-agent-ca-key.pem
  3. consul-agent-ca.pem과 consul-agent-ca-key.pem 파일로 VM에서 실행되는 서버와 클라이언트용 인증서를 만들 수 있으며, Kubernetes 서버와 같은 인증 기관을 공유합니다. consul tls 명령으로 이러한 인증서를 생성할 수 있습니다. 
    # NOTE: consul-agent-ca.pem and consul-agent-ca-key.pem must be in the current
# directory.
$ consul tls cert create -server -dc=vm-dc -node <node_name>
==> WARNING: Server Certificates grants authority to become a
    server and access all state in the cluster including root keys
    and all ACL tokens. Do not distribute them to production hosts
    that are not server nodes. Store them as securely as CA keys.
==> Using consul-agent-ca.pem and consul-agent-ca-key.pem
==> Saved vm-dc-server-consul-0.pem
==> Saved vm-dc-server-consul-0-key.pem
    위 명령의 -node 옵션에 유의하세요. 이는 Consul Agent의 노드 이름과 같아야 합니다. 이것은 Consul Federation이 작동하기 위한 요구 사항입니다. 또는 모든 Consul 서버 노드에서 같은 인증서와 키 쌍을 사용할 계획이거나 노드 이름을 미리 알 수 없다면 대신 -node "*"를 사용하세요. 이 요구 사항을 충족하지 않으면 Consul Server 로그에 다음 오류가 발생합니다: [ERROR] agent.server.rpc: TLS handshake failed: conn=from= error="remote error: tls: bad certificate". 서버 인증서 생성의 더 많은 옵션은 consul tls cert create -h의 도움말을 참조하세요.
  4. 이 인증서는 서버 구성 파일에서 사용할 수 있습니다. server.hcl 
    tls {
  defaults {
    cert_file = "vm-dc-server-consul-0.pem"
    key_file = "vm-dc-server-consul-0-key.pem"
    ca_file = "consul-agent-ca.pem"
  }
}
  5. 클라이언트의 경우 다음으로 TLS 인증서를 생성할 수 있습니다. 
    $ consul tls cert create -client
==> Using consul-agent-ca.pem and consul-agent-ca-key.pem
==> Saved dc1-client-consul-0.pem
==> Saved dc1-client-consul-0-key.pem
    또는 auto_encrypt 기능을 사용하세요.

메시 게이트웨이 주소

메시 게이트웨이의 WAN 주소를 검색합니다.

$ kubectl exec statefulset/consul-server --namespace consul -- sh -c \
  'curl --silent --insecure https://localhost:8501/v1/catalog/service/mesh-gateway | jq ".[].ServiceTaggedAddresses.wan"'
{
  "Address": "1.2.3.4",
  "Port": 443
}
{
  "Address": "1.2.3.4",
  "Port": 443
}

이 예시에서 두 메시 게이트웨이 pod가 같은 Kubernetes 로드 밸런서 뒤에 있기 때문에 주소가 같습니다.

이 주소는 서버 구성에서 primary_gateways 설정에 사용됩니다.

primary_gateways = ["1.2.3.4:443"]

복제 ACL 토큰

ACL이 활성화되어 있으면 복제 ACL 토큰도 필요합니다.

$ kubectl get secrets/consul-acl-replication-acl-token --namespace consul --template='{{.data.token | base64decode}}'
e7924dd1-dc3f-f644-da54-81a73ba0a178

이 토큰은 서버 구성에서 복제 토큰으로 사용됩니다.

acls {
  tokens {
    replication = "e7924dd1-dc3f-f644-da54-81a73ba0a178"
  }
}

ACL 시스템이 요구하는 대로 추가 ACL 토큰을 설정해야 합니다. 자세한 내용은 ACLs 문서를 참조하세요.

Gossip 암호화 키

Gossip 암호화가 활성화되어 있으면 키도 필요합니다. 키를 검색하는 명령은 키를 저장한 Kubernetes 시크릿에 따라 달라집니다.

이 키는 서버와 클라이언트 구성에서 encrypt 설정에 사용됩니다.

encrypt = "uF+GsbI66cuWU21kiXLze5JLEX5j4iDFlDTb0ZWNpDI="

최종 구성 (Final Configuration)

최종 예시 서버 구성 파일은 다음과 같을 수 있습니다.

# From above
tls {
  defaults {
    cert_file = "vm-dc-server-consul-0.pem"
    key_file = "vm-dc-server-consul-0-key.pem"
    ca_file = "consul-agent-ca.pem"
  }

  internal_rpc {
    verify_incoming = true
    verify_outgoing = true
    verify_server_hostname = true
  }
}
primary_gateways = ["1.2.3.4:443"]
acl {
  enabled = true
  default_policy = "deny"
  down_policy = "extend-cache"
  tokens {
    agent = "e7924dd1-dc3f-f644-da54-81a73ba0a178"
    replication = "e7924dd1-dc3f-f644-da54-81a73ba0a178"
  }
}
encrypt = "uF+GsbI66cuWU21kiXLze5JLEX5j4iDFlDTb0ZWNpDI="

# Other server settings
server = true
datacenter = "vm-dc"
data_dir = "/opt/consul"
enable_central_service_config = true
primary_datacenter = "dc1"
connect {
  enabled = true
  enable_mesh_gateway_wan_federation = true
}
ports {
  https = 8501
  http = -1
  grpc = 8502
}

Kubernetes를 보조(Secondary)로 사용

기본 데이터센터를 VM에서 실행한다면 Kubernetes 클러스터를 보조로 페더레이션하려면 Federation Secret을 수동으로 구성해야 합니다. 또한 ACL이 활성화된 경우 기본 클러스터는 보조 클러스터의 Kubernetes API URL에 요청을 보낼 수 있어야 합니다.

VM 클러스터는 메시 게이트웨이를 실행 중이고 메시 게이트웨이 WAN 페더레이션이 활성화되어 있어야 합니다. WAN Federation via Mesh Gateways을 참조하세요.

다음이 필요합니다.

  1. consul-agent-ca.pem에 배치된 루트 인증 기관 인증서.
  2. consul-agent-ca-key.pem에 배치된 루트 인증 기관 키.
  3. VM 데이터센터에서 실행되는 메시 게이트웨이의 IP 주소. 이것은 Kubernetes 클러스터에서 라우팅 가능해야 합니다.
  4. ACL이 활성화된 경우 다음 규칙으로 ACL 복제 토큰을 만들어야 합니다. 
    acl = "write"
operator = "write"
agent_prefix "" {
  policy = "read"
}
node_prefix "" {
  policy = "write"
}
service_prefix "" {
  policy = "read"
  intentions = "read"
}
    이 토큰은 ACL 복제와 Kubernetes에서의 자동 ACL 관리를 위해 사용됩니다. Consul Enterprise를 실행하는 경우 다음 규칙이 필요합니다. 
    operator = "write"
agent_prefix "" {
  policy = "read"
}
node_prefix "" {
  policy = "write"
}
namespace_prefix "" {
  acl = "write"
  service_prefix "" {
    policy = "read"
    intentions = "read"
  }
}
  5. ACL이 활성화된 경우 anonymous token 정책에도 다음 권한을 주도록 수정해야 합니다. 
    node_prefix "" {
   policy = "read"
}
service_prefix "" {
   policy = "read"
}
    Consul Enterprise에서는 다음을 사용합니다. 
    partition_prefix "" {
  namespace_prefix "" {
    node_prefix "" {
      policy = "read"
    }
    service_prefix "" {
      policy = "read"
    }
  }
}
    이 권한은 교차 데이터센터 요청을 허용하는 데 필요합니다. 교차 DC 요청을 하려면 발신 DC의 사이드카 프록시가 원격 DC에서 실행되는 서비스에 대해 알아야 합니다. 이를 위해 프록시는 원격 DC의 서비스를 조회할 수 있는 ACL 토큰이 필요합니다. Kubernetes에서 토큰이 생성되는 방식으로 인해 사이드카 프록시는 로컬 ACL 토큰(로컬 DC에서만 유효한 토큰)을 가집니다. 한 DC에서 다른 DC로 요청이 갈 때 요청이 로컬 토큰을 가지면 원격 DC가 그것을 검증할 수 없으므로 요청에서 토큰이 제거됩니다. 요청이 다른 DC에 도착하면 ACL 토큰이 없으므로 anonymous token 정책의 적용을 받습니다. 이것이 anonymous token 정책이 모든 서비스에 대한 읽기 액세스를 허용하도록 구성되어야 하는 이유입니다. Kubernetes DC가 기본일 때는 자동으로 처리되지만, 기본 DC가 VM에 있으면 수동으로 구성해야 합니다. anonymous token 정책을 구성하려면 먼저 위의 규칙으로 정책을 만들고 anonymous token에 연결하세요. 예를 들어 CLI를 사용합니다. 
    echo 'node_prefix "" {
   policy = "read"
}
service_prefix "" {
   policy = "read"
}' | consul acl policy create -name anonymous -rules -

consul acl token update -id 00000000-0000-0000-0000-000000000002 -policy-name anonymous
  6. Gossip 암호화가 활성화되어 있으면 키가 필요합니다.

데이터를 준비했으면 Kubernetes 페더레이션 시크릿을 만들 수 있습니다.

kubectl create secret generic consul-federation \
    --from-literal=caCert=$(cat consul-agent-ca.pem) \
    --from-literal=caKey=$(cat consul-agent-ca-key.pem)
    # If ACLs are enabled uncomment.
    # --from-literal=replicationToken="<your acl replication token>" \
    # If using gossip encryption uncomment.
    # --from-literal=gossipEncryptionKey="<your gossip encryption key>"

ACL이 활성화되어 있으면 다음으로 보조 클러스터의 Kubernetes API URL을 결정해야 합니다. 모든 보조 클러스터의 구성 파일에 API URL을 지정해야 합니다. 보조 클러스터는 전역 Consul ACL 토큰(모든 데이터센터에서 유효한 토큰)을 만들어야 하고 이 토큰은 기본 데이터센터에서만 만들 수 있기 때문입니다. API URL을 설정하면 보조 클러스터는 기본 클러스터에 Consul auth method를 구성하여 보조 클러스터의 컴포넌트가 자체 Kubernetes ServiceAccount 토큰을 사용해 기본에서 전역 Consul ACL 토큰을 검색할 수 있게 합니다.

Kubernetes API URL을 결정하려면 먼저 kubeconfig에서 클러스터 이름을 가져옵니다.

$ export CLUSTER=$(kubectl config view -o jsonpath="{.contexts[?(@.name == \"$(kubectl config current-context)\")].context.cluster}")

그런 다음 API URL을 가져옵니다.

$ kubectl config view -o jsonpath="{.clusters[?(@.name == \"$CLUSTER\")].cluster.server}"
https://<some-url>

이 URL을 global.federation.k8sAuthMethodHost 설정에 사용합니다.

그런 다음 다음 Helm 구성 파일을 사용합니다.

global:
  name: consul
  datacenter: dc2
  tls:
    enabled: true
    caCert:
      secretName: consul-federation
      secretKey: caCert
    caKey:
      secretName: consul-federation
      secretKey: caKey

  # Delete this acls section if ACLs are disabled.
  acls:
    manageSystemACLs: true
    replicationToken:
      secretName: consul-federation
      secretKey: replicationToken

  federation:
    enabled: true
    k8sAuthMethodHost: <kubernetes-api-url>
    primaryDatacenter: dc1

  # Delete this gossipEncryption section if gossip encryption is disabled.
  gossipEncryption:
    secretName: consul-federation
    secretKey: gossipEncryptionKey

connectInject:
  enabled: true
meshGateway:
  enabled: true
server:
  extraConfig: |
    {
      "primary_gateways": ["<ip of your VM mesh gateway>", "<other ip>", ...]
    }

참고:

  1. server.extraConfig 섹션을 VM에서 실행되는 메시 게이트웨이의 IP로 채워야 합니다.
  2. global.federation.k8sAuthMethodHost를 이 클러스터의 Kubernetes API URL(https:// 포함)로 설정합니다.
  3. global.federation.primaryDatacenter는 기본 데이터센터의 이름으로 설정해야 합니다.

구성 파일을 준비했으면 Installation Guide를 따라 보조 클러스터에 Consul을 설치하세요.

설치 후 consul-helm 0.30.0+를 사용한다면 데이터센터 간 트래픽을 허용하는 ProxyDefaults 리소스를 생성하세요.

다음 단계 (Next steps)

두 경우(Kubernetes가 기본 또는 보조) 모두 설치 후 Verifying Federation 섹션을 따라 페더레이션이 예상대로 작동하는지 확인하세요.

더 알아보기 (Learn more)