카테고리 없음

kubectl apply command

궁굼하다 2024. 12. 31. 02:13
728x90
반응형

1. kubectl apply란?

  • 정의:
    • kubectl apply는 Kubernetes 리소스를 선언형 방식으로 관리하는 명령어입니다.
    • YAML 또는 JSON 형식의 파일을 사용하여 리소스의 **원하는 상태(desired state)**를 정의하고, 이를 클러스터에 적용합니다.
    • 리소스가 없으면 생성하고, 이미 존재하면 업데이트를 수행합니다.

2. kubectl apply의 동작 원리

  1. 3가지 구성 비교:
    • kubectl apply는 다음 세 가지를 비교하여 변경 사항을 적용합니다:
      1. 로컬 구성 파일(Local Configuration File):
        • 사용자가 작성한 YAML/JSON 파일.
      2. 라이브 객체 구성(Live Object Configuration):
        • Kubernetes 클러스터 내부에서 현재 실행 중인 리소스의 상태.
      3. 마지막 적용된 구성(Last Applied Configuration):
        • 마지막으로 apply 령어를 실행했을 때 저장된 구성.
    • 이 세 가지를 비교하여 변경 사항만 라이브 객체에 적용합니다.
  2. JSON 형식으로 저장:
    • kubectl apply는 로컬 YAML 파일을 JSON으로 변환하여, 라이브 객체에 "last-applied-configuration"이라는 **주석(annotation)**으로 저장합니다.
    • 이 주석은 이후 변경 사항을 추적하는 데 사용됩니다.
  3. 변경 사항 처리:
    • 로컬 파일에 없는 필드는 삭제.
    • 컬 파일에 새로운 필드가 추가되면 라이브 객체에 반영.
    • 라이브 객체에만 있는 필드는 유지.

3. 주요 기능

  1. 리소스 생성 및 업데이트:
    • 리소스가 없으면 생성하고, 이미 존재하면 업데이트 수행.
  2. 디렉토리 전체 적용:
    • 여러 YAML 파일이 있는 디렉토리를 지정하여 한 번에 모든 리소스를 관리 가능.
    • kubectl diff 명령어로 로컬 파일과 현재 상태를 비교 가능. 변경 사항 비교:
    •  
  3. 변경 사항 추적:
    • 마지막 적용된 구성을 주석으로 저장하여, 변경 이력을 추적 가능.

 

주의사항

  1. 명령형과 선언형 혼용 금지:
    • kubectl create replace로 생성한 리소스를 apply로 관리하면 예상치 못한 동작 발생 가능.
  2. 주석(annotation) 관리:
    • apply 명령은 마지막 적용된 구성을 주석으로 저장하므로, 주석이 삭제되면 추적 불가.
  3. 불일치 문제 해결:
    • 라이브 객체와 로컬 파일 간 불일치 시, 수동으로 조정하거나 --force 옵션 사용.

https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/

 

 

Declarative Management of Kubernetes Objects Using Configuration Files

Kubernetes objects can be created, updated, and deleted by storing multiple object configuration files in a directory and using kubectl apply to recursively create and update those objects as needed. This method retains writes made to live objects without

kubernetes.io

kubectl.kubernetes.io/last-applied-configuration란?

  • 정의:
    • Kubernetes에서 kubectl apply 명령어를 사용할 때, 마지막으로 적용된 리소스 구성을 JSON 형식으로 저장하는 주석(annotation).
    • 이 주석은 라이브 객체(Live Object Configuration)에 저장되어, 이후 변경 사항을 추적하고 관리하는 데 사용됨.

2. 동작 방식

  1. 리소스 생성 시:
    • kubectl apply 명령어로 리소스를 처음 생성하면, 로컬 구성 파일(Local Configuration File)이 JSON 형식으로 변환되어 라이브 객체에 주석으로 저장.
    • 이 주석은 "마지막으로 적용된 구성(Last Applied Configuration)"으로 사용됨.
  2. 리소스 업데이트 시:
    • 이후 kubectl apply 명령어를 실행하면, 다음 세 가지를 비교하여 변경 사항을 확인:
      1. 로컬 구성 파일(Local Configuration File): 사용자가 작성한 YAML/JSON 파일.
      2. 라이브 객체 구성(Live Object Configuration): 현재 클러스터에 존재하는 리소스의 상태.
      3. 마지막 적용된 구성(Last Applied Configuration): 이전에 저장된 JSON 형식의 주석.
    • 변경 사항이 있으면 라이브 객체가 업데이트되고, "마지막 적용된 구성"도 최신 상태로 갱신.
  3. 필드 삭제 처리:
    • 로컬 파일에서 필드가 삭제되었고, "마지막 적용된 구성"에는 해당 필드가 있는 경우, 해당 필드는 라이브 객체에서 제거됨.
    • 반대로, 로컬 파일과 "마지막 적용된 구성" 모두에 없는 필드는 그대로 유지.
#YAML 파일 작성:
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:1.18
#리소스 생성:
kubectl apply -f pod.yaml
#kubectl.kubernetes.io/last-applied-configuration 주석 확인:
kubectl get pod nginx-pod -o yaml
#############################
#출력예시
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Pod","metadata":{"name":"nginx-pod"},"spec":{"containers":[{"image":"nginx:1.18","name":"nginx-container"}]}}
#############################
#YAML 파일 수정 (이미지 버전 변경):
containers:
  - name: nginx-container
    image: nginx:1.19
#변경 사항 적용:
kubectl apply -f pod.yaml
#업데이트 후 주석 확인:
kubectl get pod nginx-pod -o yaml
#############################
#출력예시
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Pod","metadata":{"name":"nginx-pod"},"spec":{"containers":[{"image":"nginx:1.19","name":"nginx-container"}]}}
#############################

  • kubectl run redis --image=redis:alpine --labels="tier=db"
  • Create a deployment named webapp using the image kodekloud/webapp-color with 3 replicas.
    • kubectl create deployment webapp --image=kodekloud/webapp-color --replica
      s=3 
  • Create a new pod called custom-nginx using the nginx image and run it on container port 8080.
    • kubectl run custom-nginx --image=nginx --port=8080
  • Create a new namespace called dev-ns.
    • kubectl create namespace dev-ns
  • Create a new deployment called redis-deploy in the dev-ns namespace with the redis image. It should have 2 replicas.
    • kubectl create deployment redis-deploy --image=redis --replicas=2 -n dev-
      ns
  • Create a pod called httpd using the image httpd:alpine in the default namespace. Next, create a service of type ClusterIP by the same name (httpd). The target port for the service should be 80.
    • kubectl run httpd --image=httpd:alpine
    • kubectl expose pod httpd --name httpd --port=80
    • kubectl run httpd --image=httpd:alpine --port=80 --expose=true
kubectl run httpd --image=httpd --replicas=2 --port=80 --expose=true
  1. kubectl run:
    • Pod를 생성하는 명령어.
    • --image: 컨테이너 이미지 지정.
    • --replica=2 pod 2개 생성
    • --port: 컨테이너가 사용하는 포트 지정.
    • --expose=true: ClusterIP 서비스를 자동으로 생성.
  2. kubectl expose:
    • 기존 리소스(Pod, Deployment 등)를 노출시키는 서비스 생성 명령어.
    • --type=ClusterIP: 서비스 타입 지정.
    • --port: 서비스가 노출할 포트.
반응형