이 문서에서는 포드에 다중 네트워크 인터페이스 즉, 멀티 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을 지정할 때만 다음 플러그인을 사용하세요.
인터페이스 생성:
ipvlanmacvlanbridge
메타 플러그인:
portmapsbrtuning
IPAM 플러그인:
host-localstaticwhereabouts
경로 구성
하나 이상의 NetworkAttachmentDefinitions가 지정된 포드에 다중 네트워크 인터페이스가 포함됩니다. 기본적으로 이 상황에서 포드의 라우팅 테이블은 지정된 NetworkAttachmentDefinitions에서만 로컬로 제공되는 추가 인터페이스로 확장됩니다. 기본 게이트웨이에 대해 바인딩되는 패킷은 여전히 포드의 기본 인터페이스인 eth0을 사용하도록 구성됩니다.
다음 CNI 플러그인을 사용하여 이 동작을 수정할 수 있습니다.
sbrstaticwhereabouts
예를 들어 대부분의 트래픽이 기본 게이트웨이를 통과하도록, 즉, 트래픽이 기본 네트워크 인터페이스를 통해 이동하도록 해야 할 수 있습니다. 하지만 일부 트래픽은 기본값이 아닌 인터페이스를 통해 이동하도록 해야 합니다. 두 인터페이스 유형 모두 동일한 엔드포인트를 사용할 수 있기 때문에 대상 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