쿠버네티스

컨테이너 수동 배포의 한계, 문제점

ex) EC2인스턴스를 만들어서 직접 이미지를 빌드하고 배포한다.

• EC2 인스턴스를 자체적으로 관리하고 구성해야 하며, 그 인스턴스의 소프트웨어와 운영 체제가 업데이트된 상태를 유지하도록 해야 한다.

• 컨테이너가 충돌하거나, 다운될 수 있으며 새 컨테이너로 교체해야 한다.

• 만약 수동 배포를 사용 한다면. 충돌이 발생할 때마다, 수동으로 모니터링해야 하며 그 이후에는 수동으로 컨테이너를 다시 실행해야 한다.

• 트래픽 급증 시 더 많은 컨테이너 인스턴스가 필요하다. 트래픽이 증가하고 더 많은 작업 부하가 들어오면, 컨테이너가 첫 번째 태스크를 완료하기 위해 계속 멈춰버릴 수도 있다.

• 컨테이너 수를 증가시켜 들어오는 트래픽을 줄이면서 여러 컨테이너에 고르게 분산하고자 함. 또한 들어오는 트래픽이 줄어들고나면 컨테이너를 다시 제거해야함

• 웹 개발을 위해 컨테이너만 사용할 수는 없다. 애플리케이션을 실행하는 컨테이너나 이미지 파일을 변환하는 태스크가 있는 경우에는 들어오는 HTTP 요청만 처리하는 것이 아니라 이미지 파일 처리 태스크도 해야 한다.

• 점점 더 많은 파일이 들어오는 경우 컨테이너가 이러한 모든 파일 변환을 완료하는데 오래 걸리게 된다. 따라서 여러 컨테이너를 구동하는게 해결책이 된다.

• 하지만 수동 배포를 하는 경우 스케일 인 아웃이 매우 번거롭다.

클라우드 프로바이더의 한계

• 프로바이더 마다 규칙이 다르기 때문에 그 서비스에 고정이 된다.

• 예를 들어 ECS는 AWS에서 정의한 대로 모든 것을 구성해야 한다.

• 만약 다른 프로바이더를 사용하려면 원래 사용하던 구성 파일이 작동하지 않는다.

• 또한 그 서비스의 특정 조거노가 설정할 수 있는 구성 옵션을 학습해야 한다.

• 도커를 학습하는것 뿐만 아니라 프로바이더가 제공하는 서비스에 관해서도 알아야 한다.

쿠버네티스

• 컨테이너가 실패할 경우의 모니터링하는 방법과 컨테이너를 교체하는 방법을 정의할 수 있다.

• 우리가 사용하는 클라우드 서비스와는 독립적으로 이 모든것을 정의한다.

• 오픈소스 시스템

• 컨테이너 배포를 관리하고, 컨테이너를 오케스트레이션하기 위한 사실상의 표준

• 자동배포, 스케일링, 로드 밸런싱, 일반적인 배포와 컨테이너 관리와 같은 태스크를 수행하는데 도움이 된다.

• 컨테이너를 모니터링하고, 컨테이너가 다운되면 자동으로 교체하는 것에 도움을 준다.

• 원하는 배포를 정의하는 구성 파일, 배포할 컨테이너, 인스턴스 수, 스케일을 확장해야 하는지, 교체해야 하는지 등을 설정할 수 있다.

• 특정 도구를 사용하여 그 구성을 클라우드 프로바이더 또는 우리의 자체 머신에 전달한다. 구성에 지정된 리소스와 배포를 생성하기 위해 쿠버네티스 구성을 적용한다.

• 특정 클라우드 프로바이더에 특화된 옵션을 쿠버네티스 구성 파일에 병합할 수 있다. 즉, 일부 클라우드 프로바이더에 추가 구성이 필요한 경우, 해당 구성을 메인 파일에 추가하기만 하면 된다.

• 해당 파일을 다른 클라우드 프로바이더와 함께 사용하려는 경우, 클라우드 프로바이더에 특화된 구성을 제거하거나, 새로운 클라우드 프로바이더로 교체하기만 하면 되며, 전체 구성 파일을 다시 작성할 필요가 없다.

• 배포를 설명하는 표준화된 방식을 갖는 것. 이것이 쿠버네티스의 개념이다.

• 쿠버네티스는 클라우드 프로바이더가 아니다. aws or azure의 대안이 아님.

• 모든 클라우드 프로바이더와 함께 사용할 수 있는 개념 모음이자 소프트웨어 모음이다.

• 클라우드 서비스 프로바이더가 제공하는 서비스가 아니다.

• 컨테이너를 어디에나 배포할 수 있다.

• 다중 머신 설정에 대해서도 동일한 작업을 수행한다.