쿠버네티스(Kubernetes)란?

쿠버네티스란?

---

쿠버네티스는 컨테이너를 쉽고 빠르게 배포,확장하고 관리해주는 오픈 소스 플랫폼 입니다.

구글에 의해 처음 설게되었고 현재는 리눅스 재단에서 관리되고 있습니다.

갓 구글..

k8s라고도 불리웁니다. 왜냐구요? 별거 없습니다 앞글자k 중간글자가 8글자 마지막글자s 를 땄다고 합니다.

키포인트는 컨테이너 관리, 배포/확장, 오픈소스 라는 것입니다.

k8s를 이해하고자 한다면 컨테이너가 뭔지부터 알아야합니다.

컨테이너는 가상화 기술중 하나입니다. 아래 그림의 가장 오른쪽이 컨테이너의 구조입니다.

기존 호스트 가상화 하이퍼바이저 가상화는 가상화 소프트웨어를 통해 OS와 하이퍼 바이저 위에서 또 다른 OS를 여러 개 구동시키며 그자체로 많은 리소스를 필요로 합니다.

따라서 호스트OS상에서 논리적으로 구역(컨테이너)을 나누어 어플리케이션동작을 위한 라이브러리와 어플리케이션 등을 그 안에 넣고, 개별 서버 처럼 사용하는 것이 컨테이너 가상화입니다.

컨테이너 가상화는 오버헤드가 적어 가볍고 빠른것이 가장 큰 특징입니다.

이렇게 가상화 기술이 컨테이너 가상화로 바뀌고 있습니다. 그러면 이 컨테이너를 어떻게 관리할 것인가? 가 이슈가 되었고 이를 구글에서 쿠버네티스라는 플랫폼을 만들어 해결하였죠.

컨테이너 관리가 왜 필요한가요?

예를들면 잘 돌아가고 있는 컨테이너가 갑자기 죽어버리면, 새로 살려야 하겠죠. 그럼 어떻게 다시 살리지?(배포하지?)가 이슈가 되겠죠

또는, 갑작스러운 서비스 증가로 새로운 컨테이너가 필요해 그럼 어떻게 컨테이너를 확장하지?가 이슈가 되는 것입니다.

~ 이것이 k8s가 필요한 가장 큰 이유입니다. ~

쿠버네티스(k8s)는 어떻게 컨테이너를 관리할까요?

k8s는 애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공합니다. 바로 아래와 같이 말이죠.
아래 자료는 쿠버네티스 공식 문서를(https://kubernetes.io/ko/docs/concepts/overview/what-is-kubernetes/) 발췌 하였습니다.

• 서비스 디스커버리와 로드 밸런싱
  쿠버네티스는 DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있다. 컨테이너에 대한 트래픽이 많으면, 쿠버네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 배포가 안정적으로 이루어질 수 있다.
• 스토리지 오케스트레이션
  쿠버네티스를 사용하면 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재 할 수 있다.
• 자동화된 롤아웃과 롤백
  쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있다. 예를 들어 쿠버네티스를 자동화해서 배포용 새 컨테이너를 만들고, 기존 컨테이너를 제거하고, 모든 리소스를 새 컨테이너에 적용할 수 있다.
• 자동화된 빈 패킹(bin packing)
  컨테이너화된 작업을 실행하는데 사용할 수 있는 쿠버네티스 클러스터 노드를 제공한다. 각 컨테이너가 필요로 하는 CPU와 메모리(RAM)를 쿠버네티스에게 지시한다. 쿠버네티스는 컨테이너를 노드에 맞추어서 리소스를 가장 잘 사용할 수 있도록 해준다.
• 자동화된 복구(self-healing)
  쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, ‘사용자 정의 상태 검사’에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.
• 시크릿과 구성 관리
  쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 비밀을 노출하지 않고도 비밀 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다.

"뭐.. 뭔진 자세히 모르겠지만 대단히 많은 것들을 해주고 있죠??
k8s가 이런 것들을 통해서 컨테이너를 관리해주는 좋은 플랫폼이다. 정도만 보시면 될 것 같습니다."

그럼 조금 깊게 들어가서 쿠버네티스가 어떻게 구성되어있는지 살펴보겠습니다.

쿠버네티스의 아키텍처

k8s는 클러스터 단위로 동작합니다. 음..그러니까 여러개의 작업 그룹단위로 동작한다고 생각하시면 됩니다.

이 클러스터는 크게 마스터, 노드 로 구성됩니다. 위 그림에 보시면 왼쪽이 마스터 오른쪽이 노드 입니다. (노드를 초기에는 미니언, minion 이라고 불리었다고 하네요)

• 마스터
  • 마스터는 클러스터를 관리하는 역할을 합니다.
  • 그래서 마스터에는 클러스터를 관리하는 역할인 etcd, kube-apiserver, kube-scheduler, kube-controller-manager 이런 애들을 갖고 있습니다.
• 노드
  • 노드는 컨테이너가 실행되는 곳입니다.
  • kubelet, kube-proxy, docker 이런애들을 갖고 있죠.

그럼 그림을 좀더 자세 살펴 볼까요?

마스터의 구성

• kube-apiserver
  마스터 중심에 kube-apiserver가 있습니다.이 apiserver를 통해 다른 프로세스들이 서로 필요한 정보를 주고 받습니다.
  k8s는 이 api서버를 통해 모든 기능들을 REST API로 제공하고 그에 대한 명령을 처리합니다.
• etcd
  그림에서 보시면 원통 모양이죠? 보통 데이터 저장소를 그릴때 저렇게 많이 그리죠. etcd는 분산형 키/밸류 저장소 입니다. k8s 클러스터의 데이타 베이스 역할을 합니다. 서버의 정값이나 클러스터의 상태를 저장하는 역할을 합니다.
• 스케쥴러
  스케쥴러는 k8s의 리소스들을 적절한 노드에 할당하는 역할을 합니다.

• 컨트롤러 매니져
  컨트롤러 매니저는 컨트롤러(Replica controller, Service controller, Volume Controller, Node controller 등)를 생성하고 이를 각 노드에 배포하며 이를 관리하는 역할을 한다.
• DNS
  k8s는 리소스의 엔드포인트(Endpoint)를 DNS로 맵핑하여 관리합니다. Pod나 서비스, 그러니까 실제 사용할 리소스들은 각각 IP를 배정받는데, 동적으로 IP가 생성 될때 마다 IP가 달라지게 됩니다. 그래서 그 리소스에 대한 위치 정보가 필요합니다.
  이러한 패턴을 Service discovery 패턴이라고 합니다. 쿠버네티스에서는 이를 내부 DNS서버를 두어 동적으로 생성되는 IP를 관리할 수 있도록 하였습니다.노드의 구성
•  
• 노드는 마스터에 의해 명령을 받고 실제 워크로드를 생성하여 서비스 하는 단위 입니다. 노드에는 Kubelet, Kube-proxy,cAdvisor 그리고 컨테이너 런타임이 배포됩니다.
• Kubelet
  마스터의 API서버와 통신을 하면서, 노드가 수행해야 할 명령을 받아서 수행하고, 반대로 노드의 상태를 마스터로 전달하는 역할을 합니다. 마스터와 직접적으로 통신하는 주체라고 보면됩니다.
• Kube-proxy
  노드와 마스터간의 네트워크 통신을 관리합니다. 네트워크 느래픽을 적절한 컨테이너로 라우팅하고, 로드밸런싱, 프록시 처리를 담당합니다.
• Container runtime
  컨테이너는 Pod라는 것에 의해 배포됩니다. 이렇게 배포된 컨테이너를 실행하는 것이 컨테이너 런타임 입니다.
• cAdvisor
  cAdvisor는 모니터링 에이전트로 각 노드내에서 가동되는 컨테이너들의 상태와 성능등의 정보를 수집하여, 마스터 서버의 API 서버로 전달 하는 역할을 합니다.

여기까지 쿠버네티스에 대해 알아보았습니다. 개인적으로도 다시한번 정리할 수 있었습니다.
public 클라우드 업무를 담당하면서 구글 쿠버네티스 클러스터나 AWS의 EKS를 사용하다보니 실제로 마스터가 어떻게 구성되어 있는지는 관심도 없었습니다.

ingress, pod, service만 알면 될 줄 알았는데, 쿠버네티스의 구조를 알고나니 앞으로 쿠버네티스를 사용할때 좀더 여러 측면에서 접근할 수 있을 거같습니다.

다음시간에는 AWS의 쿠버네티스 서비스인 EKS를 실제로 구축해보면서 ingress, pod, service가 뭔지 알아보겠습니다.

오늘은 여기까지 컷