자주 쓰이는 kubectl 명령어 정리

도람·2025년 11월 11일

kubectl

🖥️제로부터 시작하는 Docker & 쿠버네티스

목록 보기

22/82

기본적인 kubectl 명령어

쿠버네티스에서는 kubectl 명령어를 통해 클러스터 내부의 리소스를 직접 제어할 수 있다.
아래는 가장 많이 사용되는 명령어들을 간단히 실습해본 예시이다.

get

get은 조회 명령어, 현재 클러스터 내의 리소스 상태를 확인할 때 사용한다.

kubectl get pods
kubectl get nodes
kubectl get services

run, create, apply

run, create, apply는 리소스 생성 명령어이다.

명령어 설명
kubectl run 단일 Pod를 빠르게 실행할 때 사용
kubectl create Deployment, Service 등의 리소스를 처음 생성할 때 사용
kubectl apply 이미 존재하는 리소스를 업데이트하거나, YAML 파일을 적용할 때 사용

명령어	설명
`kubectl run`	단일 Pod를 빠르게 실행할 때 사용
`kubectl create`	Deployment, Service 등의 리소스를 처음 생성할 때 사용
`kubectl apply`	이미 존재하는 리소스를 업데이트하거나, YAML 파일을 적용할 때 사용

delete

delete는 필요없는 리소스를 삭제하는 명령어이다.

kubectl delete pod nginx
kubectl delete deployment myapp
kubectl delete -f deployment.yaml

위는 해당 명령어들을 사용해 본 예제이다.

exec

exec는 파드 내부 컨테이너에 들어가서 직접 명령을 내릴 수 있다.

scale

scale은 리소스 확장(스케일 아웃, 파드 수 확장)을 하거나 축소(스케일 인)할 때 사용한다.

kubectl scale deployment nginx --replicas=3

-> 위 명령어는 nginx 파드를 3개로 늘린다.

edit

edit은 실행 중인 리소스의 설정을 직접 수정할 수 있다.

kubectl edit deployment nginx

-> 위 명령어를 실행하면 YAML 파일 형태로 열리며, 수정 후 저장하면 바로 반영된다.

이러한 명령어들을 활용하면, 쿠버네티스 환경에서 리소스 생성부터 관리, 수정, 삭제까지의
전체 라이프사이클을 CLI 환경에서 직접 제어할 수 있다.

--dry-run=client

쿠버네티스 명령어(kubectl create, kubectl apply, kubectl run 등)에 자주 사용되는 옵션으로,
리소스를 실제로 생성하지 않고, 실행 결과를 미리 검증할 때 사용한다.

즉, “이 명령어를 실행하면 어떤 리소스가 만들어질지”를 클라이언트 측에서 테스트하는 용도이다.

사용 예시 - Pod 생성 시뮬레이션

kubectl run test-pod --image=nginx --dry-run=client

-> 실제 파드는 생성되지 않고 시뮬레이션만 한 것을 확인할 수 있다.

kubectl run test-pod --image=nginx --dry-run=client -o yaml

이 명령어는 쿠버네티스에서 “리소스 생성 YAML을 미리 확인”할 때 자주 쓰는 명령어다.

->이와같이 출력이 되는데,

kubectl run test-pod --image=nginx --dry-run=client -o yaml > test-pod.yaml

이렇게 생성된 YAML을 바로 파일로 저장해서

kubectl apply -f test-pod.yaml

하면, 코드 기반으로 쿠버네티스 리소스를 관리할 수 있다.

상태를 확인할 수 있는 명령어

쿠버네티스에서는 단순히 리소스를 생성하는 것뿐 아니라,
현재 어떤 일이 일어나고 있는지를 확인하는 명령어들도 매우 중요하다.
대표적으로 events, describe, logs 3가지를 자주 사용한다.

events

쿠버네티스 클러스터 내부에서 발생한 이벤트(상태 변화 기록)를 확인할 수 있다.
Pod가 생성되거나, 이미지 풀(Pull)에 실패했거나, 노드가 스케줄링 중일 때의 원인을 파악할 수 있다.

kubectl get events --sort-by=.metadata.creationTimestamp

최근 발생한 순서대로 정렬해서 보면,
“왜 파드가 Pending인지”, “어떤 노드에 스케줄됐는지” 같은 흐름을 이해하기 좋다.

이 사진은 events 명령어를 활용하여 출력한 사진이다.

kubectl get events --sort-by=.metadata.creationTimestamp

→ 최근에 어떤 파드가 생성되었는지, 이미지 풀 오류나 스케줄링 문제는 없는지 확인할 수 있다.

describe

describe는 특정 리소스(예: Pod, Node, Service 등)의 상세 상태 및 이벤트 내역을 볼 수 있다.

kubectl describe pod nginx

출력 내용에는 다음 정보가 포함된다.

Pod가 어떤 노드에 배포되었는지
컨테이너 상태 (Running, Waiting, Terminated 등)
최근 이벤트 기록 (이미지 풀, 스케줄링, 시작 등)

→ nginx 파드의 상태, 실행 노드, 컨테이너 로그, 이벤트 내역까지 한 번에 볼 수 있다.

logs

log는 Pod 내부 컨테이너에서 출력된 로그를 확인할 때 사용한다.

kubectl logs hello-docker

이렇게 logs 명령어를 통해 pod 내부 로그를 확인할 수 있다.

정리

events → 클러스터에서 일어난 일의 흐름
describe → 리소스의 상태를 상세히 분석
logs → 컨테이너 내부의 실행 결과 확인

본 게시글은 인프런 「그림으로 배우는 쿠버네티스」 강의를 참고하여 작성되었습니다.
강의에서 사용된 핵심 코드는 공개하지 않았으며, 제 환경에 맞게 재구성 및 편집한 내용을 정리하였습니다.
👉 강의 링크: https://www.inflearn.com/course/그림으로-배우는-쿠버네티스/dashboard