Kubernetes Network Model & Policy

쿠버네티스 클러스터 구성 중에 CNI(Container Network Interface)를 설치하지 않으면 포드간에 통신이 되지 않는다.

CNI는 쿠버네티스 네트워크 모델 구현체라고 할 수 이다.  

 

네트워크 모델의 여러 기능중에서 개인적으로 중요하다고 생각하는 부분만 살펴보겠다.

Kubernetes Networking Model

- Every Pod gets its own IP address.

- pods on a node can communicate with all pods on all nodes without NAT

- containers within a Pod must coordinate port usage

communication between containers in a Pod
- shared volumes
- Inter-process communications(IPC)
- Inter-container network communication

 

위의 네트워크 모델을 구현하는 여러가지 플러그인(Calico, WeaveNet ...)들이 존재하고, 각 플러그인 마다 장단점이 존재한다고 한다.

 

예를들면 GKE, EKS or AKS 등과 같은 대형 클라우드 업체에서 제공하는 쿠버네티스 서비스는 그들 자신의 Contaer Network Interface(CNI)를 가지고 있기 때문에 별도의 작업이 필요 없다. 이러한 대형 클라우드 업체들은 Calico를 기반으로 쿠버네티스 네트워크 모델을 구현한다고 한다.

 

AWS EKS 공식 문서를 한편 살펴보자. 

https://docs.aws.amazon.com/eks/latest/userguide/calico.html

 

Project Calico
 is a network policy engine for Kubernetes. With Calico network policy enforcement, you can implement network segmentation and tenant isolation.

 

정말 사용하고 있다! 나는 개인 On-Prem network 및 테스트에 적합하다고 하는 WeaveNet을 사용했다.

 

플러그인들을 크게 특징/타입으로 나누어 보자면 아래와 같다. 

- Cloud : Pod traffic is routed in cloud virtual network

- Overlay(ex. VXLAN) : Pod traffic is encapsulated and uses underlay for reachability

- Routing Config(ex. BGP) : Pod traffic is routed in underlay network

 

Calico는 Router Config에 해당하고, WeaveNet은 Overlay 타입/특징이라 할 수 있다.

 

이처럼 플러그인들은 각기 다른 멋진 특색을 가지고 있기 때문에 시스템에 가장 적합한 플러그인을 선택해야한다.

 

이제 Network Policy에 대해서 살펴보자.

 

보통은 인바운드 규칙을 만들고, 시스템으로 들어오는 트래픽을 제어한다. 

지금까지의 경험으로는 일부 기관을 제외하고는 아웃바운드는 모두 오픈했다.

 

Network Policy

Ingress

인그레스는 인바운드 방향의 트래픽 룰을 설정한다. 설정 범위는 podSelector로 지정한다.

- ipBlock : 특정 IP 대역으로부터 들어오는 트래픽만 허용.

- podSelector : 특정 파드로부터 들어오는 트래픽만 허용.

- namespaceSelector : 특정 네임스페이스로 부터 들어오는 트래픽만 허용.

- Protocol & Port : 특정 프로토콜 및 포트로부터 들어오는 트래픽만 허용.

 

Egress

이그레스는 아웃바운드 방향의 트래픽 룰을 설정한다. 설정 범위는 podSelector로 지정한다.

- ipBlock : 특정 IP 대역으로 나가는 트래픽만 허용.

- podSelector : 특정 파드로 나가는 통신 허가

- namespaceSelector : 특정 네임스페이스상에 있는 파드로 나가는 통신 허가.

- Protocol & Port : 특정 프로토콜 및 포트로 나가는 트래픽만 허용.

 

네트워크 정책예제

- kubectl get networkpolicy

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: sample-networkpolicy
  namespace: default # 네트워크 정책을 생성할 네임스페이스 지정
spec:
  podSelector:
    # 설정할 대상 파드를 여기에 기입
    # 레이블 셀렉터이므로 여러 파드를 대상으로 할 수 있음
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
      # Ingress 룰을 기입
    ports:
      # 허가할 수신 포트 번호와 프로토콜 기입
  egress:
  - to:
      # Egress 룰을 기입
    ports:
      # 허가할 목적지 포트 번호와 프로토콜 기입

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-policy
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          name: api-pod
      namespaceSelector:
        matchLabels:
          name: prod
    - namespaceSelector:
        matchLabels:
          name: na
    - ipBlock:
          cidr: 192.168.5.10/32
    ports:
    - protocol: TCP
      port: 3306
  egress:
  - to:
    - ipBlock:
          cidr: 192.168.5.10/32
    ports:
    - protocol: TCP
      port: 80
  - to:
    - podSelector:
         matchLabels:
           name: mysql
    ports:
    - protocol: TCP
      port: 3306

 

참고로, EKS 에서 Calico를 설치하고 NetworkPolicy의 ipBlock을 이용하여 클러스터 밖에서 접속하는 특정 트래픽만 허용하는 방화벽 설정(화이트리스트)을 하였지만 정상적으로 동작하지 않았다. 그 이유는 클러스터 내부로 트래픽이 들어올 시 Source 주소가 변경되기 때문이다(SNAT). 만약 로드밸런서로 클러스터 밖에서 트래픽이 들어올 수 있도록 허용해놓은 상황이라면 NetworkPolicy가 아닌 로드밸런서 방화벽 설정을 살펴봐야한다.

NetworkPolicies are an application-centric construct which allow you to specify how a pod is allowed to communicate with various network "entities" (we use the word "entity" here to avoid overloading the more common terms such as "endpoints" and "services", which have specific Kubernetes connotations) over the network.

출처 : https://kubernetes.io/docs/concepts/services-networking/network-policies/

https://github.com/projectcalico/calico/issues/2088

https://docs.aws.amazon.com/quickstart/latest/vpc/images/quickstart-vpc-design-fullscreen.png

 

 

참고

1. NAT란

모든 IP 패킷에는 Source IP와 Destination IP가 있다.

NAT란, Network Address Translation, 즉 IP 패킷 헤더의 IP 주소를 변경하는 기능 혹은 절차를 뜻한다. 1:1 NAT 혹은 1:다 NAT가 있다.

• PREROUTING : DNAT을 이용하여 패킷이 생길 때 사용됨
• POSTROUTING : SNAT을 이용하여 패킷이 나갈 때 사용됨

2. SNAT

• 내부 -> 외부
• 패킷의 Source 주소를 변경하는 것으로  Source NAT, SNAT, 혹은 IP 마스커레이드라고 한다.
• 인터넷으로 나가는 패킷의 Source IP를 G/W의 Public IP로 바꾼다.

3. DNAT

• 외부 -> 내부
• Destination IP 주소를 변경하여 내부에 접근할 수 있도록 패킷을 변경한다.
• 대표적인 것은 Load Balancer이다. 

---

출처

Networkpolicy with Calico on EKS

https://docs.projectcalico.org/getting-started/kubernetes/managed-public-cloud/eks

https://docs.projectcalico.org/about/about-kubernetes-services

https://docs.aws.amazon.com/eks/latest/userguide/calico.html

https://docs.aws.amazon.com/eks/latest/userguide/alternate-cni-plugins.html

https://github.com/projectcalico/calico/issues/2088

 

기타

- https://github.com/kubernetes/community/blob/master/contributors/design-proposals/network/networking.md

- https://www.slideshare.net/CodeOps/kubernetes-networking-sreenivas-makam-google-cc18

- https://ssup2.github.io/theory_analysis/Kubernetes_Calico_Plugin/

- https://itnext.io/benchmark-results-of-kubernetes-network-plugins-cni-over-10gbit-s-network-updated-april-2019-4a9886efe9c4

- https://bcho.tistory.com/1353?category=731548 

- https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing

- https://docs.aws.amazon.com/eks/latest/userguide/calico.html

- https://www.mirantis.com/blog/multi-container-pods-and-container-communication-in-kubernetes/

- https://kubedex.com/kubernetes-network-plugins/

- https://kubernetes.io/docs/concepts/cluster-administration/networking/

- https://thenordicweb.com/Kubernetes-Network-Cilium-1d4371f562ea4acdb5e679e376a7c992