카테고리 없음
kubectl apply command
궁굼하다
2024. 12. 31. 02:13
728x90
반응형
1. kubectl apply란?
- 정의:
- kubectl apply는 Kubernetes 리소스를 선언형 방식으로 관리하는 명령어입니다.
- YAML 또는 JSON 형식의 파일을 사용하여 리소스의 **원하는 상태(desired state)**를 정의하고, 이를 클러스터에 적용합니다.
- 리소스가 없으면 생성하고, 이미 존재하면 업데이트를 수행합니다.
2. kubectl apply의 동작 원리
- 3가지 구성 비교:
- kubectl apply는 다음 세 가지를 비교하여 변경 사항을 적용합니다:
- 로컬 구성 파일(Local Configuration File):
- 사용자가 작성한 YAML/JSON 파일.
- 라이브 객체 구성(Live Object Configuration):
- Kubernetes 클러스터 내부에서 현재 실행 중인 리소스의 상태.
- 마지막 적용된 구성(Last Applied Configuration):
- 마지막으로 apply 명령어를 실행했을 때 저장된 구성.
- 로컬 구성 파일(Local Configuration File):
- 이 세 가지를 비교하여 변경 사항만 라이브 객체에 적용합니다.
- kubectl apply는 다음 세 가지를 비교하여 변경 사항을 적용합니다:
- JSON 형식으로 저장:
- kubectl apply는 로컬 YAML 파일을 JSON으로 변환하여, 라이브 객체에 "last-applied-configuration"이라는 **주석(annotation)**으로 저장합니다.
- 이 주석은 이후 변경 사항을 추적하는 데 사용됩니다.
- 변경 사항 처리:
- 로컬 파일에 없는 필드는 삭제.
- 로컬 파일에 새로운 필드가 추가되면 라이브 객체에 반영.
- 라이브 객체에만 있는 필드는 유지.
3. 주요 기능
- 리소스 생성 및 업데이트:
- 리소스가 없으면 생성하고, 이미 존재하면 업데이트 수행.
- 디렉토리 전체 적용:
- 여러 YAML 파일이 있는 디렉토리를 지정하여 한 번에 모든 리소스를 관리 가능.
- kubectl diff 명령어로 로컬 파일과 현재 상태를 비교 가능. 변경 사항 비교:
- 변경 사항 추적:
- 마지막 적용된 구성을 주석으로 저장하여, 변경 이력을 추적 가능.
주의사항
- 명령형과 선언형 혼용 금지:
- kubectl create나 replace로 생성한 리소스를 apply로 관리하면 예상치 못한 동작 발생 가능.
- 주석(annotation) 관리:
- apply 명령은 마지막 적용된 구성을 주석으로 저장하므로, 주석이 삭제되면 추적 불가.
- 불일치 문제 해결:
- 라이브 객체와 로컬 파일 간 불일치 시, 수동으로 조정하거나 --force 옵션 사용.
- 라이브 객체와 로컬 파일 간 불일치 시, 수동으로 조정하거나 --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. 동작 방식
- 리소스 생성 시:
- kubectl apply 명령어로 리소스를 처음 생성하면, 로컬 구성 파일(Local Configuration File)이 JSON 형식으로 변환되어 라이브 객체에 주석으로 저장.
- 이 주석은 "마지막으로 적용된 구성(Last Applied Configuration)"으로 사용됨.
- 리소스 업데이트 시:
- 이후 kubectl apply 명령어를 실행하면, 다음 세 가지를 비교하여 변경 사항을 확인:
- 로컬 구성 파일(Local Configuration File): 사용자가 작성한 YAML/JSON 파일.
- 라이브 객체 구성(Live Object Configuration): 현재 클러스터에 존재하는 리소스의 상태.
- 마지막 적용된 구성(Last Applied Configuration): 이전에 저장된 JSON 형식의 주석.
- 변경 사항이 있으면 라이브 객체가 업데이트되고, "마지막 적용된 구성"도 최신 상태로 갱신.
- 이후 kubectl apply 명령어를 실행하면, 다음 세 가지를 비교하여 변경 사항을 확인:
- 필드 삭제 처리:
- 로컬 파일에서 필드가 삭제되었고, "마지막 적용된 구성"에는 해당 필드가 있는 경우, 해당 필드는 라이브 객체에서 제거됨.
- 반대로, 로컬 파일과 "마지막 적용된 구성" 모두에 없는 필드는 그대로 유지.
#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
- kubectl create deployment webapp --image=kodekloud/webapp-color --replica
- 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
- kubectl create deployment redis-deploy --image=redis --replicas=2 -n dev-
- 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
- kubectl run:
- Pod를 생성하는 명령어.
- --image: 컨테이너 이미지 지정.
- --replica=2 pod 2개 생성
- --port: 컨테이너가 사용하는 포트 지정.
- --expose=true: ClusterIP 서비스를 자동으로 생성.
- kubectl expose:
- 기존 리소스(Pod, Deployment 등)를 노출시키는 서비스 생성 명령어.
- --type=ClusterIP: 서비스 타입 지정.
- --port: 서비스가 노출할 포트.
반응형