1. 쿠버네티스 소개

과거의 소프트웨어는 하나의 큰 모놀리틱한 서버를 두었으나 이는 배포를 느리게 했다.
개발팀은 마지막 단계로 자신의 코드를 빌드한 전체 결과물을 시스템 통째로 운영팀에 넘기고, 그걸 운영팀이 배포하고 관리했다.
운영팀은 하드웨어 관리를 하면서 서버가 건강하도록 유지하는 작업을 진행했다.
오늘날에는 이 큰 레거시 서버를 기능 단위로 쪼개고 마이크로서비스화시키고 있다.
그래서 이제는 각 서비스가 독립적으로 개발되고 배포되며, 이는 급격히 변하는 현대의 비즈니스 요구사항을 충족시킬 수 있다.
당연히 이러한 변화는 관리 및 운영의 어려움을 촉발시킨다.
갖가지 서비스를 동시에 올리면서 하드웨어 비용 최적화를 하는 것은 어려운 일이다.
그렇기에 이를 자동화하고자 하는 수요가 생겼다.
자동 설정, 자동 모니터링, 자동 장애 회복 등의 기능이 필요하게 된 것이다.
이것이 쿠버네티스가 생긴 이유다.

쿠버네티스는 개발자가 운영팀 없이 자신의 앱을 원하는 대로 배포할 수 있게 한다.
또한 하드웨어 장애에 대해 모니터링하고 재 스케줄링을하며 운영 팀의 일도 자동화시킨다.
이제 시스템 관리자의 일은 쿠버네티스를 관리하는 것으로 간편화되었다.
쿠버네티스는 하드웨어 인프라를 추상화하고 여러 개의 데이터 센터를 하나의 거대한 리소스로 간주한다.
그래서 앱이 배포되는데 있어 실제 물리 환경적 고려가 줄어들게 된다.

1.1 쿠버네티스와 같은 시스템 수요

과거로부터 현재로 어떻게 변화됐길래 쿠버가 필요한가?

• 모놀리틱 to 마이크로
  • 값싸지만 어려운 스케일 아웃이 용이해짐
    • 각 앱 간의 관계와 의존성은 점점 어려워짐
  • 각 앱마다 의존성 관리하는 것이 어려움
• 앱에 독립적인 환경을 부여하기
  • 개발 환경과 운영 환경이 다르다고 실행이 잘 안 되는 케이스가 존재한다
• 자동 배포
  • 데브옵스나 노옵스

1.2 컨테이너 기술

쿠버네티스는 리눅스의 컨테이너 기술 사용하기에 그러한 기술을 먼저 알아본다.

컨테이너란?

과거에는 VM을 활용했지만, 서비스가 작아지고 많아지면서 모두 VM을 띄울 수는 없게 됐다.
이를 해결하기 위해 요소들을 분리하면서도 경량화된 방법이 필요하게 됐다.
컨테이너 기술은 다른 OS를 띄우지 않고 호스트의 자원을 공유하므로 오버헤드가 적다.
vm은 구동되기 위한 시스템 프로세스 집합이 필요하다.
그러나 컨테이너는 한 프로세스를 격리시킬 뿐이며 추가적인 프로세스가 필요하지 않다.

vm은 구동을 위한 프로세스가 많아서 결국 하나의 vm안에 여러 개의 앱을 구동하는 방식으로 가게 된다.
컨테이너는 그럴 필요가 없다.

가상 머신의 장점이라면, 완전한 고립을 제공한다는 것이다.
각각이 리눅스 커널을 가지기에 그렇다.
반대로 컨테이너는 각각이 다른 프로세스일 뿐이기에 부팅 프로세스가 존재하지 않는다.