Kubernetes 객체 관리

Kubernetes 객체 관리 (object-management)

kubectl이라는 커맨드라인 도구는 Kubernetes 객체를 만들고 관리하는 여러 방법을 지원해요. 이 문서는 그 방법들의 큰 그림을 설명해 줍니다. kubectl로 객체를 관리하는 세부 내용은 Kubectl 책에서 더 자세히 볼 수 있어요.

관리 기법

경고:

Kubernetes 객체는 한 가지 기법으로만 관리해야 해요. 같은 객체에 여러 기법을 섞어 쓰면 동작이 정의되지 않은 상태가 돼 버립니다.

명령형 커맨드

명령형 커맨드를 쓸 때는 클러스터에 있는 라이브 객체를 직접 다루게 돼요. 사용자가 작업 내용을 kubectl 커맨드의 인자나 플래그로 넘겨주는 방식이죠.

이 방식은 처음 시작할 때나 클러스터에서 일회성 작업을 실행할 때 권장돼요. 라이브 객체를 직접 다루기 때문에 이전 구성에 대한 기록은 남지 않는다는 특징이 있어요.

예시

Deployment 객체를 만들어서 nginx 컨테이너의 인스턴스를 하나 실행해 볼게요.

kubectl create deployment nginx --image nginx

장단점

객체 구성 방식과 비교한 장점은 이래요.

• 커맨드가 하나의 동작 단어로 표현돼요.
• 클러스터를 변경하는 데 한 단계만 거치면 돼요.

반대로 단점도 있어요.

• 커맨드는 변경 검토 프로세스와 연동되지 않아요.
• 변경과 연결된 감사(audit) 기록이 남지 않아요.
• 라이브 상태 외에는 별도의 기록 원천이 없어요.
• 새 객체를 만들기 위한 템플릿이 되지 않아요.

명령형 객체 구성

명령형 객체 구성에서는 kubectl 커맨드가 작업(create, replace 등)과 선택적인 플래그, 그리고 파일 이름을 최소 하나 지정해요. 지정한 파일에는 객체의 전체 정의가 YAML 또는 JSON 형식으로 들어 있어야 해요.

객체 정의에 대한 자세한 내용은 API 레퍼런스를 참고하세요.

경고:

명령형 replace 커맨드는 기존 spec을 새로 제공된 spec으로 통째로 교체해요. 그래서 구성 파일에 빠져 있는 객체의 변경 사항은 모두 사라져 버려요. spec이 구성 파일과 별도로 업데이트되는 리소스 유형에는 이 방식을 쓰면 안 돼요. 예를 들어 LoadBalancer 타입의 Service는 externalIPs 필드가 구성과 별개로 클러스터에 의해 업데이트되죠.

예시

구성 파일에 정의된 객체를 만들려면 이렇게 해요.

kubectl create -f nginx.yaml

두 개의 구성 파일에 정의된 객체를 삭제하려면 이렇게 해요.

kubectl delete -f nginx.yaml -f redis.yaml

라이브 구성을 덮어써서 구성 파일에 정의된 객체를 업데이트하려면 이렇게 해요.

kubectl replace -f nginx.yaml