KoreaDevKNOWLEDGE SHARING

콘텐츠 유형학습하기

AI INFRASTRUCTURE · 07 / 12

Kubernetes와 K3s

container workload를 declarative state로 배포하고 단일·다중 node cluster의 network·storage·failure를 진단합니다.

난이도
중급
구성
핵심 단원 4개 · 판단 활동 · 3단계 평가

NEW HIRE ONBOARDING

첫 업무를 받는 순서로 시작합니다

중학교를 졸업하고 처음 IT 업무를 맡은 신입사원도 따라올 수 있도록, 어려운 정의보다 상황·할 일·증거·보고할 경계를 먼저 확인합니다.

  1. 01

    상황을 한 문장으로 읽기

    API object, controller, scheduler, kubelet, CNI·Service·Ingress, CSI와 datastore를 계층별 condition과 event로 연결합니다.

  2. 02

    오늘 맡은 일

    Storage와 cluster 운영의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

  3. 03

    완료를 보여 주는 증거

    공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

  4. 04

    멈추고 선임에게 확인할 경계

    Deployment는 Available이지만 외부 요청이 503입니다. 첫 진단 순서는?

낯선 용어 먼저 풀기

Reconciliation(상태 수렴)
controller가 원하는 상태와 관찰한 상태의 차이를 계속 줄이는 동작입니다.

이 과정의 운영 질문

desired state가 실제 사용자 요청까지 수렴했는지 어떻게 증명할까?

API object, controller, scheduler, kubelet, CNI·Service·Ingress, CSI와 datastore를 계층별 condition과 event로 연결합니다.

CORE UNIT 1 / 4

Kubernetes object와 control loop

desired state와 실제 state가 수렴하는 과정을 설명합니다.

난이도
중급
구성
강의 5개 · 실습 2개 · 평가

도해·표 자료: 각 강의의 공식 1차 출처를 바탕으로 저자 구성. 원문과 검토일은 해당 강의 끝에서 확인합니다.

PREREQUISITE CHECK

본문을 읽기 전에 확인할 세 가지

정답을 외우는 시험이 아닙니다. 질문을 먼저 생각한 뒤 해설을 열어 이번 과목에서 사용할 바탕 개념을 확인하십시오.

1이 단원에서 실제 장비에 명령을 전송합니까?

아닙니다. 교육용 출력을 브라우저에서 읽고 판단합니다. 별도 재현은 승인된 격리 환경에서만 수행합니다.

2실습 전에 확인할 권한과 환경은 무엇입니까?

전용 lab cluster-admin·production credential 금지. 격리 cluster CIDR·service CIDR·문서용 ingress 주소.

3처음 보는 값과 아직 실행하지 않은 시험은 어떻게 적습니까?

미확인으로 기록합니다. 교육용 예상 출력과 실제 측정값을 구분하고, 승인 없는 작업으로 빈칸을 채우지 않습니다.

TEXTBOOK GUIDE

개념의 배경부터 판단 기준까지 읽는 본문

IT를 처음 접하는 독자도 용어를 암기하지 않고 원인과 결과를 연결할 수 있도록 한 절씩 이어서 설명합니다.

  1. Kubernetes object와 control loop의 구성요소와 실패 경계를 구성도로 설명할 수 있다.
  2. Kubernetes object와 control loop의 상태를 명령 출력과 관측값으로 판정할 수 있다.
  3. Kubernetes object와 control loop의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.
Kubernetes object와 control loop 실습 환경과 안전 경계
하드웨어3-node VM fixture·load balancer 없음
소프트웨어Ubuntu 24.04·K3s v1.31.x fixture·kubectl
필요 권한전용 lab cluster-admin·production credential 금지
네트워크격리 cluster CIDR·service CIDR·문서용 ingress 주소

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

적용 버전: Kubernetes 1.31 API fixture · K3s v1.31.x+k3s1 fixture · 원고 검토일: 2026-09-01

CONCEPT FLOW

각 장은 이렇게 연결됩니다

각 장은 따로 외우는 단답이 아닙니다. 왼쪽에서 오른쪽으로 따라가며 앞 장의 개념이 다음 판단에 어떻게 쓰이는지 먼저 살펴보세요.

  1. 1장API spec에서 확인을 시작합니다
  2. 2장controller의 실습 대상을 고정합니다
  3. 3장scheduler의 출력과 의미를 구분합니다
  4. 4장kubelet의 진행과 중단을 결정합니다
  5. 5장Kubernetes object와 control loop의 복구를 재검증합니다
Kubernetes object와 control loop의 전체 지도입니다. 아래 장문 해설과 각 장을 읽다가 길을 잃으면 이 순서로 돌아오세요.

CONTROLLED EXPLANATION

확인할 증거를 한 단계씩 따라갑니다

현재 설명 · 1/5 · API spec에서 확인을 시작합니다

다음 연결: controller의 실습 대상을 고정합니다

  1. API spec에서 확인을 시작합니다

    원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

  2. controller의 실습 대상을 고정합니다

    실습 상황:: replica 3을 요청했지만 2개만 Ready인 fixture에서 어느 control loop가 막혔는지 판정합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, observedGeneration 지연·condition 실패 조건이 보이면 다음 변경으로 넘어가지 마십시오.

  3. scheduler의 출력과 의미를 구분합니다

    값 자체를 외우는 것이 아니라 controller는 최신 spec을 관찰했고 scheduler가 자원 부족 경계에서 멈췄는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

  4. kubelet의 진행과 중단을 결정합니다

    object ownership과 condition/event를 이용해 실패 controller와 다음 owner를 정확히 적으면 성공입니다. 결과에는 실행 시각, 대상 identity, 사용한 명령, 핵심 출력, 판정과 다음 행동을 함께 남깁니다.

  5. Kubernetes object와 control loop의 복구를 재검증합니다

    실패 reason을 보존한 뒤 quota·request·node capacity 중 한 경계를 수정합니다. spec generation 증가와 observedGeneration·Ready 수렴을 다시 확인합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

개념 해설 01

API object에서 Pod condition까지 reconciliation을 추적합니다

Reconciliation(상태 수렴): controller가 원하는 상태와 관찰한 상태의 차이를 계속 줄이는 동작입니다.

Kubernetes는 명령을 node에 직접 전달하는 도구가 아니라 API object에 desired state를 기록하고 여러 controller가 actual state를 수렴시키는 system입니다. spec, status, condition, event는 서로 다른 증거입니다.

Deployment controller가 ReplicaSet을 만들고 scheduler가 미배치 Pod에 node를 선택하며 kubelet이 container runtime과 실제 Pod를 맞춥니다. 한 controller의 success는 다음 경계의 success를 보장하지 않습니다.

kubectl get의 짧은 열만 보고 정상으로 단정하지 않습니다. generation·observedGeneration·condition reason·event와 owner reference로 control loop가 어디까지 진행됐는지 읽습니다.

교육 사례에서 replicas를 3으로 제출했고 API 저장은 성공했지만 Ready Pod는 2개입니다. API의 성공 응답은 요청을 받아들였다는 뜻이지 원하는 workload가 전부 사용 가능하다는 뜻이 아닙니다. pending Pod의 scheduling event와 기존 replica readiness를 읽어 차이가 생긴 층을 찾습니다. controller가 다시 만드는 Pod를 수동 삭제하는 것만으로는 desired state가 바뀌지 않습니다.

제출한 spec과 관찰한 status의 차이를 줄이는 reconciliation 고리와, API server·Deployment controller·scheduler·kubelet 네 경계 가운데 어디서 fixture가 멈췄는지 판정을 함께 보여 주는 도표
그림 읽는 법 왼쪽 파란 상자의 고리를 위에서 아래로 읽습니다. 제출한 spec(spec.replicas 3 · metadata.generation 7)에서 controller가 관찰한 status.observedGeneration 7을 거쳐 지금의 actual state(ready 2 · Pending Pod 1개)로 내려오고, 되돌아오는 화살표는 차이가 0이 될 때까지 고리가 멈추지 않는다는 뜻입니다. 오른쪽 초록 상자는 spec · generation과 observedGeneration · condition의 reason · event 네 증거가 각각 무엇을 말하는지 구분합니다. 아래 네 상자는 ownerReference를 따라 Deployment → ReplicaSet → Pod로 내려가는 경계 순서이며, 각 상자는 담당하는 것 · 확인 명령과 보이는 값 · 판정 세 칸으로 되어 있습니다. 판정 줄만 이어 읽으면 1·2는 통과, 3(scheduler)은 Insufficient nvidia.com/gpu로 멈춤, 4(kubelet)는 미도달임을 알 수 있으며, 세 번째 상자의 채움색은 강조일 뿐 색을 구별하지 않아도 같은 판정을 읽을 수 있습니다. 마지막 상자는 고칠 곳(desired state를 소유한 상위 object와 배포 source)과 고친 뒤 다시 확인할 값(generation 8 · observedGeneration 8 · Ready 3)을 적어 둔 것입니다. 도표의 이름 · 식별자 · 수치는 교육용 fixture이며 실제 장비에서 측정한 값이 아니고, 시간 비율이나 물리 배선을 그린 그림도 아닙니다. 자료: Kubernetes Controllers · Kubernetes Deployments를 바탕으로 저자 구성.
왜 이런가
Deployment controller가 ReplicaSet을 만들고 scheduler가 미배치 Pod에 node를 선택하며 kubelet이 container runtime과 실제 Pod를 맞춥니다. 한 controller의 success는 다음 경계의 success를 보장하지 않습니다.
언제 문제가 되는가
observedGeneration 지연·condition 실패 조건이면 진행 근거가 부족합니다.
초보자가 자주 하는 오해
생성된 ReplicaSet이나 Pod를 직접 수정하면 controller가 다시 덮어쓸 수 있습니다. desired state를 소유한 상위 object와 배포 source를 고칩니다.
직접 확인하는 방법
metadata generation과 status observedGeneration을 비교합니다. ownerReferences로 Deployment→ReplicaSet→Pod 관계를 추적합니다.
이 절을 정리하면object ownership과 condition/event를 이용해 실패 controller와 다음 owner를 정확히 적으면 성공입니다.

CHAPTER 1 / 5

API spec에서 확인을 시작합니다

원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

1. metadata generation과 status observedGeneration을 비교합니다. 2. ownerReferences로 Deployment→ReplicaSet→Pod 관계를 추적합니다. 3. PodScheduled·Initialized·Ready condition의 reason을 읽습니다. 4. event를 timestamp와 source별로 정렬해 반복 실패를 찾습니다.

CHAPTER 2 / 5

controller의 실습 대상을 고정합니다

격리 환경 재현용 명령 · 브라우저에서는 실행하지 않습니다
kubectl get deploy model-api -n inference -o jsonpath='{.metadata.generation}{" "}{.status.observedGeneration}{"\n"}'
kubectl get rs,pod -n inference -l app=model-api -o wide
kubectl get events -n inference --sort-by=.metadata.creationTimestamp

CHAPTER 3 / 5

scheduler의 출력과 의미를 구분합니다

교육용 예상 출력 · 실제 측정값 아님
7 7
replicaset.apps/model-api-r7  3  3  2
pod/model-api-r7-xyz  0/1  Pending ...
Warning FailedScheduling ... Insufficient nvidia.com/gpu

CHAPTER 4 / 5

kubelet의 진행과 중단을 결정합니다

CHAPTER 5 / 5

Kubernetes object와 control loop의 복구를 재검증합니다

CONCRETE CASES

replica 3을 요청했지만 2개만 Ready인 fixture에서 어느 control loop가 막혔는지 판정합니다.

kubectl get의 짧은 열만 보고 정상으로 단정하지 않습니다. generation·observedGeneration·condition reason·event와 owner reference로 control loop가 어디까지 진행됐는지 읽습니다.

잘못된 대응과 확인할 경계

생성된 ReplicaSet이나 Pod를 직접 수정하면 controller가 다시 덮어쓸 수 있습니다. desired state를 소유한 상위 object와 배포 source를 고칩니다.

실패 reason을 보존한 뒤 quota·request·node capacity 중 한 경계를 수정합니다. spec generation 증가와 observedGeneration·Ready 수렴을 다시 확인합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

INTERACTIVE LAB 1 / 2

실습 1 · 출력에서 판정 근거 찾기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

실습 상황:: replica 3을 요청했지만 2개만 Ready인 fixture에서 어느 control loop가 막혔는지 판정합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, observedGeneration 지연·condition 실패 조건이 보이면 다음 변경으로 넘어가지 마십시오.

7 7
replicaset.apps/model-api-r7  3  3  2
pod/model-api-r7-xyz  0/1  Pending ...
Warning FailedScheduling ... Insufficient nvidia.com/gpu

값 자체를 외우는 것이 아니라 controller는 최신 spec을 관찰했고 scheduler가 자원 부족 경계에서 멈췄는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

INTERACTIVE LAB 2 / 2

실습 2 · 중단과 복구 계획 세우기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

생성된 ReplicaSet이나 Pod를 직접 수정하면 controller가 다시 덮어쓸 수 있습니다. desired state를 소유한 상위 object와 배포 source를 고칩니다.

KEY TERMS

이번 단원 핵심 용어

Reconciliation(상태 수렴)
controller가 원하는 상태와 관찰한 상태의 차이를 계속 줄이는 동작입니다.

UNIT WORKBOOK

개념을 새로운 상황에 적용하는 문제와 기록지

기본 원리 확인에서 시작해 실제 업무 판단으로 확장합니다. 답을 제출하면 정답만이 아니라 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

Kubernetes object와 control loop의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

PERSONAL WORKSHEET

내 환경에 옮겨 적는 학습 기록지

입력 내용은 현재 브라우저 화면에만 머물며 저장하거나 외부로 전송하지 않습니다. 민감한 실제 정보 대신 범주와 가명을 사용하십시오.

OFFICIAL SOURCES

공식 자료에서 다시 확인하기

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

CORE UNIT 2 / 4

K3s와 cluster 구축

단일·다중 node topology와 bootstrap 증거를 만듭니다.

난이도
중급
구성
강의 5개 · 실습 2개 · 평가

도해·표 자료: 각 강의의 공식 1차 출처를 바탕으로 저자 구성. 원문과 검토일은 해당 강의 끝에서 확인합니다.

PREREQUISITE CHECK

본문을 읽기 전에 확인할 세 가지

정답을 외우는 시험이 아닙니다. 질문을 먼저 생각한 뒤 해설을 열어 이번 과목에서 사용할 바탕 개념을 확인하십시오.

1이 단원에서 실제 장비에 명령을 전송합니까?

아닙니다. 교육용 출력을 브라우저에서 읽고 판단합니다. 별도 재현은 승인된 격리 환경에서만 수행합니다.

2실습 전에 확인할 권한과 환경은 무엇입니까?

전용 lab cluster-admin·production credential 금지. 격리 cluster CIDR·service CIDR·문서용 ingress 주소.

3앞 단원 「Kubernetes object와 control loop」에서 어떤 증거를 남겼습니까?

object ownership과 condition/event를 이용해 실패 controller와 다음 owner를 정확히 적으면 성공입니다.

TEXTBOOK GUIDE

개념의 배경부터 판단 기준까지 읽는 본문

IT를 처음 접하는 독자도 용어를 암기하지 않고 원인과 결과를 연결할 수 있도록 한 절씩 이어서 설명합니다.

  1. K3s와 cluster 구축의 구성요소와 실패 경계를 구성도로 설명할 수 있다.
  2. K3s와 cluster 구축의 상태를 명령 출력과 관측값으로 판정할 수 있다.
  3. K3s와 cluster 구축의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.
K3s와 cluster 구축 실습 환경과 안전 경계
하드웨어3-node VM fixture·load balancer 없음
소프트웨어Ubuntu 24.04·K3s v1.31.x fixture·kubectl
필요 권한전용 lab cluster-admin·production credential 금지
네트워크격리 cluster CIDR·service CIDR·문서용 ingress 주소

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

적용 버전: Kubernetes 1.31 API fixture · K3s v1.31.x+k3s1 fixture · 원고 검토일: 2026-09-01

CONCEPT FLOW

각 장은 이렇게 연결됩니다

각 장은 따로 외우는 단답이 아닙니다. 왼쪽에서 오른쪽으로 따라가며 앞 장의 개념이 다음 판단에 어떻게 쓰이는지 먼저 살펴보세요.

  1. 1장사전 조건에서 확인을 시작합니다
  2. 2장첫 server의 실습 대상을 고정합니다
  3. 3장node join의 출력과 의미를 구분합니다
  4. 4장bootstrap 증거의 진행과 중단을 결정합니다
  5. 5장K3s와 cluster 구축의 복구를 재검증합니다
K3s와 cluster 구축의 전체 지도입니다. 아래 장문 해설과 각 장을 읽다가 길을 잃으면 이 순서로 돌아오세요.

CONTROLLED EXPLANATION

확인할 증거를 한 단계씩 따라갑니다

현재 설명 · 1/5 · 사전 조건에서 확인을 시작합니다

다음 연결: 첫 server의 실습 대상을 고정합니다

  1. 사전 조건에서 확인을 시작합니다

    원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

  2. 첫 server의 실습 대상을 고정합니다

    실습 상황:: 3-node fixture의 bootstrap 계획에서 중복 hostname과 한 rack에 몰린 server quorum 문제를 찾습니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, hostname 충돌·time drift·token 노출 조건이 보이면 다음 변경으로 넘어가지 마십시오.

  3. node join의 출력과 의미를 구분합니다

    값 자체를 외우는 것이 아니라 identity·time·API port·node condition·datastore snapshot이 설계와 일치하는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

  4. bootstrap 증거의 진행과 중단을 결정합니다

    node별 사전 점검표, role/failure-domain 지도, secret 처리와 첫 snapshot restore 확인 계획을 제출하면 성공입니다. 결과에는 실행 시각, 대상 identity, 사용한 명령, 핵심 출력, 판정과 다음 행동을 함께 남깁니다.

  5. K3s와 cluster 구축의 복구를 재검증합니다

    join 실패 시 token을 재발급하기 전에 hostname·route·time·certificate log를 보존합니다. datastore quorum 문제가 있으면 새 server를 임의 추가하지 말고 공식 restore 절차로 돌아갑니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

개념 해설 01

K3s bootstrap은 사전 조건과 datastore 증거로 승인합니다

Quorum(정족수): 분산 datastore가 일관된 결정을 하기 위해 필요한 과반 참여 조건입니다.

K3s는 Kubernetes component를 단순 배포한 binary 이상으로 datastore, server token, embedded networking과 packaged component의 lifecycle을 묶습니다. 첫 server와 추가 server/agent는 역할과 복구 책임이 다릅니다.

server node는 API와 control-plane/datastore 역할을, agent는 workload 실행 역할을 가집니다. token은 node join 자격 증명이며 노출되면 임의 node가 신뢰 경계에 들어올 수 있습니다.

설치 script를 바로 실행하기 전에 hostname·time·network·port·disk·cgroup과 topology를 사전 확인합니다. install command와 configuration file revision을 evidence로 남깁니다.

교육 사례에서 embedded etcd server 세 대 중 한 대가 내려가면 두 대가 남습니다. 두 대가 동시에 내려가면 과반을 잃으므로 같은 장애 허용 능력이 아닙니다. node 수와 함께 server 역할, datastore 방식과 배치를 기록해야 합니다. K3s의 모든 설치가 embedded etcd를 쓰는 것은 아니므로 SQLite나 외부 datastore 구성을 먼저 구분합니다.

identity·time, port·topology, token, Ready·snapshot 네 gate의 확인 명령과 통과 값, 그리고 datastore 구성별 quorum 비교 표
그림 읽는 법 gate 1에서 4까지 왼쪽에서 오른쪽으로 읽습니다. 각 gate 상자는 확인 명령, 통과로 볼 값, 다음으로 넘어가지 않는 중단 조건 순서로 적혀 있습니다. 네 gate를 모두 지나야 bootstrap을 승인하며, 설치 script가 끝났다는 사실만으로는 승인하지 않습니다. 아래 표는 같은 server 3대라도 embedded etcd인지 SQLite·외부 datastore인지에 따라 한 대 정지와 두 대 동시 정지의 결과가 다르다는 것을 비교합니다. 두 대가 동시에 내려가면 과반을 잃으므로 server 수만으로는 장애 허용 능력을 말할 수 없습니다. 표 아래 한 줄은 server 세 대를 한 rack에 몰면 rack 하나가 곧 failure domain 전체가 된다는 뜻입니다. 마지막 상자는 token 처리와 join 실패 시 보존할 log, 결과에 남길 항목입니다. 도표의 식별자·수치·상태는 저자 구성 교육용 예시이며 실제 장비에서 측정한 값이 아닙니다. 자료: K3s Architecture · K3s Backup and Restore · K3s Requirements를 바탕으로 저자 구성.
왜 이런가
server node는 API와 control-plane/datastore 역할을, agent는 workload 실행 역할을 가집니다. token은 node join 자격 증명이며 노출되면 임의 node가 신뢰 경계에 들어올 수 있습니다.
언제 문제가 되는가
hostname 충돌·time drift·token 노출 조건이면 진행 근거가 부족합니다.
초보자가 자주 하는 오해
K3S_TOKEN을 shell history, process argument, ticket 본문에 남기지 않습니다. secret 전달 수단과 rotation 절차를 사용합니다.
직접 확인하는 방법
모든 node의 hostname·IP·time sync·required port를 표로 맞춥니다. server topology와 datastore mode, quorum failure domain을 설계합니다.
이 절을 정리하면node별 사전 점검표, role/failure-domain 지도, secret 처리와 첫 snapshot restore 확인 계획을 제출하면 성공입니다.

CHAPTER 1 / 5

사전 조건에서 확인을 시작합니다

원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

1. 모든 node의 hostname·IP·time sync·required port를 표로 맞춥니다. 2. server topology와 datastore mode, quorum failure domain을 설계합니다. 3. token은 secret store와 제한된 전달 경로로 관리합니다. 4. node Ready, component health, datastore snapshot과 restore 절차를 확인합니다.

CHAPTER 2 / 5

첫 server의 실습 대상을 고정합니다

격리 환경 재현용 명령 · 브라우저에서는 실행하지 않습니다
hostnamectl --static
timedatectl show -p NTPSynchronized --value
ss -lnt | grep -E ':6443|:9345' || true
kubectl get nodes -o wide
sudo k3s etcd-snapshot ls

CHAPTER 3 / 5

node join의 출력과 의미를 구분합니다

교육용 예상 출력 · 실제 측정값 아님
gpu-node-01
yes
LISTEN ... :6443
node-01 Ready control-plane,etcd ...
<snapshot-name> 2026-08-31T...Z

CHAPTER 4 / 5

bootstrap 증거의 진행과 중단을 결정합니다

CHAPTER 5 / 5

K3s와 cluster 구축의 복구를 재검증합니다

CONCRETE CASES

3-node fixture의 bootstrap 계획에서 중복 hostname과 한 rack에 몰린 server quorum 문제를 찾습니다.

설치 script를 바로 실행하기 전에 hostname·time·network·port·disk·cgroup과 topology를 사전 확인합니다. install command와 configuration file revision을 evidence로 남깁니다.

잘못된 대응과 확인할 경계

K3S_TOKEN을 shell history, process argument, ticket 본문에 남기지 않습니다. secret 전달 수단과 rotation 절차를 사용합니다.

join 실패 시 token을 재발급하기 전에 hostname·route·time·certificate log를 보존합니다. datastore quorum 문제가 있으면 새 server를 임의 추가하지 말고 공식 restore 절차로 돌아갑니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

INTERACTIVE LAB 1 / 2

실습 1 · 출력에서 판정 근거 찾기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

실습 상황:: 3-node fixture의 bootstrap 계획에서 중복 hostname과 한 rack에 몰린 server quorum 문제를 찾습니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, hostname 충돌·time drift·token 노출 조건이 보이면 다음 변경으로 넘어가지 마십시오.

gpu-node-01
yes
LISTEN ... :6443
node-01 Ready control-plane,etcd ...
<snapshot-name> 2026-08-31T...Z

값 자체를 외우는 것이 아니라 identity·time·API port·node condition·datastore snapshot이 설계와 일치하는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

INTERACTIVE LAB 2 / 2

실습 2 · 중단과 복구 계획 세우기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

K3S_TOKEN을 shell history, process argument, ticket 본문에 남기지 않습니다. secret 전달 수단과 rotation 절차를 사용합니다.

KEY TERMS

이번 단원 핵심 용어

Quorum(정족수)
분산 datastore가 일관된 결정을 하기 위해 필요한 과반 참여 조건입니다.

UNIT WORKBOOK

개념을 새로운 상황에 적용하는 문제와 기록지

기본 원리 확인에서 시작해 실제 업무 판단으로 확장합니다. 답을 제출하면 정답만이 아니라 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

K3s와 cluster 구축의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

PERSONAL WORKSHEET

내 환경에 옮겨 적는 학습 기록지

입력 내용은 현재 브라우저 화면에만 머물며 저장하거나 외부로 전송하지 않습니다. 민감한 실제 정보 대신 범주와 가명을 사용하십시오.

OFFICIAL SOURCES

공식 자료에서 다시 확인하기

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

CORE UNIT 3 / 4

Workload·service·network

Pod·Deployment·Service·Ingress의 요청 경로를 검증합니다.

난이도
중급
구성
강의 5개 · 실습 2개 · 평가

도해·표 자료: 각 강의의 공식 1차 출처를 바탕으로 저자 구성. 원문과 검토일은 해당 강의 끝에서 확인합니다.

PREREQUISITE CHECK

본문을 읽기 전에 확인할 세 가지

정답을 외우는 시험이 아닙니다. 질문을 먼저 생각한 뒤 해설을 열어 이번 과목에서 사용할 바탕 개념을 확인하십시오.

1이 단원에서 실제 장비에 명령을 전송합니까?

아닙니다. 교육용 출력을 브라우저에서 읽고 판단합니다. 별도 재현은 승인된 격리 환경에서만 수행합니다.

2실습 전에 확인할 권한과 환경은 무엇입니까?

전용 lab cluster-admin·production credential 금지. 격리 cluster CIDR·service CIDR·문서용 ingress 주소.

3앞 단원 「K3s와 cluster 구축」에서 어떤 증거를 남겼습니까?

node별 사전 점검표, role/failure-domain 지도, secret 처리와 첫 snapshot restore 확인 계획을 제출하면 성공입니다.

TEXTBOOK GUIDE

개념의 배경부터 판단 기준까지 읽는 본문

IT를 처음 접하는 독자도 용어를 암기하지 않고 원인과 결과를 연결할 수 있도록 한 절씩 이어서 설명합니다.

  1. Workload·service·network의 구성요소와 실패 경계를 구성도로 설명할 수 있다.
  2. Workload·service·network의 상태를 명령 출력과 관측값으로 판정할 수 있다.
  3. Workload·service·network의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.
Workload·service·network 실습 환경과 안전 경계
하드웨어3-node VM fixture·load balancer 없음
소프트웨어Ubuntu 24.04·K3s v1.31.x fixture·kubectl
필요 권한전용 lab cluster-admin·production credential 금지
네트워크격리 cluster CIDR·service CIDR·문서용 ingress 주소

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

적용 버전: Kubernetes 1.31 API fixture · K3s v1.31.x+k3s1 fixture · 원고 검토일: 2026-09-01

CONCEPT FLOW

각 장은 이렇게 연결됩니다

각 장은 따로 외우는 단답이 아닙니다. 왼쪽에서 오른쪽으로 따라가며 앞 장의 개념이 다음 판단에 어떻게 쓰이는지 먼저 살펴보세요.

  1. 1장Pod process에서 확인을 시작합니다
  2. 2장EndpointSlice의 실습 대상을 고정합니다
  3. 3장Service의 출력과 의미를 구분합니다
  4. 4장Ingress의 진행과 중단을 결정합니다
  5. 5장Workload·service·network의 복구를 재검증합니다
Workload·service·network의 전체 지도입니다. 아래 장문 해설과 각 장을 읽다가 길을 잃으면 이 순서로 돌아오세요.

CONTROLLED EXPLANATION

확인할 증거를 한 단계씩 따라갑니다

현재 설명 · 1/5 · Pod process에서 확인을 시작합니다

다음 연결: EndpointSlice의 실습 대상을 고정합니다

  1. Pod process에서 확인을 시작합니다

    원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

  2. EndpointSlice의 실습 대상을 고정합니다

    실습 상황:: Deployment는 Available이지만 Service endpoint가 비어 있는 fixture에서 label selector 오타를 찾습니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, selector·port·readiness 불일치 조건이 보이면 다음 변경으로 넘어가지 마십시오.

  3. Service의 출력과 의미를 구분합니다

    값 자체를 외우는 것이 아니라 Pod 준비 상태와 Service selector가 같은 endpoint를 만들지 못한 정확한 이유를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

  4. Ingress의 진행과 중단을 결정합니다

    네 hop의 identity·port·condition을 표로 만들고 하나의 불일치를 수정한 뒤 외부 요청까지 재검증하면 성공입니다. 결과에는 실행 시각, 대상 identity, 사용한 명령, 핵심 출력, 판정과 다음 행동을 함께 남깁니다.

  5. Workload·service·network의 복구를 재검증합니다

    현재 manifest와 event를 보존한 뒤 Git source의 selector 또는 probe를 고칩니다. rollout status, EndpointSlice 등록, 내부와 외부 request를 같은 revision에서 확인합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

개념 해설 01

Pod readiness에서 외부 Ingress까지 요청 경로를 검증합니다

Readiness(요청 수신 준비 상태): workload가 새 요청을 받을 준비가 되었는지 알리는 신호입니다.

Pod IP, Service virtual IP, EndpointSlice, Ingress/Gateway와 external load balancer는 서로 다른 hop입니다. Pod Ready와 Service endpoint 등록이 어긋나면 process는 살아 있어도 사용자는 실패합니다.

readiness는 새 traffic을 받을 준비, liveness는 복구를 위한 restart 필요성, startup은 기동 완료 여부를 확인합니다. startup probe가 구성된 경우 성공할 때까지 readiness와 liveness probe 실행이 대기합니다. 같은 endpoint 사용 자체가 오류는 아니지만 각 신호의 판정 조건과 실패 동작이 실제 요구를 표현하는지 검증해야 합니다.

외부에서 안 된다는 보고를 받을 때 DNS부터 무작정 추적하지 않습니다. Pod localhost, Pod IP, Service/EndpointSlice, Ingress route, external path를 한 단계씩 시험합니다.

교육 사례에서 Pod는 Running이지만 readiness가 실패해 Service의 정상 endpoint에 포함되지 않았습니다. process가 실행 중이라는 사실만 보고 외부 DNS부터 바꾸면 실패 층을 놓칩니다. Pod의 준비 상태, Service selector와 EndpointSlice를 먼저 대조한 뒤 ingress로 올라갑니다. liveness를 readiness 대신 쓰면 일시적인 외부 의존성 지연에 불필요한 재시작을 만들 수 있습니다.

Pod condition·probe에서 EndpointSlice, Service selector·targetPort, Ingress까지 네 hop을 시험 명령·보이는 값·판정으로 잇고 readiness·liveness·startup 세 probe의 계약을 구분한 도표
그림 읽는 법 위쪽 네 상자를 왼쪽에서 오른쪽으로, 즉 안쪽 hop에서 바깥으로 읽습니다. 각 상자는 시험하는 명령 · 보이는 값 · 판정 세 칸으로 나뉩니다. 1번 Pod는 Ready=True · IP 10.42.1.20으로 통과이며 Readiness probe failed 경고는 따로 적어 둡니다. 2번 EndpointSlice의 endpoints: [] 가 겉으로 드러난 증상이고, 3번 Service의 selector app: model-ap1과 Pod label app=model-api 사이 한 글자 차이가 원인입니다. 4번 Ingress는 앞 hop을 고치기 전까지 판정을 보류하며, 고친 뒤 외부 요청으로 다시 확인합니다. 아래 세 상자는 readiness · liveness · startup의 뜻과 실패했을 때 무슨 일이 일어나는지를 구분하며, 같은 endpoint 사용 자체가 오류는 아니지만, 재시작 필요성·트래픽 수용 가능성·기동 완료 여부가 서로 다르면 각 probe의 판정 조건과 실패 동작을 분리해 검증해야 합니다. 채움색이 다른 상자는 증상과 원인이 있는 hop이라는 표시일 뿐이며 색을 구별하지 않아도 판정 문장으로 같은 내용을 읽을 수 있습니다. 마지막 상자는 고칠 위치가 cluster의 object가 아니라 Git source의 selector와 probe라는 것과, 고친 뒤 같은 revision에서 rollout status · EndpointSlice 등록 · 내부와 외부 request를 다시 확인한다는 것을 적어 둔 것입니다. 도표의 이름 · 식별자 · 수치는 교육용 fixture이며 실제 장비에서 측정한 값이 아닙니다. 자료: Kubernetes Liveness, Readiness and Startup Probes · Kubernetes Services, Load Balancing, and Networking를 바탕으로 저자 구성.
왜 이런가
일시적인 외부 의존성 장애로 traffic 수용을 멈춰야 해도 process 재시작이 도움이 되지 않을 수 있습니다. 준비 상태와 재시작 필요성을 구분해야 불필요한 restart를 피할 수 있습니다.
언제 문제가 되는가
selector·port·readiness 불일치 조건이면 진행 근거가 부족합니다.
초보자가 자주 하는 오해
liveness를 너무 공격적으로 설정하면 과부하 때 정상 process를 반복 재시작해 장애를 증폭합니다. startup과 readiness 의미를 먼저 설계합니다.
직접 확인하는 방법
Pod condition과 probe failure reason을 확인합니다. EndpointSlice의 address·port·ready condition을 봅니다.
이 절을 정리하면네 hop의 identity·port·condition을 표로 만들고 하나의 불일치를 수정한 뒤 외부 요청까지 재검증하면 성공입니다.

CHAPTER 1 / 5

Pod process에서 확인을 시작합니다

원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

1. Pod condition과 probe failure reason을 확인합니다. 2. EndpointSlice의 address·port·ready condition을 봅니다. 3. Service selector·targetPort와 실제 Pod label/listen port를 대조합니다. 4. Ingress host·path·backend·TLS secret과 controller log를 연결합니다.

CHAPTER 2 / 5

EndpointSlice의 실습 대상을 고정합니다

격리 환경 재현용 명령 · 브라우저에서는 실행하지 않습니다
kubectl get pod -n inference -l app=model-api -o wide
kubectl get endpointslice -n inference -l kubernetes.io/service-name=model-api -o yaml
kubectl get service,ingress -n inference model-api -o yaml
kubectl describe pod -n inference -l app=model-api

CHAPTER 3 / 5

Service의 출력과 의미를 구분합니다

교육용 예상 출력 · 실제 측정값 아님
Pod model-api-r7-abc Ready=True IP=10.42.1.20
endpoints: []
selector: app: model-ap1
Warning Unhealthy Readiness probe failed ...

CHAPTER 4 / 5

Ingress의 진행과 중단을 결정합니다

CHAPTER 5 / 5

Workload·service·network의 복구를 재검증합니다

CONCRETE CASES

Deployment는 Available이지만 Service endpoint가 비어 있는 fixture에서 label selector 오타를 찾습니다.

외부에서 안 된다는 보고를 받을 때 DNS부터 무작정 추적하지 않습니다. Pod localhost, Pod IP, Service/EndpointSlice, Ingress route, external path를 한 단계씩 시험합니다.

잘못된 대응과 확인할 경계

liveness를 너무 공격적으로 설정하면 과부하 때 정상 process를 반복 재시작해 장애를 증폭합니다. startup과 readiness 의미를 먼저 설계합니다.

현재 manifest와 event를 보존한 뒤 Git source의 selector 또는 probe를 고칩니다. rollout status, EndpointSlice 등록, 내부와 외부 request를 같은 revision에서 확인합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

INTERACTIVE LAB 1 / 2

실습 1 · 출력에서 판정 근거 찾기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

실습 상황:: Deployment는 Available이지만 Service endpoint가 비어 있는 fixture에서 label selector 오타를 찾습니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, selector·port·readiness 불일치 조건이 보이면 다음 변경으로 넘어가지 마십시오.

Pod model-api-r7-abc Ready=True IP=10.42.1.20
endpoints: []
selector: app: model-ap1
Warning Unhealthy Readiness probe failed ...

값 자체를 외우는 것이 아니라 Pod 준비 상태와 Service selector가 같은 endpoint를 만들지 못한 정확한 이유를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

INTERACTIVE LAB 2 / 2

실습 2 · 중단과 복구 계획 세우기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

liveness를 너무 공격적으로 설정하면 과부하 때 정상 process를 반복 재시작해 장애를 증폭합니다. startup과 readiness 의미를 먼저 설계합니다.

KEY TERMS

이번 단원 핵심 용어

Readiness(요청 수신 준비 상태)
workload가 새 요청을 받을 준비가 되었는지 알리는 신호입니다.

UNIT WORKBOOK

개념을 새로운 상황에 적용하는 문제와 기록지

기본 원리 확인에서 시작해 실제 업무 판단으로 확장합니다. 답을 제출하면 정답만이 아니라 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

Workload·service·network의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

PERSONAL WORKSHEET

내 환경에 옮겨 적는 학습 기록지

입력 내용은 현재 브라우저 화면에만 머물며 저장하거나 외부로 전송하지 않습니다. 민감한 실제 정보 대신 범주와 가명을 사용하십시오.

OFFICIAL SOURCES

공식 자료에서 다시 확인하기

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

CORE UNIT 4 / 4

Storage와 cluster 운영

PV·CSI·upgrade·backup·node 장애 경계를 연결합니다.

난이도
중급
구성
강의 5개 · 실습 2개 · 평가

도해·표 자료: 각 강의의 공식 1차 출처를 바탕으로 저자 구성. 원문과 검토일은 해당 강의 끝에서 확인합니다.

PREREQUISITE CHECK

본문을 읽기 전에 확인할 세 가지

정답을 외우는 시험이 아닙니다. 질문을 먼저 생각한 뒤 해설을 열어 이번 과목에서 사용할 바탕 개념을 확인하십시오.

1이 단원에서 실제 장비에 명령을 전송합니까?

아닙니다. 교육용 출력을 브라우저에서 읽고 판단합니다. 별도 재현은 승인된 격리 환경에서만 수행합니다.

2실습 전에 확인할 권한과 환경은 무엇입니까?

전용 lab cluster-admin·production credential 금지. 격리 cluster CIDR·service CIDR·문서용 ingress 주소.

3앞 단원 「Workload·service·network」에서 어떤 증거를 남겼습니까?

네 hop의 identity·port·condition을 표로 만들고 하나의 불일치를 수정한 뒤 외부 요청까지 재검증하면 성공입니다.

TEXTBOOK GUIDE

개념의 배경부터 판단 기준까지 읽는 본문

IT를 처음 접하는 독자도 용어를 암기하지 않고 원인과 결과를 연결할 수 있도록 한 절씩 이어서 설명합니다.

  1. Storage와 cluster 운영의 구성요소와 실패 경계를 구성도로 설명할 수 있다.
  2. Storage와 cluster 운영의 상태를 명령 출력과 관측값으로 판정할 수 있다.
  3. Storage와 cluster 운영의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.
Storage와 cluster 운영 실습 환경과 안전 경계
하드웨어3-node VM fixture·load balancer 없음
소프트웨어Ubuntu 24.04·K3s v1.31.x fixture·kubectl
필요 권한전용 lab cluster-admin·production credential 금지
네트워크격리 cluster CIDR·service CIDR·문서용 ingress 주소

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

적용 버전: Kubernetes 1.31 API fixture · K3s v1.31.x+k3s1 fixture · 원고 검토일: 2026-09-01

CONCEPT FLOW

각 장은 이렇게 연결됩니다

각 장은 따로 외우는 단답이 아닙니다. 왼쪽에서 오른쪽으로 따라가며 앞 장의 개념이 다음 판단에 어떻게 쓰이는지 먼저 살펴보세요.

  1. 1장PVC 계약에서 확인을 시작합니다
  2. 2장CSI 경로의 실습 대상을 고정합니다
  3. 3장node 운영의 출력과 의미를 구분합니다
  4. 4장복구 시험의 진행과 중단을 결정합니다
  5. 5장Storage와 cluster 운영의 복구를 재검증합니다
Storage와 cluster 운영의 전체 지도입니다. 아래 장문 해설과 각 장을 읽다가 길을 잃으면 이 순서로 돌아오세요.

CONTROLLED EXPLANATION

확인할 증거를 한 단계씩 따라갑니다

현재 설명 · 1/5 · PVC 계약에서 확인을 시작합니다

다음 연결: CSI 경로의 실습 대상을 고정합니다

  1. PVC 계약에서 확인을 시작합니다

    원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

  2. CSI 경로의 실습 대상을 고정합니다

    실습 상황:: Retain이 필요한 model artifact PVC가 Delete policy인 fixture와 upgrade drain 계획을 수정합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, reclaim·snapshot·PDB 미검증 조건이 보이면 다음 변경으로 넘어가지 마십시오.

  3. node 운영의 출력과 의미를 구분합니다

    값 자체를 외우는 것이 아니라 volume 수명·attach·disruption·datastore 복구 계약이 maintenance 계획과 맞는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

  4. 복구 시험의 진행과 중단을 결정합니다

    PVC→PV→CSI→node→backup 의존 지도를 만들고 canary upgrade와 restore acceptance를 명시하면 성공입니다. 결과에는 실행 시각, 대상 identity, 사용한 명령, 핵심 출력, 판정과 다음 행동을 함께 남깁니다.

  5. Storage와 cluster 운영의 복구를 재검증합니다

    mount 실패면 Pod를 반복 삭제하지 말고 VolumeAttachment·node plugin·backend volume identity를 보존합니다. upgrade 실패는 canary를 멈추고 지원되는 이전 revision으로 rollback한 뒤 snapshot과 volume을 검증합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

개념 해설 01

PVC에서 datastore와 volume 복구까지 lifecycle을 연결합니다

PVC(PersistentVolumeClaim, 영구 volume 요청): workload가 필요한 용량과 접근 조건을 선언하는 storage 요청입니다.

PersistentVolume(PV)과 PersistentVolumeClaim(PVC)은 storage 수명과 binding 계약을 나타내며, 실제 provision·attach·mount는 Container Storage Interface(CSI) driver와 node 조건에 달려 있습니다. PV reclaim policy는 Pod 삭제 자체가 아니라 PVC 해제 이후 volume 처리와 관련된 정책입니다. Retain·Delete 설정과 CSI driver의 동작을 확인하고 Pod 수명과 PVC·PV 수명을 구분합니다.

cluster upgrade는 API·datastore·CNI·CSI·kubelet과 workload version-skew를 다룹니다. datastore snapshot만 있어도 외부 volume data와 secret, registry artifact를 복원하지 못하면 service recovery는 완성되지 않습니다.

node drain 전 PodDisruptionBudget, local volume, daemon workload와 GPU job checkpoint를 확인합니다. 모든 node를 동시에 바꾸지 않고 canary와 중단 기준을 둡니다.

교육 사례에서 PVC는 Bound이지만 Pod가 다른 zone에 배치되어 volume을 연결하지 못했습니다. Bound는 요청과 volume 연결이 성립했다는 뜻이지 모든 node에서 mount할 수 있다는 뜻이 아닙니다. StorageClass의 binding 방식, volume topology와 Pod event를 함께 읽습니다. volume을 지우는 조치는 reclaim policy와 데이터 복구 경로를 확인한 뒤에만 검토합니다.

PVC에서 PV·binding, CSI, node를 지나 backup까지 이어지는 storage 의존 사슬과 snapshot의 복구 범위, drain·upgrade 판단 기준
그림 읽는 법 위 사슬을 1번 PVC에서 5번 backup까지 순서대로 읽습니다. 각 칸에는 확인 명령, 그 경계가 보장하는 것, 끊겼을 때 나타나는 증상이 함께 있습니다. PVC가 Bound라는 표시는 요청과 volume의 연결이 성립했다는 뜻일 뿐이어서, 3번 CSI 칸처럼 다른 zone의 node에서는 mount하지 못할 수 있습니다. 아래 두 상자는 datastore snapshot이 되돌리는 것과 snapshot만으로는 되돌아오지 않는 것을 나눕니다. 외부 volume의 data·secret·registry artifact를 함께 복원하지 못하면 service recovery는 완성되지 않습니다. 마지막 상자는 drain 전에 확인할 항목, mount와 upgrade가 실패했을 때의 조치, PVC 삭제 시험의 제한입니다. reclaim·snapshot·PDB가 검증되지 않았으면 다음 변경으로 넘어가지 않습니다. 도표의 식별자·수치·상태는 저자 구성 교육용 예시이며 실제 장비에서 측정한 값이 아닙니다. 자료: Kubernetes Persistent Volumes · K3s Backup and Restore · Kubernetes Safely Drain a Node를 바탕으로 저자 구성.
왜 이런가
cluster upgrade는 API·datastore·CNI·CSI·kubelet과 workload version-skew를 다룹니다. datastore snapshot만 있어도 외부 volume data와 secret, registry artifact를 복원하지 못하면 service recovery는 완성되지 않습니다.
언제 문제가 되는가
reclaim·snapshot·PDB 미검증 조건이면 진행 근거가 부족합니다.
초보자가 자주 하는 오해
PVC 삭제 시험은 실제 volume을 지울 수 있습니다. production과 분리된 lab class에서 reclaim behavior를 검증합니다.
직접 확인하는 방법
PVC access mode·storage class·binding mode·reclaim policy를 확인합니다. VolumeAttachment·CSI controller/node log로 attach/mount 경계를 읽습니다.
이 절을 정리하면PVC→PV→CSI→node→backup 의존 지도를 만들고 canary upgrade와 restore acceptance를 명시하면 성공입니다.

CHAPTER 1 / 5

PVC 계약에서 확인을 시작합니다

원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

1. PVC access mode·storage class·binding mode·reclaim policy를 확인합니다. 2. VolumeAttachment·CSI controller/node log로 attach/mount 경계를 읽습니다. 3. PDB·local data·checkpoint와 drain 영향을 계산합니다. 4. datastore와 application volume을 격리 환경에서 함께 restore합니다.

CHAPTER 2 / 5

CSI 경로의 실습 대상을 고정합니다

격리 환경 재현용 명령 · 브라우저에서는 실행하지 않습니다
kubectl get pvc,pv -A -o wide
kubectl get storageclass -o yaml
kubectl get volumeattachment
kubectl get pdb -A
sudo k3s etcd-snapshot ls

CHAPTER 3 / 5

node 운영의 출력과 의미를 구분합니다

교육용 예상 출력 · 실제 측정값 아님
inference/model-cache Bound pvc-... 500Gi RWO fast-csi
reclaimPolicy: Retain
volumeattachment... attached: true
model-api-pdb ALLOWED DISRUPTIONS 1

CHAPTER 4 / 5

복구 시험의 진행과 중단을 결정합니다

CHAPTER 5 / 5

Storage와 cluster 운영의 복구를 재검증합니다

CONCRETE CASES

Retain이 필요한 model artifact PVC가 Delete policy인 fixture와 upgrade drain 계획을 수정합니다.

node drain 전 PodDisruptionBudget, local volume, daemon workload와 GPU job checkpoint를 확인합니다. 모든 node를 동시에 바꾸지 않고 canary와 중단 기준을 둡니다.

잘못된 대응과 확인할 경계

PVC 삭제 시험은 실제 volume을 지울 수 있습니다. production과 분리된 lab class에서 reclaim behavior를 검증합니다.

mount 실패면 Pod를 반복 삭제하지 말고 VolumeAttachment·node plugin·backend volume identity를 보존합니다. upgrade 실패는 canary를 멈추고 지원되는 이전 revision으로 rollback한 뒤 snapshot과 volume을 검증합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

INTERACTIVE LAB 1 / 2

실습 1 · 출력에서 판정 근거 찾기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

실습 상황:: Retain이 필요한 model artifact PVC가 Delete policy인 fixture와 upgrade drain 계획을 수정합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, reclaim·snapshot·PDB 미검증 조건이 보이면 다음 변경으로 넘어가지 마십시오.

inference/model-cache Bound pvc-... 500Gi RWO fast-csi
reclaimPolicy: Retain
volumeattachment... attached: true
model-api-pdb ALLOWED DISRUPTIONS 1

값 자체를 외우는 것이 아니라 volume 수명·attach·disruption·datastore 복구 계약이 maintenance 계획과 맞는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

INTERACTIVE LAB 2 / 2

실습 2 · 중단과 복구 계획 세우기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

PVC 삭제 시험은 실제 volume을 지울 수 있습니다. production과 분리된 lab class에서 reclaim behavior를 검증합니다.

KEY TERMS

이번 단원 핵심 용어

PVC(PersistentVolumeClaim, 영구 volume 요청)
workload가 필요한 용량과 접근 조건을 선언하는 storage 요청입니다.

UNIT WORKBOOK

개념을 새로운 상황에 적용하는 문제와 기록지

기본 원리 확인에서 시작해 실제 업무 판단으로 확장합니다. 답을 제출하면 정답만이 아니라 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

Storage와 cluster 운영의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

PERSONAL WORKSHEET

내 환경에 옮겨 적는 학습 기록지

입력 내용은 현재 브라우저 화면에만 머물며 저장하거나 외부로 전송하지 않습니다. 민감한 실제 정보 대신 범주와 가명을 사용하십시오.

OFFICIAL SOURCES

공식 자료에서 다시 확인하기

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

DECISION ACTIVITY

Deployment는 Available이지만 외부 요청이 503입니다. 첫 진단 순서는?

먼저 필요한 증거와 중단 기준을 적은 뒤 판단을 선택하십시오.

답 선택

THREE-LEVEL ASSESSMENT

기본 원리에서 운영 판단까지

답을 제출하면 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

기본 문제 1

Kubernetes controller의 핵심 역할은?

답 선택
적용 문제 2

readiness probe 실패가 뜻하는 올바른 동작은?

답 선택
종합 문제 3

cluster upgrade 전 가장 중요한 복구 증거는?

답 선택

LEARNING RECORD

본문·판단 활동·모든 해설을 확인했나요?

완료 기록은 이 브라우저에만 저장됩니다.