kubectl 커맨드라인 툴은 쿠버네티스 오브젝트를 생성하고 관리하기 위한
몇 가지 상이한 방법을 지원한다. 이 문서는 여러가지 접근법에 대한 개요를
제공한다. Kubectl로 오브젝트 관리하기에 대한 자세한 설명은
Kubectl 서적에서 확인한다.
| 관리기법 | 대상 | 권장 환경 | 지원하는 작업자 수 | 학습 난이도 |
|---|---|---|---|---|
| 명령형 커맨드 | 활성 오브젝트 | 개발 환경 | 1+ | 낮음 |
| 명령형 오브젝트 구성 | 개별 파일 | 프로덕션 환경 | 1 | 보통 |
| 선언형 오브젝트 구성 | 파일이 있는 디렉터리 | 프로덕션 환경 | 1+ | 높음 |
명령형 커맨드를 사용할 경우, 사용자는 클러스터 내 활성 오브젝트를 대상으로
직접 동작시킨다. 사용자는 실행할 작업을 인수 또는 플래그로 kubectl 커맨드에
지정한다.
이것은 클러스터에서 일회성 작업을 개시시키거나 동작시키기 위한 추천 방법이다. 이 기법은 활성 오브젝트를 대상으로 직접적인 영향을 미치기 때문에, 이전 구성에 대한 이력을 제공해 주지 않는다.
디플로이먼트 오브젝트를 생성하여 nginx 컨테이너의 인스턴스를 구동시킨다.
kubectl create deployment nginx --image nginx
오브젝트 구성에 비해 장점은 다음과 같다.
오브젝트 구성에 비해 단점은 다음과 같다.
명령형 오브젝트 구성에서는 kubectl 커맨드로 작업(생성, 교체 등), 선택적 플래그, 그리고 최소 하나의 파일 이름을 지정한다. 그 파일은 YAML 또는 JSON 형식으로 오브젝트의 완전한 정의를 포함해야만 한다.
오브젝트 정의에 대한 더 자세한 내용은 API 참조를 참고한다.
replace 커맨드는 기존 spec을 새로 제공된 spec으로 바꾸고
구성 파일에서 누락된 오브젝트의 모든 변경 사항을 삭제한다.
이 방법은 spec이 구성 파일과는 별개로 업데이트되는 리소스 유형에는
사용하지 말아야한다.
예를 들어 LoadBalancer 유형의 서비스는 클러스터의 구성과 별도로
externalIPs 필드가 업데이트된다.구성 파일에 정의된 오브젝트를 생성한다.
kubectl create -f nginx.yaml
두 개의 구성 파일에 정의된 오브젝트를 삭제한다.
kubectl delete -f nginx.yaml -f redis.yaml
활성 동작하는 구성을 덮어씀으로써 구성 파일에 정의된 오브젝트를 업데이트한다.
kubectl replace -f nginx.yaml
명령형 커맨드에 비해 장점은 다음과 같다.
명령형 커맨드에 비해 단점은 다음과 같다.
선언형 오브젝트 구성에 비해 장점은 다음과 같다.
선언형 오브젝트 구성에 비해 단점은 다음과 같다.
선언형 오브젝트 구성을 사용할 경우, 사용자는 로컬에 보관된 오브젝트
구성 파일을 대상으로 작동시키지만, 사용자는 파일에서 수행 할
작업을 정의하지 않는다. 생성, 업데이트, 그리고 삭제 작업은
kubectl에 의해 오브젝트마다 자동으로 감지된다. 이를 통해 다른 오브젝트에 대해
다른 조작이 필요할 수 있는 디렉터리에서 작업할 수 있다.
replace API를
사용하는 대신, patch API를 사용하여 인지되는 차이만
작성하기 때문에 가능하다.configs 디렉터리 내 모든 오브젝트 구성 파일을 처리하고 활성 오브젝트를
생성 또는 패치한다. 먼저 어떠한 변경이 이루어지게 될지 알아보기 위해 diff
하고 나서 적용할 수 있다.
kubectl diff -f configs/
kubectl apply -f configs/
재귀적으로 디렉터리를 처리한다.
kubectl diff -R -f configs/
kubectl apply -R -f configs/
명령형 오브젝트 구성에 비해 장점은 다음과 같다.
명령형 오브젝트 구성에 비해 단점은 다음과 같다.