이전 블로그 게시물에서 vSphere with Tanzu의 새로운 기능들을 강조하는데 꽤 많은 시간을 할애했다. 이들 게시물에서 TKG(Tanzu Kubernetes Grid) 게스트 클러스터를 프로비저닝하여 업스트림과 유사한 네이티브 쿠버넷을 제공하는 데 vSphere with Tanzu를 어떻게 사용할 수 있는지 살펴보았다. 이 게시물에서는 게스트 클러스터를 좀 더 자세히 살펴보고 TKG 게스트 클러스터와 함께 현재 출하되고 있는 Antrea라는 새로운 기본 Container Network Interface(CNI)를 살펴보려고 한다.
Antrea는 쿠버네티스 클러스터에 네트워킹과 보안 서비스를 제공한다. 이는 Pod-to-Pod 통신을 위한 네트워크 오버레이를 제공하기 위한 네트워킹 데이터 평면으로 사용되는 OVS(Open vSwitch Project)를 기반으로 한다. Antrea의 또 다른 흥미로운 특징은 네트워크 보안 정책이다. 쿠버네티스는 내장형 네트워크 정책을 가지고 있지만, 앤트리아는 자체적으로 더 세분화된 네트워크 정책을 제공하기 위해 이러한 네이티브 네트워크 정책을 기반으로 한다. 이름에서 알 수 있듯이 Kubernetes 클러스터 수준에서 작동하는 ClusterNetworkPolicy를 가지고 있다. 또한 정책의 범위를 쿠베르네츠 네임스페이스로 제한하는 NetworkPolicy도 가지고 있다. ClusterNetworkPolicy는 Kubernetes Cluster Admin이 클러스터 전체에 대한 보안 정책을 만드는 수단으로 생각할 수 있다. NetworkPolicy는 개발자가 특정 네임스페이스에서 애플리케이션을 보호하기 위한 수단으로 생각할 수 있다. 이러한 네트워크 정책을 사용하여 동일한 워크로드의 Pods 간 트래픽과 동일한 클러스터 내의 워크로드 간 트래픽을 보호하는 방법에 대해 나중에 살펴보기 바란다.
먼저 TKG 게스트 클러스터를 살펴봅시다. vSphere with Tanzu에서 이미 프로비저닝한 TKG 게스트 클러스터. 쿠베르네츠 v1.18.5를 실행하고 있으며, 단일 제어면 노드와 2개의 작업자 노드로 전개되었다. 안트레이아 관련 포드도 전시해봤다.
$ kubectl get nodes NAME STATUS ROLES AGE VERSION tkg-cluster-1-18-5-control-plane-bsn9l Ready master 21d v1.18.5+vmware.1 tkg-cluster-1-18-5-workers-8zj27-67c98696dc-52g5r Ready <none> 21d v1.18.5+vmware.1 tkg-cluster-1-18-5-workers-8zj27-67c98696dc-kfd5z Ready <none> 21d v1.18.5+vmware.1 $ kubectl get pods -A | grep antrea NAMESPACE NAME READY STATUS RESTARTS AGE kube-system antrea-agent-ktn22 2/2 Running 8 21d kube-system antrea-agent-l7gzv 2/2 Running 9 21d kube-system antrea-agent-mt8xt 2/2 Running 11 21d kube-system antrea-controller-846bd89cc6-87bjk 1/1 Running 5 21d
이 단일 제어면과 2개의 작업 노드 TKG 클러스터에서 볼 수 있듯이, 1개의 Antrea 컨트롤러와 3개의 Antrea 에이전트가 있다. Antrea Controller는 Kubernetes API 서버를 감시하며, 네트워크 정책 또는 Pod와 네임스페이스 네트워킹에 대한 요청이나 업데이트가 있을 경우 컨트롤러는 필요한 정책을 모든 Antrea 에이전트에 배포한다.
내 TKG 클러스터에 Cassandra 스테이트풀 세트와 nginx 배포를 배치했다. 클러스터IP는 쿠베르네츠에 의해 제공되었다(vSphere with Tanzu와 함께 배포된 HA-Proxy 로드 밸런싱 장치가 nginx 웹 서버를 위한 외부 IP를 제공한다).
$ kubectl get svc -A NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE cassandra cassandra ClusterIP 10.100.48.126 <none> 9042/TCP 20d default kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 20d default nginx-svc LoadBalancer 10.108.137.209 10.27.62.18 443:30472/TCP,80:30915/TCP 20d default supervisor ClusterIP None <none> 6443/TCP 20d kube-system antrea ClusterIP 10.96.120.159 <none> 443/TCP 20d kube-system kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP,9153/TCP 20d $
이 정보를 가지고, 앤트레이아 에이전트 중 하나를 구성하고 있는 컨테이너에 대해 자세히 살펴보자. 나는 파드에 로그를 요청하는 나의 오래된 기술을 사용할 것이다. 그것은 실패하지만 동시에 팟을 구성하는 컨테이너를 내게 알려준다. 아래에서도 볼 수 있듯이 파드는 antrea-agent와 antrea-ovs 컨테이너가 있다. 먼저 antrea-ovs 컨테이너를 살펴보자. 보시다시피 여러 OVS 관련 명령을 사용할 수 있다. Open vSwitch 설명서는 명령에 대한 자세한 정보를 제공한다.
$ kubectl logs antrea-agent-ktn22 -n kube-system
error: a container name must be specified for pod antrea-agent-ktn22, \
choose one of: [antrea-agent antrea-ovs] or one of the init containers: [install-cni]
$ kubectl exec -it antrea-agent-ktn22 -n kube-system -c antrea-ovs -- bash
root [ / ]# ovs-
ovs-appctl ovs-dpctl ovs-ofctl ovs-pki ovs-test ovs-vsctl
ovs-bugtool ovs-dpctl-top ovs-parse-backtrace ovs-tcpdump ovs-testcontroller ovs-vswitchd
ovs-docker ovs-l3ping ovs-pcap ovs-tcpundump ovs-vlan-test
root [ / ]# ovs-vsctl show
83ed275e-084b-4ebb-a19e-f150646bf62b
Bridge br-int
datapath_type: system
Port antrea-gw0
Interface antrea-gw0
type: internal
Port vsphere--940a85
Interface vsphere--940a85
Port nginx-de-548af9
Interface nginx-de-548af9
Port antrea-tun0
Interface antrea-tun0
type: geneve
options: {csum="true", key=flow, remote_ip=flow}
Port cassandr-1e6e0a
Interface cassandr-1e6e0a
Port nginx-de-481c4a
Interface nginx-de-481c4a
ovs_version: "2.13.1"위의 ovs-vsctl 명령 출력을 사용하면 OVS(Open vSwitch) 구성 데이터베이스와 상호 작용할 수 있다. 위는 데이터베이스 내용에 대한 간략한 개요다. 위의 출력에서 주의할 점은 antrea-tun0이다. 이 노드의 ‘로컬’ 포드 중 하나에서 나온 패킷이 다른 노드의 포드로 전송될 때, 그것들은 ‘로컬’ OVS의 antrea-tun0 포트로 전달된다. 패킷은 터널을 통해 대상 노드로 전송된다(위의 geneve를 사용하여 구현됨). 대상 노드에서 패킷은 해당 antrea-tun0 포트를 통해 수신되어 대상 포드로 전달된다.
패킷이 외부로 어떻게 라우팅되는지도 흥미롭다. 노드의 네트워크의 외부 IP로 전송된 패킷은 antrea-gw0 포트로 포워드 되고, 쿠베르네츠 노드의 적절한 네트워크 인터페이스로 라우팅되어 거기서 네트워크로 송신된다. Antrea Kubernetes Networking 백서에는 이러한 모든 내부 작업에 대한 자세한 내용이 수록되어 있으며, 자세한 내용을 알아보려면 이 백서를 참조하십시오.
다음은 antrea-agent인 다른 앤트레이아 컨테이너로 관심을 돌리자. 이것은 정말 유용한 또 다른 효용인 antctl을 가지고 있다. 아래 출력에서 OVS를 사용하는 이 노드/에이전트의 포드 검사를 위해 사용하고 있다.
$ kubectl exec -it antrea-agent-ktn22 -n kube-system -c antrea-agent -- bash root [ / ]# root [ / ]# antctl get Get the status or resource of a topic Usage: antctl get [command] Available Commands: addressgroup Print address groups agentinfo Print agent's basic information appliedtogroup Print appliedto groups networkpolicy Print NetworkPolicies ovsflows Dump OVS flows podinterface Print Pod's network interface information Flags: -h, --help help for get Global Flags: -k, --kubeconfig string absolute path to the kubeconfig file -s, --server string address and port of the API server, taking precedence over the default endpoint and the one set in kubeconfig -t, --timeout duration time limit of the execution of the command -v, --verbose enable verbose output Use "antctl get [command] --help" for more information about a command. root [ / ]# root [ / ]# antctl get podinterface NAMESPACE NAME INTERFACE-NAME IP MAC PORT-UUID OF-PORT CONTAINER-ID cassandra cassandra-1 cassandr-1e6e0a 192.168.2.6 4e:c8:62:fb:8b:75 9fd9bdc3-5fd1-4c4a-b46a-d4e35af0f8da 7 ac559b874be default nginx-deployment-cc7df4f8f-69cm2 nginx-de-481c4a 192.168.2.2 32:a1:45:43:7c:96 bf184406-a53c-4b3d-84c7-a979f435e162 3 f3d429a49c6 default nginx-deployment-cc7df4f8f-pcn79 nginx-de-548af9 192.168.2.4 f2:38:81:3e:e0:08 54b7032b-f513-4a2b-9bc8-924b2dcb620f 4 52c08818eeb vmware-system-csi vsphere-csi-node-86fds vsphere--940a85 192.168.2.3 d2:95:fc:3a:1e:a1 352c776b-1bcc-41d9-a961-50039e804689 5 08a976b1c76
보시다시피 IP주소, MAC주소 등 좋은 정보가 많다. 우리는 또한 OVS 흐름을 표시하기 위해 이 명령을 사용할 수 있다. OBS 흐름은 “로컬” 파드용 NetworkPolicies를 구현하는 데 사용된다. 첫 번째 명령과 같이 -h(도움말) 옵션을 사용하면 모든 흐름의 목록을 얻을 수 있다. 두 번째 명령에서는 특정 지역 포드(Pod)에 대한 흐름을 덤프하여, 그것과 연관된 흐름의 유형을 관찰할 수 있다. 나는 흐름 번호와 설명을 쉽게 식별할 수 있도록 몇 가지 색상을 출력에 추가했다.
root [ / ]# antctl get ovsflows -h
Dump all the OVS flows or the flows installed for the specified entity.
Usage:
antctl get ovsflows [flags]
Aliases:
ovsflows, of
Examples:
Dump all OVS flows
$ antctl get ovsflows
Dump OVS flows of a local Pod
$ antctl get ovsflows -p pod1 -n ns1
Dump OVS flows of a NetworkPolicy
$ antctl get ovsflows --networkpolicy np1 -n ns1
Dump OVS flows of a flow Table
$ antctl get ovsflows -T IngressRule
Antrea OVS Flow Tables:
0 Classification
5 Uplink
10 SpoofGuard
20 ARPResponder
29 ServiceHairpin
30 ConntrackZone
31 ConntrackState
40 DNAT(SessionAffinity)
40 SessionAffinity
41 ServiceLB
42 EndpointDNAT
45 CNPEmergencyEgressRule
46 CNPSecurityOpsEgressRule
47 CNPNetworkOpsEgressRule
48 CNPPlatformEgressRule
49 CNPApplicationEgressRule
50 EgressRule
60 EgressDefaultRule
70 l3Forwarding
80 L2Forwarding
85 CNPEmergencyIngressRule
86 CNPSecurityOpsIngressRule
87 CNPNetworkOpsIngressRule
88 CNPPlatformIngressRule
89 CNPApplicationIngressRule
90 IngressRule
100 IngressDefaultRule
105 ConntrackCommit
106 HairpinSNATTable
110 Output
Flags:
-h, --help help for ovsflows
-n, --namespace string Namespace of the entity
--networkpolicy string NetworkPolicy name. If present, Namespace must be provided.
-o, --output string output format: json|table|yaml (default "table")
-p, --pod string Name of a local Pod. If present, Namespace must be provided.
-T, --table string Antrea OVS flow table name or number
Global Flags:
-k, --kubeconfig string absolute path to the kubeconfig file
-s, --server string address and port of the API server, taking precedence over the default endpoint and the one set in kubeconfig
-t, --timeout duration time limit of the execution of the command
-v, --verbose enable verbose output
root [ / ]#
root [ / ]# antctl get ovsflows -n default -p nginx-deployment-cc7df4f8f-69cm2
FLOW
table=70, n_packets=3, n_bytes=222, priority=200,ip,dl_dst=aa:bb:cc:dd:ee:ff,nw_dst=192.168.2.2 actions=set_field:46:05:cf:f0:69:b3->eth_src,set_field:32:a1:45:43:7c:96->eth_dst,dec_ttl,goto_table:80
table=0, n_packets=498, n_bytes=34716, priority=190,in_port="nginx-de-481c4a" actions=load:0x2->NXM_NX_REG0[0..15],goto_table:10
table=10, n_packets=5, n_bytes=270, priority=200,ip,in_port="nginx-de-481c4a",dl_src=32:a1:45:43:7c:96,nw_src=192.168.2.2 actions=goto_table:30
table=10, n_packets=5, n_bytes=210, priority=200,arp,in_port="nginx-de-481c4a",arp_spa=192.168.2.2,arp_sha=32:a1:45:43:7c:96 actions=goto_table:20
table=80, n_packets=5, n_bytes=370, priority=200,dl_dst=32:a1:45:43:7c:96 actions=load:0x3->NXM_NX_REG1[],load:0x1->NXM_NX_REG0[16],goto_table:90
root [ / ]#위의 흐름표에서 table 70은 L3 포워딩을 정의하고 table 80은 L2 포워딩을 정의한다. 나는 그것들을 구별하기 더 쉬운 색상을 몇 가지 추가했다. table 10은 spoof-guards다. 이는 로컬 포드로부터 IP와 ARP 스푸핑을 방지한다. 각 플로우 테이블에 대한 자세한 내용을 보려면 각 테이블에 대한 자세한 정보가 들어 있는 이 OVS 파이프라인 문서를 확인하기 바란다.
이 antrea-agent 컨테이너에서 실행하기에 흥미로울 수 있는 다른 명령들은 네트워크 정책에 대한 정보뿐만 아니라 에이전트 정보도 표시하는 것이다. 우리는 아직 네트워크 정책을 만들지 않았기 때문에 여기서는 아직 별로 쓸만한 것이 없다. 우리는 곧 이 일로 돌아갈 것이다.
root [ / ]# antctl get agentinfo POD NODE STATUS NODE-SUBNET NETWORK-POLICIES ADDRESS-GROUPS APPLIED-TO-GROUPS LOCAL-PODS kube-system/antrea-agent-ktn22 tkg-cluster-1-18-5-workers-8zj27-67c98696dc-52g5r Healthy 192.168.2.0/24 0 0 0 4 root [ / ]#
OK – 컨테이너를 종료하고 내 데스크톱으로 돌아가자. antrea 에이전트 중 하나에 대해 설명 해봅시다. 그래서 앞에서 본 포드의 미세한 부분에서는 아니지만 비슷한 흐름 테이블 정보를 관찰할 수 있도록 하자. 나는 읽기 쉽게 하기 위해 출력물의 일부를 잘라냈다. 이것은 콘트롤 플레인 에이전트다.
$ kubectl describe antreaagentinfos tkg-cluster-1-18-5-control-plane-bsn9l
Name: tkg-cluster-1-18-5-control-plane-bsn9l
Namespace:
Labels: <none>
Annotations: <none>
Agent Conditions:
Last Heartbeat Time: 2020-11-12T17:35:35Z
Status: True
Type: AgentHealthy
<--snip-->
Kind: AntreaAgentInfo
Local Pod Num: 5
Metadata:
Creation Timestamp: 2020-10-23T08:25:23Z
Generation: 29285
Managed Fields:
API Version: clusterinformation.antrea.tanzu.vmware.com/v1beta1
<--snip-->
Manager: antrea-agent
Operation: Update
Time: 2020-11-12T17:35:35Z
Resource Version: 7476901
Self Link: /apis/clusterinformation.antrea.tanzu.vmware.com/v1beta1/antreaagentinfos/tkg-cluster-1-18-5-control-plane-bsn9l
UID: 8e1bd7c7-0c3a-4f00-a405-3ef2f0b1d8f1
Network Policy Controller Info:
Node Ref:
Kind: Node
Name: tkg-cluster-1-18-5-control-plane-bsn9l
Node Subnet:
192.168.0.0/24
Ovs Info:
Bridge Name: br-int
Flow Table:
0: 8
10: 13
100: 1
105: 3
110: 2
20: 4
30: 1
31: 4
40: 2
50: 2
60: 1
70: 9
80: 7
90: 3
Version: 2.13.1
Pod Ref:
Kind: Pod
Name: antrea-agent-l7gzv
Namespace: kube-system
Version: v0.9.2-unknown
Events: <none>다시, Spoof-guard table (10) 과 같은 Antrea가 정의한 OVF 흐름 테이블의 목록과 L2 (80) 와 L3 (70) 포워딩 테이블의 목록을 볼 수 있다. 우리는 또한 각 테이블에서 패킷 처리 흐름의 수를 본다. 이제 Antrea의 다른 특징, 즉 NetworkPolicies에 관심을 집중해 봅시다. 여기서 사용할 수 있는 네트워크 정책을 구성하는 방법에 대한 정보는 상당히 많다(참고: 이는 TKG 게스트 클러스터에서는 현재 사용할 수 없지만 참조 목적으로 여전히 유용한 정보를 가지고 있는 Antrea 기본 정책을 위한 것이다). 이 부분에 대해서는 Curtis Collicutt이 제공한 훌륭한 사례를 활용하겠다. 쿠도스 커티스!
이미 언급된 바와 같이, 그리고 게시물 전체에 걸쳐 보여진 바와 같이, 기본 네임스페이스에 간단한 nginx 배포를 가지고 있다. 이제 동일한 네임스페이스에 간단한 busybox 파드를 배포하고 현재 파드 간 액세스가 어떻게 광범위하게 열려 있는지 보여줌으로써 새로 배포된 파드가 ClusterIP를 통해 nginx 웹 서버에 직접 액세스할 수 있음을 시사한다.
$ kubectl get svc nginx-svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx-svc LoadBalancer 10.108.137.209 10.27.62.18 443:30472/TCP,80:30915/TCP 20d $ kubectl get pods NAME READY STATUS RESTARTS AGE IP nginx-deployment-cc7df4f8f-69cm2 1/1 Running 2 20d nginx-deployment-cc7df4f8f-ms5jm 1/1 Running 2 20d nginx-deployment-cc7df4f8f-pcn79 1/1 Running 2 20d $ kubectl apply -f busybox-cor.yaml pod/ch-busybox created $ kubectl get pods NAME READY STATUS RESTARTS AGE ch-busybox 1/1 Running 0 3m13s nginx-deployment-cc7df4f8f-69cm2 1/1 Running 2 20d nginx-deployment-cc7df4f8f-ms5jm 1/1 Running 2 20d nginx-deployment-cc7df4f8f-pcn79 1/1 Running 2 20d $ kubectl exec -it ch-busybox -- sh / # wget -q -O - 10.108.137.209 | grep title <title>Welcome to nginx!</title> / # exit $
이 시점에서 클러스터에서 실행되는 모든 포드는 다른 모든 포드에 액세스할 수 있다. 이것은 아마도 바람직하지 않을 것이다. 다음 목표는 busybox 파드가 nginx 웹 서버에 액세스하지 못하도록 하는 수신 규칙을 사용하여 NetworkPolicy를 만드는 것이다. 아래 매니페스트를 사용하여 생성한 네트워크 정책은 일치하는 레이블(nginx)을 가진 포드만 nginx 포드에 대한 수신 액세스를 허용한다.
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: nginx-allow
spec:
podSelector:
matchLabels:
app: nginx
ingress:
- from:
- podSelector:
matchLabels:
app: nginx분명히 이것은 단일 수신 규칙을 가진 매우 간단한 정책이다. 네임스페이스의 파드 간에 다른 유형의 트래픽을 허용할지 또는 삭제할지 여부를 제어하는 여러 수신 및 송신 규칙을 포함하는 훨씬 더 상세한 정책을 상상할 수 있다.
이제 이 네트워크 정책을 적용하여 busybox Pod가 nginx 웹 서버에 여전히 액세스할 수 있는지 확인해보자.
$ kubectl apply -f antrea-network-policy.yaml networkpolicy.networking.k8s.io/nginx-allow created $ kubectl get networkpolicy NAME POD-SELECTOR AGE nginx-allow app=nginx 8s $ kubectl exec -it ch-busybox -- sh / # wget -q -O - 10.108.137.209 | grep title wget: can't connect to remote host (10.108.137.209): Connection timed out / #
우리가 볼 수 있듯이, 바쁜 busybox는 더 이상 nginx 웹 서비스에 접속할 수 없다. 꽤 멋지지, 응?
이제, 포인트를 증명하기 위해서, ingress 네트워크 정책은 이 라벨을 가진 모든 포드가 웹 서버에 접근할 수 있도록 허용하기 때문에, 우리는 busybox 매니페스트를 편집하여 라벨(app=nginx)을 다시 한번 웹 서버와 통신할 수 있게 할 수 있다. 아래 첫 번째 명령은 우리가 라벨을 추가했다는 것을 보여준다. 그런 다음 다시 포드에 연결하고 wget 명령을 다시 시도한다.
$ kubectl get pod ch-busybox -L app NAME READY STATUS RESTARTS AGE APP ch-busybox 1/1 Running 0 16m nginx $ kubectl exec -it ch-busybox -- sh / # wget -q -O - 10.108.137.209 | grep title <title>Welcome to nginx!</title> / #
좋아! 그리고 이제 앞에서 본 antctl 명령을 사용하면 앤트레이아 에이전트 컨테이너에 있는 새로운 수신 규칙(Flow Table 90)을 볼 수 있다.
$ kubectl exec -it antrea-agent-ktn22 -n kube-system -c antrea-agent -- antctl get ovsflows -T ingressRule FLOW table=90, n_packets=11666344, n_bytes=1394912954, priority=210,ct_state=-new+est,ip actions=goto_table:105 table=90, n_packets=7, n_bytes=518, priority=210,ip,nw_src=192.168.2.1 actions=goto_table:105 table=90, n_packets=0, n_bytes=0, priority=200,ip,nw_src=192.168.2.2 actions=conjunction(1,1/2) table=90, n_packets=0, n_bytes=0, priority=200,ip,nw_src=192.168.2.4 actions=conjunction(1,1/2) table=90, n_packets=0, n_bytes=0, priority=200,ip,nw_src=192.168.1.2 actions=conjunction(1,1/2) table=90, n_packets=0, n_bytes=0, priority=200,ip,nw_src=192.168.2.7 actions=conjunction(1,1/2) table=90, n_packets=0, n_bytes=0, priority=200,ip,reg1=0x3 actions=conjunction(1,2/2) table=90, n_packets=0, n_bytes=0, priority=200,ip,reg1=0x4 actions=conjunction(1,2/2) table=90, n_packets=0, n_bytes=0, priority=200,ip,reg1=0x8 actions=conjunction(1,2/2) table=90, n_packets=1, n_bytes=74, priority=190,conj_id=1,ip actions=load:0x1->NXM_NX_REG6[],goto_table:105 table=90, n_packets=586, n_bytes=43364, priority=0 actions=goto_table:100
위에서 강조된 네트워크 소스는 ingress 규칙으로 포드의 IP 주소에 직접 연결될 수 있다.
$ kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES ch-busybox 1/1 Running 0 24m 192.168.2.7 tkg-cluster-1-18-5-workers-8zj27-67c98696dc-52g5r <none> <none> nginx-deployment-cc7df4f8f-69cm2 1/1 Running 2 20d 192.168.2.2 tkg-cluster-1-18-5-workers-8zj27-67c98696dc-52g5r <none> <none> nginx-deployment-cc7df4f8f-ms5jm 1/1 Running 2 20d 192.168.1.2 tkg-cluster-1-18-5-workers-8zj27-67c98696dc-kfd5z <none> <none> nginx-deployment-cc7df4f8f-pcn79 1/1 Running 2 20d 192.168.2.4 tkg-cluster-1-18-5-workers-8zj27-67c98696dc-52g5r <none> <none>
이번에는 조금 다른 접근을 시도해보자. busybox Pod에 다른 라벨(busybox)을 주고, 이것을 네트워크 정책 매니페스트에 다른 항목으로 추가하여 다른 라벨을 가진 Pods가 서로 통신할 수 있도록 하자.
$ kubectl get pod ch-busybox -L app NAME READY STATUS RESTARTS AGE APP ch-busybox 1/1 Running 70 2d22h busybox $ kubectl exec -it ch-busybox -- sh / # wget -q -O - 10.108.137.209 | grep title wget: can't connect to remote host (10.108.137.209): Connection timed out / #
이전과 같이 app=nginx가 있는 pods만 서로 통신하는 ingress 규칙을 가지고 있다. app=busybox에 대한 ingress도 허용하는 다른 규칙을 네트워크 정책에 추가해 봅시다.
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: nginx-allow
spec:
podSelector:
matchLabels:
app: nginx
ingress:
- from:
- podSelector:
matchLabels:
app: nginx
- podSelector:
matchLabels:
app: busybox변경 사항을 적용하고 테스트를 반복하자.
$ kubectl apply -f antrea-network-policy.yaml networkpolicy.networking.k8s.io/nginx-allow configured $ kubectl exec -it ch-busybox -- sh / # wget -q -O - 10.108.137.209 | grep title <title>Welcome to nginx!</title> / #
그리고 busybox 라벨이 부착된 포드에 대한 ingress는 현재 작동하고 있다. 나이스! 마지막으로 보여줄 것은 앤트레이아 에이전트 포드의 앤트레이아 에이전트 컨테이너에 있는 antctl을 통해 네트워크 정책도 쿼리할 수 있다는 것이다.
$ kubectl exec -it antrea-agent-ktn22 -n kube-system -c antrea-agent -- antctl get networkpolicy NAMESPACE NAME APPLIED-TO RULES default nginx-allow 766a9e51-f132-5c2f-b862-9ac68e75d77d 1
Tanzu TKG Guest 클러스터가 설치된 vSphere의 새로운 Antrea CNI에서 네트워크 정책이 얼마나 단순하지만 강력한지 알 수 있기를 바란다. 나는 이제 막 실험을 시작했을 뿐인데, 여러 가지 새로운 혁신들이 줄을 잇고 있다는 것을 알고 있다. 의심의 여지 없이, 언젠가 안트리아를 다시 방문해서 너와 더 좋은 점을 공유하게 될 거야.
마지막으로, 안트리아 팀의 Antonin Bas에게 감사의 말을 전하고 싶다. Merci beaucoup Antonin.
