📌 kubectl apply vs create 차이점 정복

📌 kubectl apply vs create 차이점  정복 (실습 포함)

쿠버네티스를 막 시작한 사람이라면 kubectl apply랑 kubectl create의 차이 때문에 혼란스러울 수 있습니다.
두 명령어는 리소스를 "만든다"는 점에서는 비슷하지만, 실제 사용 목적과 동작 방식은 확연히 다릅니다.

🧠 개념 먼저: create vs apply 차이

항목	kubectl create	kubectl apply
목적	리소스 최초 생성	리소스 생성 및 이후 업데이트
상태 추적	없음	.last-applied-configuration 주석으로 상태 추적
덮어쓰기	불가 (이미 있으면 오류)	가능 (변경사항만 반영)
선언적 관리	❌ 명령형	✅ 선언형 (YAML 중심)
사용 예	초기 리소스 배포	배포 후 설정 변경 관리

🧪 실습으로 이해하기

📄 Step 1. 테스트용 deployment.yaml 만들기

# nginx-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80

▶️ Step 2. kubectl create 로 배포

kubectl create -f nginx-deploy.yaml

결과: 리소스가 생성됩니다. 하지만 다시 실행하면 Error from server (AlreadyExists) 오류가 발생합니다.

🛠 Step 3. 이미지 버전 수정 후 다시 create 실행

image: nginx:1.25

kubectl create -f nginx-deploy.yaml

결과: 여전히 실패. 이미 존재하므로 create 로는 수정 불가합니다.

✅ Step 4. 이번엔 apply 로 실행

kubectl apply -f nginx-deploy.yaml

결과: 기존 리소스를 감지하고 수정된 부분만 반영됩니다. (롤링 업데이트 수행됨)

---

📌 언제 create, 언제 apply?

상황	추천 명령어	이유
리소스 처음 만들 때	kubectl create	간단하게 생성 가능
여러 번 배포/변경 예정	kubectl apply	선언형 방식에 최적화
GitOps 또는 CI/CD 연동	kubectl apply	코드 기반 관리에 적합
덮어쓰기 방지 필요	kubectl create	이미 있으면 오류 발생시켜줌

🚨 apply 실수 방지 팁

• YAML은 Git으로 관리하는 습관 들이기
• kubectl edit로 직접 수정 후 apply 하면 충돌 위험 있음
• 수정은 항상 YAML → apply로 반영

---

✅ 한 줄 요약

create는 "처음 만들 때", apply는 "만들고 계속 관리할 때" 쓴다.