쿠버네티스(Kubernetes, K8S): #1 들어가기

쿠버네티스는 그리스어로 조타 장치 또는 선박 조종사를 뜻한다.

배경

현재 하고있는일, 그리고 관심 분야가 데브옵스 관련 이다보니 쿠버네티스라는 것에 대해 많이 접하게 되었다.

컨퍼런스에 참여하거나 업무를 통해서나 쿠버네티스를 접하게 될때면 공부를 해봐야겠다 라는 생각을 많이 하였고 서적도 구매했지만, 차일 피일 미루어 왔었다.

하지만 빠른 시일내에 팀에서 만든 솔루션을 쿠버네티스 위에서 운영해야하는 준비를 해야했고, 또한 해당 솔루션의 배포(Delivery) 목적지가 쿠버네티스인 것을 준비해야했다.

이를 계기로 쿠버네티스 자체에 대한 공부를 시작하게 되었다.

 

1. 쿠버네티스란 무엇인가?

쿠버네티스(Kubernetes, 약어로 K8S)를 한 문장으로 설명하자면 컨테이너 기반 어플리케이션의 배포, 확장, 관리를 조율하는 플랫폼이다.

즉 컨테이너 기반 운영환경에서 컨테이너를 적절한 곳에 배포해주는 스케줄링 역할과 컨테이너가 정상적으로 동작하도록 관리해주는 역할을 하는 솔루션이다.

출처: https://www.zdnet.co.kr/view/?no=20180109152442

이러한 역할을 해주는 솔루션 또는 플랫폼을 컨테이너 오케스트레이션(Container Orchestration)이라 부른다.

컨테이너 오케스트레이션은 Docker Swarm, Mesosphere 등이 있지만, 아래 그래프에서 확인할수 있듯이 쿠버네티스가 확실한 리더로 굳혀지고 있는 듯 하다.

출처: https://bcho.tistory.com/1255

구글은 일찍이 컨테이너 기반 운영환경을 사용하였고 이를 위해 보그(Borg, 이후 오메가(Omega)로 변경)라는 내부 시스템을 개발해 사용하였다. 2014년 보그, 오메가, 그 밖의 내부 시스템을 통합하여 오픈소스 시스템으로 출시한 것이 '쿠버네티스'이다.

구글은 'Cloud Native Computing Foundation(CNCF)' 라는 컨테이너 자체 보다는 컨테이너에 담긴 Workload 관리 방안에 초점을 맞춘 재단을 만들었고, 이 CNCF에서 쿠버네티스를 주관(관리,운영)하고 있다.

2. 왜 쿠버네티스가 필요한 것일까?

쿠버네티스가 필요해진 이유와 많이 쓰이고 있는 이유는 DevOps 문화의 확산, 컨테이너 기술의 발전, 클라우드 기술의 발전 등 여러가지 엮여있는 이유들이 있지만 결정적인 이유는 마이크로서비스 아키텍처로의 전환과 확산이라고 생각한다.

마이크로서비스 아키텍처(Microservices Architecture)로의 전환

대부분의 레거시 시스템은 모놀리식 아키텍처(Monolithic Architecture) 스타일로 구현된 시스템이었다. 모놀리식 아키텍처는 한 통(어플리케이션)에 모든 기능(로직)이 들어가 있는 형태이다. 이러한 구성이 장점도 있지만 개발, 배포, 운영에서여러 단점이 있었고 결정적으로 이러한 단점들에 의해 급변하는 비즈니스를 충족하기 어려움이 있었다. 그래서 나온것이 마이크로서비스 아키텍처(MSA)이다. 

출처: https://www.redhat.com/ko/topics/microservices/what-are-microservices

마이크로서비스 아키텍처(MSA)는 모놀리식 어플리케이션을 마이크로서비스라는 독립적으로 배포 가능한 더 작은 단위로 쪼개어서 한 통에 담겨 있던것을 기능 등의 기준을 통해 여러통에 나눠담는것이다.

쇼핑몰 서비스를 예로 들자면, 모놀리식은 한 어플리케이션에 회원가입, 상품 정보, 리뷰 등의 모든 기능이 들어있는 것이고 마이크로서비스는 회원가입, 상품 정보, 리뷰 등의 기능이 각각의 어플리케이션으로 나뉘어져있는 형태이다.

*Microservice Architecture 에 대한 자세한 공부 및 정리는 추후 하도록 하겠다.

이러한 MSA 는 모놀리식의 단점을 해결하는 장점들을 갖고 있지만, 잘개 쪼개면 쪼갤수록 관리 포인트가 늘어나는 단점을 갖고 있다.

배포 가능한 구성 요소의 수가 증가하고 전체 시스템의 규모는 증가하면서 이를 원할하게 구성, 관리 유지하는것은 점점 어려워졌다.

이를 해결하기 위해 등장한 것이 쿠버네티스 이다.

쿠버네티스는 서버의 구성 요소를 자동으로 스케줄링하고, 자동으로 구성하고, 자동으로 오류를 처리 가능하게 한다.

 

3. 쿠버네티스 클러스터 아키텍처

*클러스터란 원래 '포도송이'를 말하며 집단이나 군집을 의미한다. 이를 전산분야로 옮겨오면 독립적으로 수행가능한 것(컴퓨터)이 연결되어 하나의 시스템처럼 동작하는 집합을 말한다.

출처: https://futurecreator.github.io/2019/02/25/kubernetes-cluster-on-google-compute-engine-for-developers/

쿠버네티스 클러스터는 크게 Control Plane(Master node) 와 Worker node로 구성되어 있다.

Control Plane (Master node)

마스터 노드는 클러스터를 관리하고 기능을 실행하는 역할을 한다. 

마스터 컴포넌트는 단일 호스트에 설정하는 것이 일반적이나, 고가용성 시나리오나 대규모 클러스터를 고려할 경우 이중화 될수있다.

마스터 노드의 구성요소는 다음과 같다.

• API서버: 쿠버네티스는 모든 명령, 통신을 API를 통해서 한다.이러한 처리를 담당하는 구성요소이다. API 서버는 모든 데이터를 etcd에 저장하므로 수평으로 확장이 가능하다.
• etcd:쿠버네티스 클러스터의 데이터 베이스 역할을 하는 요소로서 설정값이나 클러스터의 상태를 저장한다. 대규모 클러스터의 경우 이중화 고가용성을 위해 3~5개 노드의 etcd 클러스터를 갖기도 한다.
• 스케줄러: Pod, 서비스등의 리소스를 적절한 노드에 할당하는 역할을 한다.
• 컨트롤러 매니저:API를 사용해 클러스터의 상태를 감시하고, 클러스터를 원하는 상태로 조정하는 역할을 한다. 복제 컨트롤러, 포드 컨트롤러, 서비스 컨트롤러, 엔드포인트 컨트롤러 등의 다양한 매니저를 하나의 바이너리로 통합한 도구이다.

Worker node

워커 노드는 컨테이너화된 어플리케이션을 실행하는 시스템이다. 서비스를 실행, 모니터링, 제공하는 작업은 다음과 같은 구성 요소로 실행된다.

• Kubelet:노드에 배포되는 에이전트로 마스터의 API 서버와 통신하며 노드가 수행해야 할 명령을 받아 수행하고, 노드의 상태를 마스터로 전달하는 역할을 한다.
• Kube-proxy: 각 노드에서 트래픽을 적절한 컨테이너로 라우팅하는 등의 저수준의 네트워크 관리 업무를 수행한다.
• 컨트롤러 런타임(컨테이너 런타임): Pod를 통해 배포된 컨테이너를 실행하는 컨테이너 런타임. 런타임에는 도커, rkt, Hyper container 등 다양한 런타임이 있다. *runtime: 실행되고 있는 때 존재하는 곳, 구동되는 환경