쿠버네티스란?
컨테이너화된 애플리케이션을 배포 및 관리하기 위한 오픈 소스 도구 (컨테이너 오케스트레이션)
무엇을 할 수 있나요?
-
배포 컨테이너로 컨테이너(서비스)를 여러 서버에 손쉽게 배포할 수 있습니다.
-
자동 스케일링을 지원합니다, 트래픽에 따라 자동으로 서버를 늘리거나 줄일 수 있습니다.
-
동일한 컨테이너를 여러 서버에 복제하여 하나의 서버에 장애가 발생해도 지속적인 서비스 운영이 가능합니다.
-
컨테이너의 장애가 발생하면 자동으로 롤백할 수 있어 안정성이 높습니다. (의도한 상태 특성)
한번 구성하면 스케일링을 마음대로 조절할 수 있다는 점, 컨테이너 배포가 쉽다는 점이 저에게는 큰 매력으로 다가왔습니다.
특성
쿠버네티스의 특징이 존재합니다. 바로 '의도한 상태' 라는 개념으로 컨테이너를 관리하는데요
저희가 원하는 상태(Desired State)를 변경하고 싶다면 계속하여 현재 상태(Current State)를 확인하여 비교하게 됩니다.
쿠버네티스 구조
마스터
클러스터 전체를 관리
- kube-apiserver
쿠버네티스 API를 사용할 수 있도록 하는 컴포넌트 입니다. API 서버는 쿠버네티스 클러스터로 온 요청을 검증하고, API 서버를 통해 다른 컴포넌트가 서로 필요한 정보를 주고받게 됩니다. - etcd
etcd는 쿠버네티스에서 필요한 모든 데이터를 Key-Value 형태로 저장하는 저장하는 데이터베이스 입니다. etcd는 서버 하나당 프로세스 1개만 사용할 수 있는데, 보통 etcd 자체를 클러스터링 한 후 여러 개 마스터 서버에 분산해서 실행해 안정성을 보장하도록 합니다.
kube-apiserver 서버만 접근이 가능합니다. - kube-scheduler
현재 클러스터 안에서 자원 할당이 가능한 노드를 선택해서 새로운 Pod를 실행합니다. 처음 Pod가 실행될 때 최소 할당 RAM 사이즈 같은 설정들을 할 수 있는데, 이러한 조건에 맞추어 알맞은 노드에 Pod를 실행시켜주는 자동화 작업해주게 됩니다. - kube-controller-manager
쿠버네티스의 Pod들을 관리하는 컨트롤러입니다. 컨트롤러 논리적으로 개별적인 프로세스로 동작하지만 모든 컨트롤러는 바이너리 파일로 컴파일해서 단일 프로세스로 실행합니다. - cloud-controller-manager
쿠버네티스의 컨트롤러들을 클라우드 서비스와 연결해서 관리하는 컴포넌트입니다.
노드
클러스터가 배포되는 물리적 머신
-
kubelet
클러스터 내부 속한 모든 노드에서 실행되는 에이전트입니다. PodSpec 설정을 전달받아서 Pod 컨테이너의 실행을 직접 관리하고 해당 컨테이너가 정상적으로 실행되는지 헬스 체크를 진행합니다. 참고로 노드 안에 컨테이너가 있더라도 해당 컨테이너가 쿠버네티스로 생성된 컨테이너가 아니면 관리대상이 아닙니다. -
kube-proxy
쿠버네티스는 클러스터 안에서 별도의 가상 네트워크를 생성하고 관리하게 되는데, kube-proxy는 이런 가상 네트워크의 동작을 관리하는 컴포넌트입니다. -
container runTime
실제로 컨테이너를 실행시키는 컴포넌트입니다. 거의 대부분은 도커지 않을까요?
오브젝트
기본 오브젝트, 오브젝트 컨트롤러, 오브젝트의 스펙들로 구성이 되어있습니다.
오브젝트는 spec 과 status 등의 값을 가지는데, 여기에는 오브젝트를 생성한 의도나 오브젝트를 관리할 때 원하는 상태 등을 설정합니다.
- 기본 오브젝트
- Pod : 쿠버네티스에서 실행되는 최소 단위. 독립적인 공간과 IP를 가집니다.
- Namespace : 쿠버네티스 클러스터에서 사용되는 리소소들을 구분해서 관리하는 그룹.
- Volume : Pod가 사라지더라도 데이터 저장/보존이 가능하며 Pod에서 사용할 수 있는 디렉터리를 제공.
- Service : Pod는 유동적이기 때문에 접속 정보가 고정되지 않으므로, Pod 접속을 안정적으로 유지하기 위한 기능
NameSpace로 개발 / 스테이징 / 운영 처럼 나눌 수도 있고 서비스 도메인에 따라 구분할 수도 있습니다.
Pod 생명주기
Pod의 생명주기는 kubelet 모니터링 합니다. kubectl get pods
- pending : 클러스터 내 Pod 생성이 승인되었지만 아직 내부의 컨테이너가 완전히 시작되기 전이며, 아직 노드에 배치되지 않은 상태
- running : Pod가 클러스터의 특정 노드에 배치완료되었으며, 내부의 모든 컨테이너가 생성 완료된 상태다. Pod 내부에 존재하는 컨테이너가 동작 중인 상태
- succeeded : Pod 안의 모든 컨테이너가 특정 작업을 정상적으로 마치고 종료된것을 의미
- failed : Pod 안의 컨테이너 중 하나 이상이 비정상 종료되었을 때 발생
그 외
- unknown : Pod의 상태 확인이 불가한 경우, 대부분 노드의 네트워크 문제로 발생 (생명주기가 아닌 상태입니다.)
- terminating : Pod 삭제할 경우, 일반적으로 Pod는 30초의 유예 시간 후에 완전히 삭제되며, 즉시 삭제를 원한다면
kubectl delete --force를 수행하면 됩니다. (생명주기가 아닌 상태입니다.)
느낀 점
개인공부 할 때는 쿠버네티스까지 구축할 규모가 안되서 개념만 알고있었는데
AWS EKS를 사용하면 편하게 쓸 수 있지만
저는 이 모든 것을 온프레미스 환경에서 전부 구성할 것 같아서
많은 공부와 삽질이 필요할 것 같습니다 ㅠㅠㅠㅠ
설계 및 구성할 때 우려되는 부분은 네트워크 부분에서 kube-proxy, namespace를 잘 조합해서 pod 끼리 잘 통신이 가능할지
Inbound, OutBound 제약을 걸 수 있는지 등등 좀 삽질할 것 같긴하네요.
일단 오늘은 쿠버네티스가 어떠한 특징과 왜 사용하는지 그리고 구조에 대해서만 좀 공부해보았고
쿠버네티스 설정 부터 ArgoCD, Service Mesh인 Istio 등등등등~~등은 추후 또 공부해 보려고 합니다.
쿠버네티스는 앞으로도 계속 공부 많이 할 예정입니다.
참고
