개발

Kubernetes 심화

Service, Ingress, PV/PVC, 롤링 업데이트, RBAC 등 Kubernetes 실전 운영 가이드

이종관2025년 11월 8일

프로덕션 Kubernetes 운영에 필요한 네트워킹, 스토리지, 배포 전략, 접근 제어를 정리합니다.

Kubernetes의 기본 오브젝트(Pod, Deployment, Service)만으로는 프로덕션 환경의 요구사항을 충족하기 어렵습니다. 외부 트래픽 라우팅, 네트워크 정책, 스토리지 관리, 보안 설정 등 운영에 필요한 고급 기능을 알아야 안정적인 클러스터를 운영할 수 있습니다.

네트워킹 및 서비스

Service 종류

타입	접근 범위	사용 사례
ClusterIP	클러스터 내부	마이크로서비스 간 통신
NodePort	노드IP:포트	개발/테스트 환경
LoadBalancer	외부 LB	프로덕션 외부 노출

Ingress

HTTP/HTTPS 트래픽에 대한 라우팅 규칙을 정의합니다.

yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: api-v1
            port:
              number: 80
      - path: /v2
        pathType: Prefix
        backend:
          service:
            name: api-v2
            port:
              number: 80

Ingress Controller: Nginx, HAProxy, Traefik, Istio Gateway 등

Namespace

클러스터를 논리적으로 분리하여 리소스를 격리/관리합니다.

bash

kubectl create namespace dev
kubectl create namespace prod

NetworkPolicy

Pod 간 트래픽 흐름을 세밀하게 제어합니다.

podSelector는 정책을 적용할 대상 Pod를 지정합니다. ingress.from은 그 Pod로 트래픽을 보낼 수 있는 출처를 지정합니다. 아래 예시는 app: backend Pod가 app: frontend Pod에서 오는 인바운드 트래픽만 받도록 제한합니다.

yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

flowchart LR
    U["외부 클라이언트"] --> I["Ingress controller<br/>호스트와 경로 판정"]
    I --> S["Service<br/>안정된 접근 지점"]
    S --> A["Pod A"]
    S --> B["Pod B"]
    N["NetworkPolicy<br/>허용할 통신 선언"] -. "지원하는 CNI가 적용" .-> A
    N -.-> B

Ingress 규칙은 Ingress controller가 있어야 동작합니다. NetworkPolicy도 이를 지원하는 컨테이너 네트워크 인터페이스(Container Network Interface, CNI) 구현이 실제로 적용해야 합니다.

스토리지

Volume vs PV vs PVC

개념	설명
Volume	Pod 내부 마운트 디렉터리 (emptyDir, hostPath 등)
PersistentVolume (PV)	클러스터 레벨 스토리지 리소스
PersistentVolumeClaim (PVC)	Pod의 스토리지 요청

PV/PVC 예시

yaml

# PersistentVolume
apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /data/my-pv
 
---
# PersistentVolumeClaim
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

ConfigMap & Secret

yaml

# ConfigMap - 일반 설정
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DATABASE_URL: "postgres://db:5432"
  LOG_LEVEL: "info"
 
---
# Secret - 민감 정보
apiVersion: v1
kind: Secret
metadata:
  name: app-secret
type: Opaque
data:
  DB_PASSWORD: cGFzc3dvcmQxMjM=  # base64 인코딩

배포 전략

롤링 업데이트 (기본)

maxSurge는 목표 replica 수를 넘겨 추가로 띄울 수 있는 Pod 수입니다. maxUnavailable은 업데이트 중 동시에 중단해도 되는 Pod 수입니다. 아래처럼 maxUnavailable: 0으로 두면 새 Pod가 준비된 뒤에야 기존 Pod를 내리므로 가용 용량이 줄지 않습니다.

yaml

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # 추가 Pod 허용 수
      maxUnavailable: 0  # 동시 중단 허용 수

bash

# 배포
kubectl apply -f deployment.yaml
 
# 롤백
kubectl rollout undo deployment my-deployment
 
# 히스토리 확인
kubectl rollout history deployment my-deployment

Canary 배포

일부 트래픽(5~10%)만 새 버전으로 보냅니다. 안정성을 확인한 뒤 점진적으로 확대합니다.

yaml

# v1: 9개 replicas
# v2: 1개 replicas (약 10% 트래픽)

Service는 엔드포인트 단위로 부하를 분산하므로, replica 비율은 트래픽 분배의 근사값입니다. 정밀한 가중치 제어가 필요하면 Ingress 가중치나 서비스 메시(Istio 등)를 씁니다.

Blue/Green 배포

두 환경(Blue/Green)을 동시에 운영하고 트래픽을 한 번에 전환합니다.

bash

# Blue 환경 운영 중
# Green 환경에 새 버전 배포 & 테스트
# Service selector를 Green으로 변경

StatefulSet

상태를 가지는 애플리케이션(DB, 캐시 등) 배포용

Pod에 고유한 ID 부여
순서 보장 (생성/삭제)
고유한 PVC 연결

volumeClaimTemplates는 replica마다 별도 PVC를 생성하는 템플릿으로, 각 Pod가 자신의 영속 스토리지를 갖게 합니다.

yaml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: postgres
  replicas: 3
  selector:
    matchLabels:
      app: postgres
  template:
    # ...
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi

보안 및 접근 제어

RBAC (Role-Based Access Control)

RBAC는 어떤 사용자나 서비스 계정이 어떤 리소스에 어떤 동작을 할 수 있는지 권한을 제어합니다.

yaml

# Role - 네임스페이스 내 권한
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
 
---
# RoleBinding - 사용자에 Role 연결
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: dev
subjects:
- kind: User
  name: developer
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRole vs Role

종류	범위
Role	특정 네임스페이스 내
ClusterRole	클러스터 전체

Security Context

Pod/컨테이너 수준 보안 설정

yaml

spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
  containers:
  - name: app
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true

정리

주제	핵심
네트워킹	Service, Ingress, NetworkPolicy
스토리지	PV/PVC, ConfigMap, Secret
배포	Rolling, Canary, Blue/Green, StatefulSet
보안	RBAC, Security Context

쿠버네티스 운영의 핵심은 선언적 구성과 자동화입니다. YAML 매니페스트로 원하는 상태를 정의하면, 컨트롤러가 현재 상태와의 차이를 감지하고 자동으로 조정합니다. 네트워킹과 스토리지, 배포, 접근 제어도 이 선언적 모델에 따라 구성합니다.

전체 글

개발

Kubernetes 심화

Service, Ingress, PV/PVC, 롤링 업데이트, RBAC 등 Kubernetes 실전 운영 가이드

이종관2025년 11월 8일

프로덕션 Kubernetes 운영에 필요한 네트워킹, 스토리지, 배포 전략, 접근 제어를 정리합니다.

네트워킹 및 서비스

Service 종류

타입	접근 범위	사용 사례
ClusterIP	클러스터 내부	마이크로서비스 간 통신
NodePort	노드IP:포트	개발/테스트 환경
LoadBalancer	외부 LB	프로덕션 외부 노출

Ingress

HTTP/HTTPS 트래픽에 대한 라우팅 규칙을 정의합니다.

yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: api-v1
            port:
              number: 80
      - path: /v2
        pathType: Prefix
        backend:
          service:
            name: api-v2
            port:
              number: 80

Ingress Controller: Nginx, HAProxy, Traefik, Istio Gateway 등

Namespace

클러스터를 논리적으로 분리하여 리소스를 격리/관리합니다.

bash

kubectl create namespace dev
kubectl create namespace prod

NetworkPolicy

Pod 간 트래픽 흐름을 세밀하게 제어합니다.

yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

flowchart LR
    U["외부 클라이언트"] --> I["Ingress controller<br/>호스트와 경로 판정"]
    I --> S["Service<br/>안정된 접근 지점"]
    S --> A["Pod A"]
    S --> B["Pod B"]
    N["NetworkPolicy<br/>허용할 통신 선언"] -. "지원하는 CNI가 적용" .-> A
    N -.-> B

스토리지

Volume vs PV vs PVC

개념	설명
Volume	Pod 내부 마운트 디렉터리 (emptyDir, hostPath 등)
PersistentVolume (PV)	클러스터 레벨 스토리지 리소스
PersistentVolumeClaim (PVC)	Pod의 스토리지 요청

PV/PVC 예시

yaml

# PersistentVolume
apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /data/my-pv
 
---
# PersistentVolumeClaim
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

ConfigMap & Secret

yaml

# ConfigMap - 일반 설정
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DATABASE_URL: "postgres://db:5432"
  LOG_LEVEL: "info"
 
---
# Secret - 민감 정보
apiVersion: v1
kind: Secret
metadata:
  name: app-secret
type: Opaque
data:
  DB_PASSWORD: cGFzc3dvcmQxMjM=  # base64 인코딩

배포 전략

롤링 업데이트 (기본)

yaml

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # 추가 Pod 허용 수
      maxUnavailable: 0  # 동시 중단 허용 수

bash

# 배포
kubectl apply -f deployment.yaml
 
# 롤백
kubectl rollout undo deployment my-deployment
 
# 히스토리 확인
kubectl rollout history deployment my-deployment

Canary 배포

일부 트래픽(5~10%)만 새 버전으로 보냅니다. 안정성을 확인한 뒤 점진적으로 확대합니다.

yaml

# v1: 9개 replicas
# v2: 1개 replicas (약 10% 트래픽)

Blue/Green 배포

두 환경(Blue/Green)을 동시에 운영하고 트래픽을 한 번에 전환합니다.

bash

# Blue 환경 운영 중
# Green 환경에 새 버전 배포 & 테스트
# Service selector를 Green으로 변경

StatefulSet

상태를 가지는 애플리케이션(DB, 캐시 등) 배포용

Pod에 고유한 ID 부여
순서 보장 (생성/삭제)
고유한 PVC 연결

volumeClaimTemplates는 replica마다 별도 PVC를 생성하는 템플릿으로, 각 Pod가 자신의 영속 스토리지를 갖게 합니다.

yaml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: postgres
  replicas: 3
  selector:
    matchLabels:
      app: postgres
  template:
    # ...
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi

보안 및 접근 제어

RBAC (Role-Based Access Control)

RBAC는 어떤 사용자나 서비스 계정이 어떤 리소스에 어떤 동작을 할 수 있는지 권한을 제어합니다.

yaml

# Role - 네임스페이스 내 권한
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
 
---
# RoleBinding - 사용자에 Role 연결
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: dev
subjects:
- kind: User
  name: developer
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRole vs Role

종류	범위
Role	특정 네임스페이스 내
ClusterRole	클러스터 전체

Security Context

Pod/컨테이너 수준 보안 설정

yaml

spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
  containers:
  - name: app
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true

정리

주제	핵심
네트워킹	Service, Ingress, NetworkPolicy
스토리지	PV/PVC, ConfigMap, Secret
배포	Rolling, Canary, Blue/Green, StatefulSet
보안	RBAC, Security Context