Part 4 — 네트워킹과 스토리지

Chapter 19. K8s 네트워크 모델

* 세 가지 네트워크 통신

K8s의 네트워크 모델에는 세 가지 수준의 통신이 있다:

1) 같은 Pod 안의 컨테이너 간 통신: localhost로 통신. 포트만 다르면 된다.

2) Pod 간 통신: 모든 Pod은 고유한 IP를 가지며, 클러스터 내의 모든 Pod은 NAT 없이 서로 직접 통신할 수 있다.

용어: NAT(Network Address Translation) — IP 주소를 다른 IP 주소로 변환하는 기술이다. 가정에서 공유기를 쓸 때, 내부 IP(192.168.x.x)가 공유기를 통해 공인 IP로 변환되는 것이 NAT다. K8s는 Pod 간 통신에서 NAT를 쓰지 않는다. Pod A가 Pod B의 IP로 직접 통신한다.

3) 외부 → 클러스터 내부 통신: Service(NodePort, LoadBalancer)나 Ingress를 통해 외부 트래픽을 클러스터 내부 Pod으로 전달한다.

* CNI — 네트워크를 구현하는 플러그인

용어: CNI(Container Network Interface) — K8s의 네트워크를 실제로 구현하는 플러그인 표준이다. K8s 자체는 네트워크 구현을 포함하지 않고, CNI 플러그인에 위임한다.

K8s는 “모든 Pod은 서로 통신할 수 있어야 한다”는 요구사항만 정의하고, 이를 어떻게 구현할지는 CNI 플러그인이 결정한다.

대표적인 CNI 플러그인:

• Calico: 가장 널리 사용된다. 네트워크 정책(Network Policy) 지원이 강하다.
• Flannel: 설정이 간단하다. 소규모 클러스터에 적합하다.
• Cilium: eBPF 기반으로 고성능. 최근 주목받고 있다.
• Weave Net: 설치가 쉽고 암호화를 내장하고 있다.

용어: eBPF — Extended Berkeley Packet Filter. 리눅스 커널 안에서 프로그램을 실행할 수 있게 하는 기술이다. 네트워크 패킷 처리를 커널 수준에서 매우 빠르게 할 수 있다. Cilium이 이 기술을 사용한다.

 

---

 

Chapter 20. Ingress — HTTP 라우팅

* 왜 Ingress가 필요한가

LoadBalancer 타입의 Service를 쓰면 외부 접근이 가능하지만, 서비스마다 로드밸런서 하나가 생긴다. 서비스가 10개면 로드밸런서 10개. 비용이 많이 든다.

Ingress는 하나의 진입점으로 여러 Service에 HTTP/HTTPS 트래픽을 라우팅하는 리소스다.

                    Ingress
                      │
         ┌────────────┼────────────┐
         │            │            │
    /api/*        /web/*      /admin/*
         │            │            │
    api-service   web-service  admin-service

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - host: myapp.example.com         # 도메인 기반 라우팅
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 80
          - path: /web
            pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 80
  tls:                                 # HTTPS 설정
    - hosts:
        - myapp.example.com
      secretName: tls-secret           # TLS 인증서가 담긴 Secret

* Ingress Controller

용어: Ingress Controller — Ingress 리소스를 실제로 동작하게 하는 컴포넌트다. Ingress 리소스만 만들면 아무 일도 안 일어난다. 반드시 Ingress Controller가 클러스터에 설치되어 있어야 한다.

K8s 자체에는 Ingress Controller가 포함되어 있지 않다. 별도로 설치해야 한다.

대표적인 Ingress Controller:

• NGINX Ingress Controller: 가장 보편적. NGINX를 기반으로 한 리버스 프록시.
• Traefik: 자동 설정, Let’s Encrypt 통합 등이 편리하다.
• HAProxy Ingress: HAProxy 기반. 고성능이 필요할 때.
• AWS ALB Ingress Controller: AWS 환경에서 ALB를 자동 프로비저닝.

 

---

 

Chapter 21. Network Policy — 네트워크 접근 제어

용어: Network Policy — Pod 수준의 방화벽 규칙이다. 어떤 Pod이 어떤 Pod과 통신할 수 있는지를 제어한다.

기본적으로 K8s에서는 모든 Pod이 모든 Pod과 통신할 수 있다. Network Policy를 적용하면 이것을 제한할 수 있다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      role: backend              # 이 정책이 적용되는 Pod
  policyTypes:
    - Ingress                    # 들어오는 트래픽 제어
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: frontend     # frontend Pod에서만 접근 허용
      ports:
        - protocol: TCP
          port: 8080

이 정책의 의미: “backend Pod에는 frontend Pod에서 오는 8080 포트 트래픽만 허용하고, 나머지는 전부 차단한다.”

주의: Network Policy가 동작하려면 CNI 플러그인이 Network Policy를 지원해야 한다. Calico, Cilium은 지원하지만, Flannel은 기본적으로 지원하지 않는다.

 

---

 

Chapter 22. PersistentVolume과 PersistentVolumeClaim

* PV와 PVC의 관계

용어: PersistentVolume (PV) — 클러스터 수준의 스토리지 자원이다. 관리자가 미리 프로비저닝하거나, StorageClass를 통해 동적으로 생성된다.

용어: PersistentVolumeClaim (PVC) — 사용자(개발자)가 스토리지를 요청하는 방법이다. “나에게 10Gi 스토리지를 줘”라고 요청한다.

비유하자면: PV는 주차장의 주차 공간이고, PVC는 주차 티켓이다. 주차 공간(PV)은 관리자가 만들어두고, 사용자는 티켓(PVC)을 발급받아서 공간을 사용한다.

# PersistentVolume (관리자가 생성)
apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce              # 하나의 노드에서만 읽기/쓰기
  persistentVolumeReclaimPolicy: Retain   # PVC 삭제 후에도 데이터 유지
  hostPath:                      # 예시용. 프로덕션에서는 NFS, 클라우드 스토리지 등 사용
    path: /mnt/data

---
# PersistentVolumeClaim (사용자가 요청)
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi               # 5Gi 요청 (10Gi PV에 바인딩됨)

Access Modes

• ReadWriteOnce (RWO): 하나의 노드에서만 읽기/쓰기 가능. 가장 일반적이다.
• ReadOnlyMany (ROX): 여러 노드에서 읽기만 가능.
• ReadWriteMany (RWX): 여러 노드에서 읽기/쓰기 가능. NFS 등 공유 스토리지가 필요하다.

Reclaim Policy

PVC가 삭제될 때 PV의 데이터를 어떻게 처리할지:

• Retain: 데이터를 보존한다. 관리자가 수동으로 정리해야 한다.
• Delete: PV와 데이터를 자동으로 삭제한다. 클라우드 환경에서 많이 사용.
• Recycle: (더 이상 권장되지 않음) 데이터를 삭제하고 PV를 재사용.

Pod에서 PVC 사용

apiVersion: v1
kind: Pod
metadata:
  name: app-with-storage
spec:
  containers:
    - name: app
      image: my-app:1.0
      volumeMounts:
        - name: data-volume
          mountPath: /app/data        # 컨테이너 안에서 이 경로로 접근
  volumes:
    - name: data-volume
      persistentVolumeClaim:
        claimName: my-pvc             # PVC 이름 참조

 

---

 

Chapter 23. StorageClass — 동적 프로비저닝

PV를 일일이 수동으로 만드는 건 번거롭다. StorageClass를 사용하면 PVC가 생성될 때 자동으로 PV가 만들어진다.

용어: 동적 프로비저닝(Dynamic Provisioning) — PVC를 만들면 StorageClass가 자동으로 적절한 PV를 생성해주는 것이다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs    # 스토리지 제공자
parameters:
  type: gp3                           # AWS EBS gp3
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer  # Pod이 스케줄링될 때까지 바인딩 지연

# PVC에서 StorageClass 지정
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-dynamic-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: fast-ssd          # 이 StorageClass 사용
  resources:
    requests:
      storage: 20Gi

PVC를 만들면 StorageClass가 자동으로 20Gi SSD 볼륨을 만들고 PV를 생성해서 바인딩한다. 수동으로 PV를 만들 필요가 없다.

실무 포인트: 클라우드 환경(NHN Cloud, AWS, GCP 등)에서는 StorageClass 기반의 동적 프로비저닝을 쓰는 것이 일반적이다. 각 클라우드마다 provisioner 이름이 다르다.