쿠버네티스 이해하기

쿠버네티스는 DevOps와 같이 쓰이는데, 애플리케이션과 서비스를 빠른 속도로 제공할 수 있도록 조직의 역량을 향상 시키는 문화 철학, 방식 및 도구의 조합이다. -> DevOps
 
그렇기 때문에 DevOps는 쿠버네티스를 포함하고 있는 말이기 때문에, 결론은 더 빨리, 더 자주 실패없이 배포하자 가 쿠버네티스의 매커니즘이다.
 
먼저 쿠버네티스 공식 홈페이지에 들어가보자!
https://kubernetes.io/

들어가면 한국어도 지원이 된다. 
 
밑으로 내려보면 다음과 같은 글이 써져있다. 

쿠버네티스에서 제공해주는 기능들이라 볼 수 있다. 이중 몇가지 핵심에 대해 설명하려고 한다.
 
그 전에  쿠버네티스 버전에 대해 말하려고한다. 쿠버네티스 1.24버전을 기준으로 쿠버네티스가 많이 바뀌었다고 한다. 
1.24버전 전에는 도커엔진을 쓰도록 되어있는데, 그 이후로는 사용자가 원하는 컨테이너 엔진을 사용할 수 있도록 되어있다.
 
우리는 익숙한 도커를 사용하기 위해 1.23버전을 사용하려고한다. 
 
먼저 설명에 앞서 Controller Plain(마스터 노드) 1개와 Worker Node3개로 설명하려고한다. 
 
우리가 도커에서는 단위가 컨테이너 였다면 쿠버네티스에서는 배포의 단위를 Pod라고한다. Pod끼리는 내부에서 localhost로 통신이 가능하다. 
즉 어플리케이션을 독립적으로 배포하기 위해서 만든 것이 쿠버네티스다. (MSA 를 위한..)
MSA를 배포할 때는 One Pod One Container가 이상적이라고 한다.
즉, 한 파드에는 하나의 컨테이너가 제일 적합하다. 물론 하나의 파드에 여러개의 컨테이너가 올라갈 수는 있지만, 권장하진 않는다고 한다.
그 이유는 관리의 복잡성, 확장성 및 롤링 업데이트 롤백의 복잡성 때문이다.
 
 

Automatic bin packing

먼저 그림을 봐보자 왼쪽 부터 마스터 노드, 워커노드 3개가 있다.
마스터 노드를 살펴보면 3가지가 있다.
1. API Server 
2. Scheduler
3. Controller manager
먼저 API Server는 인증/인가를 진행한다. 대부분의 요청은 API Server로 들어온다고 생각하면 된다.
클러스터내의 리소스를 관리하고 클라이언트와 상호작용을 한다.
 
Scheduler는 새로운 파드를 배포하려고하면 워커노드 내에 동일한 파드가 있는지 확인하고, 리소스 사용률이 적은 곳을 수전적으로 스케줄러가 판단해서 파드를 배포한다.
 
Controller Manager는 만약 Mysql:5.8을 2개 배포한다고 하면 파드를 비교해주는 구성요소이다. 워커노드에 배포된 파드의 수가 우리가 요청한 갯수가 맞는지 계속 확인한다. 만약 같지 않다면 같게끔 다시 배포를 진행한다.
 
결국 Automatic bin packing은 쿠버네티스 내의 리소스를 효율적으로 사용할 수 있게끔 도와주는 것이다. 
위에서 말한 3개지의 기능을 이용해서 우리가 마스터 노드에 "Pod 배포해줘" 하면 알아서 자동으로 적절한 워커 노드에 배포를 해준다. 
 
그리고 그림에 보면 CNI라고 적혀있는데 이는 워커노드끼리의 통신을 할 수 있게해주는 가상의 네트워크이다. (Container Network Interface)
 
그렇다면 우리가 해야할 것은 Pod를 배포하는데 얼마나 빨리 배포되는지 알아야한다. 그렇게 하기 위해서는 백엔드를 경량화 해야하기 때문에, MSA를 사용해서 경량화 시킨다. 
 
각각의 워커노드에 dockererd라 적혀있는거는 도커 데몬을 표시한 것이다.
그리고 마스터 노드에 보면 etcd라는 DB가 존재하는데, 이는 마스터 노드에 요청이 들어오면 etcd에 기록을하고, 워커 노드안에 kubelet이 기록된 etcd를 보고 할 일이있는지 확인한다. 쿠블렛에 보면 cAdvisor가 있는데, 이는 모니터링이다. 그렇기 때문에 쿠블렛 안에 cAdvisor가 etcd를 보며 모니터링하고 요청을 받으면 dockererd에 요청을해서 pod를 띄우는 구조다.

Self-Healing

Docker에서도 헬스체크 기능이있었다. 쿠버네티스 또한 헬스 체크 가 가능하다.
Controller Plain에 pod요청을 할 때 파드가 정상인지 아닌지 판단한다. 정상이 아니라면 파드에 연결을 하지 않는다.
그리고 파드의 상태를 상시 체크하는 기능이있다. 만약 파드에 문제가 생긴다면 알아서 지우고 다시 배포한다. 
 
여기서 중요한게 쿠버네티스는 파드를 절대로 마이그레이션하지 않는다. 그냥 단순히 새로 배포하는 것이다. 
그리고 중요한점이 있다. 워커노드는 각각의 ec2이다.
그런데 만약 N1이 있는 ec2를 삭제한다면? N1에 있던 mysql은 어떻게 될까?
etcd에 기록하고 쿠블렛이 etcd를 보고 다른 워커노드에 배포한다. 지금 그림의 경우 N3에 배포를 할 것이다. 리소스를 효율적으로 사용하기 때문이다. 
이걸 모르고 그냥 ec2를 삭제한다면 다른 곳에가서 살아있을 것이다. 그러므로 ec2를 지울 때 파드를 먼저 지우는것이 좋겠다.

Automated rollouts and rollbacks

다음으로는 롤링 업데이트다. 
쿠버네티스는 파드에 문제가 생기면 다시 배포한다고 했는데, 이때 방법이 여러개있다. 
* 롤링 업데이트
 - 파드를 새로만든 다음에 삭제한다.
 - 배포를 위해서 추가비용이 발생하지 않는다.
 - 배포중에 장애가 발생하면 롤백 또한 자동으로 해준다.
* 블루그린 배포
 - 인프라를 그대로 복사해서 새로운 버전을 배포하고, 사용자의 엔드포인트로만 변경을 시킨다.
 - 기업에서 선호하는 방식
 - 고가용성이지만, 비용이 많이 든다.
* 카나리아 배포
 - 서비스의 변경이 너무 커서 프로덕션에 올리기에는 걱정이 될때 사용
 - 기존의 파드의 성능을 90%로 하고 새로운 파드를 10%로 한다. 그리고나서 모니터링한다.
 - 장애가 나면 안되는 상황에서 사용한다.
 
우리는 롤링 업데이트만해도 충분하다

Service Discovery and Load Balancing

우리가 파드를 올리면 파드에 대해서 가상의 IP가 생성된다. 
그리고 이 서비스를 요청하게 되면 해당 서비스에 대해 가상의 IP로 자동 매핑해준다. 
그러므로 서비스의 가상 IP만 알고 있으면 컨트롤 플레인(마스터노드)에서 각 서비스의 컨테이너의 엔드포인트에 맞게 트래픽을 보내준다. 
큐블렛이 내 서비스에 대한 엔드포인트를 생성한다. kube-proxy 는 각각의 워커 노드에 있다.
kubelet -> kube-proxy -> pod 이순서이다.
큐브 프록시가 서비스로 이동하는 룰을 적용시킨다. 그러면 서비스에 대한 가상 IP로 요청이 들어오면 iptables가 백분율로 로드밸런싱해준다. 
로드밸런싱을 해주는 주체는 iptables이지만 그 룰을 설정해주는 것은 kube-proxy이다.
여기서 ip로 요청한다고 했는데, 만약 ip가 바뀌면 전혀 요청이 수행이 안될 수 있다. 그렇기 때문에 Core-dns가 도메인 기준으로 지정해줄 수 있다. (여기서 Spring Cloud의 Eureka와 매우 유사하다고 생각함.)

Batch Execution

이 기능은 심플하다. 리눅스의 크론탭 기능을 알 것이다. 일정 시간마다 실행하게 해주는 스케줄링기능인데, 쿠버네티스에서도 이를 리눅스 기반의 cronTab 기반으로 Batch 를 제공해주는 것이다.

Secret and configuration management

어플리케이션 내의 파일 정보를 config-map에 객체로 만들 수 있다. 
이렇게 말하면 처음에 이해가 안됐지만, Spring Cloud에서 보던 config 서버와 유사하다. 어플리케이션과 환경설정을 분리해주는 기능이다. 아마 스프링클라우드에서 처럼 분리하는 이유는 설정파일이 자주 바뀌기 때문에 따로 관리하려는 목적인 것 같다.
여기서 설정 정보에 민감한 정보들이 있을 것이다. (ex : DB 비밀번호) 이런 경우 configMap에 secret라는 객체가 존재하는데, Base64로 인코딩한다.  이는 인코딩이기 때문에 암호화는 아니라고 한다.

Storage Orchestration

실무에서는 네트워크 스토리지를 개발자가 구성하는게 불가능하다. 개발자가 개발을 하고 그에 맞게 스토리지 생성하고, 이러는게 사실상 불가능 하다는 소리다. 
오른쪽 아래를 보면 스토리지에 대해 파드가 올라갈 때마다 생성이 되는데 이걸 개발자가 매번 할 수가 없다. 이를 쿠버네티스가 해주는 것을 스토리지 오케스트레이션이다. 
어떤 파드를 요청하면 자동으로 스토리지가 생성되고 붙여준다.
만약 파드가 죽거나 삭제되면 파드가 사용했던 스토리지를 죽일지, 살릴지에 대한 설정이 가능하다고 한다. 
이는 cloud와 같이 사용하면 강력하다고 한다. 
 

추가 내용

Controller Plain의 API Server가 있다고 위에서 얘기 했는데, 사실은 쿠블렛이 etcd로 가는 것이 아니라 API Server로 요청하고 API Server가 etcd로 가는 것이다. 그렇기 때문에 부하가 제일 많이 발생하는 곳이다. 그래서 로드밸런싱을 해줘야한다.
 
 
다음에는 ec2에 쿠버네티스환경을 만들어 보려고한다.