이 문서에서는 포드에 다중 네트워크 인터페이스 즉, 멀티 NIC를 제공하도록 VMware용 Google Distributed Cloud(소프트웨어만 해당)를 구성하는 방법을 설명합니다. 포드에 대한 멀티 NIC 기능은 데이터 영역 트래픽에서 컨트롤 플레인 트래픽을 분리하는 데 도움을 주고, 영역 간 격리를 생성합니다. 추가 네트워크 인터페이스는 또한 포드에 대한 멀티캐스트 기능을 사용 설정합니다. 포드의 멀티 NIC는 사용자 클러스터에 대해 지원되며, 관리자 클러스터에는 허용되지 않습니다.
네트워크 영역 격리는 광역 통신망의 소프트웨어 정의 네트워킹(SD-WAN), 클라우드 접근 보안 브로커(CASB), 차세대 방화벽(NG-FW)와 같은 네트워크 기능 가상화(NFV)를 사용하는 시스템에 중요합니다. 이러한 유형의 NFV에서는 제어 영역과 데이터 영역을 구분하기 위해 여러 인터페이스에 대한 액세스가 필요합니다.
다중 네트워크 인터페이스 구성은 성능 이점을 제공할 수 있는 네트워크 인터페이스와 노드 풀 연결을 지원합니다. 예를 들어 클러스터에는 노드 유형이 혼합되어 있을 수 있습니다. 고성능 머신을 하나의 노드 풀로 그룹화할 때는 트래픽 흐름을 향상시키기 위해 노드 풀에 추가 인터페이스를 만들 수 있습니다.
다중 네트워크 인터페이스 설정
일반적으로 포드에 대해 다중 네트워크 인터페이스를 설정하는 단계는 다음 3가지입니다.
클러스터 구성 파일에서
multipleNetworkInterfaces
및enableDataplaneV2
필드를 사용하여 사용자 클러스터에 대해 멀티 NIC를 사용 설정합니다.클러스터 구성 파일에서
additionalNodeInterfaces
섹션을 사용하여 네트워크 인터페이스를 지정하고 하나 이상의NetworkAttachmentDefinition
커스텀 리소스를 만듭니다.k8s.v1.cni.cncf.io/networks
주석을 사용하여 포드에 네트워크 인터페이스를 지정합니다.
멀티 NIC 사용 설정
사용자 클러스터 구성 파일에서 multipleNetworkInterfaces
및 enableDataplaneV2
필드를 true
로 설정하여 포드에 대해 멀티 NIC를 사용 설정합니다.
apiVersion: v1 multipleNetworkInterfaces: true enableDataplaneV2: true ...
네트워크 인터페이스 지정
클러스터 구성 파일에서 additionalNodeInterfaces
섹션에 추가 노드 네트워크 인터페이스를 지정합니다.
예를 들어 사용자 클러스터 구성 파일에서 추가 노드 네트워크 인터페이스를 보여주는 부분은 다음과 같습니다.
apiVersion: v1 multipleNetworkInterfaces: true enableDataplaneV2: true network: serviceCIDR: "10.96.0.0/20" podCIDR: "192.168.0.0/16" vCenter: networkName: network-private310 ... # New multiple network configs additionalNodeInterfaces: - networkName: "gke-network-1" ipBlockFilePath: "my-block-yaml" type: static
앞의 구성에 따라 클러스터를 만든 후에는 사용자 클러스터에서 추가 네트워크 인터페이스를 지정하는 NetworkAttachmentDefinition
(NAD) 커스텀 리소스를 하나 이상 만들어야 합니다. NetworkAttachmentDefinitions
는 포드에 사용 가능한 네트워크에 따라 달라집니다. 다음 예시에서는 NetworkAttachmentDefinition
의 매니페스트를 보여줍니다.
apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: gke-network-1 namespace: default spec: config: '{ "cniVersion":"0.3.0", "type": "ipvlan", "master": "ens224", # defines the node interface that this Pod interface would map to "mode": "l2", "ipam": { "type": "whereabouts", "range": "172.16.0.0/24" } }'
매니페스트를 YAML 파일로 저장하고(예: my-nad.yaml
) NetworkAttachmentDefinition
을 만듭니다.
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] apply -f my-nad.yaml
포드에 네트워크 인터페이스 할당
k8s.v1.cni.cncf.io/networks
주석을 사용하여 하나 이상의 네트워크 인터페이스를 포드에 할당합니다. 각 네트워크 인터페이스에는 네임스페이스와 NetworkAttachmentDefinition
이름이 슬래시(/
)를 사용해서 구분된 상태로 지정됩니다. 다중 네트워크 인터페이스를 지정하려면 쉼표로 구분된 목록을 사용합니다.
다음 예시에서는 두 개의 네트워크 인터페이스가 samplepod
포드에 할당됩니다. 네트워크 인터페이스는 default
네임스페이스에 생성된 2개의 NetworkAttachmentDefinitions
인 gke-network-1
, gke-network-2
이름으로 지정됩니다.
--- apiVersion: v1 kind: Pod metadata: name: samplepod annotations: k8s.v1.cni.cncf.io/networks: default/gke-network-1,default/gke-network-2 spec: containers: ...
네트워크 인터페이스를 노드 집합으로 제한
NetworkAttachmentDefinition
이 전체 클러스터에 적용되지 않도록 하려면 기능을 일부 노드로 제한할 수 있습니다.
노드에 지정된 표준 라벨 또는 고유 커스텀 라벨을 사용해서 클러스터 노드를 그룹화할 수 있습니다. 그런 후 NetworkAttachmentDefinition
매니페스트 파일에서 k8s.v1.cni.cncf.io/nodeSelector
주석을 사용하여 노드 라벨을 지정할 수 있습니다. Google Distributed Cloud는 이 커스텀 리소스를 참조하는 모든 포드가 이 라벨이 있는 노드에 강제로 배포되도록 합니다.
apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: annotations: k8s.v1.cni.cncf.io/nodeSelector: LABEL_KEY=LABEL_VALUE name: gke-network-1 spec: ...
다음 예시는 NetworkAttachmentDefinition
에 표시된 my-label=multinicNP
라벨을 보여주고, gke-network-1
네트워크에 지정된 모든 포드가 이 라벨이 있는 노드에 강제로 배포되도록 합니다.
apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: annotations: k8s.v1.cni.cncf.io/nodeSelector: my-label=multinicNP name: gke-network-1 spec: ...
커스텀 라벨을 노드에 적용하려면 kubectl label nodes
명령어를 사용합니다.
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] label nodes NODE_NAME LABEL_KEY=LABEL_VALUE
다음을 바꿉니다.
NODE_NAME
: 라벨을 지정하려는 노드의 이름LABEL_KEY
: 라벨에 사용할 키입니다.LABEL_VALUE
: 라벨 값입니다.
이 예시에서는 my-node
노드에 environment=production
라벨이 지정됩니다.
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] label nodes my-node environment=production
보안 문제
NetworkAttachmentDefinition
은 네트워크에 대해 전체 액세스 권한을 제공합니다. 따라서 클러스터 관리자는 다른 사용자에게 만들기, 업데이트, 삭제 액세스 권한을 제공할 때 주의해야 합니다. 지정된 NetworkAttachmentDefinition
을 격리해야 할 경우, 이를 만들 때 기본값이 아닌 네임스페이스를 지정할 수 있습니다. 그러면 이 네임스페이스의 포드만 액세스할 수 있습니다.
다음 다이어그램에서 default
네임스페이스의 포드는 privileged
네임스페이스의 네트워크 인터페이스에 액세스할 수 없습니다.
지원되는 CNI 플러그인
이 섹션에서는 Google Distributed Cloud에 대해 멀티 NIC 기능이 지원하는 CNI 플러그인의 목록을 확인할 수 있습니다. NetworkAttachmentDefinition
을 지정할 때만 다음 플러그인을 사용하세요.
인터페이스 생성:
ipvlan
macvlan
bridge
메타 플러그인:
portmap
sbr
tuning
IPAM 플러그인:
host-local
static
whereabouts
경로 구성
하나 이상의 NetworkAttachmentDefinitions
가 지정된 포드에 다중 네트워크 인터페이스가 포함됩니다. 기본적으로 이 상황에서 포드의 라우팅 테이블은 지정된 NetworkAttachmentDefinitions
에서만 로컬로 제공되는 추가 인터페이스로 확장됩니다. 기본 게이트웨이에 대해 바인딩되는 패킷은 여전히 포드의 기본 인터페이스인 eth0
을 사용하도록 구성됩니다.
다음 CNI 플러그인을 사용하여 이 동작을 수정할 수 있습니다.
sbr
static
whereabouts
예를 들어 대부분의 트래픽이 기본 게이트웨이를 통과하도록, 즉, 트래픽이 기본 네트워크 인터페이스를 통해 이동하도록 해야 할 수 있습니다. 하지만 일부 트래픽은 기본값이 아닌 인터페이스를 통해 이동하도록 해야 합니다. 두 인터페이스 유형 모두 동일한 엔드포인트를 사용할 수 있기 때문에 대상 IP(일반 라우팅)를 기반으로 트래픽을 구분하기 어려울 수 있습니다. 이 경우에는 소스 기반 라우팅(SBR)이 도움이 될 수 있습니다.
SBR 플러그인
sbr
플러그인은 애플리케이션이 라우팅 결정을 제어할 수 있게 해줍니다. 애플리케이션은 설정된 연결의 소스 IP 주소로 사용되는 항목을 제어합니다. 애플리케이션이 해당 소스 IP에 대해 NetworkAttachmentDefinition
의 IP 주소를 사용하도록 선택하면 추가 라우팅 테이블 sbr
의 패킷 배치가 설정됩니다. sbr
라우팅 테이블은 NetworkAttachmentDefinition
의 인터페이스를 통해 이동하는 고유 기본 게이트웨이를 통해 트래픽을 전송합니다. 테이블 내의 기본 게이트웨이 IP는 whereabouts
또는 static
플러그인 내의 gateway
필드로 제어됩니다. sbr
플러그인은 연결된 플러그인으로 실행됩니다. 사용 정보를 포함하여 sbr
플러그인에 대한 자세한 내용은 소스 기반 라우팅 플러그인을 참조하세요.
다음 예시에서는 whereabouts
에 설정된 "gateway":"21.0.111.254"
와 ipvlan
다음에 연결된 플러그인으로 설정된 sbr
을 보여줍니다.
# ip route
default via 192.168.0.64 dev eth0 mtu 1500
192.168.0.64 dev eth0 scope link
# ip route list table 100
default via 21.0.111.254 dev net1
21.0.104.0/21 dev net1 proto kernel scope link src 21.0.111.1
정적 및 whereabouts 플러그인
whereabouts
플러그인은 기본적으로 static
플러그인의 확장이며, 두 플러그인 모두 라우팅 구성을 공유합니다. 구성 예시는 고정 IP 주소 관리 플러그인을 참조하세요.
포드의 라우팅 테이블에 추가할 게이트웨이 및 경로를 정의할 수 있습니다. 하지만 이 방법으로는 포드의 기본 게이트웨이를 수정할 수 없습니다.
다음 예시는 NetworkAttachmentDefinition
의 "routes": [{ "dst": "172.31.0.0/16" }]
추가를 보여줍니다.
# ip route
default via 192.168.0.64 dev eth0 mtu 1500
172.31.0.0/16 via 21.0.111.254 dev net1
21.0.104.0/21 dev net1 proto kernel scope link src 21.0.111.1
192.168.0.64 dev eth0 scope link
구성 예시
이 섹션에서는 멀티 NIC 기능으로 지원되는 몇 가지 공통적인 네트워크 구성을 보여줍니다.
다중 포드에 사용되는 단일 네트워크 연결:
단일 포드에 사용되는 다중 네트워크 연결:
단일 포드에 사용되는 동일한 인터페이스를 가리키는 다중 네트워크 연결:
단일 포드에 여러 번 사용되는 동일한 네트워크 연결:
문제 해결
추가 네트워크 인터페이스가 잘못 구성되어 있으면 지정된 포드가 시작되지 않습니다. 이 섹션에서는 멀티 NIC 기능으로 문제 해결 정보를 찾는 방법을 보여줍니다.
포드 이벤트 확인
Multus는 Kubernetes 포드 이벤트를 통해 오류를 보고합니다. 다음 kubectl describe
명령어를 사용하여 지정된 포드의 이벤트를 확인합니다.
kubectl describe pod POD_NAME
로그 확인
각 노드에 대해 다음 위치에서 Whereabouts 및 Multus 로그를 찾을 수 있습니다.
/var/log/whereabouts.log
/var/log/multus.log
포드 인터페이스 검토
kubectl exec
명령어를 사용하여 포드 인터페이스를 확인합니다. NetworkAttachmentDefinitions
가 성공적으로 적용되었으면 포드 인터페이스가 다음 출력과 같이 표시됩니다.
user@node1:~$ kubectl exec samplepod-5c6df74f66-5jgxs -- ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
link/ether 00:50:56:82:3e:f0 brd ff:ff:ff:ff:ff:ff
inet 21.0.103.112/21 scope global net1
valid_lft forever preferred_lft forever
38: eth0@if39: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 36:23:79:a9:26:b3 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.2.191/32 scope global eth0
valid_lft forever preferred_lft forever
포드 상태 가져오기
kubectl get
을 사용하여 지정된 Pod에 대해 네트워크 상태를 검색합니다.
kubectl get pods POD_NAME -oyaml
다음은 다중 네트워크의 Pod 상태를 보여주는 샘플 출력입니다.
apiVersion: v1
kind: Pod
metadata:
annotations:
k8s.v1.cni.cncf.io/network-status: |-
[{
"name": "",
"interface": "eth0",
"ips": [
"192.168.1.88"
],
"mac": "36:0e:29:e7:42:ad",
"default": true,
"dns": {}
},{
"name": "default/gke-network-1",
"interface": "net1",
"ips": [
"21.0.111.1"
],
"mac": "00:50:56:82:a7:ab",
"dns": {}
}]
k8s.v1.cni.cncf.io/networks: gke-network-1