CKA 핸즈온 랩

발행: 1주 전 (2026년 1월 10일 오전 08:40 GMT+9)

10 min read

I’m ready to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (excluding the source line you already provided) here? Once I have it, I’ll keep the source link unchanged and translate the rest into Korean while preserving all formatting, markdown, and technical terms.

주제 범위

Startup / Readiness / Liveness Probes
ConfigMaps
Secrets
Configuration mistakes & fixes

환경

Minikube
kubectl
로컬 머신 (macOS / Linux / Windows)

minikube start
kubectl get nodes

예상: STATUS: Ready

Lab 1 – Startup Probe (무한 재시작 해결)

1️⃣ 손상된 매니페스트 (`lab1-broken.yaml`)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: slow-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: slow
  template:
    metadata:
      labels:
        app: slow
    spec:
      containers:
        - name: app
          image: busybox
          command: ["sh", "-c"]
          args:
            - sleep 30; echo STARTED; sleep 3600
          livenessProbe:
            exec:
              command: ["sh", "-c", "echo ok"]
            initialDelaySeconds: 5
            periodSeconds: 5

# 손상된 매니페스트 적용
kubectl apply -f lab1-broken.yaml

# 파드 상태 확인
kubectl get pods

결과 – 파드가 CrashLoopBackOff 상태가 됩니다. 이는 liveness probe가 애플리케이션의 시작 시퀀스가 끝나기 전에 실행되기 때문입니다.

# 파드가 실패하는 이유 확인
kubectl describe pod <pod-name>

2️⃣ 수정된 매니페스트 (`lab1-fixed.yaml`)

startupProbe를 추가하여 컨테이너가 준비될 때까지 liveness probe를 차단합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: slow-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: slow
  template:
    metadata:
      labels:
        app: slow
    spec:
      containers:
        - name: app
          image: busybox
          command: ["sh", "-c"]
          args:
            - sleep 30; echo STARTED; sleep 3600
          startupProbe:
            exec:
              command: ["sh", "-c", "echo ok"]
            failureThreshold: 40   # 40 × 1 s = 40 s 전체 대기 시간
            periodSeconds: 1
          livenessProbe:
            exec:
              command: ["sh", "-c", "echo ok"]
            initialDelaySeconds: 5
            periodSeconds: 5

# 수정된 매니페스트 적용
kubectl apply -f lab1-fixed.yaml

# 파드가 정상적으로 시작되는지 확인
kubectl get pods

결과 – 파드가 재시작 없이 성공적으로 시작됩니다. startup probe가 컨테이너가 준비되었다는 신호를 보낼 때까지 liveness probe를 보류합니다.

📚 왜 중요한가

느리게 시작되는 애플리케이션(예: Java 서비스, 데이터베이스, 마이그레이션)은 헬스 체크에 응답하기 전에 더 많은 시간이 필요합니다.
startup probe가 없으면 조기 liveness probe가 불필요한 재시작을 유발하고 파드를 크래시 루프에 빠뜨릴 수 있습니다.
올바르게 구성된 startup probe는 비정상적인 파드에 트래픽이 전달되는 것을 방지하면서 반복적인 재시작을 피하게 해 줍니다.

Lab 2 – Readiness Probe (트래픽 제어)

1. 손상된 매니페스트

Deployment (`lab2-broken.yaml`)

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

Service (`service.yaml`)

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

매니페스트 적용

kubectl apply -f lab2-broken.yaml
kubectl apply -f service.yaml

관찰 내용

파드가 즉시 트래픽을 받으며, 애플리케이션이 비정상 상태여도 마찬가지입니다.
파드가 나쁜 상태에 있을 때 트래픽을 차단하는 메커니즘이 없습니다.

kubectl get endpoints ready-svc

2. Readiness Probe 추가

다음과 같이 readiness probe를 배포에 추가합니다:

readinessProbe:
  tcpSocket:
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 3

팁: lab2-broken.yaml의 컨테이너 정의 아래에 readinessProbe 블록을 삽입한 뒤 파일을 다시 적용합니다.

업데이트된 배포 적용

kubectl apply -f lab2-broken.yaml   # 이제 readinessProbe가 포함됨

변경 사항 확인

kubectl get pods
kubectl get endpoints ready-svc

결과

readiness probe가 실패하면 파드는 Running 상태를 유지하지만 Service의 엔드포인트 목록에서 제거됩니다.
따라서 트래픽이 비정상 파드로 자동 라우팅되는 일이 중단됩니다.

3. Readiness Probe가 중요한 이유

장점	설명
무중단 배포	새 파드가 readiness 검사를 통과한 후에만 서비스에 추가되므로, 사용자가 깨진 인스턴스를 호출하는 일이 방지됩니다.
자체 복구	준비 상태가 되지 않는 파드를 Kubernetes가 재시작하거나 교체하여 전체 신뢰성을 높입니다.
트래픽 제어	Service는 준비된 파드에만 트래픽을 라우팅하므로 오류율이 감소합니다.

다음 단계: 다양한 probe 유형(httpGet, exec)을 실험하고 initialDelaySeconds, periodSeconds, failureThreshold 값을 애플리케이션 시작 특성에 맞게 조정해 보세요.

Lab 3 – Liveness Probe (Self‑healing)

1. Broken manifest (`lab3-broken.yaml`)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hang-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hang
  template:
    metadata:
      labels:
        app: hang
    spec:
      containers:
        - name: app
          image: nginx

Apply the manifest:

kubectl apply -f lab3-broken.yaml

Simulate a hung container

# Get the pod name (assumes the label `app=hang` is unique)
POD=$(kubectl get pods -l app=hang -o jsonpath='{.items[0].metadata.name}')

# Stop PID 1 inside the container to simulate a hang
kubectl exec -it "$POD" -- kill -STOP 1

# Verify the pod status
kubectl get pods

Result: The pod stays Running even though the application inside is dead.

2. Adding a liveness probe (`lab3-fixed.yaml`)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hang-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hang
  template:
    metadata:
      labels:
        app: hang
    spec:
      containers:
        - name: app
          image: nginx
          livenessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 10
            periodSeconds: 5

Apply the updated deployment:

kubectl apply -f lab3-fixed.yaml
kubectl get pods

Result: When the probe fails, Kubernetes automatically restarts the pod. Liveness probes provide self‑healing; without them Kubernetes does nothing.

ConfigMap 동작

1. ConfigMap 생성

kubectl create configmap app-config --from-literal=APP_COLOR=blue

2. ConfigMap을 환경 변수로 사용

env:
  - name: APP_COLOR
    valueFrom:
      configMapKeyRef:
        name: app-config
        key: APP_COLOR

Pod를 배포한 뒤 ConfigMap을 수정합니다:

kubectl edit configmap app-config   # APP_COLOR 값 변경

Observation: 실행 중인 Pod는 새로운 값을 자동으로 반영하지 않습니다.

kubectl rollout restart deployment <deployment-name>

Key point: 실행 중인 컨테이너의 환경 변수는 변경할 수 없으므로, 재시작이 필요합니다.

3. ConfigMap을 파일로 마운트

volumes:
  - name: config
    configMap:
      name: app-config

volumeMounts:
  - name: config
    mountPath: /etc/config

ConfigMap을 수정하면 노드의 파일은 업데이트되지만, 애플리케이션이 파일을 수동으로 다시 로드해야 합니다—Kubernetes는 Pod를 자동으로 재시작하지 않습니다.

Secret Handling

비밀 생성

kubectl create secret generic db-secret \
  --from-literal=DB_PASS=secret123

비밀을 환경 변수로 사용하기

env:
  - name: DB_PASS
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: DB_PASS

비밀 확인하기

kubectl describe pod <pod-name>

관찰: 비밀은 Base64로 저장됩니다. kubectl describe를 실행하면 디코딩된 값이 일반 텍스트로 표시됩니다.

모범 사례

비밀은 민감한 데이터로 취급하고 절대 소스 코드에 커밋하지 마세요.
RBAC를 사용해 비밀에 대한 접근을 제한하세요.
가능하면 외부 비밀 관리 솔루션을 사용하는 것을 선호하세요.

RBAC (역할 기반 접근 제어)

Define Role 또는 ClusterRole 객체를 정의하여 워크로드가 실제로 필요한 권한만 부여합니다.
Bind 해당 역할을 RoleBinding 또는 ClusterRoleBinding을 사용해 사용자, 그룹, 서비스 계정에 바인딩합니다.
Never cluster-admin 권한으로 워크로드를 실행하지 마세요.

요약

시작 프로브: 컨테이너가 실제로 준비될 때까지 살아있는(liveness) 검사를 지연시켜, 시작이 느린 애플리케이션이 무한 재시작되는 것을 방지합니다.
준비 프로브: 파드가 트래픽을 받을지 여부를 제어하여 무중단 업데이트를 가능하게 합니다.
활성 프로브: 비정상적인 컨테이너를 재시작함으로써 자체 복구(self‑healing)를 제공합니다.
ConfigMap 변경 사항을 환경 변수에 반영하려면 파드를 재시작해야 합니다; 파일 마운트는 자동으로 업데이트되지만 애플리케이션이 데이터를 다시 로드해야 합니다.
Secrets는 base64‑인코딩되어 있으므로 주의해서 다루고 RBAC를 적용해 권한을 제한합니다.

문제 해결 팁

kubectl describe를 사용해 파드와 프로브 설정을 확인합니다.
kubectl logs를 사용해 컨테이너 출력을 확인합니다.
kubectl exec를 사용해 실행 중인 컨테이너 안에서 명령을 실행합니다.

CKA 핸즈온 랩

주제 범위

환경

Lab 1 – Startup Probe (무한 재시작 해결)

1️⃣ 손상된 매니페스트 (`lab1-broken.yaml`)

2️⃣ 수정된 매니페스트 (`lab1-fixed.yaml`)

📚 왜 중요한가

Lab 2 – Readiness Probe (트래픽 제어)

1. 손상된 매니페스트

Deployment (`lab2-broken.yaml`)

Service (`service.yaml`)

매니페스트 적용

관찰 내용

2. Readiness Probe 추가

업데이트된 배포 적용

변경 사항 확인

결과

3. Readiness Probe가 중요한 이유

Lab 3 – Liveness Probe (Self‑healing)

1. Broken manifest (`lab3-broken.yaml`)

Simulate a hung container

2. Adding a liveness probe (`lab3-fixed.yaml`)

ConfigMap 동작

1. ConfigMap 생성

2. ConfigMap을 환경 변수로 사용

3. ConfigMap을 파일로 마운트

Secret Handling

비밀 생성

비밀을 환경 변수로 사용하기

비밀 확인하기

RBAC (역할 기반 접근 제어)

요약

문제 해결 팁

관련 글

StatefulSet 프로젝트

Mageia, Mandrake Linux의 영광스러운 시절을 회상한다

2026년에 다시 DevOps를 배워야 한다면, 내가 따를 길은 이것이다

Kubernetes Services & Ingress. 프로젝트 #1

주제 범위

환경

Lab 1 – Startup Probe (무한 재시작 해결)

1️⃣ 손상된 매니페스트 (lab1-broken.yaml)

2️⃣ 수정된 매니페스트 (lab1-fixed.yaml)

📚 왜 중요한가

Lab 2 – Readiness Probe (트래픽 제어)

1. 손상된 매니페스트

Deployment (lab2-broken.yaml)

Service (service.yaml)

매니페스트 적용

관찰 내용

2. Readiness Probe 추가

업데이트된 배포 적용

변경 사항 확인

결과

3. Readiness Probe가 중요한 이유

Lab 3 – Liveness Probe (Self‑healing)

1. Broken manifest (lab3-broken.yaml)

Simulate a hung container

2. Adding a liveness probe (lab3-fixed.yaml)

ConfigMap 동작

1. ConfigMap 생성

2. ConfigMap을 환경 변수로 사용

3. ConfigMap을 파일로 마운트

Secret Handling

비밀 생성

비밀을 환경 변수로 사용하기

비밀 확인하기

RBAC (역할 기반 접근 제어)

요약

문제 해결 팁

관련 글

StatefulSet 프로젝트

Mageia, Mandrake Linux의 영광스러운 시절을 회상한다

2026년에 다시 DevOps를 배워야 한다면, 내가 따를 길은 이것이다

Kubernetes Services & Ingress. 프로젝트 #1

Lab 1 – Startup Probe (무한 재시작 해결)

1️⃣ 손상된 매니페스트 (`lab1-broken.yaml`)

2️⃣ 수정된 매니페스트 (`lab1-fixed.yaml`)

Lab 2 – Readiness Probe (트래픽 제어)

Deployment (`lab2-broken.yaml`)

Service (`service.yaml`)

Lab 3 – Liveness Probe (Self‑healing)

1. Broken manifest (`lab3-broken.yaml`)

2. Adding a liveness probe (`lab3-fixed.yaml`)