[Infra] kubernetes 간단 정리 (1)
회사에서 쿠버네티스를 쓴다고 해서 저번에 팀리더와 간단한 실습을 했다.
하라는 대로 따라하면서도 대체 무슨 일이 일어나고 있는 건지 감이 잘 잡히지 않았다.. 🥹
마침 시간적 여유가 생겨 간단하게라도 정리해보려고 한다. 진짜 간단함. 완전 입문용.
쿠버네티스란
컨테이너 관리 툴. 좀 더 정확히는, 컨테이너를 쉽고 빠르게 배포, 확장하고 관리를 자동화해주는 오픈소스 플랫폼이다.
컨테이너 관리 툴은 쿠버네티스 이전에도 많이 있었지만(Docker의 스웜, AWS의 ECS, 하시코프의 Nomad, Mesos의 Marathon 등)
쿠버네티스 스펙과 기능이 넘 좋아서 등장 이후로 사실상 일인자가 된 듯 하다.
쿠버네티스를 쓰면 뭐가 좋을까?
1) 모니터링이 쉬워진다
컨테이너가 여러 개 있는데, 그 중 하나의 컨테이너가 죽었다고 해보자.
일반적으론 유저의 제보, 혹은 상태를 볼 수 있는 대시보드 등으로 죽었다는 걸 알게 된 후, 수동으로 컨테이너를 다시 켜야 했다.
쿠버네티스의 경우, 모니터링을 통해 최소 5개의 컨테이너들 상태를 상시로 체크하고 있으며, 컨테이너가 죽으면 자동으로 다시 켜주는 기능(self-healing) 또한 제공한다.
2) 유저 수에 따른 확장이 용이해진다
서비스 첫 개시, 프로모션과 같은 이유로 서비스에 유저가 갑자기 몰릴 때가 있다. 이 경우 서버가 트래픽을 감당하지 못해 터질 수도 있기 때문에 스케일 업아웃, 인프라 재구성 등을 이용해 트래픽과 상관없이 안정적인 서비스를 제공해야 한다. 당연히 수동이라 별안간 새벽에 개발자가 불타는 일이 생기기도 한다.
쿠버네티스는 웹 니즈에 맞춰 컨테이너 수를 자동으로!! 맞춘다. 유저가 늘어나면 새 컨테이너를 만들어주고, 유저가 줄어들면 컨테이너 수를 줄인다. 서비스 제공에 필요한 최소 컨테이너 수만 지정해 준다면 알아서 유동적으로 컨테이너 확장 관리를 한다.
3) 서비스 중단 없이 업데이트가 가능하다
클라우드에 컨테이너가 여러 개 있다고 해보자. 업데이트를 해야 할 일이 생기면 먼저 모든 컨테이너를 끄고 업데이트를 시킨 후, 다시 켜야한다. 같은 말인 즉슨 아무리 업데이트를 빨린 한들 서비스가 다운되는 시간이 있다는 걸 감내해야 한다.
쿠버네티스를 쓰면 컨테이너 각각을 차례대로 업데이트를 해주기 때문에 서비스가 꺼지는 일 없이 안정적으로 사용할 수 있다.
4) 이것 외에도...
저장소 자동 탑재, 자동 롤아웃과 롤백, 자동 빈패킹, 시크릿키 관리 등 다양한 기능을 제공한다.
결론적으로, 쿠버네티스는 컨테이너를 많이 사용하는 환경에서 안정적으로 서비스를 업데이트하고 유지하고 싶을 때 유용한 툴이다. 사이드 프로젝트처럼 작은 서비스를 운용할 때(인스턴스가 하나라던가 유저풀이 작다던가)는 굳이 적용할 필요는 없다!
쿠버네티스는 어떻게 이루어져 있는걸까?
일단 컨테이너 자동 관리 플랫폼인 만큼, 컨테이너에 대해 알아야 한다. 컨테이너에 대한 설명은 44Bits 블로그의 게시물에서 친절하고 자세하게 써놨다. 그 외에 쿠버네티스를 이해하는데 필요한 개념들을 KANDAN하게 설명해보도록 노력하겠다.
0 .클러스터 Cluster
컨테이너 형태의 애플리케이션을 호스팅하는 물리/가상 환경의 노드들로 이루어진 집합.
컨트롤 플레인(마스터)를 설치한 이후 노드들을 설치해 컨트롤 플레인에 연결을 했을 때 클러스터를 하나 만들었다고 얘기를 한다.
(+) 컨트롤 플레인과 노드는 실제 물리적인 서버다. 클러스터는 추상적인 개념. 울타리라고 생각하면 편하다.
1. 컨트롤 플레인 Control Plane = Master
쿠버네티스의 메인 기능을 담당하는 시스템.
클러스터 전체를 컨트롤할 수 있기에 관리자만 접속할 수 있도록 보안 설정을 해야 한다.
확장성을 고려해 기능 별로 쪼개져 있어 API 서버, 스케줄러, 컨트롤러 매니저, etcd로 구성되어 있다.
1-1. API 서버 kube-apiserver
쿠버네티스의 기능을 REST API로 제공하고 그에 대한 명령을 처리하는 시스템.
쿠버네티스는 모든 명령과 통신을 API를 통해 하는데, 개발자 또한 API 서버를 통해 쿠버네티스와 통신할 수 있다.
kubectl 요청 뿐만 아니라 내부 모듈 요청도 처리해 권한을 체크하여 요청을 거부할 수 있다.
노드에서 실행중인 컨테이너의 로그를 보여주고 명령을 보내는 등 디버거 역할도 수행한다.
1-2. 스케줄러 kube-scheduler
Pod, 서비스 등 각 리소스들을 적절한 노드에 할당하는 시스템.
1-3. 컨트롤러 매니저 kube-controller-manager
컨트롤러를 생성하고 이를 각 노드에 배포하며 이를 관리하는 역할을 한다.
Replica 컨트롤러, Service 컨트롤러, Volume 컨트롤러, Node 컨트롤러 등을 생성한다.
2. 노드 node = Compute machine
컨트롤 플레인에게 명령을 받아 실제 워크로드를 생성하여 서비스를 하는 컴포넌트.
실제 컨테이너들이 생성되는 곳으로 확장이 거의 무제한급으로 된다. 컨테이너무제한제공거짓말사건
각 서버에 라벨을 붙여 사용 목적을 정의할 수 있다.
노드에는 kubelet, kube-proxy, 컨테이너 런타임 엔진이 배포된다.
2-1. kubelet
노드에 배포되는 에이전트.
API 서버와 통신하면서 노드가 수행해야 할 명령을 받아 수행하고,
반대로 노드의 상태 등을 컨트롤 플레인에 전달하는 역할.
컨트롤 플레인과 노드 사이의 매개체라 보면 된다.
2-2. kube-proxy
노드로 들어오는 네트워크 트래픽, 통신을 관리하는 역할.
트래픽을 적절한 컨테이너로 라우팅하고, 로드밸런싱 등 노드로 오고가는 트래픽을 프록시하고, 노드와 컨트롤 플레인 간의 네트워크 통신을 담당하고 있다.
2-3. 컨테이너 런타임 엔진 Container runtime
포드를 통해 배포된 컨테이너를 실행하는 역할.
도커 컨테이너라 생각하면 된다. 물론 도커 이외에도 krt, Hyper container 등 다양한 런타임이 존재한다.
2-3-0. 포드 Pod
쿠버네티스에서 가장 작은 배포 단위. 애플리케이션의 단일 인스턴스.
각 포드마다 고유한 IP를 할당받으며 하나 또는 연관된 일련의 컨테이너들로 구성되어 있다.
영구저장소에 연결해 stateful 애플리케이션을 실행할 수 있다.
아래 두 개는 클러스터에 속하진 않으나 인프라를 구성할 때 필요한 요소들이다.
영구저장소 Persistant storage
데이터베이스.
쿠버네티스를 사용하면 저장소 인프라에 관한 정보를 몰라도 리소스 요청을 할 수 있다.
Persistant Volume 아님!
컨테이너 레지스트리 Container registry
쿠버네티스에서 사용하는 컨테이너 이미지들이 저장되는 곳.
직접 구성하거나 외부에서 구성할 수 있다.
쿠버네티스 단점?
러닝 커브가 높다. 기본 개념 이해가 어렵고 구조가 복잡하기도 하다.
한글 공식 문서가 있지만 말 자체가 어렵게 되어있어 이해가 어렵다. 🙃
게다가 처음 사용해야 할 때 설정해야 할 YAML 파일도 많고 클러스터 만들기도 생각보다 어렵다. 🥲
그래도 k9s(UI 제공), argo cd(대시보드 제공), helm(패키지 매니저) 등등 관리형 서비스와 플러그인을 사용하면 보다 편하게 사용할 수 있을 것 같다.
(+) 사실 앞서 말한 예시들은 회사에서 쓰고 있는 거라ㅎㅎ 이것들도 따로 정리해볼 예정이다. 😇
다음 게시물에선 쿠버네티스를 사용하는 방법(아마도)에 대해 작성해볼거다 ^ㅡ^
어렵긴 한데 실습으로 배포를 한번 해보니까 편하고 좋다.
참고자료
https://subicura.com/2019/05/19/kubernetes-basic-1.html
https://www.redhat.com/ko/topics/containers/kubernetes-architecture
https://velog.io/@hidaehyunlee/쿠버네티스-아키텍처-2.-오브젝트-Objects
https://kubernetes.io/ko/docs/concepts/overview/what-is-kubernetes/