[k8s] 매니징 쿠버네티스 - 쿠버네티스 API

쿠버네티스 API

• HTTP 및 JSON 기반의 RESTful API
• k8s의 모든 구성 요소는 API를 이용해 통신함

쿠버네티스 API는 항상 개발되고 있지만 핵심 오브젝트는 오랜 기간 안정적이었다. 그래서 이번에는 핵심 오브젝트들을 정리해 보고자 한다.

기본 오브젝트

파드 (pod)

클러스터 스케쥴링에서 가장 작은 원자(atomic) 단위로, 하나 이상의 실행 중인 컨테이너로 구성된다.

파드가 원자 단위라는 의미는, 파드 안의 모든 컨테이너가 클러스터에서 동일한 자원을 공유한다는 것을 보장한다는 의미이다.

파드는 배포, 실행의 단위가 아니고, 스케일링과 복제(replication)의 단위이다.

레플리카셋 (replicaSet)

replica는 복제품이라는 의미이다, replicaSet은 복제품을 관리하는 것으로 예측해 볼 수 있다.

컨테이너 오케스트레이터를 사용하는 이유는 개별 컨테이너를 실행하기 위한 것이 아니다.

개별 컨테이너가 고장나거나 시스템의 부하를 처리할 수 없는 경우에도 서비스의 완전한 중단이나 실패 없이 운영하고 싶은 것이다.

또한 수평적 확장(scale out)에 따른 부하에 대응하여 확장하고 싶을 수도 있을 것이다.

이런 종류의 확장을 위해서 ReplicaSet을 제공한다.

주어진 Pod 정의에서 시스템에 여러 개의 레플리카(복제품)가 존재함을 보장한다.

즉, 레플리카셋 오브젝트를 사용하면, 여러개의 레플리카의 존재를 보장한다.

서비스 (Service)

ReplicaSet을 사용해 애플리케이션을 복제했다면, 이 여러 개의 레플리카에 트래픽을 분산할 필요가 있다.

이러한 트래픽 분산을 위한 로드 밸런서 장치를 만들 필요가 있는데, 이것을 Service라는 오브젝트로 제공한다.

서비스는 다음과 같은 속성이 있다.

• 자체 IP 주소
• 가상의 고정 IP 주소, 해당 서비스를 구현하는 파드 집합으로 로드 밸런스된다.
• 쿠버네티스 클러스터 DNS 항목
• 같은 클러스터의 다른 컨테이너가 서비스 로드 밸런서의 IP 주소를 검색할 수 있게 한다.
• 파드로 트래픽을 프록시하는 로드 밸런싱 규칙
• 해당 서비스와 통신하려고 시도하는 컨테이너가 적절한 파드에 올바르게 로드 밸런싱 될 수 있도록 하는 규칙을 가지고 있다.

사용자는 서비스를 구현하는 파드에 대한 서비스 IP 주소 연결을 신뢰할 수 있도록 보장한다.

볼륨 (Volume)

컨테이너가 클러스터 안을 드나들고, 서로 다른 시스템에 상주하는 이 상황에서 컨테이너와 파일, 스토리지를 어떻게 관리해야 하는가?

초기에는 파드 API의 일부로 볼륨 집합을 정의할 수 있었다.

볼륨을 연결(mount)하도록 선택했다.

이렇게 하면, 실행 중인 컨테이너가 볼륨 내의 스토리지에 접근할 수 있다.

만약 레플리카 마다 다른 볼륨을 사용해야 한다면? 구체적인 제공자를 지정하지 않고 일반적인 스토리지를 요청하는 경우라면?

이를 위해서 PersistentVolumes, PersistentVolumesClaims를 도입하였다.

클러스터 구성 오브젝트

오브젝트를 쉽게 만들 수 있지만, 동시에 오브젝트가 많아지며 클러스터 운영에 어려움을 가져오게 된다.

이러한 복잡성을 해결하고, 오브젝트 관리, 쿼리, 추론을 쉽게 수행 할 수 있게 도와주는 오브젝트를 소개한다.

네임스페이스

오브젝트를 위한 폴더라고 생각할 수 있다.

역할 기반 접근 제어 규칙(RBAC)의 범위를 제공할 수도 있다.

레이블 (label)

레이블은 오브젝트를 식별하는 데 도움이 되는 문자열 키/값 쌍.

어노테이션 (annotation)

오브젝트에 할당된 메타데이터, 단순한 주석 처럼 사용도 가능

고급 오브젝트

더 전문적인 유스 케이스에 맞게 추가된 오브젝트들.

디플로이먼트 (Deployment)

ReplicaSet은 동일한 컨테이너 이미지의 여러 레플리카를 실행하기 위한 기본 요소이다.

하지만, 실제로 애플리케이션은 항상 변경된다. 즉 버전 업, 다운이 필요한 상황이 온다는 것.

Deployment 오브젝트는 버전 간의 안전한 롤아웃을 위해서 추가되었다.

실제로 대부분의 유저는 ReplicaSet을 직접 관리하기 보다 Deployment를 단독으로 사용하는 추세이다.

인그레스 (Ingress)

경로 및 호스트 기반 HTTP 로드 밸런서와 라우터

Ingress가 HTTP 요청 내용을 사용하여 다른 Service로 라우팅 할 수 있게 한다.

스테이트풀셋 (StatefulSets)

ReplicaSet은 각각의 레플리카에 대해서 순서를 보장하지 않고, 차이를 식별하지 않는다.

반면 스테이트풀셋은 다음과 같은 것을 보장하는 ReplicaSet처럼 이해할 수 있다.

• 레플리카가 단조롭게 증가하는 색인으로 생성된다. (ex. backend-0, backend-1 ...)
• 레플리카 1이 생성되기 전에 레플리카 0이 생성되어 정상적이라는 것을 보장한다.
• 레플리카 갯수를 조정할 경우, 가장 높은 인덱스의 레플리카 먼저 제거된다.

배치 워크로드

배치, 일회성 워크로드로, 지속해서 트래픽을 제공하지 않고, 계산을 수행하고 계산이 완료되면 파기된다.

Job, CronJobs