쿠버네티스 YAML 튜토리얼: apiVersion·kind·metadata·spec로 파드 만들기

핵심 메시지

• 도커 같은 도구는 컨테이너를 만들지만 고가용성과 장애 내성을 제공하지 못한다. 쿠버네티스 같은 오케스트레이터가 이를 보완한다.
• 쿠버네티스는 여러 VM을 묶어 클러스터를 만들고, 노드가 죽으면 컨테이너(파드)를 다른 건강한 노드로 자동 재생성한다.
• 쿠버네티스는 컨테이너를 직접 다루지 않고 컨테이너를 감싸는 파드(pod) 단위로 관리한다.
• 파드 YAML에는 apiVersion, kind, metadata, spec 네 가지를 작성한다. status는 쿠버네티스가 자동으로 채운다.
• YAML의 자료형은 키-값 쌍, 딕셔너리, 배열 세 가지이며, 공식 API 문서가 무엇을 적을지 알려주는 기준이다.

쉽게 이해하기

Edureka 세션 강사는 쿠버네티스를 “컨테이너 오케스트레이터”로 정의하며 출발한다. 도커·Podman·Containerd 같은 도구로 컨테이너를 만들 수 있지만, 단일 VM에서 그 VM이 죽으면 모든 컨테이너가 함께 사라진다. 즉 장애 내성과 고가용성이 없다는 것이 핵심 문제다.

해결책으로 쿠버네티스는 여러 VM을 묶어 클러스터 네트워크(파드/컨테이너 네트워크)를 구성한다. 각 VM에는 OS와 컨테이너 도구가 올라가고, 어느 노드에서 컨테이너를 만들든 사설 네트워크로 서로 통신한다. 한 노드가 죽으면 그 위의 컨테이너는 자동으로 다른 건강한 노드에서 재생성된다. 강사는 이것이 곧 자가 치유(self-healing)이자 장애 내성이며, 같은 애플리케이션의 사본을 여러 컨테이너로 띄우는 것이 고가용성이라고 설명한다.

강사는 쿠버네티스가 컨테이너를 직접 관리하지 않는다는 점을 강조한다. 컨테이너를 감싸는 한 겹의 층인 파드(pod)를 통해 관리하며, 하나의 파드 안에 여러 컨테이너가 들어갈 수도 있다. 파드를 만드는 방법은 두 가지로, 명령어(kubectl run)와 YAML 파일(kubectl apply -f) 방식이 있는데 실무에서는 YAML 방식을 쓴다.

파드 YAML에는 네 가지 최상위 필드가 들어간다. apiVersion, kind, metadata, spec이다. status는 사용자가 적지 않아도 쿠버네티스가 자동으로 채운다. kind는 만들려는 리소스 종류(Pod, Deployment, ReplicaSet 등)이고, apiVersion은 그룹/버전 형태인데, 그룹이 core이면 core는 deprecated이므로 버전만(v1) 적는다는 규칙을 강사는 거듭 강조한다.

강사는 metadata와 spec을 YAML 자료형으로 풀어 설명한다. apiVersion·kind는 키-값 쌍이고, metadata는 여러 키-값 쌍을 담는 딕셔너리(이름·네임스페이스·레이블 등), labels는 그 안의 중첩 딕셔너리다. spec 안의 containers는 배열이라 하이픈(-)으로 시작하며, 각 컨테이너의 name과 image(예: nginx)를 적는다. 무엇을 적을지는 모두 공식 쿠버네티스 API 문서를 기준으로 삼는다.

주요 인사이트

• 강사는 어떤 필드가 키-값 쌍·딕셔너리·배열인지 API 문서로 구분하는 요령을 제시한다. 필드 아래 하이퍼링크가 없으면 키-값 쌍, 하이퍼링크가 있으면 딕셔너리, 하이퍼링크와 함께 “array”라고 적혀 있으면 배열이며 YAML에서 하이픈으로 시작한다.
• YAML에서는 탭(tab)이 허용되지 않는다. 탭을 넣으면 실행이 실패하므로 들여쓰기는 공백으로 해야 하며, 가독성을 위해 보통 두 칸을 쓴다.
• 같은 YAML 파일로 리소스를 만들고(kubectl apply -f) 삭제(kubectl delete -f)할 수 있다. 즉 생성에 쓴 파일을 그대로 삭제에도 재사용한다.
• 강사는 실습에서 단일 노드 클러스터로 빠르게 시연하지만, 노드가 하나면 그 노드가 죽을 때 파드를 옮길 곳이 없으므로 운영 환경에서는 반드시 여러 노드를 둬야 한다고 못 박는다.

자주 묻는 질문

관련 AI 소식