쿠버네티스란?

도커와 쿠버네티스의 개요

쿠버네티스(Kubernetes)는 컨테이너화된 어플리케이션을 효율적으로 배포하고 운영하기 위해 설계된 오픈 소스이다.

따라서 쿠버네티스를 이해하기 위해서는 먼저 컨테이너를 사용하는 이유부터 알아야 한다.

 

애플리케이션이 생활 많은곳에 사용되고 중요성이 높아지고 있어 지속적 통합(CI)과 지속적 배포(CD)의 중요성이 점차 높아지고 있다.

사용자에게 새로운 기능과 서비스를 빠르고 안정적으로 제공해야 하는 것이다.

컨테이너 기술은 이러한 요구사항에 효과적인 대안을 제시한다.

 

개발자들은 서로 다른 개발환경으로 개발하기 때문에 개발 생산성과 안정성이 떨어지게 된다.

이러한 상황에서 컨테이너 기술이 빛을 발한다.

컨테이너 기술은 애플리케이션 실행에 필요한 라이브러리나 운영체제 패키지 등을 모두 담아서 불변의 실행 환경을 제공한다.

개발자들 간에, 그리고 테스트와 운영 환경 간의 차이를 없앨 수 있어 개발 생산성을 높이고, 애플리케이션 정식 서비스를 안정적으로 배포가 가능하다.

---

쿠버네티스의 개요

쿠버네티스는 구글의 사내 운영 시스템인 Bong을 오픈 소스로 만든 것이며, 크게 다음과 같은 기능을 제공한다.

1. 새로운 버전의 애플리케이션을 무정지로 업그레이드할 수 있다.
2. 하드웨어 가동률을 높여 자원 낭비를 줄인다.
3. 배포 계획에 맞춰 애플리케이션을 신속하게 배포할 수 있다.
   
   • 컨테이너 개수, CPU 사용률, 메모리 사용량 설정 가능
   • 저장 공간, 네트워크 접근 제어, 로드밸런싱 기능 설정 가능
4. 가동 중인 애플리케이션을 스케일 업/다운할 수 있다.
   
   • 요청이 많을때는 컨테이너 수를 늘려서 처리 능력을 높임
   • 요청이 적을때는 컨테이너 수를 중여서 자원 점유율이나 요금을 줄임

 

쿠버네티스는 서비스 운영에서 발생하는 다양한 부담을 줄이는 것을 목표로 하여 다음과 같은 특징을 가진다.

 

1. 다양한 환경에서 쿠버네티스 사용 가능
   
   • 퍼블릭 클라우드 : 고객들 간에 공유하는 대신 저렴하고 신속한 운영이 가능한 인프라 환경
   • 프라이빗 클라우드 : 독점적으로 사용하여 보안을 높일 수 있는 인프라 환경
   • 멀티 클라우드 : 여러 퍼블릭 클라우드를 함께 사용하는 경우
   • 하이브리드 클라우드 : 온프레미스와 퍼블릭 클라우드를 함께 사용하는 경우
   • 온프레미스 : 자사 설비를 이용해 애플리케이션에 특화된 운영을 하는 경우
2. 계속되는 변화를 전제로 설계된 높은 유연성과 확장성
   
   • 마이크로 서비스화된 애플리케이션에 최적화된 실행 환경
   • 느슨한 결합에 의한 유연성, 교체 용이성
   • 다양한 스펙의 서버가 혼재하는 클러스터 구성에 사용 가능
   • 서버(노드)의 정지, 추가, 제거가 용이
   • 저장소나 로드밸런서의 동적 프로비저닝
   • 퍼블릭 클라우드 API와 연동한 쿠버네티스 조각
3. 고가용성과 성능 관리
   
   • 서버 정지 시 애플리케이션 재배포 자동화
   • 애플리케이션의 이상 종료 시 자동 재기동
   • 필요한 인스턴스의 개수를 유지
   • 높은 부하에서 자동 스케일

---

쿠버네티스가 해결화는 과제

1. 애플리케이션의 빈번한 출시
   좋은 어플리케이션을 제공하기 위해서는 많은 아이디어를 실험해보고 실패를 경험하고 성공에 도달하는것이 중요하다.
   쿠버네티스의 롤백 기능은 새로운 기능을 빈번하게 출시하고 버그 수정을 긴급 투입하는 것과 같은 민감한 작업을 안전하게 자동화해 준다.
   정식 운영중인 서비스와 애플리케이션 컨테이너를 무정지로 교체할 수 있다. 또한, 교체 중에 발생하는 오류 및 충돌을 대비해 컨테이너 교체 정책(police)을 설정할 수 있고 롤아웃을 취소하고 롤백하는 것도 가능하다.
   
   
2. 무정지 서비스
   스마트폰이 보급되면서 사용자들은 24시간 언제 어디서나 애플리케이션을 사용한다.
   이처럼 IT기술이 사람들의 생활을 감싸기 시작하면서 서비스의 가용성이 중요한 요건이 되었다.
   쿠버네티스의 자기 회복 기능은 무정지 서비스 운영을 도화준다. 응답이 없어진 컨테이너를 재기동하며, 쿠버네티스 클러스터 내에 지정한 수 만큼 컨테이너가 돌도록 관리해준다.
   
   
3. 초기 비용을 낮추고 비지니스 상황에 맞게 규모를 조정
   컨테이너 기술은 애플리케이션과 실행 환경을 하나로 묶어서 배포할 수 있게 해준다.
   그리고 쿠버네티스는 복수의 노드 위에서 컨테이너가 조화롭게 돌아갈 수 있도록 해준다.
   이때 쿠버네티스 클러스터의 각 노드들이 똑같은 스펙일 필요는 없다. 따라서 비지니스의 초기 단계에서는 스펙이 낮고 저렴한 가상 서버를 사용하다가, 비지니스가 확대되면 고성능 가상 서버나 물리 서버를 투입시키는 전략을 취하여 초기 비용을 낮출 수 있다.
   
   
4. 쿠버네티스와 외부 서비스와의 연동
   애플리케이션 서버와 달리 데이터베이스에 대한 컨테이너화는 신중하게 접근할 필요가 있다.
   컨테이너는 태생적으로 언제든지 재시작 될 수 있는 일시적인 존재로 상태를 포함하지 않는 것을 전제로 하기 때문이다.
   이때,  하이브리드한 시스템을 구축하는 것이 한가지 대안이 될 수 있다.
   예를 들면 클라우드의 DBaaS(Database as a Service)나 온 프레미스에서 관리하는 데이터베이스와 연동하는 것이다.
   이러한 연동을 위해 쿠버네티스는 외부 서비스를 내무 DNS에 등록하는 기능을 제공한다.
   
   
5. 개발 환경과 운영 환경의 분리
   컨테이너의 개발이 완료되어 테스트까지 끝났다면 정직 서비스 때 배포하기 전까지는 이미지를 다시 빌드하지 않는 것이 좋다.
   테스트로 검증되지 않은 기능이 포함될 여지가 있기 때문이다.
   하지만 운영 환경에서 사용하는 엔드포인트나 인증 정보는 테스트 환경과 다르기 마련이다. 
   예를 들어 데이터베이스의 접속 주소나 HTTPS를 위한 인증서 등이 다르다.
   쿠버네티스에서는 클러스터를 여러개의 가상 환경으로 분할하는 것이 가능하다. 그리고 각각의 가상 환경에 설정 파일, 보안이 필요한 인증서나 비밀번호를 저장할 수 있다. 그리고 컨테이너에서는 이 저장된 정보에 접근할 수 있다. 따라서 이를 활용하면 테스트 환경에서 운영 환경으로 옮길 때, 이미지를 다시 만들 필요가 없다.
   즉, 테스트가 완료된 컨테이너의 이미지를 그리고 정식 운영환경에 배포할 수 있는 것이다.
   
   
6. 온프레미스와 클라우드 위에 구축
   보안상의 이유로 인터네을 경유하는 퍼블릭 클라우드를 사용하지 않는 기업도 있다. 하지만 보안이 문제되지 않는 상황이라면 퍼블릭 클라우드를 최대한 활용하고 싶은 개발자들도 늘고 있다. 이에 따라 퍼블릭 클라우드의 활용 또한 점차 늘어나는 추세다.
   대현 클라우드 업체들은 EKS(AWS), AKS(Azure), IKS(IBM Cloud)와 같은 쿠버네티스 서비스를 제공한다.
   쿠버네티스는 인프라의 복잡성을 감추며, 일관된 인터페이스로 다룰 수 있도록 설계되었다. 따라서 온프레미스와 클라우드 환경에서 동일한 인터페이스로 조작하며 운영할 수 있다.
   
   
7. 애플리케이션 중심의 오케스트레이션
   퍼블릭 클라우드 덕택에 애플리케이션을 위한 인프라를 구축하는 노동과 시간이 상당히 줄어들었다.
   여기에 쿠버네티스는 애플리케이션 중심의 운영이라는 흐름을 더욱 가속화하고 있다. 애플리케이션 개발자가 YAML 파일을 기술하여 쿠버네티스에 제출하면 로드밸런서, 저장소, 네트워크, 런타임 등의 환경이 구성된다.
   
   
8. 특정 기업에 종속되지 않는 표준 기술
   특정 IT 기업이 독점하는 기술에 의지하는 건 리스크 관리 측면에서도 피해야 할 일이다.
   쿠버네티스 프로젝트는 원래 구굴에서 시작되었지만, CNCF에 기증되어 오픈 소스 프로젝트로 운영되고 있다.
   170여 개의 회사가 참가하고 있기 때문에 특정 회사에 중속되지 않은 표준 기술로 자리하고 있다.
   
   
9. 서버들의 가동률 높이기
   CPU 사용률이 낮은 서버가 많은 것은 퍼블릭 클라우드에서도 온프레미스에서도 바람직하지 않다.
   한편, 쿠버네티스에서 사용되는 컨테이너 기술은 애플리키에션이 정해진 서버에서 돌지 않아도 된다는 자유를 제공한다.
   또한, CPU 사용 시간이나 메모리 요구량도 간단히 제어할 수 있다.
   이러한 기술 덕분에 쿠버네티스는 가동률이 적은 서버의 애플리케이션을 한곳에 모을 수 있고 서버의 CPU 가동률을 높에 유지하면서도 안정적으로 서비스를 제공한다는 상반되는 요구사항을 충족시킬 수 있다.

---

쿠버네티스의 아키텍처

쿠버네티스의 아키텍처를 매우 간단하다. 클러스터 관리를 담당하는 마스터와 컨테이너화된 애플리케이션을 실제로 실행하는 노드라는 단 두 종류의 서버로 구성된다.
클라우드의 문서에서는 마스터를 마스터 노드, 노드를 워커 노드로 기재하는 경우도 있다. 또한, 노드는 초기에 미니언이라 불리기도 했다.

마스터는 kubectl과 같은 API 클라이언트로부터 요청을 받아서 애플리케이션의 배포, 스케일 업/다운, 컨테이너의 버전 업 등의 요구를 처리한다.
마스터는 클러스터의 단일 장애점(Single Point of Failure, SPOF)이 되지 않도로 다중화 할 수 있다.

유저의 요청이 늘어나 처리 능력을 늘려야 할 때는 기본적으로 컨테이너의 수를 늘리면 되는데,
이때 노드 수를 늘려야 할 때도 있다.(버전 1.11 기준으로 5000대의 노드를 쿠버네티스에 연결 가능)

노드를 추가하고 제거하는 작업은 애플리케이션이 돌아가는 중에도 가능하다.

 

한편 쿠버네티스 클러스터의 외부에는 레지스트리가 있다.

이는 도커의 레지스트리와 동일하다.

각 노드에서 이미지를 다운로드 할 수 있도록 네트워크상 접근 가능한 곳에 있어야 한다.