Tanzu 게스트 클러스터를 지원하는 vSphere의 새로운 CNI인 Antrea에 대해 자세히 알아보기

이전 블로그 게시물에서 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.

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

You May Also Like