AWS EKS VPC CNI - KANS 9주차

Amazon VPC CNI

Amazon EKS에서는 Amazon VPC CNI 플러그인을 통해서 클러스터 간 네트워크 연결을 지원합니다.

이전에 다루었던, 다른 네트워크 플러그인(Flannel, Calico, Cilium)과 구별되는 Amazone VPC CNI의 주요 특징은 다음과 같습니다.

1. VPC 네트워크와의 통합
   Kubernetes의 파드가 AWS VPC의 네트워크 대역과 통합되어, VPC Flow logs, VPC 라우팅 정책, 보안그룹 등의 사용이 가능해집니다.
2. ipamd를 통한 ENI 및 IP풀 관리
   ipamd가 ENI 및 IP 풀을 자동 관리하여 최적화된 네트워크 설정을 제공합니다.
3. 네트워크 성능 최적화
   노드와 파드가 같은 IP 대역을 사용하므로, 직접 통신이 가능해 네트워크 경로가 단순해지고 최적의 성능을 제공합니다.

조금 더 자세히 VPC CNI의 동작 방식에 대해 알아 보겠습니다.

 

ENI(Elastic Network Interface)
AWS에서 제공하는 가상 네트워크 인터페이스 = NIC

 

EKS의 각 워커노드에는 ENI가 할당되고 노드의 기본 네트워크 인터페이스의 연결됩니다(eth0). 새로운 Pod가 생성되면 VPC CNI 플러그인은 ipamd를 통해 보조 ENI와 추가 IP주소를 노드의 할당합니다(eth1). VPC CNI는 iptables 규칙과 라우팅 테이블을 업데이트하여 Pod 및 외부 네트워크 간 트래픽이 라우팅 되도록 설정합니다.

 

VPC CNI는 ipam으로 L-IPAM(Local IP AddressManager)을 사용합니다. worm pool을 통해서 IP 주소 할당을 미리 준비하여 Pod 시작 속도를 높입니다.(캐시와 비슷함). 파드의 수가 증가하여 IP가 부족하게 되면, 새로운 ENI와 IP주소를 노드에 자동으로 추가하여 worm pool을 채웁니다.

 

하지만, 워커노드의 EC2 인스턴스 유형에 따라서, 최대 ENI 개수가 정해지게 됩니다. ENI 당 시스템 용도로 사용하는 IP의 개수를 제외하면, 아래와 같이 t3.medium의 경우 최대 15개까지의 파드를 배치할 수 있게 됩니다. 따라서, 네트워크를 규모에 맞게 노드의 스펙을 잘 설계하는 것이 중요하며, IP를 더 밀도 있게 쓰기 위해서 IPv4 Prefix Delegation와 같은 방법을 사용할 수도 있습니다.

파드 생성 개수 제한 실습

워커노드의 EC2 인스턴스 유형이 가질 수 있는 최대 ENI의 개수를 확인합니다.

 

계산식은 다음과 같습니다. 실습에 사용하는 t3.medium의 경우 최대 3개의 ENI를 가질 수 있고, 17개의 파드의 IP를 할당할 수 있습니다.

아래 명령어를 통해서도 할당가능한 최대 파드의 수를 확인할 수 있습니다.

 

nginx-deployment를 배포하고 레플리카 수를 늘려, 파드의 생성 개수가 제한이 되는지를 확인합니다. 실습에 사용되는 워커 노드는 3대로 구성되어 있는데, 레플리카 수를 50개로 증가시키게 되면, pending 상태가 되어 스케줄링을 하지 못하는 것을 확인할 수 있습니다.

gif : 노드에 파드 생성 갯수 제한 실습

EKS 네트워크 기본 정보 확인

replicas=3인, 디플로이먼트를 생성 시, 동작하는 각 노드의 네트워크 인터페이스가 추가됨을 확인할 수 있습니다.

gif : 파드 생성 시, EKS 네트워크 인터페이스 확인

파드 안에서 네트워크 정보 확인

 netshoot-pod-74b7555dc7-nr4wz  ~  ip -c addr1: 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
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
3: eth0@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc noqueue state UP group default 
    link/ether 66:05:f3:79:74:c4 brd ff:ff:ff:ff:ff:ff link-netnsid 0    inet 192.168.1.236/32 scope global eth0
       valid_lft forever preferred_lft forever    inet6 fe80::6405:f3ff:fe79:74c4/64 scope link 
       valid_lft forever preferred_lft forever

 

파드가 동작하는 노드의 라우트 정보를 확인하면 파드의 ip 인터페이스와 링크된 것을 확인할 수 있습니다.

[ec2-user@ip-192-168-3-34 ~]$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.3.1     0.0.0.0         UG    0      0        0 eth0
169.254.169.254 0.0.0.0         255.255.255.255 UH    0      0        0 eth0
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.3.94    0.0.0.0         255.255.255.255 UH    0      0        0 eniac70ac73ad3
192.168.3.128   0.0.0.0         255.255.255.255 UH    0      0        0 enic12d6d53fd2
### 노드 및 파드 간 통신 실습 

노드 간 파드 통신 확인

EKS에서는 노드 간 파드 통신 시, 파드의 IP로 직접 통신합니다.

tcpdump: 노드 간 파드 통신

파드에서 외부통신 확인

파드에서 외부로 통신 시에는 파드가 동작하는 노드의 이더넷 IP로 SNAT이 되어 외부와 통신이 됩니다.

tcpdump: 파드 -> 외부 통신확인

Iptables 설정을 확인해 보면, AWS-SNAT-CHAIN 룰에 의해서 SANT 되어 외부로 통신할 수 있게 됩니다.

 

ALB(AWS Load Balancer)

AWS LoadBalancer Controller

 

ALB Controller는 kubernetes 클러스터에 ALB를 배포하려면 먼저, 필수적으로 설치되어야 하는 컨트롤러입니다.
쿠버네티스에서 ALB/NLB를 자동으로 생성하고 관리하며, 가장 큰 특징은 ALB 컨트롤러 파드를 통해서 지속적인 정보(파드의 IP)를 제공받아 서비스를 거치지 않고 바로 파드의 IP로 통신한다는 점입니다. 또한 쿠버네티스의 리소스를 제어를 통해서 targetgroup 등 AWS의 리소스와의 통합하여 관리할 수 있다는 장점이 있습니다.

 

이제, ALB Controller를 배포합니다.

# Helm Chart 설치
helm repo add eks https://aws.github.io/eks-charts
helm repo update
helm install aws-load-balancer-controller eks/aws-load-balancer-controller -n kube-system --set clusterName=$CLUSTER_NAME

 

설치된 리소스를 확인합니다. ALB 서비스 어카운트에 권한이 세팅이 되어있다는 전제하에 실습을 진행합니다.

## 설치 확인
kubectl get crd
kubectl get deployment -n kube-system aws-load-balancer-controller
kubectl describe deploy -n kube-system aws-load-balancer-controller
kubectl describe deploy -n kube-system aws-load-balancer-controller | grep 'Service Account'

 

서비스에서 NLB 활용

NLB 서비스 파드 배포

• loadBalancerClass: service.k8s.aws/nlb : AWS에서 제공하는 NLB(Network Load Balancer)를 사용할 것을 지정합니다.

cat <<EOF | kubectl create -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-echo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: deploy-websrv
  template:
    metadata:
      labels:
        app: deploy-websrv
    spec:
      terminationGracePeriodSeconds: 0
      containers:
      - name: akos-websrv
        image: k8s.gcr.io/echoserver:1.5
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: svc-nlb-ip-type
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
    service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
    service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: "8080"
    service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
spec:
  ports:
    - port: 80
      targetPort: 8080
      protocol: TCP
  type: LoadBalancer
  loadBalancerClass: service.k8s.aws/nlb
  selector
    app: deploy-websrv
EOF

 

LoadBalancer Tpye의 서비스를 확인합니다.

(admin-eks@myeks:N/A) [root@myeks-bastion ~]# kubectl get pod -o wide
NAME                           READY   STATUS    RESTARTS   AGE   IP              NODE                                               NOMINATED NODE   READINESS GATES
deploy-echo-857b6cfb88-pj2x7   1/1     Running   0          81s   192.168.3.135   ip-192-168-3-14.ap-northeast-2.compute.internal    <none>           <none>
deploy-echo-857b6cfb88-q9txl   1/1     Running   0          81s   192.168.1.134   ip-192-168-1-239.ap-northeast-2.compute.internal   <none>           <none>
(admin-eks@myeks:N/A) [root@myeks-bastion ~]# kubectl get pod,svc -o wide
NAME                               READY   STATUS    RESTARTS   AGE    IP              NODE                                               NOMINATED NODE   READINESS GATES
pod/deploy-echo-857b6cfb88-pj2x7   1/1     Running   0          115s   192.168.3.135   ip-192-168-3-14.ap-northeast-2.compute.internal    <none>           <none>
pod/deploy-echo-857b6cfb88-q9txl   1/1     Running   0          115s   192.168.1.134   ip-192-168-1-239.ap-northeast-2.compute.internal   <none>           <none>

NAME                      TYPE           CLUSTER-IP    EXTERNAL-IP                                                                         PORT(S)        AGE    SELECTOR
service/kubernetes        ClusterIP      10.100.0.1    <none>                                                                              443/TCP        90m    <none>
service/svc-nlb-ip-type   LoadBalancer   10.100.8.26   k8s-default-svcnlbip-54b460fe01-cf1f57c8afd126b9.elb.ap-northeast-2.amazonaws.com   80:31812/TCP   115s   app=deploy-websrv

 

AWS 콘솔을 통해서도 생성한 서비스와 대상그룹(Target Group)이 잘 생성됨을 확인할 수 있습니다.

 

반복 접속 시마다, 부하분산이 이루어지는 것을 확인할 수 있습니다.

(admin-eks@myeks:N/A) [root@myeks-bastion ~]# for i in {1..100}; do curl -s $NLB | grep Hostname ; done | sort | uniq -c | sort -nr

     51 Hostname: deploy-echo-857b6cfb88-q9txl
     49 Hostname: deploy-echo-857b6cfb88-pj2x7

 

웹에서 반복 접속 시, Hostname이 변경되는 것을 확인할 수 있습니다. 이는 부하분산이 잘 이루어짐을 나타냅니다.

 

Ingress에서 ALB 활용

Ingress 리소스에서도 ingressClassName: alb로 설정하여 AWS LoadBalancer Controller가 ALB를 생성하도록 지정할 수 있습니다.

kubectl get ingressclass
NAME   CONTROLLER            PARAMETERS   AGE
alb    ingress.k8s.aws/alb   <none>       43m

 

서비스 파드 배포
간단한 게임을 제공하는 파드와 서비스를 배포하고, 이번에는 ingress에서 ALB를 생성하여, 동작을 확인합니다.

cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Namespace
metadata:
  name: game-2048
---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: game-2048
  name: deployment-2048
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: app-2048
  replicas: 2
  template:
    metadata:
      labels:
        app.kubernetes.io/name: app-2048
    spec:
      containers:
      - image: public.ecr.aws/l6m2t8p7/docker-2048:latest
        imagePullPolicy: Always
        name: app-2048
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  namespace: game-2048
  name: service-2048
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  type: NodePort
  selector:
    app.kubernetes.io/name: app-2048
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: game-2048
  name: ingress-2048
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: service-2048
              port:
                number: 80
EOF

 

AWS 콘솔에서도 ALB가 잘 생성되었고, 인그레스에서 설정한 Routing 룰과 일치하는 것을 확인할 수 있습니다.

 

Ingress에서 생성한 ALB 역시, ALB Controller에 의해 서비스를 거치지 않고, 파드의 IP로 직접 통신하게 된다.

Externel-IP 주소를 통해 게임에 접속되는 것을 확인할 수 있습니다.

Externel DNS

Externel DNS를 사용하면, K8S 서비스/인그레스 생성 시 도메인을 설정하면, 다양한 DNS 서비스(Route53, CoreDNS, PowerDNS)에 레코드를 생성하고 관리할 수 있습니다.

 

먼저, ExternelDNS를 설치합니다.

MyDomain=<자신의 도메인>
MyDomain=hackjap.com

# 자신의 Route 53 도메인 ID 조회 및 변수 지정
MyDnzHostedZoneId=$(aws route53 list-hosted-zones-by-name --dns-name "${MyDomain}." --query "HostedZones[0].Id" --output text)

# 변수 확인
echo $MyDomain, $MyDnzHostedZoneId

# ExternalDNS 배포
curl -s -O https://raw.githubusercontent.com/gasida/PKOS/main/aews/externaldns.yaml
cat externaldns.yaml
MyDomain=$MyDomain MyDnzHostedZoneId=$MyDnzHostedZoneId envsubst < externaldns.yaml | kubectl apply -f -

# 확인 및 로그 모니터링
kubectl get pod -l app.kubernetes.io/name=external-dns -n kube-system
kubectl logs deploy/external-dns -n kube-system -f

 

테트리스 디플로이먼트와 NLB 서비스를 배포합니다.

# 테트리스 디플로이먼트 배포
cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: tetris
  labels:
    app: tetris
spec:
  replicas: 1
  selector:
    matchLabels:
      app: tetris
  template:
    metadata:
      labels:
        app: tetris
    spec:
      containers:
      - name: tetris
        image: bsord/tetris
---
apiVersion: v1
kind: Service
metadata:
  name: tetris
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
    service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
    service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "http"
    #service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: "80"
spec:
  selector:
    app: tetris
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  type: LoadBalancer
  loadBalancerClass: service.k8s.aws/nlb
EOF

 

NLB에 ExternelDNS로 도메인을 연결합니다.

kubectl annotate service tetris "external-dns.alpha.kubernetes.io/hostname=tetris.$MyDomain"
while true; do aws route53 list-resource-record-sets --hosted-zone-id "${MyDnzHostedZoneId}" --query "ResourceRecordSets[?Type == 'A']" | jq ; date ; echo ; sleep 1; done

 

Route53의 A 레코드가 추가된 것을 확인할 수 있습니다.

 

이제 등록한 도메인을 통해 테트리스 게임이 잘 접속되는지 확인합니다.

Topology Aware Routing(구 Topology Hints)

Topology Aware Routing은 Kubernetes에서 트래픽을 가깝게 위치한 노드로 라우팅 하여 성능을 최적화하는 기능입니다. 대규모 네트워크의 경우 멀티 AZ, 클러스터 환경에서 라우팅을 효율적으로 하는 것만으로도 네트워크 비용과 성능이 향상되기 때문에, 효율적인 트래픽 처리에 있어서 고려해야 하는 부분입니다.

 

노드의 AZ 정보 확인합니다.

(admin-eks@myeks:N/A) [root@myeks-bastion ~]# kubectl get node --label-columns=topology.kubernetes.io/zone

NAME                                               STATUS   ROLES    AGE    VERSION               ZONE
ip-192-168-1-239.ap-northeast-2.compute.internal   Ready    <none>   3h2m   v1.30.4-eks-a737599   ap-northeast-2a
ip-192-168-2-85.ap-northeast-2.compute.internal    Ready    <none>   3h2m   v1.30.4-eks-a737599   ap-northeast-2b
ip-192-168-3-14.ap-northeast-2.compute.internal    Ready    <none>   3h2m   v1.30.4-eks-a737599   ap-northeast-2c

 

실습을 위해 접속 테스트를 할 Client/Server 파드와 서비스를 배포합니다.

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-echo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: deploy-websrv
  template:
    metadata:
      labels:
        app: deploy-websrv
    spec:
      terminationGracePeriodSeconds: 0
      containers:
      - name: websrv
        image: registry.k8s.io/echoserver:1.5
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: svc-clusterip
spec:
  ports:
    - name: svc-webport
      port: 80
      targetPort: 8080
  selector:
    app: deploy-websrv
  type: ClusterIP
EOF

# 접속 테스트를 수행할 클라이언트 파드 배포
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: netshoot-pod
spec:
  containers:
  - name: netshoot-pod
    image: nicolaka/netshoot
    command: ["tail"]
    args: ["-f", "/dev/null"]
  terminationGracePeriodSeconds: 0
EOF

 

3개의 파드가 연결된 서비스로 접속 테스트를 해보면, 랜덤 부하분산 됨을 확인할 수 있습니다.

kubectl exec -it netshoot-pod -- zsh -c "for i in {1..100}; do curl -s svc-clusterip | grep Hostname; done | sort | uniq -c | sort -nr"

     42 Hostname: deploy-echo-859cc9b57d-zpx7n
     29 Hostname: deploy-echo-859cc9b57d-prsjp
     29 Hostname: deploy-echo-859cc9b57d-2n8mt

 

Iptables 룰에는 아래와 같이 랜덤 부하분산 설정이 적용되어 있습니다.

이제, topology aware routing을 적용합니다. annotation 명령어를 통해 service.kubernetes.io/topology-mode=auto를 추가하면, 자동으로 설정이 적용됩니다. endpointsslices를 확인해 보면 hints 정보가 들어있는데, AZ에 따라 라우팅 될 파드의 정보가 들어있는 것을 확인할 수 있습니다.

 

이제 서비스로 반복 요청을 시도하면 한 개의 파드로만 전부 라우팅 되는 것을 확인할 수 있습니다. 이는 서비스를 요청한 Client 파드로 가까운 AZ의 파드로부터 응답한 것입니다.

(admin-eks@myeks:N/A) [root@myeks-bastion ~]# kubectl exec -it netshoot-pod -- zsh -c "for i in {1..100}; do curl -s svc-clusterip | grep Hostname; done | sort | uniq -c | sort -nr"
    100 Hostname: deploy-echo-859cc9b57d-zpx7n                      

 

Iptables룰을 확인해 보면 기존에 적용되었던 랜덤부하분산 설정이 제거되고 한 개의 파드 엔드포인트 정보만 남게 됩니다.

 

Network Policies with VPC CNI

EKS 네트워크 플러그인 VPC CNI에서 쿠버네티스의 NetworkPolicy 기능을 기본 지원하게 되어, 써드파트 플러그인 없이, 클러스터의 파드 네트워크 트래픽 보호하고 격리할 수 있습니다. eBPF 기반 네트워크 정책을 사용하여 커널 내에서 패킷 필터링을 수행하기 때문에, 기존 iptables 방식보다 효율적입니다. 또한, AWS의 보안그룹(SG), VPC등과 통합이 가능해 AWS 인프라와 일관성을 유지할 수도 있다는 장점이 있습니다.

 

EKS에서 NetworkPolicy 기능을 사용하기 위해서는 아래와 같은 조건이 필요합니다.

• EKS 1.25 +
• AWS VPC CNI 1.14+
• OS 커널 5.10 +
• EKS 최적화 AMI(AL2, Bottlerocket, Ubuntu)

enableNetworkPolicy: "true" 설정을 통해 Network Policy 기능을 활성화할 수 있습니다.

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
...
addons:
  - name: vpc-cni
    version: 1.14.0
    attachPolicyARNs: #optional
    - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy 
    configurationValues: |-
      enableNetworkPolicy: "true"

# 적용 
eksctl create cluster -f cluster.yaml

 

활성화를 확인하기 위해서, 아래 aws-node 데몬 셋의 매개변수와, bpf 볼륨 설정을 확인합니다.

kubectl get ds aws-node -n kube-system -o yaml | k neat
...
    - args: 
      - --enable-ipv6=false
      - --enable-network-policy=true
...
    volumeMounts: 
    - mountPath: /host/opt/cni/bin
      name: cni-bin-dir
    - mountPath: /sys/fs/bpf
      name: bpf-pin-path
    - mountPath: /var/log/aws-routed-eni
      name: log-dir
    - mountPath: /var/run/aws-node
      name: run-dir
...

# EKS 1.25 버전 이상 확인
kubectl get nod

# OS 커널 5.10 이상 확인
ssh ec2-user@$N1 uname -r
5.10.210-201.852.amzn2.x86_64

 

이제, 실습을 통해서, NetworkPolicy을 기능이 잘 동작하는지 확인합니다.

 

먼저, 샘플 애플리케이션을 배포합니다.

git clone https://github.com/aws-samples/eks-network-policy-examples.git
cd eks-network-policy-examples
tree advanced/manifests/
kubectl apply -f advanced/manifests/

(admin-eks@myeks:N/A) [root@myeks-bastion eks-network-policy-examples]# kubectl get pod,svc
NAME                            READY   STATUS    RESTARTS       AGE
pod/client-one                  1/1     Running   0              65m
pod/client-two                  1/1     Running   0              65m
pod/demo-app-786dbc7dfc-xlfqq   1/1     Running   0              65m
pod/netshoot-pod                1/1     Running   0              106m

NAME                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/demo-app     ClusterIP   10.100.49.222   <none>        80/TCP    65m
...

 

실습 구성은 다음과 같습니다. 두 네임스페이스의 서로 다른 두 개의 파드가 동작합니다.

https://aws.amazon.com/ko/blogs/containers/amazon-vpc-cni-now-supports-kubernetes-network-policies/

서로 다른 네임스페이스 간 파드 통신 시, 정상적으로 응답을 가져옵니다.

 

이제, 모든 트래픽을 거부하는 네트워크 정책을 적용합니다.

# 배포 
cat << EOF | kubectl apply -f -
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: demo-app-deny-all
spec:
  podSelector:
    matchLabels:
      app: demo-app
  policyTypes:
  - Ingress
EOF

# 확인 
kubectl get networkpolicy
NAME                POD-SELECTOR   AGE
demo-app-deny-all   app=demo-app   10s

 

다시 서비스로 요청을 하면, 이번에는 연결에 실패가 되는 것을 확인할 수 있습니다.

 

각 노드에서 eBPF 관련 정보를 확인해 보면, 실행 중인 eBPF 프로그램을 확인할 수 있습니다.

 

eBPF 로그는 아래 경로를 통해 확인할 수 있습니다.

for i in $N1 $N2 $N3; do echo ">> node $i <<"; ssh ec2-user@$i sudo cat /var/log/aws-routed-eni/ebpf-sdk.log; echo; done
for i in $N1 $N2 $N3; do echo ">> node $i <<"; ssh ec2-user@$i sudo cat /var/log/aws-routed-eni/network-policy-agent; echo; done

 

이번에는 Ingress(수신)이 아닌, Egress(송신) 네트워크 정책을 적용합니다. client-one 라벨을 가진 파드에서 모든 egress 통신을 차단합니다.

cat << EOF | kubectl apply -f -
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: client-one-deny-egress
spec:
  podSelector:
    matchLabels:
      app: client-one
  egress: []
  policyTypes:
  - Egress
EOF

k get networkpolicies.networking.k8s.io 
NAME                     POD-SELECTOR     AGE
client-one-deny-egress   app=client-one   26s

 

client-one 파드에서 네트워크 정책을 적용하기 전과 후의 응답 결과를 확인할 수 있습니다.

client-two 파드에서는 정상으로 egress 통신이 되는 것을 확인할 수 있습니다.