왜 쿠버네티스 인가?

모놀리식 아키텍처

• 전통적인 아키텍처, 기존에 사용하던 서비스 방법
• 서비스가 하나의 애플리케이션으로 돌아가는 구조
• 기존의 개발 방식을 사용해 개발하여 간단히 배포
• 하나의 서비스 또는 어플리케이션이 하나의 거대한 아키텍처
• 다양한 기능을 동작하는 서비스를 서버에서 실행하여 서비스

단점

• 서버 스케일링을 할 경우
  • 기존의 애플리케이션을 그대로 복제
  • 불필요한 서비스까지 모두 복제
• 종속적인 라이브러리의 충돌
• 조금만 수정해도 전체 빌드 및 배포 필요
  • 소스코드 전체가 하나로써 동작
    • 작은 수정만 있더라도 전체를 빌드하여 다시 배포

마이크로 서비스 아키텍처

• 서비스 단위 빠른 개발
• 배포 용이
• 서비스 단위 고효율 저비용

단점

• 분산시스템 환경에서 Transaction 보장, 테스트, 배포, 관리 복잡

컨테이너

• 가상머신을 사용해 각 마이크로 서비스를 격리 하는 기술
• 컨테이너는 가상머신처럼 하드웨어를 전부 구현하지 않기 때문에 매우 빠른 실행이 가능함
• 프로세스의 문제가 발생할 경우 컨테이너 전체를 조정해야 하기 때문에 컨테이너에 하나의 프로세스를 실행하도록 하는 것이 좋음

컨테이너 격리 기술

• 리눅스 네임 스페이스와 cgroup 을 사용해서 가능하게 함
• 각 프로세스가 파일 시스템 마운트, 네트워크, 유저, 호스트 네임등 시스템에 독립 뷰를 제공
• 프로세스로 소비할 수 있는 리소스 양을 제한

도커(Docker)

• 컨테이너 기술의 사실상 표준
• 2014 가장 인기 있는 클라우드 오픈 소스 2위
• 다양한 운영체제에서 사용 가능
• 애플리케이션에 국한 되지 않고 의존성 파일 및 파일 시스템까지 패키징하여 빌드
• 리눅스의 네임 스페이스와 cgroups 와 같은 커널 기능을 사용하여 가상화

컨테이너

이미지를 격리하여 독립된 공간에서 실행한 가상 환경

이미지

필요한 프로그램과 라이브러리, 소스를 설치 한 뒤 만든 하나의 파일

아키텍처

• 도커 엔진:이미지, 네트워크, 디스크 관리
• Containerd: OCI 구현체 (주로 runC)를 이용해 container를 관리해주는 daemon
• 두 프로그램이 각각 돌아가기 때문에 Docker Engine을 재시작해도 각 이미지에 영향이 없음

한계

• 서비스가 커지면 커질수록 관리해야 하는 컨테이너의 양이 급격히 증가
• 도커를 사용하여 관리를 한다 하더라도 쉽지 않은 형태

쿠버네티스

• 2014년 구글이 오픈 소스 공개
• 구글의 컨테이너 운영 노하우가 담긴 오픈소스
• 많은 시스템을 통합, 컨테이너를 다루기위한 API 제공

DevOps

• 소프트웨어 개발과 IT 운영을 결합한 합성어
• 기존의 분리된 소프트웨어 개발과 IT 운영의 협업으로 전체 라이프 사이클을 함께 관리함
• 소프트웨어 개발팀과 IT 팀이 더 빠르고 안정적으로 소프트웨어를 빌드, 릴리즈 할 수 있도록 두 팀간의 프로세스를 자동화하는 일련의 과정