Kubernetes의 객체
Kubernetes의 객체 (Objects In Kubernetes)
이 페이지는 Kubernetes 객체가 Kubernetes API에서 어떻게 표현되는지, 그리고 .yaml 형식으로 어떻게 표현하는지 설명해요.
출처: 문서
본문
Kubernetes 객체 이해하기
Kubernetes 객체는 Kubernetes 시스템의 영속적인 엔티티예요. Kubernetes는 이 엔티티들을 사용해 클러스터의 상태를 표현해요. 구체적으로 다음을 설명할 수 있어요.
- 어떤 컨테이너화된 애플리케이션이 실행 중인지(어느 노드에서)
- 그 애플리케이션에 가용한 리소스
- 재시작 정책, 업그레이드, 장애 허용성 같은 그 애플리케이션 동작에 관한 정책
Kubernetes 객체는 "의도 기록(record of intent)"이에요. 객체를 생성하면 Kubernetes 시스템은 그 객체가 존재하도록 끊임없이 작업해요. 객체를 생성함으로써 클러스터의 워크로드가 어떤 모습이었으면 하는지를 Kubernetes 시스템에 알리는 셈이며, 이게 클러스터의 원하는 상태(desired state) 예요.
Kubernetes 객체를 다루려면(생성, 수정, 삭제) Kubernetes API를 사용해야 해요. 예를 들어 kubectl 명령줄 인터페이스를 사용할 때, CLI가 필요한 Kubernetes API 호출을 대신 수행해요. 클라이언트 라이브러리 중 하나로 자체 프로그램에서 Kubernetes API를 직접 사용할 수도 있어요.
객체 spec과 status
거의 모든 Kubernetes 객체는 객체의 구성을 주관하는 두 개의 중첩 객체 필드, 즉 객체 spec과 객체 status를 포함해요. spec이 있는 객체는 생성할 때 spec을 설정해야 해요. 리소스가 갖길 원하는 특성, 즉 원하는 상태에 대한 설명을 제공하는 거죠.
status는 객체의 현재 상태를 설명하며, Kubernetes 시스템과 그 컴포넌트가 제공·업데이트해요. Kubernetes 컨트롤 플레인은 모든 객체의 실제 상태를, 사용자가 제공한 원하는 상태와 일치시키도록 지속적이고 적극적으로 관리해요.
예를 들어 Kubernetes에서 Deployment는 클러스터에서 실행 중인 애플리케이션을 표현할 수 있는 객체예요. Deployment를 만들 때 애플리케이션의 복제본이 3개 실행되기를 원한다고 Deployment spec에 설정할 수 있어요. Kubernetes 시스템은 Deployment spec을 읽고 원하는 애플리케이션의 인스턴스 3개를 시작하고, status를 spec과 일치하도록 업데이트해요. 인스턴스 중 하나가 실패하면(상태 변경), Kubernetes 시스템은 spec과 status의 차이에 대응해 교정을 하는데, 이 경우에는 대체 인스턴스를 시작해요.
객체 spec, status, metadata에 대한 더 많은 정보는 Kubernetes API 관례를 참고해요.
Kubernetes 객체 설명하기
Kubernetes에서 객체를 만들 때는 객체의 원하는 상태를 설명하는 객체 spec과 객체에 대한 기본 정보(이름 등)를 제공해야 해요. Kubernetes API로 객체를 생성할 때(직접 또는 kubectl을 통해) 그 API 요청은 요청 본문에 그 정보를 JSON으로 포함해야 해요. 대부분은 매니페스트(manifest) 라고 하는 파일로 kubectl에 정보를 제공해요. 관례상 매니페스트는 YAML이에요(JSON 형식도 사용 가능). kubectl 같은 도구는 HTTP로 API 요청을 할 때 매니페스트의 정보를 JSON이나 다른 지원되는 직렬화 형식으로 변환해요.
다음은 Kubernetes Deployment의 필수 필드와 객체 spec을 보여주는 예시 매니페스트예요.
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 2 # tells deployment to run 2 pods matching the template
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
위와 같은 매니페스트 파일로 Deployment를 만드는 한 가지 방법은 kubectl 명령줄 인터페이스에서 kubectl apply 명령을 사용하고 .yaml 파일을 인자로 전달하는 거예요. 예시:
kubectl apply -f https://k8s.io/examples/application/deployment.yaml
출력은 다음과 비슷해요.
deployment.apps/nginx-deployment created
필수 필드 (Required fields)
만들려는 Kubernetes 객체의 매니페스트(YAML 또는 JSON 파일)에서 다음 필드에 대한 값을 설정해야 해요.
apiVersion— 이 객체를 만들 때 사용하는 Kubernetes API 버전kind— 만들고 싶은 객체 종류metadata— 이름 문자열, UID, 선택적 네임스페이스를 포함해 객체를 고유하게 식별하는 데 도움이 되는 데이터spec— 객체에 대해 원하는 상태
객체 spec의 정확한 형식은 Kubernetes 객체마다 다르며, 그 객체에 특화된 중첩 필드를 포함해요. Kubernetes API 참조가 Kubernetes로 만들 수 있는 모든 객체의 spec 형식을 찾는 데 도움을 줘요.
예를 들어 Pod API 참조의 spec 필드를 참고해요. 각 파드에 대해 .spec 필드는 파드와 그 원하는 상태(그 파드 안 각 컨테이너의 컨테이너 이미지 이름 같은)를 지정해요.
객체 사양의 또 다른 예시는 StatefulSet API의 spec 필드예요. StatefulSet의 경우 .spec 필드는 StatefulSet과 그 원하는 상태를 지정해요. StatefulSet의 .spec 안에는 Pod 객체용 템플릿이 있어요. 그 템플릿은 StatefulSet 사양을 충족하기 위해 StatefulSet 컨트롤러가 생성할 파드를 설명해요.
서로 다른 종류의 객체는 서로 다른 .status를 가질 수도 있어요. 다시 말하지만 API 참조 페이지가 각 객체 유형의 .status 필드 구조와 내용을 자세히 설명해요.
YAML 구성 파일 작성에 대한 추가 정보는 Kubernetes 구성 모범 사례를 참고해요.
서버 측 필드 검증 (Server side field validation)
Kubernetes v1.25부터 API 서버는 객체의 인식되지 않는 필드나 중복 필드를 감지하는 서버 측 필드 검증을 제공해요. 서버 측에서 kubectl --validate의 모든 기능을 제공해요.
kubectl 도구는 --validate 플래그를 사용해 필드 검증 수준을 설정해요. ignore, warn, strict 값을 받아들이며 true(strict와 동일)와 false(ignore와 동일) 값도 받아들여요. kubectl의 기본 검증 설정은 --validate=true예요.
Strict— 엄격한 필드 검증, 검증 실패 시 오류Warn— 필드 검증은 수행하지만, 오류는 요청을 실패시키는 대신 경고로 노출Ignore— 서버 측 필드 검증 수행 안 함
kubectl이 필드 검증을 지원하는 API 서버에 연결할 수 없으면 클라이언트 측 검증을 사용하도록 폴백해요. Kubernetes 1.27 이상은 항상 필드 검증을 제공하지만, 이전 릴리스는 제공하지 않을 수 있어요. 클러스터가 v1.27보다 오래됐다면 사용 중인 Kubernetes 버전의 문서를 확인해요.
다음 단계
Kubernetes를 처음 접한다면 다음을 더 읽어보세요.
- 가장 중요한 기본 Kubernetes 객체인 파드
- Deployment 객체
- Kubernetes의 컨트롤러
- kubectl과 kubectl 명령
Kubernetes 객체 관리는 kubectl로 객체를 관리하는 방법을 설명해요. 아직 없으면 kubectl을 설치해야 할 수도 있어요.
일반적으로 Kubernetes API에 대해 배우려면 Kubernetes API 개요를 방문해요.
Kubernetes의 객체를 더 깊이 배우려면 이 섹션의 다른 페이지를 읽어보세요.