쿠버네티스 기초 (키워드, 아키텍처, 흐름)

개인적으로 쿠버네티스에 관심이 있어서 표면적인 지식을 학습하려고합니다. 쿠버네티스는 구글에서 개발한 오픈소스 컨테이너 오케스트레이션 도구이며 구글에서 가이드라인을 주기로는 행성급 애플리케이션(약 10억개의 컨테이너)에 어울리는 기술이라고 합니다.

 

때문에, 웬만한 기업에선 쿠버네티스를 사용하는 것이 오히려 유지보수적인 측면에서 독이 될 정도로 사용하기 까다로운 기술 중 하나입니다. 

 

신입인 저는 공부하는 것이 오버스펙이라고 주변에서 뜯어말리지만 공부는 그냥 자기가 하고싶은거 하는게 최고이지 않겠습니까 공부해서 손해보는 공부는 없으니까요. 그래서 사람들 말 무시하고 제가 하고싶은 공부 하기로 했습니다. 

 

쿠버네티스란?

위의 사진은 개발 단계를 표현한 그림입니다. 

 

맨 처음 전통적인 개발 방식은 하드웨어에 OS를 설치하고 그 위에 바로 애플리케이션을 설치하는 과정을 거쳤습니다. 

 

하지만 가상화 기술이 발달하고 OS위에 가상 머신을 두어 그 가상 머신에 애플리케이션을 설치하게 되었죠. 하지만 이 가상 머신들은 구현하기위해 자원을 많이 소모해야 하기 때문에 비효율적이라는 말이 있었습니다. 

 

이를 해결하기위해 컨테이너 기반의 개발방식이 개발되었고 이는 많은 사람들이 컨테이너를 사용하게 되는 계기가 되었습니다. 

 

 

잠깐! 컨테이너?

컨테이너는 각각이 격리된 환경이라고 생각하시면 됩니다. 이 컨테이너에는 우리의 애플리케이션이 놓이게 되고 실행됩니다. 

 

컨테이너들은 경량화 되어있고 애플리케이션을 구동하는데 필요한 모든 것(코드, 런타임, 라이브러리 등등)을 가지고 있습니다. 

 

 

이제 본격적으로 쿠버네티스에 들어가보도록 하겠습니다. 

 

쿠버네티스의 키워드

• Pod (팟) : 쿠버네티스는 컨테이너들을 직접적으로 다루지 않습니다. 대신 쿠버네티스는 팟이라고 부르는 것을 이용해 컨테이너들을 관리합니다. 팟은 쿠버네티스 안에서 배포할 수 있는 가장 작은 유닛이며 스토리지나 네트워킹같은 자원들을 공유하는 하나 혹은 더 많은 컨테이너를 가지고 있을 수 있습니다. 
• Node (노드) : 팟은 노드 위에서 동작하는데 노드는 쿠버네티스에서 워커 머신입니다(워커 머신, 워커 노드에 대해서는 뒤에서 더 서술하도록 하겠습니다.). 그리고 이 워커 머신은 물리적 머신일 수도 있고 가상 머신이 될 수도 있습니다. 각각의 노드들은 팟들을 실행하고 마스터에 의해 관리됩니다. 
• Master (마스터) : 마스터는 쿠버네티스의 컨트롤 플레인 (컨트롤 타워라고 보시면 됩니다.) 마스터는 클러스터에 대한 전역적인 결정을 내리고 클러스터 이벤트를 감지하고 응답합니다. 여기서 클러스터 이벤트란 장애 상황에서 팟이 내려갔다가 다시 생성되는 상황같은 것을 말합니다.
• Deployment (배포) : Deployment는 우리가 원하는 만큼 동작시킨 팟들을 말합니다. Master 안에 있는 Deployment Controller는 원하는 수의 팟들을 항상 이용 가능하게 동작시키는 것을 보장합니다. 
• Services (서비스) : 쿠버네티스 서비스들은 논리적으로 정의한 일련의 팟들이거나 그 팟들에 접근할 수 있는 정책을 추상화한것입니다. 이 서비스들은 마이크러 서비스로 생각할 수 있고 서비스에 의해 타겟팅 된 일련의 팟들은 보통 Label Selector에 의해 결정됩니다. 
• Kubectl : Kubectl은 우리의 쿠버네티스 클러스터들에 대하여 명령을 실행하는 커맨드라인 툴입니다. 우리는 kubectl을 사용해서 애플리케이션을 배포하고 클러스터 자원들을 관리하고 로그를 볼 수도 있습니다. 
• Namespace : 쿠버네티스는 여러개의 가상 클러스터들을 지원하는데 이것들은 같은 물리적 클러스터를 지원해줍니다. 이러한 가상화 클러스터는 namespace라고 부르고 이것들은 리소스를 논리적으로 이름이 지정된 그룹으로 분할할 수 있습니다. 
• Storage & Config : 쿠버네티스는 우리의 팟을 위한 저장 공간을 관리할 수 있습니다. 그리고 우리의 팟으로 설정 정보들을 주입할 수도 있습니다. 
• Self-healing : 쿠버네티스는 장애 상황에서 컨테이너를 재실행할 수도 있고 노드가 죽었을 때 팟을 리스케줄링하거나 대체할 수 있고 유저 (여기선 개발자)가 정의한 헬스체크에 제대로 응답하지 않는 컨테이너를 죽여버릴 수도 있습니다.
• Scaling & Load Balancing : 쿠버네티스는 애플리케이션을 필요한만큼 스케일 업하거나 스케일 다운할 수 있습니다. 그리고 안정적인 애플리케이션 퍼포먼스를 위해 네트워크 트래픽을 분산시킬 수도 있습니다. 

 

키워드가 좀 많네요 ㅎㅎ..

 

자 이제 쿠버네티스에 우리가 컨테이너를 올리고 애플리케이션을 배포했을 때 어떤 과정이 내부적으로 돌아가는지 간단하게 살펴보도록 하겠습니다. 

 

 

쿠버네티스 흐름

1. Deployment Request

먼저 우리가 애플리케이션을 배포하기 위해서는 일반적으로 Deployment 설정을 만들어야합니다. 이 설정은 우리의 애플리케이션이 어떤 상태를 원하는지 묘사하는데 예를 들어서 어떤 컨테이너 이미지를 사용할 것인지, 얼마나 많은 레플리카 애플리케이션을 구동할 것인지 등등이 포함되어 있습니다. 

 

그리고 이제 내부적으로 API를 요청하게 됩니다. 이 때 사용되는 것이 바로 API Server라고 합니다. AWS로 치면 API Gateway같은 것입니다. 

 

API Server는 Master Node위에 존재하고 API Server는 요청 과정을 검증하고, etcd 데이터 스토어 안에서 원하는 상태를 업데이트 하는 과정이 포함됩니다. 

 

2. Scheduling

자 이제 본격적으로 시작입니다. 쿠버네티스는 내부적으로 노드의 상태를 확인하는 스케줄러가 있습니다. 

 

우리의 Deployment 설정으로 인해 컨테이너가 만들어지고 노드가 만들어지고 팟이 만들어지면서 애플리케이션의 컨테이너가 캡슐화 되고 스케줄러가 반응합니다. 

 

스케줄러는 Master Node위에 존재하고 있고 스케줄러는 노드가 할당되어있지 않은 새로운 팟을 주의깊게 살펴보고 있다가 가동중인 노드 중 리소스가 사용가능한지, 제약사항은 없는지 같은 요인을 확인하고 선택해서 할당해줍니다. 

 

3. Running the Pods

클러스터 안에 있는 각각의 노드들은 Kubelet을 구동시킵니다. Kubelet은 팟 안에 있는 컨테이너가 정상적으로 작동하고 있는지 확인하는 것에 책임이 있습니다. Kubelet은 팟 안에 컨테이너를 구동시키기 위한 컨테이너 런타임을 작동시킵니다. 

 

그리고 도커, CRI-O같은 각각의 노드 위의 컨테이너 런타임은 필요한 컨테이너 이미지를 풀링하고 컨테이너를 만들고 컨테이너를 구동시킵니다. 

 

4. Networking and Service Discovery

Kube-Proxy는 팟들 각각 서로 커뮤니케이션 하기 위한 노드들에 대해 네트워크 규칙을 관리합니다. 이는 내부적인 로드 밸런싱이나 네트워크 라우팅, 외부 소스로부터 팟들을 연결하는 작업을 거치죠. 

 

또한 쿠버네티스는 내부적으로 DNS 서비스를 제공해주는데 그래서 팟들은 서로서로를 잘 찾을 수 있게 해줍니다. 

 

5. Health Checks and Self-healing

개발자가 정한 헬스체크를 Kubelet이 보고 헬스체크를 동작시킵니다. 만약 컨테이너에 문제가 생기는 경우 재시작을 진행합니다. 

 

그 과정에서 Deployment에 의해 관리되는 ReplicaSet들은 원하는 개수의 레플리카 팟들을 항상 작동가능하도록 담당합니다. 

 

6. Scaling and Load Balancing

쿠버네티스는 내부적으로 Replication Controller가 들어있어서 CPU 사용량에 기반하여 안에 있는 많은 수의 팟들을 자동적으로 수평적으로 확장해줍니다. 

 

그리고 Service는 이 타이밍에 많은 수의 팟의 네트워크 트래픽을 분산시키기 위해 로드밸런서를 가동해줍니다. 

 

7. Updates and Rollbacks

쿠버네티스는 우리의 애플리케이션을 롤링 배포를 통해 배포합니다. 하지만 우리가 설정해준다면 카나리 배포나 블루그린 배포도 가능합니다. 

 

또한, 만약 문제가 생긴다면 쿠버네티스는 우리의 애플리케이션의 이전 버전으로 롤백을 지원해줍니다. 

 

8. Logging and Monitoring 

쿠버네티스는 디버깅 목적으로 로그를 유지하고 있어서 개발자들은 애플리케이션 퍼포먼스나 상황이 정리되어 있는 각각의 컨테이너 로그들에 접근할 수 있습니다. 

 

그리고 쿠버네티스는 자체적인 모니터링 솔루션을 갖고 있진 않습니다만 모니터링이나 알람을 위한 프로메테우스같은 서드 파티 툴과 결합할 수 있습니다. 

 

9. Storage Management

쿠버네티스는 Persistent Volumes를 통해 저장공간을 관리합니다. 이는 데이터를 영원히 보관하기 위해 stateful한 애플리케이션으로 제공되고 팟 개개인의 라이프사이클에 기반합니다. 

 

10. Cluster Management

개발자는 kubectl을 이용해서 클러스터들과 상호작용할 수 있고 쿠버네티스 대쉬보드 같은 GUI도 이용할 수 있습니다. 

 

 

 

가만...

얘기를 쭉 듣다보니 쿠버네티스는 우리가 도커를 사용할 때 항상 하던 컨테이너 생성과 삭제 그리고 장애 상황시 대처, 로드밸런싱, 헬스체크, 셀프힐링, 스케일링, 배포, 롤백, 로깅, 모니터링, 스토리지 관리까지 자동으로 해준다는거야?

 

이런 끝내주는 기술이 있는데 왜 행성급 규모에서만 사용하라고 하는거지?

 

 

아서라 아서

중요한 부분은 저걸 다 할 수 있다는 것이 아닙니다. 

 

중요한 것은 바로 저 모든 것을 개발자가 직접 개발해야 하는 것들이 많다는 것이죠. 

 

쿠버네티스가 자체적으로 가지고 있는 것은 셀프힐링 정도밖에 없습니다. 나머지는 개발자가 일일히 관리해줘야 하는 것입니다. 

 

모든 것을 유지보수 할 수 있는 인력이 없는 상황에서는 오히려 쿠버네티스가 독이 될 수 있다는 것입니다. 그래서 많은 사람들이 MSA는 신의 선물이 아니라 신이 내린 저주라고 말하는 것이죠. 

 

 

정리

저도 표면적인 지식만 습득해서 아직 자세히는 잘 모르겠습니다만 정말 흥미로운 기술입니다. 

 

많은 개발자 선배님들이 쿠버네티스는 신입에게 오버스펙이다 라고 말씀하시는 것이 왜인지 알 것 같습니다. 하지만 정말 재밌어보이는 기술인 것은 틀림 없습니다. 

 

요즘 자소서 쓰느라 블로그 포스팅이 조금 뜸했는데 신입 기준에서 앞으로 뭘 공부해야 할지도 막막해서 더 뜸했던 것 같습니다. 이제 쿠버네티스라는 재밌는 장난감을 조금씩 만지면서 놀아보도록 하겠습니다. 

 

긴 글 읽어주셔서 감사합니다. 오늘도 즐거운 하루 되세요~

 

출처

https://potato-yong.tistory.com/100

[kubernetes] kubernetes 개념 및 구조

 

https://devocean.sk.com/blog/techBoardDetail.do?ID=163578

초보자를 위한 EKS 맛 보기