[Kubernetes] 컨테이너 네트워크 서비스(CNI)

10월 29일(화) 수업 내용 중

컨테이너 네트워크 인터페이스(CNI)와 쿠버네티스 네트워킹

여러 컨테이너와 애플리케이션이 서로 데이터를 공유하고 안정적으로 연결되는 환경을 구축하려면 네트워킹의 역할이 매우 중요하다. 쿠버네티스에서는 컨테이너 간 통신과 데이터 공유를 효율적으로 관리하기 위해 CNI(Container Network Interface)와 SDN(Software-Defined Networking)을 활용한다. 이번 시간에는 CNI와 SDN이 어떻게 쿠버네티스 네트워크에서 활용되는지, 주요 설정 파일과 예제를 통해 배웠다.

---

1. CNI (Container Network Interface) 란?

• 쿠버네티스에서 컨테이너의 네트워크 설정을 담당하는 표준화된 인터페이스
• CNI는 쿠버네티스가 각 Pod에 IP를 할당하고, 네트워크 설정을 통해 클러스터 내/외부에서 안정적인 통신이 가능하도록 한다.
• CNI는 플러그인 방식으로, 다양한 네트워크 플러그인(Calico, Flannel, Weave 등)을 통해 확장 가능하며, 쿠버네티스 클러스터의 네트워크를 사용자 환경에 맞춰 손쉽게 구성할 수 있다.

2. 볼륨을 통한 데이터 공유

볼륨(volume): 컨테이너 환경에서 데이터를 지속적으로 저장하거나 다른 컨테이너 간 데이터 공유를 가능하게 하는 방식. 컨테이너의 수명은 일시적이지만, 볼륨을 사용하면 데이터를 안전하게 보관할 수 있어 컨테이너를 재시작해도 데이터를 유지할 수 있다.

 

Container → Pod → ReplicaSet/Deployment → Cluster → 외부

- Conatiner 레벨: 동일 Pod 내의 컨테이너들은 볼륨을 통해 데이터를 공유할 수 있다.

- Pod 레벨: Pod에 정의된 볼륨은 Pod 내부의 모든 컨테이너가 접근 가능하고, Pod가 재시작되어도 데이터가 유지된다.

- ReplicaSet/Deployment 레벨: Persistent Volume(PV)을 통해 여러 Pod 간 데이터 공유 가능. 스토리지 클래스를 사용하면 동적 볼륨 프로비저닝도 가능. 

- Cluster 레벨: 클러스터 전체에서 사용 가능한 공유 스토리지 관리. 스토리지 클래스를 통한 스토리지 리소스 관리

3. SDN (Software-Defined Networking) : 소프트웨어 정의 네트워킹이란?

SDN이 필요한 이유

• 네트워크 리소스를 가상화하고 컨테이너화된 애플리케이션의 요구사항에 따라 신속하게 네트워크를 재구성할 수 있도록
• SDN은 네트워크의 제어 평면(control plane)과 데이터 평면(data plane)을 분리해 소프트웨어에서 네트워크 구성을 프로그래밍할 수 있는 환경을 제공
• 쿠버네티스에서는 SDN을 활용해 Pod가 이동하더라도 올바른 경로로 트래픽을 흐르게 하여 파드 간 통신이 원활하게 이루어지도록 지원한다. 

4. 쿠버네티스에서 SDN과 CNI의 역할

쿠버네티스에서 SDN이 필요한 이유

 

쿠버네티스 환경에서는 수백 개의 파드가 존재하고, 그중 일부는 같은 서비스에 속해 있다. 이러한 파드들이 이동하거나 생성/삭제될 때에도 모든 트래픽이 정확히 라우팅될 수 있도록 네트워크 설정이 필요하다. 이를 위해 쿠버네티스는 Service Proxy와 CNI라는 두 가지 도구를 제공한다.

• Service Proxy: 파드 뒤에 위치하며 정적 IP를 가진 서비스 객체에 파드를 로드 밸런싱한다.
• CNI: Pod가 클러스터 내부 네트워크에서 안정적으로 재생되도록 하며, 외부와의 네트워크 연결을 관리한다.

이 두 가지를 통해 쿠버네티스에서 Pod가 항상 접근 가능한 상태를 유지하도록 하며, 네트워크의 확장성과 접근성을 동시에 보장한다. 

5. ClusterIP와 NodePort 서비스: 파드와 클러스터의 통신 방식

• ClusterIP: 클러스터 내부에서만 라우팅 가능한 기본적인 네트워크 요소. 클러스터 내 애플리케이션이 파드의 IP 주소를 이용해 다른 서비스와 통신할 수 있다.
• NodePort: 모든 노드의 특정 포트를 외부에 노출하여 외부 트래픽이 클러스터 내부의 파드로 전달되도록 한다. 이를 통해 외부 로드 밸런서를 설정하여 다양한 트래픽을 처리할 수 있다.

6. (실습) NodePort 서비스를 이용한 CoreDNS 컨테이너 설정

Cluster IP가 클러스터 내부 통신에 집중하는 반면, NodePort는 외부와의 연결을 허용한다. 이번 실습에서는 my-nodeport.yml 파일을 통해 쿠버네티스 클러스터의 CoreDNS 서비스를 NodePort로 설정해보았다. 

(1) my-nodeport.yml 파일 작성

apiVersion: v1
kind: Service
metadata:
  annotations:
    prometheus.io/port: "9153"
    prometheus.io/scrape: "true"
  labels:
    k8s-app: kube-dns
    kubernetes.io/cluster-service: "true"
    kubernetes.io/name: CoreDNS
  name: kube-dns-2
  namespace: kube-system
spec:
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - name: dns
    port: 53
    protocol: UDP
    targetPort: 53
  - name: dns-tcp
    port: 53
    protocol: TCP
    targetPort: 53
  selector:
    k8s-app: kube-dns
  sessionAffinity: None
  type: NodePort

• 클러스터 내부 Pod들은 53번 포트로 DNS 서비스 접근
• 외부에서는 NodePort(30530)를 통해 DNS 서비스 접근 가능
• UDP/TCP 두 프로토콜 모두 지원

위 파일을 통해 쿠버네티스 클러스터 내부 CoreDNS 컨테이너를 NodePort로 설정하고 나면, 외부에서 해당 포트를 통해 클러스터 내부의 DNS 서비스를 사용할 수 있다.

(2) 서비스 생성

kubectl apply -f my-nodeport.yml

(3) 서비스 확인

 kubectl get svc -o wide -A
 kubectl get svc,ep