Kubernetes 서비스 및 네트워킹

Source: Dev.to

번역을 진행하려면 원본 텍스트(코드 블록, URL, 마크다운 형식 포함)를 제공해 주시겠어요?
제공해 주신 내용을 그대로 유지하면서 한국어로 번역해 드리겠습니다.

Architecture Overview (Mental Model)

Traffic flow

Browser
  ↓
Ingress
  ↓
Service
  ↓
Pod
  ↓
Container

이 자료의 모든 내용은 이 흐름을 중심으로 구성됩니다.

MODULE 1 — Kubernetes 서비스 및 네트워킹

서비스가 존재하는 이유

Pods

• 동적 IP를 가짐
• 언제든지 재생성될 수 있음
• 직접 접근해서는 안 됨

서비스가 제공하는 것

• 안정적인 IP
• 로드 밸런싱
• Pod 탐색

서비스 유형

프로젝트 1 — 서비스 트래픽 흐름

단계 1 — 배포

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: app
        image: hashicorp/http-echo:0.2.3
        args:
          - "-listen=:8080"
          - "-text=SERVICE WORKS"
        ports:
        - containerPort: 8080

Apply:

kubectl apply -f deployment.yaml

단계 2 — ClusterIP 서비스

apiVersion: v1
kind: Service
metadata:
  name: web-svc
spec:
  selector:
    app: web
  ports:
  - port: 80
    targetPort: 8080

Apply:

kubectl apply -f service.yaml

Verify:

kubectl get svc
kubectl get endpoints web-svc

단계 3 — 클러스터 내부 접근

kubectl run tmp --rm -it --image=busybox -- sh
wget -qO- http://web-svc

핵심 개념 학습

• 서비스는 라벨을 사용해 Pods를 선택합니다.
• 엔드포인트는 실제 트래픽 대상들을 보여줍니다.
• 서비스 실패는 보통 셀렉터 불일치를 의미합니다.

MODULE 2 — 인그레스 (실제 프로덕션 진입)

인그레스는 다음을 제공합니다

• 단일 진입점
• 경로 기반 라우팅
• 호스트 기반 라우팅
• SSL 종료

프로젝트 2 — 인그레스 라우팅

단계 1 — 두 버전 배포

안정 버전 배포

apiVersion: apps/v1
kind: Deployment
metadata:
  name: stable
spec:
  replicas: 2
  selector:
    matchLabels:
      app: echo
      version: stable
  template:
    metadata:
      labels:
        app: echo
        version: stable
    spec:
      containers:
      - name: app
        image: hashicorp/http-echo:0.2.3
        args:
          - "-listen=:8080"
          - "-text=STABLE VERSION"
        ports:
        - containerPort: 8080

카나리 배포

apiVersion: apps/v1
kind: Deployment
metadata:
  name: canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: echo
      version: canary
  template:
    metadata:
      labels:
        app: echo
        version: canary
    spec:
      containers:
      - name: app
        image: hashicorp/http-echo:0.2.3
        args:
          - "-listen=:8080"
          - "-text=CANARY VERSION"
        ports:
        - containerPort: 8080

단계 2 — 서비스

안정 서비스

apiVersion: v1
kind: Service
metadata:
  name: stable-svc
spec:
  selector:
    app: echo
    version: stable
  ports:
  - port: 80
    targetPort: 8080

카나리 서비스

apiVersion: v1
kind: Service
metadata:
  name: canary-svc
spec:
  selector:
    app: echo
    version: canary
  ports:
  - port: 80
    targetPort: 8080

단계 3 — 인그레스

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: stable-svc
            port:
              number: 80
      - path: /canary
        pathType: Prefix
        backend:
          service:
            name: canary-svc
            port:
              number: 80

테스트

curl http:///
curl http:///canary

모듈 3 — ConfigMaps 및 Secrets

왜 구성을 외부에 두어야 하는가

이미지는:

• 불변이어야 함
• 모든 환경에서 동작해야 함

구성은:

• 이미지를 재빌드하지 않고 변경 가능해야 함
• 환경별로 달라야 함

프로젝트 3 — ConfigMap 주입

1단계 — ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  MESSAGE: "CONFIGMAP VALUE"

2단계 — ConfigMap을 사용한 Deployment

containers:
- name: app
  image: hashicorp/http-echo:0.2.3
  args:
    - "-listen=:8080"
    - "-text=$(MESSAGE)"
  env:
  - name: MESSAGE
    valueFrom:
      configMapKeyRef:
        name: app-config
        key: MESSAGE

실시간 구성 업데이트

kubectl edit configmap app-config
kubectl rollout restart deployment web

Source:

MODULE 4 — Resource Management

Requests vs Limits

Project 4 — OOM‑Kill Demo

resources:
  requests:
    memory: "32Mi"
    cpu: "50m"
  limits:
    memory: "64Mi"
    cpu: "100m"

Observe:

kubectl describe pod

모듈 5 — 자동 스케일링 (HPA)

프로젝트 5 — CPU 기반 스케일링

단계 1 — 메트릭 활성화

kubectl get apiservices | grep metrics

단계 2 — HPA

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2
  maxReplicas: 5
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

부하 생성

while true; do wget -qO- http://web-svc; done

관찰:

kubectl get hpa
kubectl get pods

MODULE 6 — 로그 및 문제 해결

디버그 순서

1. Pod 상태
2. 이벤트
3. 로그
4. 리소스 사용량
5. 서비스 엔드포인트

일반 명령

kubectl get pods
kubectl describe pod 
kubectl logs 
kubectl get events --sort-by=.metadata.creationTimestamp

사고 시뮬레이션

• Pod이 Running 상태
• 브라우저에 아무 것도 표시되지 않음
• 엔드포인트 목록이 비어 있음
• 수정: 선택자를 올바르게 지정

MODULE 7 — 보안 기본

최소 securityContext

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false

이미지 모범 사례

• 절대 latest를 사용하지 마세요
• 고정 버전을 사용하세요
• 신뢰할 수 있는 레지스트리를 사용하세요

최종 통합 프로젝트

프로덕션 애플리케이션 포함 내용:

• readiness probe가 포함된 Deployment
• ClusterIP 서비스
• Ingress 라우팅
• ConfigMap
• 리소스 제한
• HPA
• 로그 및 이벤트
• 보안 컨테이너 설정

이는 실제 기업에서 Kubernetes가 사용되는 방식을 반영합니다.