소개
현대 애플리케이션은 흔히 컨테이너로 패키징됩니다. 컨테이너는 애플리케이션 실행에 필요한 라이브러리와 설정을 애플리케이션과 함께 묶어, 어디서든 일관되게 실행하기 쉽게 만듭니다. 컨테이너 하나를 실행하는 일은 간단하지만, 여러 컨테이너를 안정적으로 운영하는 일은 훨씬 어렵습니다. 운영자는 컨테이너를 어디에서 실행할지 결정하고, 장애가 난 컨테이너를 다시 시작하며, 애플리케이션끼리 연결하고, 변경 사항을 안전하게 배포해야 합니다.
Kubernetes는 이러한 클러스터 수준의 운영 업무를 처리하는 컨테이너 오케스트레이션 시스템입니다. 예를 들어“이 웹 애플리케이션을 세 개 실행하라”처럼 원하는 상태를 선언하면, Kubernetes 는 실제 상태가 원하는 상태와 일치하도록 지속적으로 조정합니다.
Kubernetes 클러스터는 노드라고 부르는 하나 이상의 머신으로 구성됩니다. 컨트롤 플레인은 클러스터를 관리하고, 노드는 애플리케이션이 사용하는 CPU, 메모리, 네트워크, 컨테이너 런타임을 제공합니다. 애플리케이션은 Pod, Deployment, Service 같은 Kubernetes 객체로 실행됩니다.
이번 첫 번째 실습에서는 아직 애플리케이션을 배포하지 않습니다. 먼저 실제 클러스터 안에서 현재 위치를 파악하는 방법을 익힙니다.
- 사용할 도구와 현재 클러스터, Kubernetes 버전, 노드 상태를 확인합니다.
- Kubernetes 를 구성하는 컨트롤 플레인 및 노드 구성 요소를 찾습니다.
- 클러스터 엔드포인트와 노드의 상세 정보를 점검합니다.
- 네임스페이스 전반의 Pod, Deployment, Service 를 탐색합니다.
설치 작업에 신경 쓰지 않고 Kubernetes 개념에 집중할 수 있도록 환경이 이미 준비되어 있습니다. 이 환경은 labex-v135라는 프로필로 Minikube v1.38.1 을 사용하며, Kubernetes v1.35.5 를 실행합니다. Minikube 는 LabEx VM 의 Docker 컨테이너 안에서 완전한 Kubernetes 클러스터를 실행합니다. 학습을 위한 단일 노드 환경이지만, 여기서 연습하는 Kubernetes 명령과 개념은 더 큰 클러스터에도 그대로 적용됩니다.
모든 작업은 터미널에서 수행합니다. 각 명령을 실행하기 전에 설명을 읽고, 실제 출력 결과를 설명된 내용과 비교해 보세요. 정확한 생성 시점, 재시작 횟수, 자동 생성된 이름은 실행 중인 시스템에 따라 달라질 수 있으며, 이는 정상입니다.
미리 구성된 클러스터 확인
환경 시작: 이 실습에서는 완전한 Kubernetes 클러스터가 시작됩니다. 컨트롤 플레인, 노드 및 네트워크 구성 요소를 설정하는 데 일반적으로 2～3분이 걸립니다. 환경 로딩이 완료될 때까지 잠시 기다린 후 작업을 시작하세요.
이번 단계에서는 터미널 도구가 Kubernetes 에 연결되는 방식과 제공된 소프트웨어 버전을 확인하고, 클러스터가 준비되었는지 점검합니다. 클러스터를 변경하기 전에 현재 어떤 클러스터가 활성화되어 있고 정상 상태인지 확인하는 것은 관리자의 기본 절차입니다.
도구 이해하기
서로 연관된 두 가지 명령줄 도구를 사용합니다.
minikube는 로컬 Kubernetes 클러스터를 생성하고 관리합니다. 이름이 지정된 Minikube 환경을 프로필이라고 합니다. 이 실습에서는labex-v135프로필을 사용합니다.kubectl은 Kubernetes 의 표준 명령줄 클라이언트입니다. Kubernetes API 서버에 요청을 보내 객체를 조회, 생성, 수정, 삭제합니다.
클러스터는 이미 실행 중입니다. minikube start를 실행하지 마세요. 기존 환경을 Minikube 가 다시 확인하는 동안 불필요하게 기다리게 될 수 있습니다.
작업 디렉터리로 이동
이후 실습에서 매니페스트와 학습자가 생성하는 파일을 저장할 프로젝트 디렉터리로 이동합니다.
cd /home/labex/project
cd 명령은 셸의 현재 디렉터리를 변경합니다. 정상적으로 실행되면 일반적으로 아무 출력도 표시되지 않습니다.
Minikube 버전 확인
설치된 Minikube 버전을 표시합니다. --로 시작하는 옵션은 명령의 동작을 변경합니다. 여기서 --short는 버전 번호만 표시하도록 요청합니다.
minikube version --short
v1.38.1
이 버전은 클러스터 관리 도구의 버전이며 Kubernetes 버전이 아닙니다. Minikube 와 Kubernetes 는 서로 다른 프로젝트이므로 버전 번호도 별도로 관리됩니다.
클라이언트 및 서버 버전 확인
kubectl에 버전 정보를 요청합니다. 이 명령은 클러스터에 연결하므로 로컬 클라이언트와 원격 API 서버를 모두 확인합니다.
kubectl version
Client Version: v1.35.5
Kustomize Version: ...
Server Version: v1.35.5
Client Version은 설치된 kubectl의 버전이고, Server Version은 Kubernetes API 서버가 보고한 버전입니다. 서버 버전 줄이 표시되면 kubectl이 클러스터에 정상적으로 연결되었다는 뜻입니다. Kustomize 는 매니페스트를 사용자 지정하는 기능으로 함께 제공되지만, 이번 실습에서는 사용하지 않습니다.
현재 컨텍스트 확인
한 대의 컴퓨터에는 여러 클러스터에 대한 접속 정보가 kubeconfig 파일에 저장될 수 있습니다. kubeconfig 의 컨텍스트는 사용할 클러스터, 사용자 인증 정보, 기본 네임스페이스를 선택합니다. 현재 컨텍스트를 확인하면 잘못된 클러스터에서 작업하는 실수를 예방할 수 있습니다.
kubectl config current-context
labex-v135
이는 준비된 Kubernetes v1.35 프로필과 일치합니다.
컨텍스트 목록 확인 및 선택
실제 kubeconfig 파일에는 여러 컨텍스트가 포함되어 있는 경우가 많습니다. 전환하기 전에 목록을 확인하면 이름을 추측할 필요가 없습니다.
kubectl config get-contexts
NAME 열에는 컨텍스트 이름이 표시되고, CURRENT 열에서는 현재 활성화된 컨텍스트에 *가 표시됩니다. 각 컨텍스트에 연결된 클러스터, 인증 정보, 기본 네임스페이스는 나머지 열에 나타납니다.
이름을 선택해야 할 때는 use-context를 사용합니다. 이미 현재 컨텍스트인 labex-v135를 다시 선택해도 안전하며, 실제 컨텍스트 전환 절차를 그대로 연습할 수 있습니다.
kubectl config use-context labex-v135
Switched to context "labex-v135".
current-context는“현재 어떤 컨텍스트가 선택되어 있는가?”를 확인하고, get-contexts는“어떤 선택지가 있는가?”를 확인하며, use-context NAME은 선택 항목을 변경합니다. 이 명령들은 로컬 클라이언트의 선택만 변경할 뿐, 클러스터를 시작하거나 중지하거나 수정하지 않습니다.
Minikube 프로필 확인
이 프로필의 상태를 Minikube 에 요청합니다. 짧은 옵션 -p는 프로필을 의미하며, 뒤에 프로필 이름을 지정합니다.
minikube status -p labex-v135
labex-v135
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured
host는 Minikube 노드 컨테이너가 실행 중이라는 뜻입니다. kubelet은 노드 에이전트입니다. apiserver는 Kubernetes API 엔드포인트입니다. kubeconfig: Configured는 로컬 클라이언트 설정이 이 클러스터를 가리킨다는 의미입니다. 모든 항목이 정상이어야 합니다.
노드 목록 확인
대부분의 kubectl 명령은 kubectl <verb> <resource> 형식을 따릅니다. 여기서 get은 객체를 조회하고 nodes는 리소스 유형입니다.
kubectl get nodes
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35.5
NAME은 노드를 식별합니다. STATUS=Ready는 해당 노드가 워크로드를 실행할 수 있다는 뜻입니다. ROLES는 이 노드가 컨트롤 플레인을 호스팅한다는 것을 보여 줍니다. 이미지가 준비된 스냅샷을 복원하므로 AGE는 이번 세션보다 오래되었을 수 있습니다. VERSION은 kubelet 버전입니다.
이 실습에서는 하나의 노드가 컨트롤 플레인과 워크로드 실행을 모두 담당합니다. 실제 운영 클러스터에서는 이러한 역할을 여러 머신에 분산하는 경우가 일반적입니다.
단계 확인
kubectl이 의도한 labex-v135 클러스터에 연결되고 있으며, 해당 노드가 Kubernetes v1.35.5 에서 Ready 상태임을 확인했습니다. 익숙하지 않은 클러스터에 접속할 때마다 활용할 수 있는 유용한 점검 절차입니다.
Kubernetes 아키텍처 구성 요소 식별
이번 단계에서는 Kubernetes 아키텍처 모델을 실제 구성 요소와 연결해 봅니다. API 서버, 스케줄러, kubelet 같은 이름은 실제로 실행 중인 Pod 를 직접 확인하면 훨씬 쉽게 기억할 수 있습니다.
Kubernetes 에서 요청이 처리되는 과정
Kubernetes 에 웹 애플리케이션을 실행해 달라고 요청한다고 가정해 보겠습니다. 먼저 kubectl이 kube-apiserver에 요청을 보내고, kube-apiserver 는 요청을 검증한 뒤 원하는 상태를 etcd에 저장합니다.
다음으로 kube-scheduler가 새 Pod 마다 실행할 노드를 선택합니다. kube-controller-manager는 클러스터를 감시하면서 실제 상태가 원하는 상태와 일치하도록 조정합니다.
마지막으로 선택된 노드의 kubelet이 컨테이너 런타임에 Pod 의 컨테이너를 시작하도록 요청합니다. 네트워크 구성 요소는 Pod 와 Service 가 서로 통신할 수 있도록 지원합니다.
원하는 상태와 실제 상태를 지속적으로 비교하고 조정하는 과정을 **조정 (reconciliation)**이라고 합니다. Deployment 가 Pod 세 개를 요청했지만 두 개만 존재한다면, 컨트롤러가 누락된 Pod 를 생성합니다.
Pod 와 시스템 네임스페이스 이해하기
Pod는 Kubernetes 에서 배포할 수 있는 가장 작은 단위입니다. 밀접하게 연관된 하나 이상의 컨테이너를 묶고, 공유 네트워크 및 스토리지 환경을 제공합니다.
네임스페이스는 네임스페이스 리소스에 대한 논리적 범위를 제공합니다. kube-system에는 클러스터 인프라가 포함됩니다. -n kube-system 옵션은 kubectl이 기본 네임스페이스가 아니라 해당 네임스페이스에서 검색하도록 지정합니다. 더 긴 형식인 --namespace=kube-system도 동일한 범위를 선택합니다.
Minikube 는 컨트롤 플레인 구성 요소를 정적 Pod로 실행합니다. kubelet 이 노드의 파일에서 이러한 Pod 를 직접 생성하므로, 일반적인 스케줄링을 사용할 수 있게 되기 전에도 컨트롤 플레인을 시작할 수 있습니다.
컨트롤 플레인 목록 확인
객체에는 그룹화와 선택에 사용하는 키 - 값 메타데이터인 레이블을 지정할 수 있습니다. -l tier=control-plane을 사용하면 해당 레이블이 있는 Pod 만 선택할 수 있습니다.
kubectl get pods -n kube-system -l tier=control-plane
NAME READY STATUS RESTARTS AGE
etcd-labex-v135 1/1 Running ... ...
kube-apiserver-labex-v135 1/1 Running ... ...
kube-controller-manager-labex-v135 1/1 Running ... ...
kube-scheduler-labex-v135 1/1 Running ... ...
API 서버는 Kubernetes 로 들어가는 관문입니다. etcd 는 클러스터 상태를 저장합니다. 스케줄러는 Pod 가 실행될 위치를 결정합니다. 컨트롤러 관리자는 상태를 조정하는 컨트롤러를 실행합니다.
READY=1/1은 Pod 에 포함된 컨테이너 하나가 준비되었다는 의미입니다. 계속 실행되어야 하는 구성 요소는 Running 상태여야 합니다. 저장된 클러스터가 다시 시작된 후에는 RESTARTS가 0 이 아닐 수도 있습니다. AGE는 이 실습에서 경과한 시간이 아니라 객체가 생성된 후의 시간입니다.
레이블 확인
마지막 열에 레이블을 표시합니다.
kubectl get pods -n kube-system -l tier=control-plane --show-labels
component=kube-apiserver와 tier=control-plane을 찾아보세요. 첫 번째 레이블은 구성 요소를 구분하고, 두 번째 레이블은 모든 컨트롤 플레인 Pod 를 하나의 그룹으로 묶습니다. 레이블은 객체를 식별하고, 셀렉터는 조건에 맞는 객체를 찾습니다.
노드 네트워크 구성 요소 확인
k8s-app 값이 kube-proxy 또는 calico-node 중 하나라는 집합 기반 셀렉터를 사용합니다. 따옴표는 셸이 괄호를 해석하지 않도록 합니다.
kubectl get pods -n kube-system -l 'k8s-app in (kube-proxy,calico-node)'
NAME READY STATUS RESTARTS AGE
calico-node-... 1/1 Running ... ...
kube-proxy-... 1/1 Running ... ...
Calico 는 Pod 네트워크를 구성합니다. kube-proxy 는 Service 가 트래픽을 Pod 로 전달할 수 있도록 노드의 규칙을 관리합니다. kubelet 은 Pod 를 운영하는 호스트 에이전트이므로 이 목록에는 나타나지 않습니다. kubelet 은 일반적인 Pod 가 아니라 호스트 서비스로 실행되며, 자기 자신이 관리하는 일반 Pod 로 실행되지 않습니다.
단계 확인
API 서버는 요청을 수락하고, etcd 는 상태를 저장하며, 스케줄러는 실행 위치를 선택합니다. 컨트롤러는 상태를 조정하고, kubelet 은 노드를 운영하며, Calico 와 kube-proxy 는 네트워크 기능을 지원합니다.
클러스터 및 노드 세부 정보 점검
이번 단계에서는 간단한 상태 확인에서 상세한 점검으로 범위를 넓힙니다. Kubernetes 는 간결한 목록 보기와 자세한 설명을 모두 제공하므로, 언제 어떤 명령을 사용할지 아는 것이 문제 해결의 기본 습관입니다.
클러스터 엔드포인트 찾기
kubectl cluster-info는 현재 환경을 파악하기 위한 전용 명령입니다. kubectl get처럼 특정 리소스 유형 하나를 나열하는 대신, 활성 클러스터에 API 서버와 CoreDNS 같은 주요 서비스의 주소를 보고하도록 요청합니다.
kubectl cluster-info
Kubernetes control plane is running at https://...
CoreDNS is running at https://...
컨트롤 플레인 URL 은 API 서버 엔드포인트입니다. CoreDNS 는 DNS 서비스 검색을 제공하므로, 워크로드가 계속 변하는 IP 주소를 추적하지 않고 이름으로 Service 를 찾을 수 있습니다. 주소는 환경에 따라 달라질 수 있으므로 is running이라는 부분에 집중하세요. 이는 API 서버가 정보를 반환했다는 뜻이지만, 모든 워크로드가 정상이라는 의미는 아닙니다.
노드 목록 확장
더 많은 열을 표시하려면 -o wide를 추가합니다.
kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP ... OS-IMAGE
labex-v135 Ready control-plane ... v1.35.5 192.168.49.2 ... Debian GNU/Linux 12 (bookworm)
INTERNAL-IP는 클러스터 네트워크에서 사용하는 노드 주소입니다. EXTERNAL-IP=<none>은 Kubernetes 가 관리하는 공개 주소가 없다는 뜻입니다. OS-IMAGE, KERNEL-VERSION, CONTAINER-RUNTIME은 노드의 소프트웨어 환경을 설명합니다.
LabEx 백엔드는 Ubuntu 22.04 를 사용하지만, Minikube 는 Debian 기반 Docker 컨테이너를 Kubernetes 노드로 나타냅니다. 따라서 여기서 Debian 이 표시되는 것은 정상입니다.
노드 설명 확인
목록의 한 행만으로 충분한 정보를 얻기 어려울 때는 describe를 사용합니다. 기본 형식은 kubectl describe <resource-type> <name>입니다. 여기서는 리소스 유형이 node이고 객체 이름은 labex-v135입니다.
kubectl describe node labex-v135
출력 상단에서 노드 식별 정보와 스케줄링 관련 항목을 확인합니다.
Name: labex-v135
Roles: control-plane
Taints: <none>
Unschedulable: false
Taints는 이를 허용하는 설정이 없는 Pod 가 해당 노드에 배치되는 것을 막을 수 있습니다. <none>은 이 학습용 노드에 테인트가 없다는 뜻입니다. Unschedulable: false는 Kubernetes 가 이 노드에 워크로드를 배치할 수 있다는 의미입니다.
Conditions 표를 찾습니다.
Type Status ... Reason
NetworkUnavailable False ... CalicoIsUp
MemoryPressure False ... KubeletHasSufficientMemory
DiskPressure False ... KubeletHasNoDiskPressure
PIDPressure False ... KubeletHasSufficientPID
Ready True ... KubeletReady
압박 상태나 네트워크 불가 상태에서는 문제가 존재하지 않음을 나타내는 False가 정상입니다. 반면 Ready에서는 True가 정상입니다. 항상 조건 이름과 상태 값을 함께 해석해야 합니다.
Capacity는 노드가 보고하는 전체 리소스입니다. Allocatable은 시스템 예약량을 제외한 뒤 Pod 에 제공할 수 있는 리소스입니다. System Info에는 컨테이너 런타임과 kubelet 정보가 표시됩니다. 이후 섹션에서는 Pod 목록, 할당된 요청 및 제한, 이벤트를 확인합니다. 정확한 값과 시각은 환경에 따라 달라질 수 있습니다.
단계 확인
빠른 표 형식의 결과가 필요하면 get, 추가 열이 필요하면 get -o wide, 특정 객체의 조건, 용량, 런타임 세부 정보, 이벤트를 확인하려면 describe를 사용합니다.
네임스페이스 전반의 리소스 점검
이번 단계에서는 자주 사용하는 객체를 초보자 관점에서 정리해 봅니다. 네임스페이스는 리소스를 구분하고, Pod 는 컨테이너를 실행하며, Deployment 는 Pod 를 관리하고, Service 는 안정적인 네트워크 접근 경로를 제공합니다.
객체 간 관계 이해하기
- Pod는 배포 가능한 가장 작은 단위이며 하나 이상의 컨테이너를 포함합니다.
- Deployment는 무상태 애플리케이션의 실행 복제본 수를 선언하고, ReplicaSet 을 통해 Pod 를 관리합니다.
- Service는 선택한 Pod 에 안정적인 가상 IP 와 DNS 이름을 제공합니다. 교체 가능한 Pod 의 IP 주소는 변경될 수 있기 때문입니다.
- Namespace는 네임스페이스 객체를 그룹화하고, 서로 다른 범위에서 동일한 이름을 사용할 수 있게 합니다.
간단히 말하면 Deployment 가 Pod 를 관리하고, Service 가 해당 Pod 를 선택해 클라이언트에 안정적인 엔드포인트를 제공합니다. 모든 객체가 네임스페이스에 속하는 것은 아닙니다. Node 는 클러스터 전체에 속합니다.
모든 네임스페이스의 Pod 목록 확인
네임스페이스 옵션 없이 kubectl get pods를 실행하면 현재 네임스페이스에서만 검색합니다. -A는 --all-namespaces의 약식 표현입니다.
kubectl get pods -A
NAMESPACE는 논리적 범위입니다. NAME은 해당 범위 안에서 Pod 를 식별합니다. READY는 준비된 컨테이너 수를 전체 컨테이너 수로 나눈 값입니다. STATUS는 수명 주기 상태를 나타냅니다. RESTARTS는 재시작 횟수이고, AGE는 객체 생성 후 경과 시간입니다.
계속 실행되는 인프라 구성 요소는 Running 상태여야 합니다. 일부 인그레스 승인용 Pod 는 일회성 Job 을 수행한 뒤 정상 종료되므로 0/1 readiness 와 함께 Completed로 표시될 수 있습니다. 정상 여부는 워크로드의 목적에 맞춰 해석해야 합니다.
Deployment 목록 확인
복수형 리소스 이름인 deployments는 Deployment 객체를 조회합니다. 시스템 Deployment 는 현재 default 네임스페이스 외부에 있으므로 -A를 그대로 사용합니다.
kubectl get deployments -A
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE
ingress-nginx ingress-nginx-controller 1/1 1 1 ...
kube-system calico-kube-controllers 1/1 1 1 ...
kube-system coredns 1/1 1 1 ...
kube-system metrics-server 1/1 1 1 ...
READY는 준비된 복제본 수를 원하는 복제본 수로 나눈 값입니다. UP-TO-DATE는 현재 Pod 템플릿을 사용하는 복제본 수입니다. AVAILABLE은 해당 목적에 사용할 수 있는 복제본 수입니다. 앞에서 확인한 coredns-... Pod 는 coredns Deployment 가 관리합니다.
Service 목록 확인
Pod 는 교체될 수 있으므로 클라이언트가 Pod IP 에 직접 의존해서는 안 됩니다. 안정적인 Service 엔드포인트를 확인합니다.
kubectl get services -A
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default kubernetes ClusterIP 10.96.0.1 <none> 443/TCP ...
kube-system kube-dns ClusterIP 10.96.0.10 <none> ... ...
ingress-nginx ingress-nginx-controller NodePort ... <none> ... ...
TYPE은 외부 노출 방식을 나타냅니다. ClusterIP는 클러스터 내부에서 접근할 수 있고, NodePort는 노드 포트도 엽니다. CLUSTER-IP는 안정적인 가상 주소입니다. EXTERNAL-IP=<none>은 외부 주소가 할당되지 않았다는 뜻입니다. PORT(S)에는 노출된 프로토콜과 포트가 표시됩니다.
kubernetes Service 는 클러스터 내부에서 API 에 접근할 수 있도록 합니다. kube-dns는 CoreDNS 에 대한 안정적인 접근 경로를 제공합니다. 인그레스 Service 는 들어오는 HTTP 및 HTTPS 요청을 지원합니다.
통합 보기 구성
어떤 유형의 일반적인 워크로드가 존재하는지 아직 모를 때는 kubectl get all을 사용하면 전체적인 구조를 빠르게 파악할 수 있습니다. 앞에서 사용한 모든 네임스페이스 범위를 적용하려면 -A를 추가합니다.
kubectl get all -A
이 명령은 Pod, Service, DaemonSet, Deployment, ReplicaSet, Job 과 같은 주요 리소스를 묶어서 보여 줍니다. 하나의 구성 요소가 Deployment, ReplicaSet, Pod 등 여러 계층으로 표시될 수 있습니다.
이름과 달리 get all이 모든 리소스를 반환하는 것은 아닙니다. ConfigMap, Secret, NetworkPolicy 등 많은 리소스는 제외됩니다. 먼저 전체적인 구조를 파악하는 용도로 사용한 다음, 필요한 정확한 리소스 유형을 별도로 조회하세요.
단계 확인
네임스페이스는 범위를 제공하고, Pod 는 컨테이너를 실행하며, Deployment 는 원하는 Pod 복제본 수를 유지하고, Service 는 변경될 수 있는 Pod 에 안정적인 네트워크 접근 경로를 제공합니다.
요약
첫 번째 Kubernetes 클러스터 안내 탐색을 완료했습니다. Kubernetes 가 노드 전체에서 원하는 상태를 관리하며, kubectl이 활성 kubeconfig 컨텍스트를 사용해 API 서버와 통신한다는 점을 배웠습니다.
Minikube, Kubernetes, kubectl의 버전을 구분하고, 컨텍스트와 노드가 준비되었는지 확인하는 방법을 연습했습니다. 또한 컨트롤 플레인, 노드, 네트워크 구성 요소를 식별하고, 레이블과 셀렉터를 사용하며, get, get -o wide, describe 중 적절한 명령을 선택하는 방법을 익혔습니다. 노드의 조건과 리소스 용량을 해석하고, Namespace, Pod, Deployment, Service 의 관계도 살펴보았습니다.
초보자가 반드시 익혀야 할 핵심 습관은 무엇인가를 변경하기 전에 먼저 점검하는 것입니다. 현재 컨텍스트를 확인하고, 노드 상태를 점검하며, 관련 네임스페이스와 리소스 유형을 식별한 뒤, 표시된 상태 정보를 주의 깊게 읽어야 합니다. 이후 실습에서는 이 모델을 바탕으로 직접 워크로드를 생성하게 됩니다.
