이 문서에서는 Google Distributed Cloud에서 클러스터에 대한 Network Connectivity Gateway를 구성하는 방법을 보여줍니다.
때로는 클러스터에서 실행 중인 포드가 Virtual Private Cloud(VPC)에서 실행 중인 워크로드와 통신해야 하는 경우가 있습니다. 이 통신은 안전해야 합니다. 그리고 프록시 서버를 사용하지 않고 평면적인 네트워크에서 이 통신을 수행해야 할 수 있습니다. Network Connectivity Gateway는 이러한 종류의 통신을 가능하게 해줍니다.
Network Connectivity Gateway는 클러스터에서 포드로 실행됩니다. 다음 다이어그램에 표시된 것처럼 이 솔루션은 클러스터의 포드에서 VPC의 VM으로 이동하는 트래픽에 대한 IPsec 터널을 제공합니다. 게이트웨이 포드는 Border Gateway Protocol(BGP) 세션을 통해 VPC 서브넷의 프리픽스를 수신할 때 Dataplane V2를 사용하여 전달을 설정합니다. 다른 포드가 이러한 프리픽스 중 하나를 포함하는 주소로 트래픽을 전송하면 트래픽이 게이트웨이 포드로 유도됩니다. 그런 후 게이트웨이 포드가 IPsec 터널을 통해 Google Cloud로 트래픽을 라우팅합니다.
Network Connectivity Gateway는 다음 특성 및 기능을 지원하지 않습니다.
- HA VPN용 IPv6(및 BGP)
- BGP용 MD5
- BGP용 양방향 전달 감지(BFD)
Google Cloud 리소스 만들기
클러스터에서 Network Connectivity Gateway를 사용 설정하기 전 다음 Google Cloud 리소스를 준비해야 합니다.
Cloud Router
HA VPN 게이트웨이
피어 VPN 게이트웨이: 인터페이스 하나
2개 VPN 터널
2개 BGP 세션: 각 VPN 터널당 하나씩
이러한 리소스를 만들고 구성하는 방법은 피어 VPN 게이트웨이에 대한 HA VPN 게이트웨이 만들기를 참조하세요.
이러한 리소스를 만들 때 다음 정보를 수집하고 나중에 사용할 수 있도록 준비합니다.
Google Cloud가 HA VPN 게이트웨이에 할당한 2개의 외부 IP 주소.
조직에서 나가는 IPsec/VPN 트래픽에 대한 공개 IP 주소. 이 주소는 네트워크 주소 변환(NAT)의 결과일 수 있습니다.
사전 공유 키.
BGP 세션에 대해 Cloud Router에 할당한 자율 시스템 번호(ASN).
BGP 세션에 대해 온프레미스 클러스터에서 사용하도록 선택한 ASN.
각 BGP 세션에 대해
169.254.1.1과 같은 Cloud Router에 사용할 링크-로컬 주소 및 온프레미스 클러스터에 사용할 링크 로컬 주소.
BGP 세션 구성의 세부정보를 찾는 방법은 BGP 세션 구성을 참조하세요.
클러스터 요구사항
Network Connectivity Gateway 명령줄 도구 다운로드 ncgctl-v1.12.0-linux-amd64.tar.gz는 버전 1.12 Google Distributed Cloud와만 호환됩니다. 새 버전 1.12.0 클러스터를 만드는 경우 클러스터 구성 파일에 주석으로 Network Connectivity Gateway를 사용 설정합니다.
클러스터 생성 중에 Network Connectivity Gateway를 사용 설정하려면 다음 안내를 따르세요.
클러스터 구성 파일에서
baremetal.cluster.gke.io/enable-gng: "true"주석을 추가합니다.apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: annotations: baremetal.cluster.gke.io/enable-gng: "true" name: my-cluster namespace: cluster-my-cluster spec: ... anthosBareMetalVersion: 1.12.0 ...bmctl create를 사용하여 클러스터를 만듭니다.bmctl create cluster -c CLUSTER_NAMECLUSTER_NAME을 클러스터 구성 파일을 만들 때 지정한 이름으로 바꿉니다. 클러스터 만들기에 대한 자세한 내용은 클러스터 만들기 개요를 참조하세요.
다운로드
Network Connectivity Gateway 명령줄 도구인 ncgctl을 다운로드하려면 다음 단계를 수행합니다.
Network Connectivity Gateway 구성요소 및 커스텀 리소스 정의를 다운로드합니다.
gcloud storage cp gs://ncg-release/anthos-baremetal/ncgctl-v1.12.0-linux-amd64.tar.gz .아카이브를 추출합니다.
tar -xvzf ncgctl-v1.12.0-linux-amd64.tar.gz
설치
ncgctl을 설치하려면 다음 단계를 수행합니다.
실행 전 검사를 실행하여 클러스터가 기본 요건을 충족하는지 확인합니다. 예를 들어 Dataplane V2가 사용 설정되었는지 확인합니다.
./bin/ncgctl --verify --kubeconfig CLUSTER_KUBECONFIGCLUSTER_KUBECONFIG를 클러스터 kubeconfig 파일의 경로로 바꿉니다.Network Connectivity Gateway를 설치합니다.
./bin/ncgctl --install --kubeconfig CLUSTER_KUBECONFIG기존 1.12.0 클러스터가 있는 경우 다음
ncgctl명령어를 사용하여 Network Connectivity Gateway를 사용 설정할 수 있습니다../bin/ncgctl --enable-ncg-on-existing-clusterncgctl명령어는-e를 사용 설정 플래그의 짧은 버전으로 허용합니다.추가 단축키와 기타 명령어 도움말을 보려면 다음 명령어를 사용합니다.
./bin/ncgctl --help
사전 공유 키의 보안 비밀 만들기
IPsec 터널 끝의 게이트웨이는 인증을 위해 사전 공유 키를 포함하는 보안 비밀을 사용합니다.
보안 비밀을 만들려면 다음 단계를 따르세요.
다음 보안 비밀 매니페스트 세부정보를 사용하여
psk-secret.yaml이라는 파일을 만듭니다.apiVersion: v1 kind: Secret metadata: name: "ike-key" namespace: "kube-system" data: psk: PRE_SHARED_KEYPRE_SHARED_KEY를 base64-encoded 사전 공유 키로 바꿉니다. 키가 일반 텍스트로 되어 있으면 이 보안 비밀을 만들기 전 base64 형식으로 키를 인코딩합니다. 예를 들어 Google Cloud 콘솔에서 키가 생성된 경우 일반 텍스트로 되어 있으며, 이를 인코딩해야 합니다. 키를 base64로 인코딩하려면 다음 안내를 따르세요.echo -n PLAINTEXT_KEY | base64보안 비밀을 만듭니다.
kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f psk-secret.yaml
OverlayVPNTunnel 커스텀 리소스 2개 만들기
2개의 IPsec 세션을 시작하려면 2개의 OverlayVPNTunnel 커스텀 리소스를 만듭니다.
다음
OverlayVPNTunnel매니페스트 세부정보를 사용하여overlay-vpn-tunnels.yaml이라는 파일을 만듭니다.apiVersion: networking.gke.io/v1alpha1 kind: OverlayVPNTunnel metadata: namespace: "kube-system" name: TUNNEL_1_NAME spec: ikeKey: name: "ike-key" namespace: "kube-system" peer: publicIP: PEER_PUBLIC_IP_1 self: publicIP: SELF_PUBLIC_IP localTunnelIP: SELF_LOCAL_TUNNEL_IP_1 --- apiVersion: networking.gke.io/v1alpha1 kind: OverlayVPNTunnel metadata: namespace: "kube-system" name: TUNNEL_2_NAME spec: ikeKey: name: "ike-key" namespace: "kube-system" peer: publicIP: PEER_PUBLIC_IP_2 self: publicIP: SELF_PUBLIC_IP localTunnelIP: SELF_LOCAL_TUNNEL_IP_2다음을 바꿉니다.
TUNNEL_NAME_1: 첫 번째OverlayVPNTunnel에 대해 선택한 이름입니다.TUNNEL_NAME_2: 두 번째OverlayVPNTunnel에 대해 선택한 이름입니다.PEER_PUBLIC_IP_1: HA VPN 게이트웨이에서 한 인터페이스의 공개 IP 주소입니다. 이 인터페이스는 처음 VPN 터널을 만들 때 지정되었습니다.PEER_PUBLIC_IP_2: HA VPN 게이트웨이에서 다른 인터페이스의 공개 IP 주소입니다. 이 인터페이스는 두 번째 VPN 터널을 만들었을 때 지정되었습니다.SELF_LOCAL_TUNNEL_IP_1: 첫 번째 터널을 통해 BGP 세션에 대해 클러스터에 사용할 링크-로컬 주소입니다.SELF_LOCAL_TUNNEL_IP_2: 두 번째 터널을 통해 BGP 세션에 대해 클러스터에 사용할 링크-로컬 주소입니다.SELF_PUBLIC_IP: 조직에서 나가는 IPsec/VPN 트래픽에 대한 공개 IP 주소입니다. 이 주소는 네트워크 주소 변환(NAT)의 결과일 수 있습니다.
2개의
OverlayVPNTunnels를 만듭니다.kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f overlay-vpn-tunnels.yaml터널 상태를 확인합니다.
kubectl --kubeconfig CLUSTER_KUBECONFIG get OverlayVPNTunnel \ --namespace kube-system --output yaml
OverlayBGPPeer 커스텀 리소스 2개 만들기
각 터널을 통해 BGP 세션을 시작하려면 2개의 OverlayBGPPeer 커스텀 리소스를 만듭니다.
다음
OverlayBGPPeer매니페스트 세부정보를 사용하여overlay-bgp-peers.yaml이라는 파일을 만듭니다.apiVersion: networking.gke.io/v1alpha1 kind: OverlayBGPPeer metadata: namespace: "kube-system" name: BGP_PEER_1_NAME spec: localASN: LOCAL_ASN localIP: LOCAL_IP peerIP: PEER_IP_1 peerASN: PEER_ASN vpnTunnel: TUNNEL_1_NAME --- apiVersion: networking.gke.io/v1alpha1 kind: OverlayBGPPeer metadata: namespace: "kube-system" name: BGP_PEER_2_NAME spec: localASN: LOCAL_ASN localIP: LOCAL_IP peerIP: PEER_IP_2 peerASN: PEER_ASN vpnTunnel: TUNNEL_2_NAME다음을 바꿉니다.
BGP_PEER_1_NAME: 첫 번째OverlayBGPPeer에 대해 선택한 이름입니다.BGP_PEER_2_NAME: 두 번째OverlayBGPPeer에 대해 선택한 이름입니다.LOCAL_ASN: BGP 세션에 대해 클러스터에 사용할 ASN입니다.LOCAL_IP: 조직에서 나가는 IPsec/VPN 트래픽에 대한 공개 IP 주소입니다. 이 주소는 네트워크 주소 변환(NAT)의 결과일 수 있습니다.PEER_IP_1: HA VPN 게이트웨이에서 한 인터페이스의 공개 IP 주소입니다. 이 인터페이스는 처음 VPN 터널을 만들 때 지정되었습니다.PEER_IP_2: HA VPN 게이트웨이에서 다른 인터페이스의 공개 IP 주소입니다. 이 인터페이스는 두 번째 VPN 터널을 만들었을 때 지정되었습니다.PEER_ASN: BGP 세션에 대해 Cloud Router에 할당된 ASN입니다.TUNNEL_1_NAME: 이전에 만든 첫 번째 OverlayVPNTunnel의 이름입니다.TUNNEL_2_NAME: 이전에 만든 두 번째 OverlayVPNTunnel의 이름입니다.
OverlayBGPPeer커스텀 리소스를 만듭니다.kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f overlay-bgp-peers.yamlBGP 세션의 상태를 확인합니다.
kubectl --kubeconfig CLUSTER_KUBECONFIG get OverlayBGPPeer --namespace kube-system \ --output yaml
Network Connectivity Gateway의 상태 확인
설치로 NetworkConnectivityGateway 커스텀 리소스가 생성되었습니다.
NetworkConnectivityGateway커스텀 리소스를 확인합니다.kubectl --kubeconfig CLUSTER_KUBECONFIG get NetworkConnectivityGateway --namespace kube-system \ --output yaml출력은 다음과 비슷합니다.
Status: Healthy가 표시되는지 확인합니다.apiVersion: networking.gke.io/v1alpha1 kind: NetworkConnectivityGateway metadata: namespace: kube-system name: default spec: status: CurrNode: worker1-node CreatedTime: 2021-09-07T03:18:15Z LastReportTime: 2021-09-21T23:57:54Z Status: Healthy
Network Connectivity Gateway 로그 확인
게이트웨이 포드는 ncgd라는 DaemonSet에 속하므로 포드 이름이 ncgd로 시작합니다.
Network Connectivity Gateway 로그를 보려면 다음 단계를 수행합니다.
게이트웨이 포드의 이름을 찾습니다.
kubectl --kubeconfig CLUSTER_KUBECONFIG pods --namespace kube-system | grep ncgd게이트웨이 포드의 로그를 봅니다.
kubectl --kubeconfig CLUSTER_KUBECONFIG logs GATEWAY_POD --namespace kube-system \ --output yamlGATEWAY_POD를 게이트웨이 포드 이름으로 바꿉니다.
제거
클러스터에서 Network Connectivity Gateway를 제거하려면 다음 안내를 따르세요.
./bin/ncgctl –-uninstall --kubeconfig CLUSTER_KUBECONFIG
문제 해결
Network Connectivity Gateway와 관련된 문제 해결 팁은 Network Connectivity Gateway 문제 해결을 참조하세요.