노드 네트워킹

이 항목에서는 노드 IP 주소 사용자 지정 및 vSphere DHCP 예약, 노드 IPAM 및 IPv6 구성을 포함하여 워크로드 클러스터에 대한 노드 네트워킹을 사용자 지정하는 방법을 설명합니다.

노드 DHCP 예약 및 끝점 DNS 레코드 구성(vSphere 전용)

vSphere 새 클러스터의 경우 해당 노드에 대한 DHCP 예약을 생성해야 하며 제어부 끝점에 대한 DNS 레코드를 생성해야 할 수도 있습니다.

클러스터 노드에 대한 DHCP 예약:

여러 제어부 노드의 전원이 꺼지거나 장기간 오프라인 상태가 될 수 있는 환경에서 안전 예방 조치로 주소가 정적으로 유지되고 임대가 만료되지 않도록 새로 생성된 클러스터의 제어부 및 Worker 노드의 IP 주소에 대한 DHCP 예약을 조정합니다.

DHCP 예약을 구성하는 방법에 대한 지침은 DHCP 서버 설명서를 참조하십시오.
제어부 끝점에 대한 DNS 레코드:

제어부 끝점에 Kube-Vip가 아닌 NSX Advanced Load Balancer를 사용하고 VSPHERE_CONTROL_PLANE_ENDPOINT를 숫자 IP 주소가 아닌 FQDN으로 설정하는 경우 다음과 같이 주소를 예약합니다.
1. NSX ALB가 클러스터에 할당된 제어부 IP 주소를 검색합니다.
```
kubectl get cluster CLUSTER-NAME -o=jsonpath='{.spec.controlPlaneEndpoint} {"\n"}'
```
2. 출력에 "host"로 표시된 IP 주소를 기록합니다(예: 192.168.104.107).
3. FQDN을 기록한 IP 주소에 연결하는 DNS A 레코드를 생성합니다.
4. FQDN을 테스트하려면 NSX ALB의 IP 주소 대신 FQDN을 사용하는 새 kubeconfig를 생성합니다.
  1. kubeconfig를 생성합니다.
```
tanzu cluster kubeconfig get CLUSTER-NAME --admin --export-file ./KUBECONFIG-TEST
```
  2. kubeconfig 파일 KUBECONFIG-TEST를 편집하여 IP 주소를 FQDN으로 변경합니다. 예를 들어 다음
```
server: https://192.168.104.107:443
```
    다음으로 대체합니다.
```
server: https://CONTROLPLANE-FQDN:443
```
  3. 수정된 kubeconfig를 사용하여 클러스터의 포드를 검색합니다.
```
kubectl get pods -A --kubeconfig=./KUBECONFIG-TEST
```
    출력에 포드가 나열되면 DNS가 FQDN에 대해 작동합니다.

클러스터 노드 IP 주소 사용자 지정(독립형 MC)

독립형 관리 클러스터와 배포하는 워크로드 클러스터의 노드에 클러스터별 IP 주소 블록을 구성할 수 있습니다. 이 작업을 수행하는 방법은 클러스터가 실행되는 클라우드 인프라에 따라 다릅니다.

vSphere

vSphere에서 클러스터 구성 파일의 VSPHERE_NETWORK는 Tanzu Kubernetes Grid가 클러스터 노드 및 기타 Kubernetes 개체에 사용하는 VM 네트워크를 설정합니다. IP 주소는 Tanzu Kubernetes Grid와 별도로 배포된 이 VM 네트워크에서 실행되는 DHCP 서버에 의해 노드에 할당됩니다.

NSX 네트워킹을 사용하는 경우 VMware NSX-T Data Center 설명서에서 세그먼트에서 DHCP 고정 바인딩 구성을 수행하여 클러스터 노드의 DHCP 바인딩을 구성할 수 있습니다.

참고
v4.0 이상의 경우 VMware NSX-T Data Center 이름이 "VMware NSX"로 변경됩니다.

AWS

AWS(Amazon Web Services)에서 클러스터별 IP 주소 블록을 구성하려면 구성 파일 변수 참조의 AWS 테이블에 설명된 대로 클러스터 구성 파일에서 다음 변수를 설정합니다.

공용 노드의 IP 주소 범위를 설정하려면 AWS_PUBLIC_NODE_CIDR를 설정합니다.
- AWS_PRIVATE_NODE_CIDR_1 또는 AWS_PRIVATE_NODE_CIDR_2를 설정하여 추가 범위를 사용할 수 있도록 합니다.
개인 노드의 IP 주소 범위를 설정하려면 AWS_PRIVATE_NODE_CIDR을 설정합니다.
- AWS_PRIVATE_NODE_CIDR_1 및 AWS_PRIVATE_NODE_CIDR_2를 설정하여 추가 범위를 사용할 수 있도록 합니다.
모든 노드 CIDR 범위는 클러스터의 VPC 범위 내에 있어야 합니다. 기본값은 10.0.0.0/16입니다.

Microsoft Azure

Azure에서 클러스터별 IP 주소 블록을 구성하려면 구성 파일 변수 참조의 Microsoft Azure 테이블에 설명된 대로 클러스터 구성 파일에서 다음 변수를 설정합니다.

Worker 노드 IP 주소의 CIDR 블록을 사용하여 새 VNet을 생성하려면 AZURE_NODE_SUBNET_CIDR을 설정합니다.
제어부 노드 IP 주소의 CIDR 블록을 사용하여 새 VNet을 생성하려면 AZURE_CONTROL_PLANE_SUBNET_CIDR을 설정합니다.
기존 VNet의 범위에서 Worker 노드 IP 주소를 할당하려면 AZURE_NODE_SUBNET_NAME을 설정합니다.
기존 VNet의 범위에서 제어부 노드 IP 주소를 할당하려면 AZURE_CONTROL_PLANE_SUBNET_NAME을 설정합니다.

노드 IPAM(vSphere)

노드 IPAM을 사용하면 클러스터 내 IPAM 제공자는 클러스터 생성 및 확장/축소 중에 클러스터 노드의 IP 주소를 할당 및 관리하므로 외부 DHCP를 구성할 필요가 없습니다.

vSphere의 독립형 관리 클러스터 및 해당 클러스터가 관리하는 클래스 기반 워크로드 클러스터의 노드 IPAM을 구성할 수 있습니다. 아래 절차에서는 클래스 기반 워크로드 클러스터에 대한 노드 IPAM을 구성합니다. 관리 클러스터에 대한 노드 IPAM을 구성하려면 vSphere용 관리 클러스터 구성에서 노드 IPAM 구성을 참조하십시오.

참고
이 절차는 vSphere with Tanzu Supervisor가 있거나 AWS 또는 Azure의 독립형 관리 클러스터가 있는 TKG에는 적용되지 않습니다.

새 워크로드 클러스터 또는 기존 워크로드 클러스터에 대해 노드 IPAM을 구성할 때 사용자는 IPAM 제공자가 정적 IP 주소를 할당하는 내부 IP 풀과 게이트웨이 주소를 지정합니다.

클러스터 노드에 주소를 할당할 때 노드 IPAM은 항상 풀에서 사용 가능한 가장 낮은 주소를 선택합니다.

사전 요구 사항

TKG 독립형 관리 클러스터
워크로드 클러스터의 제어부 및 Worker 노드에 대한 네임서버
- 클러스터 노드가 더 이상 DHCP를 통해 네임서버를 수신하여 vCenter에서 이름을 확인하지 않으므로 필요합니다.
kubectl 및 Tanzu CLI가 로컬로 설치됨

제한 사항

노드 IPAM에는 TKG v2.3에서 다음과 같은 제한 사항이 있습니다.

vSphere 관리 클러스터에 의해 배포된 신규 클래스 기반 워크로드 클러스터에만 해당됩니다.
- 기존 DHCP 기반 클러스터를 노드 IPAM으로 변환할 수 없습니다.
Windows 노드는 지원되지 않습니다.
이중 스택이 아닌 IPv4 또는 IPv6 환경에만 해당합니다.
클러스터 제어부 끝점이 아닌 노드 주소만 할당합니다.
노드 IPAM은 해당 IP 풀이 다른 클러스터에서 이미 사용 중인 DHCP 풀과 충돌하는지 여부를 확인하지 않습니다.

워크로드 클러스터용 노드 IPAM 구성

워크로드 클러스터의 노드 IPAM 풀은 주소가 다른 클러스터와 공유되는 방식에 따라 두 가지 다른 개체 유형으로 정의할 수 있습니다.

InClusterIPPool은 동일한 관리 클러스터 네임스페이스의 워크로드 클러스터에서만 사용할 수 있는 IP 풀(예: default)을 구성합니다.
- TKG v2.1 및 v2.2에서 사용할 수 있는 유일한 유형입니다.
GlobalInClusterIPPool은 여러 네임스페이스에서 워크로드 클러스터에 할당할 수 있는 주소로 IP 풀을 구성합니다.

노드 IPAM을 사용하여 새 클러스터 또는 기존 클러스터를 구성하려면 다음을 수행합니다.

TKG가 워크로드 클러스터에 정적 IP 주소를 할당하는 데 사용할 수 있는 서브넷의 IP 주소 범위를 설정하는 my-ip-pool.yaml IP 풀 개체 정의를 생성합니다. IP 풀의 범위를 지정하는 방법에 따라 개체를 InClusterIPPool 또는 GlobalInClusterIPPool로 정의합니다. 예를 들면 다음과 같습니다.
- InClusterIPPool: 네임스페이스 10.10.10.2-10.10.10.100 및 10.10.10.102 ~ 10.10.10.104 범위가 포함된 네이스페이스 default의 워크로드 클러스터에 IP 풀 inclusterippool을 생성하려면:
```
apiVersion: ipam.cluster.x-k8s.io/v1alpha2
kind: InClusterIPPool
metadata:
  name: inclusterippool
  namespace: default
spec:
  gateway: 10.10.10.1
  addresses:
  - 10.10.10.2-10.10.10.100
  - 10.10.10.102
  - 10.10.10.104
  prefix: 24
```
  참고
  이전 TKG 버전은 InClusterIPPool 개체의 valpha1 버전을 사용했으며, 이는 TKG v2.1 설명서에 설명된 대로 start 및 end에 의해 지정된 연속 IP 풀 범위만 지원했습니다. 클러스터를 v2.3으로 업그레이드하면 해당 IP 풀이 새 구조로 변환됩니다.
- GlobalInClusterIPPool: 위의 InClusterIPPool과 동일한 주소를 포함하는 네임스페이스 간에 공유하는 IP 풀 inclusterippool을 생성하려면:
```
apiVersion: ipam.cluster.x-k8s.io/v1alpha2
kind: GlobalInClusterIPPool
metadata:
  name: inclusterippool
spec:
  gateway: 10.10.10.1
  addresses:
  - 10.10.10.2-10.10.10.100
  - 10.10.10.102
  - 10.10.10.104
  prefix: 24
```
IP 풀 개체를 생성합니다.
```
kubectl apply -f my-ip-pool.yaml
```

구성 파일에 설명된 대로 플랫 클러스터 구성 파일 또는 Kubernetes 스타일 개체 규격 내에서 IP 풀을 사용하도록 워크로드 클러스터를 구성합니다.

예:

플랫 구성 파일(새 클러스터를 생성):

# The name of the InClusterIPPool object specified above
NODE_IPAM_IP_POOL_NAME: inclusterippool
CONTROL_PLANE_NODE_NAMESERVERS: 10.10.10.10,10.10.10.11
WORKER_NODE_NAMESERVERS: 10.10.10.10,10.10.10.11

개체 규격(새 클러스터를 생성하거나 기존 클러스터를 수정):

---
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
spec:
topology:
  variables:
  - name: network
    value:
      addressesFromPools:
      - apiGroup: ipam.cluster.x-k8s.io
        kind: InClusterIPPool
        name: inclusterippool
  - name: controlplane
    value:
      network:
        nameservers: [10.10.10.10,10.10.10.11]
  - name: worker
    value:
      network:
        nameservers: [10.10.10.10,10.10.10.11]

이제 워크로드 클러스터를 배포할 수 있습니다.

풀 규칙

IP 풀 범위는 겹치지 않아야 합니다.
- 풀이 겹치면 오류가 발생할 수 있으며 TKG는 풀 범위를 검증하지 않거나 겹침을 감지하지 않습니다.
현재 할당된 IP 주소를 IP 풀에서 제거하지 마십시오.

노드 IPAM 문제 해결

클러스터 노드에 IP 주소가 할당되었는지 확인하려면 kubectl get을 실행하여 IaaS별 시스템 개체인 vspherevms를 나열하고 IPAddressClaimed 상태를 확인합니다. True는 노드의 주소 할당이 성공하고 상태가 False이면 명령 출력에서 조건이 준비되지 않은 이유를 Reason을 보고합니다.
```
kubectl -n CLUSTER-NAMESPACE get vspherevms
```
IP 주소 할당을 보려면 ipaddressclaims를 나열합니다. 각 시스템에 대해 addressesFromPools 항목으로 인해 하나의 IPAddressClaim이 생성됩니다.
```
kubectl -n CLUSTER-NAMESPACE get ipaddressclaims
```
IP 주소를 보려면 ipaddress를 나열합니다. 클러스터 내 IPAM 제공자는 각 IPAddressClaim을 감지하고 해당하는 IPAddress 개체를 생성해야 합니다.
```
kubectl -n CLUSTER-NAMESPACE get ipaddress
```
지정된 VM에 대한 모든 클레임이 IP 주소와 일치하면 CAPV는 할당된 IP 주소를 VM의 cloud-init 메타데이터에 기록하고 VM을 생성합니다. IP 주소 조정 단계를 보려면 CAPV 및 클러스터 API CAIP(IPAM 제공자) 로그를 참조하십시오.
```
kubectl logs -n capv-system capv-controller-manager
kubectl logs -n caip-in-cluster-system capi-in-cluster-controller-manager
```

IPv6 네트워킹(vSphere)

Ubuntu 기반 노드를 사용하여 Kube-Vip가 있는 vSphere IPv6 전용 싱글 스택 네트워킹 환경에서 관리 및 워크로드 클러스터를 실행할 수 있습니다.

참고 vSphere with Tanzu Supervisor 클러스터를 사용하여 IPv6 클러스터를 생성할 수 없습니다. Tanzu Mission Control에 IPv6 클러스터를 등록할 수 없습니다. NSX Advanced Load Balancer 서비스 및 이중 스택 IPv4/IPv6 네트워킹은 현재 지원되지 않습니다.

사전 요구 사항:

부트스트랩 클러스터에서 연결할 수 있는 IPv6 주소의 vSphere를 구성합니다
부트스트랩 클러스터에서 연결할 수 있는 IPv6 주소를 사용하여 Docker 데몬에서 DNS 확인자를 구성합니다.
IPv6 클러스터를 IPv4 네트워크에 연결해야 할 때 일반적인 경우 프록시 구성에 설명된 대로 HTTP 프록시를 구성합니다.

IPv6 관리 클러스터 배포

부트스트랩 시스템에서 다음을 수행하여 관리 클러스터를 IPv6 네트워킹 환경에 배포합니다.

Docker 서비스가 시작될 때 라우팅 테이블에서 기본 IPv6 경로가 제거되지 않도록 라우터 알림을 수락하도록 Linux를 구성합니다. 자세한 내용은 Docker CE가 IPv6 Default 경로를 삭제를 참조하십시오. sudo sysctl net.ipv6.conf.eth0.accept_ra=2
부트스트랩 클러스터에서 송신 트래픽을 전송하는 부트스트랩 클러스터의 가상 규칙을 생성합니다. sudo ip6tables -t nat -A POSTROUTING -s fc00:f853:ccd:e793::/64 ! -o docker0 -j MASQUERADE 가상 규칙에 대한 자세한 내용은 가상을 참조하십시오.
관리 클러스터에 다음의 구성 파일의 변수를 설정합니다.
- TKG_IP_FAMILY을 ipv6로 설정합니다.
- VSPHERE_CONTROL_PLANE_ENDPOINT를 고정 IPv6 주소로 설정합니다.
- (선택 사항) CLUSTER_CIDR and SERVICE_CIDR을 설정합니다. 기본값은 각각 fd00:100:64::/48 및 fd00:100:96::/108입니다.
구성 파일에서 관리 클러스터 배포에 설명된 대로 tanzu mc create를 실행하여 관리 클러스터를 배포합니다.
- IPv6를 지원하려면 설치 관리자 인터페이스가 아닌 구성 파일에서 관리 클러스터를 배포해야 합니다.

IPv6 워크로드 클러스터 배포

IPv6 관리 클러스터를 배포한 경우 다음과 같이 IPv6 워크로드 클러스터를 배포합니다.

워크로드 클러스터에 다음의 구성 파일의 변수를 설정합니다.
- TKG_IP_FAMILY을 ipv6로 설정합니다.
- VSPHERE_CONTROL_PLANE_ENDPOINT를 고정 IPv6 주소로 설정합니다.
- (선택 사항) CLUSTER_CIDR and SERVICE_CIDR을 설정합니다. 기본값은 각각 fd00:100:64::/48 및 fd00:100:96::/108입니다.
워크로드 클러스터 생성에 설명된 대로 워크로드 클러스터를 배포합니다.

이중 스택 클러스터(기술 미리보기)

참고
이 기능은 지원되지 않는 기술 미리보기 상태입니다. TKG 기능 상태를 참조하십시오.

이중 스택 기능을 사용하면 IPv4 및 IPv6 IP 제품군을 사용하여 클러스터를 배포할 수 있습니다. 그러나 기본 IP 패밀리는 IPv4입니다. 이 기능을 실험하기 전에 IPv4 및 IPv6 연결을 모두 지원하도록 vCenter Server를 구성합니다.

다음은 이 릴리스의 이중 스택 기능 제한 사항입니다.

이중 스택 기능은 vSphere IaaS(Infrastructure as a Service) 제품으로만 지원합니다.
Photon OS 노드가 있는 클러스터에서는 이중 스택을 구성할 수 없습니다. ubuntu의 OS_NAME으로 구성된 클러스터만 지원됩니다.
vSphere with Tanzu Supervisor 클러스터 또는 해당 클러스터가 생성하는 워크로드 클러스터에 대해 이중 스택 네트워킹을 구성할 수 없습니다.
설치 관리자 인터페이스를 사용하여 이중 스택 관리 클러스터를 배포할 수 없습니다.
ALB(NSX Advanced Load Balancer)에서 제공된 로드 밸런서 서비스에서는 이중 스택 또는 IPv6 서비스를 사용할 수 없습니다. kube-vip를 이중 스택 클러스터의 제어부 끝점 제공자로 사용할 수 있습니다. 이중 스택 클러스터에 대한 제어부 끝점 제공자로 NSX ALB를 사용하는 것이 검증되지 않았습니다.
Antrea, Calico, CSI, CPI, Pinniped와 같은 핵심 추가 기능 구성 요소만 이 릴리스에서 이중 스택 지원을 위해 검증되었습니다.

클러스터에서 이중 스택을 구성하려면 다음을 수행합니다.

이중 스택 기능 플래그를 설정합니다.

a. 관리 클러스터에서 기능을 사용하도록 설정하려면 다음 명령을 실행합니다.
```
tanzu config set features.management-cluster.dual-stack-ipv4-primary true
```
B. 워크로드 클러스터에서 기능을 사용하도록 설정하려면 다음 명령을 실행합니다.
```
tanzu config set features.cluster.dual-stack-ipv4-primary true
```
필요에 따라 관리 클러스터 또는 워크로드 클러스터 생성.

클러스터 구성 파일에서 다음을 수행합니다.
- IP 패밀리 구성 변수 TKG_IP_FAMILY: ipv4,ipv6을 설정합니다.
- 필요한 경우 서비스 CIDR 및 클러스터 CIDR을 설정합니다.
참고
각 변수에는 두 개의 CIDR이 있습니다. 이러한 CIDR의 IP 패밀리는 구성된 TKG_IP_FAMILY의 순서를 따릅니다. IPv4 주소에 허용되는 가장 큰 CIDR 범위는 /12이고 가장 큰 IPv6 SERVICE_CIDR 범위는 /108입니다. CIDR을 설정하지 않으면 기본값이 사용됩니다.
- Antrea를 클러스터의 CNI로 사용하는 경우 다음 구성 파일 매개 변수를 설정합니다.
```
ANTREA_ENDPOINTSLICES: true
```
이제 PreferDualStack 또는 RequireDualStack 규격에 지정된 ipFamilyPolicy가 있는 서비스에 IPv4 또는 IPv6을 통해 액세스할 수 있습니다.

참고
업스트림 Kubernetes의 이중 스택 기능에 대한 종단 간 테스트는 클러스터 노드가 기본 IP 주소(이 경우 IPv4 주소)만 IP 주소로 전파하기 때문에 실패할 수 있습니다.