[k8s 강의] 1. 쿠버네티스란 무엇인가?

 

이번 포스팅은 스터디 구성원들의 쿠버네티스에 대한 이해를 위해 실습형 교육자료 입니다.

 

1. What is Kubernetes ? 

• 지난시간에 Docker에 대해서 배웠다. 이번 시간에는 Kubernetes의 개념에 대해서 배워보겠다.
• 그전에 Docker , 컨테이너 개념에 대해 한번 정리해보자.

 

 

 

2. Why Kubernetes ?

 

 

쿠버네티스는 컨테이너 Orchestation 툴이다. 
오케스트레이션? 경량화된 컨테이너 어플리케이션을 배포하고 관리 하며, 스케일링 해주는 툴입니다. 

 

 

Docker을 통해 이미지들을 관리하는데 있어서 제한사항들을 쿠버네티스가 해결 할수 있다.

사실 도커를 사용하는 머신이 하나라면, 굳이 오케스트레이션에 대한 고민을 할 필요가 없다.

지난 시간 배운 내용으로도 충분히 컨테이너 기반의 어플리케이션을 관리할수 있기 때문이다. 

 

 

2020.11.26 - [컨테이너/Docker] - [도커 강의] (1) 도커 설치 (*리눅스/ *윈도우)

[도커 강의] (1) 도커 설치 (*리눅스/ *윈도우)

 

하지만 두개 이상의 호스트(가상머신) 에서 도커 데몬을 관리한다고 가정해보자. 이럴 경우 머리는 매우 복잡해진다. 외부 사용자는 컨테이너를 생성해서 사용하고 싶은데

 

 어느 도커 데몬에 컨테이너를 생성하는 것이 맞을까? 일반적으론 가장 유휴 자원이 많은 곳을 선택해 컨테이너를 생성하는것이 옳을 것이다

어디다 배포할래?

그러나 유휴 자원이 많은 호스트를 선택하는 것도, 모든 컨테이너를 각 서버별로 관리하는것도 귀찮은 일이다. 

이러한 스케쥴링 기능은 쿠버네티스의 기능중에 일부분이며, 그 이외에도 쿠버네티스를 쓰는 여러가지 이유들이 있다. 

 

 

쿠버네티스를 사용하는 이유

1) 여러 개의 도커 서버를 하나의 Pool로 사용   kubernetes는 여러 개의 도커 데몬과 연결되어 있다. 그리고 사용자는 안에 도커 데몬 서버가 몇개나 있는지는 알 필요가 없고, 그냥 "N개의 컨테이너를 XXX 목적에 맞는 이미지로 생성해!" 라고 kubernetes master에게 명령만 내린다. 그러면 여러 개의 도커 데몬 서버에 알아서 컨테이너가 생성된다. 예시를 들어보자. 서버가 2개가 있다고 가정하자(A서버, B서버). 필자가 3개의 컨테이너를 생성해달라고 명령을 내리면 1개는 A서버에 생성되고, 2개는 B 서버에 생성될 수도 있다. 이는 kubernetes가 알아서 해준다. 게다가 더 멋진건 kubernetes가 A서버에 유휴 자원과 B서버에 유휴 자원을 확인하여, 더 적합한 서버에 배포한다.

(2) CNI를 통한 다른 서버에 있는 컨테이너와의 통신  머리회전이 빠른 사람은 여기서 바로 문제점을 알아챌 것이다. 3개의 컨테이너들은 각자의 호스트에서 private IP를 가질텐데, A서버에 있는 1개의 컨테이너와 B 서버에 있는 2개의 컨테이너는 어떻게 통신을 하는가? 이는 kube-proxy와 flanneld / antrea / calico 라는 서브 툴로 가능하게 한다. 이중에 flannel / antrea / calico가 CNI라는 녀석인데 컨테이너 네트워크 인터페이스라고 불린다.

(3) 컨테이너 fail 시 재생성 만약 컨테이너가 fail하여 exit 상태로 들어갔다면, 동일한 컨테이너를 생성해 서비스를 지속적으로 제공할 수 있도록 한다. 이는 kubernetes의 리소스 중 Replicaset / Deployment 리소스에 포함되어 있는 기능이다. 그 뿐만 아니라 다음과 같은 기능도 제공한다. - 스케일 업 , 다운 - 롤아웃 , 롤백 , 롤링 업데이트 ( 롤링 업데이트란, 배포할때 새로운 파드를 하나씩 늘려가고 기존의 파드를 하나씩 줄여가는 방식입니다. 무중단 배포 라고도 합니다. ) - history 저장, 추적 , 이미지 변경

(4) Service 타입의 다양성을 통한 서비스 검색 및 부하 분산   하나의 클러스터로 묶인 3개의 웹 서버 컨테이너를 Kubernetes를 통해서 생성했다고 가정하자. 하나는 A서버에, 두 개는 B 서버에 존재한다. 그렇다면 사용자는 XXX.XXX.XXX.XXX:80 이라는 public IP로 웹 서버에 접근을 하는데, 사용자가 접근할 때마다 다른 컨테이너의 웹 서버에 접근하도록 round-robin 형태의 로드밸런싱을 제공한다. 이는 service라는 추상화 기능으로 가능한 것이다.

 

쿠버네티스를 사용하는 이유

(5) Secret과 Config Map 쿠버네티스 리소스에는 Secret과 ConfigMap이라는 리소스가 있다.  단어 그대로 Config를 저장해두는 ConfigMap과 민감한 데이터를 저장해두는 Secret을 사용하여 쿠버네티스에서  어플리케이션에서 활용되는 Config등을 쿠버네티스 레이어로 분리할수 있다. 이것이 중요한 이유는 Config와 어플리케이션을 분리함으로 인해 의존성을 제거할수 있고 그로 인해 환경변수가 수정되어야 할때 어플리케이션의 지속성을 유지할수 있다.   워크로드의 무중단과 고가용성 뿐만 아니라 변경 작업시 작업소요를 엄청나게 줄일수 있다는 점에서 Config를 분리하는것이  현대화된 어플리케이션 관점에서 매우 중요한 부분이다.

 

 

 

사실 위에 svc / LoadBalancer/ ingress 그리고 self healing과 autoscale / rollback / rolling updates 모든 기능들은 MSA 패턴으로 어플리케이션을 개발하기 위해서 반드시 필요한 요소들이다.

수천개의 서비스들이 지들끼리 api 를 통해 통신하고 있는 MSA 생태계에서 당연히 통신하고 있던 endpoint가 죽으면 스스로 self-healing을 해야할 것이고, 한쪽에 트래픽이 몰려서 해당 서비스 컨테이너가 죽지 않게 Loadbalancing을 해주는것도 반드시 필요하기 때문에, ingress나 Loadbalancer 형태의 svc를 사용하는것이다.