👉 이 게시글은 도커 / 쿠버네티스 온라인 부트캠프 with 카카오엔터프라이즈 강의를 바탕으로 작성되었습니다.

1. Kubernetes란?

쿠버네티스는 컨테이너화된 애플리케이션을 배포, 관리하기 위한 오픈소스 오케스트레이터이다. 쿠버네티스라는 명칭은 유래는 키잡이(helmsman)나 파일럿을 뜻하는 그리스어인 kubernētēs에서 유래되었다. Kubernetes를 K8s로 약식으로 표기하기도 한다. (K8s에서 8은 u~e까지의 알파벳 문자의 수를 의미한다.) 2003년 구글에서 만든 최초의 컨테이너 관리 시스템인 Borg가 시초이며, 2014년에 구글이 이를 쿠버네티스라는 이름으로 오픈소스화하여 세상에 널리 알려지게 되었다. 따라서 쿠버네티스에는 프로덕션 워크로드를 대규모로 운영하는 15년 이상의 구글의 경험과 커뮤니티의 아이디어 및 적용 사례가 결합되어 있다고 할 수 있다. 쿠버네티스에서 관리할 수 있는 가장 작은 단위는 파드(Pod)이다. 파드는 하나의 애플리케이션을 나타내고, 스토리지 리소스 및 IP 주소를 공유하는 1개 이상의 컨테이너로 구성된다. 국내에도 쿠버네티스를 이용하는 많은 개발자들이 정보를 공유하는 커뮤니티가 존재한다. 쿠버네티스에 대한 더 많은 정보를 얻길 원한다면 해당 커뮤니티에서 활동해보는 것을 추천한다.

• 쿠버네티스 공식 사이트 : https://kubernetes.io/ko/
• 쿠버네티스 페이스북 커뮤니티 : https://www.facebook.com/groups/k8skr/

a) 쿠버네티스의 기능

쿠버네티스는 PaaS (Platform as a Service) 구조의 서비스에 많이 활용되며, 인프라 영역의 서버, 스토리지, 네트워킹을 지원하는 다양한 기능을 제공한다. 제공하는 기능들은 다음과 같다.

• 서버 : Pod, Replica Set, Deployment
• 스토리지 : PV (Persistent Volume), PVC (Persistent Volume Claim)
• 네트워킹 : 서비스, 인그레스, 로드밸런서

b) 왜 쿠버네티스인가?

쿠버네티스가 컨테이너 관리용 오케스트레이션으로 가장 많은 사랑을 받고 있는 이유는 과연 무엇일까? 함께 알아보도록 하자.

• 서비스 디스커버리와 로드 밸런싱
  쿠버네티스는 DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출시킬 수 있으며, 컨테이너에 대한 트래픽이 높아지면 네트워크 트래픽을 로드밸런싱하기 때문에 안정적인 배포가 가능하다.

• 스토리지 오케스트레이션
  쿠버네티스를 사용하면 로컬 저장소, 공용 클라우드 공급자 등과 같은 저장소를 자동으로 탑재할 수 있다.

• 자동화된 롤아웃과 롤백
  쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태를 서술할 수 있다. 또한, 쿠버네티스를 통해 배포용 컨테이너 생성 및 제거, 리소스 적용과 같은 여러 작업들을 자동화할 수 있다.

• 자동화된 배치 - 빈 패킹 (bin packing)
  컨테이너화된 작업을 실행하는 과정에서 사용할 수 있는 쿠버네티스 클러스터 노드를 제공한다. 또한, 쿠버네티스는 컨테이너를 노드에 맞춰 리소스를 가장 잘 사용할 수 있도록 선택한다.

• 자동화된 복구 (self-healing)
  쿠버네티스는 실패한 컨테이너를 다시 시작하거나 교체하고 사용자 정의 상태 검사에 응답하지 않는 컨테이너를 자동으로 제거한다.

• 시크릿과 구성 관리
  쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 용이하게 관리할 수 있다.

2. Infra 발전의 역사

IT 생태계의 인프라 구조는 지난 수십년간 기술의 비약적 발전을 통해 다양한 형태로 발전해왔다.
처음에는 하드웨어 + 운영체제 + 애플리케이션으로 구성된 컴퓨터 구조에서 시작하였다. 이후 운영체제 위에 각각의 독립적인 운영체제로 구성된 여러 개의 가상 머신을 관리하는 Hypervisor가 추가된 가상화 구조로 발전하였고, 이후에 운영체제를 모두 공유하는 컨테이너 개념이 도입이 되면서 지금의 고효율, 고집적의 컨테이너 구조에 이르게 되었고, 이를 효율적으로 관리하기 위한 도구로써 쿠버네티스가 떠오르게 된 것이다.
하지만 각 구조마다 장단점이 존재하기 때문에 서비스의 용도에 맞게 아키텍처를 구성하는 것이 좋다. 전통적 구조의 장점은 장애 대응 및 성능 유지에 용이하고, 전체적인 관점에서 운용이 가능하다는 것이다. 하지만 많은 사용자에게 서비스를 제공하기에는 힘든 구조이다. 컨테이너 구조는 보다 많은 사용자에게 효율적으로 서비스를 제공할 수 있으나, 장애 발생시 대응을 빠르게 하기 힘들다.