하드웨어 가상화는 하이퍼바이저를 사용하여 가상 머신(VMs)과 물리적 하드웨어를 공유함으로써 확장성, 보안, 격리 등의 여러 장점을 제공합니다. 현재, 가상 머신은 유일한 가상화 형태가 아니며, 컨테이너도 매우 인기가 있습니다. VMs가 기본 머신의 물리적 하드웨어를 공유하는 반면, 컨테이너는 기본 운영 체제의 커널을 공유합니다. 컨테이너는 가벼운 가상 머신이 아니지만, 마이크로서비스 기반 소프트웨어 아키텍처를 사용하여 개발된 응용 프로그램을 전달하는 데 사용되는 표준화된 실행 가능한 패키지이며, 응용 프로그램을 실행하는 데 필요한 모든 구성 요소가 포함되어 있습니다.
도커 엔진은 컨테이너를 실행하는 가장 인기 있는 플랫폼입니다. Kubernetes는 컨테이너화 및 클라우드 컴퓨팅 분야에서 점점 더 자주 듣게 될 용어입니다. 그러나 도커와 쿠버네티스 중 어느 것이 더 좋은가요? 이것은 인기 있는 논쟁 주제이지만, 이렇게 말하는 것은 기술적으로 정확하지 않습니다. 예를 들어 “뜨거운 게 더 좋은지 파란 게 더 좋은지”와 같이 묻는 것은 불가능합니다.
도커란 무엇인가요?
도커는 컨테이너화된 응용 프로그램을 실행하는 데 사용되는 엔진으로 독립적인 오픈 소스 응용 프로그램입니다. 이는 운영 체제(OS)에 설치되어야 하며, 우선적으로 리눅스에 설치되지만 Windows 및 macOS에도 설치할 수 있으며, 이를 통해 물리적 또는 가상 머신에서 실행됩니다.
컨테이너에서 실행되는 애플리케이션은 시스템의 나머지 부분과 다른 컨테이너로부터 격리되지만, 자체 OS 인스턴스에서 실행되는 것처럼 느껴집니다. 여러 개의 Docker 컨테이너를 동시에 단일 운영 체제에서 실행할 수 있으며, Docker를 사용하여 이러한 컨테이너를 관리할 수 있으며, Kubernetes 없이 Docker를 실행할 수 있습니다. 컨테이너를 실행하기 위한 여러 호스트가 있는 경우 수동으로 관리하는 것은 어려울 수 있으며, 일반적으로 중앙 집중식 관리 도구나 오케스트레이션 솔루션을 선택하는 것이 더 좋습니다.
Docker Compose는 다중 컨테이너 Docker 애플리케이션을 실행하기 위한 기본적인 컨테이너 오케스트레이션 도구입니다. 각 컨테이너에 대해 별도의 Dockerfiles을 수동으로 구성하는 대신 하나의 YAML(yml) Docker Compose 구성 파일을 사용하여 다중 컨테이너 애플리케이션을 정의할 수 있습니다. 단일 YAML 파일을 구성한 후 Linux 콘솔에서 하나의 명령어로 필요한 모든 컨테이너를 실행할 수 있습니다. Docker Compose를 사용하여 Docker 컨테이너를 오케스트레이션하는 한 가지 방법은 있지만, Docker Compose의 강력한 대안이 있으며 이를 Kubernetes라고 합니다.
Kubernetes란 무엇인가?
Kubernetes는 컨테이너화된 소프트웨어 및 서비스를 자동화된 방식으로 관리하기 위한 오픈 소스 컨테이너 오케스트레이션 솔루션입니다.
Kubernetes는 컨테이너에서 실행되는 애플리케이션의 배포, 확장 및 가용성을 자동화하기 위한 Google 프로젝트입니다. 컨테이너를 실행하는 호스트 수를 11개 이상까지 늘릴 수 있습니다. 또한 Kubernetes를 사용하여 고가용성과 로드 밸런싱을 보장하기 위해 Docker 컨테이너의 클러스터를 생성할 수 있습니다.
클러스터에 사용되는 호스트는 노드라고 부르며, Kubernetes의 아키텍처 유형은 마스터-슬레이브 방식으로, 마스터 노드와 워커 노드로 구성되어 있습니다. Kubernetes가 추천하는 최소 노드 수는 4개이며, 예제 및 테스트를 실행하려면 단 한 대의 머신으로 클러스터를 구성할 수 있지만 적어도 4개의 노드가 필요합니다. 생산 트래픽을 처리하는 Kubernetes 클러스터는 최소 3개의 워커 노드를 가져야 합니다. 마스터 노드가 하나 실패해도 대처할 수 있도록 두 개의 마스터 노드를 사용하는 것이 좋습니다. 필요하면 더 많은 마스터 노드를 사용할 수 있습니다.
- 마스터 노드는 클러스터의 상태를 관리하며, 클라이언트 요청 수락, 컨테이너와의 스케줄링 작업, 컨트롤 루프 실행 등을 담당합니다. 각 마스터 노드에서는 클러스터의 모든 데이터를 저장하는 etcd 데이터베이스의 복사본을 실행해야 합니다. 마스터 노드에서는 kube-apiserver, kube-controller-manager, kube-scheduler 세 가지 프로세스를 실행합니다.
- 워커 노드는 애플리케이션 워크로드를 실행하기 위해 컨테이너를 실행하며, 워커 노드에서는 마스터 노드와 커뮤니케이션을 담당하는 kubelet과 각 노드에서 Kubernetes 네트워크 서비스를 반사하는 kube-proxy라는 두 가지의 Kubernetes 프로세스를 실행합니다.
- Replication Controller은 특정 숫자가 지정된 Pod 복제본이 항상 실행되는 것을 보장하는 구성 요소입니다. 따라서 필요할 때마다 항상 Pods가 사용 가능하도록 할 수 있습니다.
쿠버네티스를 사용하는 경우 서비스 간 통신에는 다른 CLI 및 API가 사용됩니다. 또한 쿠버네티스로 구축된 클러스터의 구성 요소인 RESTful API의 객체와 리소스에 대한 특정 용어도 있습니다. - Pod은 쿠버네티스의 기본 스케줄링 단위입니다. 여기에는 여러 컨테이너가 작동할 수 있는 리소스 그룹이 포함됩니다. 하나의 Pod에 속한 컨테이너는 동일한 호스트에서 실행되며 동일한 리소스와 동일한 로컬 네트워크를 사용할 수 있습니다. Pod 내의 컨테이너는 격리되어 있지만 서로 쉽게 통신할 수 있습니다. 따라서 Pods는 일반적으로 쿠버네티스에서 사용되지만 독립적인 Docker 애플리케이션을 사용하는 경우에는 컨테이너 풀만 사용할 수 있습니다.
- Service는 예를 들어 다중 계층 애플리케이션의 기능을 제공하는 일련의 컨테이너입니다. 쿠버네티스는 추상화를 사용하여 Pod의 동적 명명 및 로드 밸런싱을 지원합니다. 이 접근 방식은 서비스 간에 이름으로 투명한 연결을 보장하고 현재 상태를 추적할 수 있도록 합니다.
- Labels는 Pod 및 다른 객체나 서비스에 바인딩되는 키/값 쌍입니다. 이를 통해 그룹화하고 작업을 할당할 수 있습니다.
- 네임스페이스는 Kubernetes 클러스터를 여러 가상 클러스터로 논리적으로 나눌 수 있는 방법입니다. 각 가상 클러스터는 다른 가상 클러스터에 영향을 미치지 않고 할당량에 제한된 가상 환경 내에서 존재할 수 있습니다.
쿠버네티스는 Docker와 함께 사용할 수 있지만, Docker는 Kubernetes와 함께 사용할 수 있는 유일한 컨테이너 플랫폼은 아닙니다. Kubernetes는 또한 Windows 컨테이너, Linux 컨테이너, rkt 등과 함께 작동할 수 있습니다. K8s는 때때로 기술 문서에서 찾을 수 있는 Kubernetes의 이름입니다.
Kubernetes vs Docker: 네트워킹 비교
각 솔루션에 대한 네트워킹 옵션을 검토해 봅시다.
Docker는 컨테이너 간 네트워크 통신을 위한 세 가지 네트워크 모드를 제공합니다.
Bridge. 이 모드는 가상 레이어-3 브리지를 생성하여 기본적으로 사용됩니다. 이 네트워크의 호스트에서의 네트워크 이름은 docker0입니다. Docker는 자동으로 레이어-3 네트워크 브리지를 생성하고 외부 네트워크 인터페이스에 대한 마스커레이딩 규칙을 구성하여, 컨테이너가 서로 통신하고 외부 네트워크에 연결할 수 있게 합니다. 다른 호스트 및 외부 네트워크에서 컨테이너에 연결하려면 호스트 머신의 네트워크 인터페이스에 대한 포트 포워딩을 구성할 수 있습니다. 따라서 호스트 머신의 적절한 포트에 연결하면 Docker 컨테이너의 필요한 포트로 포워딩됩니다. 필요한 경우 Docker 컨테이너에 대해 하나 이상의 네트워크 인터페이스를 생성할 수 있습니다.
호스트. 이 모드에서 호스트 네트워크 드라이버는 컨테이너가 도커 호스트로부터 격리되지 않도록 보장합니다. 컨테이너는 호스트 네트워크 스택을 공유하며, 컨테이너의 호스트 이름은 호스트 운영 체제의 호스트 이름과 동일합니다. TCP 포트 8080에서 수신 대기 중인 컨테이너를 실행하면, 컨테이너 응용 프로그램은 호스트 기계의 IP 주소의 TCP 포트 8080에서 사용할 수 있습니다. 호스트 네트워킹 드라이버는 Linux 기계에서만 사용할 수 있습니다.
없음. 주어진 컨테이너의 네트워크 인터페이스에 대해 IP 주소가 구성되지 않습니다. 루프백 인터페이스의 127.0.0.1 주소를 제외하고는 외부 네트워크에 액세스할 수 없습니다. 없음 네트워크 모드가 설정된 경우 외부 네트워크에 액세스할 수 없습니다.
도커 컨테이너의 다중 호스트 네트워킹. 컨테이너가 다른 호스트에서 실행 중인 경우, 오버레이 네트워킹을 구성한 후 서로 통신할 수 있습니다. 유효한 키-값 저장소 서비스 (Consul, Etcd, 또는 ZooKeeper)를 구성해야 이러한 네트워크를 생성할 수 있습니다.
쿠버네티스. 독립적인 도커 컨테이너를 사용하는 경우, 각 컨테이너는 적절한 네트워크 인터페이스를 사용하여 네트워크를 통해 통신하는 기본 단위로 간주될 수 있습니다. 쿠버네티스를 사용하는 경우, Pod가 컨테이너 클러스터의 기본 단위입니다. 각 Pod는 자체 IP 주소를 가지며 적어도 하나의 컨테이너로 구성됩니다. Pod는 관련 작업에 사용되는 여러 컨테이너로 구성될 수 있습니다. 동일한 Pod의 컨테이너는 동시에 동일한 포트를 열 수 없습니다. 이러한 제한은 여러 컨테이너로 구성된 Pod가 여전히 단일 IP 주소를 가지고 있기 때문에 사용됩니다.
게다가 쿠버네티스는 각 Pod에 대해 특별한 일시 중지 컨테이너를 생성합니다. 이 특별한 컨테이너는 다른 컨테이너들에게 네트워크 인터페이스(내부 및 외부 통신용)를 제공하기 위한 것으로, 일반적으로 일시 중지(수면 모드) 상태에 있습니다. 이러한 일시 중지 컨테이너는 쿠버네티스가 “SIGTERM” 신호를 보낼 때 깨어납니다.
Flannel은 일반적으로 네트워크 오버레이의 원리를 사용하여 쿠버네티스 내의 컨테이너를 연결하는 네트워크 패브릭으로 사용됩니다. 오버레이 네트워킹을 통해 클러스터의 다른 물리적 호스트(노드로 지칭됨)들 간에 논리적 네트워크를 통해 컨테이너를 실행할 수 있습니다. 오픈 소스인 etcd 키/값 저장소는 컨테이너에 호스트가 할당한 실제 IP 주소와 오버레이 네트워크의 IP 주소 간의 매핑을 저장하는 데 사용됩니다.
쿠버네티스 네트워킹은 NSX 컨테이너 플러그인을 사용하여 VMware NSX-T와 통합될 수 있습니다. 이 통합을 통해 쿠버네티스에서 “기본 제공되지 않는” 멀티 테넌트 네트워크 토폴로지를 사용할 수 있습니다.
쿠버네티스 네트워킹 모델은 다음과 같은 기능을 제공합니다:
- 모든 컨테이너는 NAT 없이 클러스터 내 다른 모든 컨테이너와 통신할 수 있습니다.
- 모든 클러스터 노드는 NAT 없이 클러스터 내 모든 컨테이너와 통신할 수 있습니다. 역으로, 모든 컨테이너는 모든 클러스터 노드와 통신할 수 있습니다.
- 컨테이너는 자신의 IP 주소를 보고, 쿠버네티스의 다른 구성 요소들도 해당 IP 주소를 볼 수 있습니다.
Ingress는 쿠버네티스의 API 객체로, 클러스터 외부에서 서비스에 대한 액세스를 관리하는 데 사용됩니다(주로 HTTP 및 HTTPS). Ingress를 구성하여 컨테이너화된 서비스에 대한 외부 액세스, 로드 밸런싱, SSL 종료 및 이름 기반 가상 호스팅을 수행할 수 있습니다. Ingress 컨트롤러는 Ingress 규칙이 작동하려면 마스터 노드에 배포되어야 합니다.
사용 사례
독립형 소프트웨어로 Docker를 사용하는 것은 응용 프로그램 개발에 좋습니다. 개발자는 응용 프로그램을 격리된 환경에서 실행할 수 있습니다. 또한 테스터는 샌드박스 환경에서 응용 프로그램을 실행하는 데 Docker를 사용할 수도 있습니다. 프로덕션 환경에서 Docker를 사용하여 많은 수의 컨테이너를 실행하려는 경우 일부 문제에 직면할 수 있습니다. 예를 들어, 일부 컨테이너는 쉽게 과부하가 걸리거나 실패할 수 있습니다. 해당하는 머신에서 컨테이너를 수동으로 다시 시작할 수 있지만, 수동 관리는 많은 시간과 에너지를 소비할 수 있습니다.
쿠버네티스는 고 가용성, 로드 밸런싱, 컨테이너 오케스트레이션 도구 등과 같은 주요 기능을 제공함으로써 이러한 문제를 해결할 수 있습니다. 결과적으로 쿠버네티스는 많은 수의 Docker 컨테이너를 포함하는 고 부하 프로덕션 환경에 가장 적합합니다. 독립형 Docker 응용 프로그램을 설치하는 것보다 쿠버네티스를 배포하는 것이 더 어렵기 때문에 쿠버네티스는 항상 개발 및 테스트에 사용되지 않을 수 있습니다.
쿠버네티스 대 Docker Swarm
Docker Swarm는 도커의 기본 클러스터링 도구로, 도커 호스트 풀을 단일 가상 호스트로 변환할 수 있습니다. Docker Swarm은 Docker Engine과 완전히 통합되어 표준 API 및 네트워킹 프로세스를 사용할 수 있게 해주며, Docker 컨테이너를 배포, 관리 및 확장하는 데 사용됩니다.
Swarm은 노드라고 불리는 Docker 호스트의 클러스터입니다. Docker Swarm을 사용할 때 다음과 같은 클러스터의 주요 구성 요소를 고려해보겠습니다. Kubernetes와 Docker Swarm의 클러스터 배포를 비교하기 전에:
매니저 노드는 제어 오케스트레이션, 클러스터 관리 및 작업 분배를 수행하는 데 사용됩니다.
워커 노드는 매니저 노드가 할당한 작업을 실행하는 데 사용됩니다. 각 노드는 매니저 노드, 워커 노드 또는 둘 다로 구성할 수 있어 매니저 및 워커 노드 기능을 모두 수행할 수 있습니다. 워커 노드가 스웜 서비스를 실행합니다.
서비스. Docker Swarm의 서비스는 각 컨테이너화된 서비스에 대한 필요한 최적의 상태를 정의합니다. 서비스는 복제본 수, 해당 서비스에 대한 사용 가능한 네트워크 리소스, 외부 네트워크에서 액세스할 수 있어야 하는 포트 등과 같은 매개변수를 제어합니다. 서비스 구성(네트워크 구성과 같은)은 서비스를 수동으로 컨테이너와 함께 다시 시작할 필요 없이 수정하고 적용할 수 있습니다.
작업. 작업은 단일 컨테이너가 실행되는 슬롯입니다. 작업은 스웜 서비스의 일부입니다.
클러스터 배포
Docker Swarm. 표준 Docker API를 사용하여 표준 Docker CLI(명령 줄 인터페이스)를 통해 Swarm을 배포할 수 있으며, 이는 배포를 처음 시도할 때 특히 배포를 쉽게 만듭니다. Swarm의 배포 용이성은 단일 Docker 마스터가 서비스를 배포하는 방법을 결정할 수 있는 능력에 의해서도 달성됩니다. Docker Swarm에서는 Pods를 사용하지 않습니다.
Kubernetes는 표준 Docker 명령과 다른 지정된 명령을 사용해야 합니다. Kubernetes에서는 지정된 API가 사용되므로 Docker 관리 명령을 알고 있더라도 Kubernetes 배포를 위해 추가 도구 집합을 사용해야 할 수 있습니다. 노드는 Kubernetes 클러스터에서 수동으로 정의되어야 합니다. 마스터 노드를 선택하고 컨트롤러, 스케줄러 등을 정의해야 합니다.
확장성
Docker Swarm. Docker에서 제공하는 간단한 API 덕분에 대규모 및 소규모 클러스터에서 컨테이너 및 서비스 업데이트를 빠르게 수행할 수 있습니다. 명령 줄 인터페이스(CLI)는 매우 간단하고 이해하기 쉽습니다. 결과적으로 Swarm은 Kubernetes와 비교했을 때 더 확장 가능한 솔루션으로 간주될 수 있습니다.
Kubernetes은 상대적으로 통합된 API를 제공하며, 종종 느린 배포 과정을 야기하는 여러 기능을 제공합니다. 구성해야 하는 구성 요소는 Pod, Deploy, Service 세 가지 유형이 있습니다. 오토 스케일링에 대해 이야기할 때, Kubernetes는 서버 부하를 분석하고 주어진 요구 사항에 따라 자동으로 확장 및 축소할 수 있는 능력 때문에 선호됩니다. Kubernetes는 대규모 분산 네트워크와 복잡한 시스템에 대한 최적의 선택지입니다.
고가용성
두 가지 솔루션 옵션 모두 유사한 서비스 복제 및 중복 메커니즘을 갖추고 있으며, 양쪽 모두 시스템이 자체 조정되며 실패한 노드가 클러스터로 다시 돌아온 후 수동으로 다시 구성할 필요가 없습니다.
Docker Swarm. 관리자 노드는 작업자 노드 및 전체 클러스터의 리소스를 처리합니다. 스웜 클러스터 노드는 서비스를 복제하는 데 참여합니다.
Kubernetes. Kubernetes의 로드 밸런싱 서비스에 의해 비정상적인 노드가 감지되고 클러스터에서 제거됩니다. 모든 Pod는 노드 간에 분산되어 있어, 컨테이너화된 응용 프로그램이 실행되는 노드가 실패할 경우에도 고가용성을 제공합니다.
로드 밸런싱
Docker Swarm. 로드 밸런싱은 내부 스웜 네트워크를 사용하여 자동으로 수행될 수 있는 내장 기능입니다. 클러스터로의 모든 요청은 분산되어 클러스터 노드로 리디렉션되며, 모든 노드가 모든 컨테이너에 연결할 수 있습니다. Docker Swarm은 서비스 이름으로 들어오는 요청을 분배하기 위해 DNS 요소를 사용합니다.
쿠버네티스. 파드에 정의된 정책은 쿠버네티스에서 로드 밸런싱에 사용됩니다. 이 경우, 컨테이너 파드는 서비스로 정의되어야 합니다. 로드 밸런싱 설정은 수동으로 구성해야 하며, 이 때 Ingress를 사용할 수 있습니다.
컨테이너 생성 및 실행
도커 스웜. 도커 CLI에 사용 가능한 대부분의 명령어는 도커 스웜을 사용할 때에도 사용할 수 있습니다. 이는 도커 스웜의 표준화된 API 덕분입니다. 도커 컴포즈는 볼륨 및 사용된 네트워크 설정을 정의하고, 어떤 컨테이너가 함께 그룹화되어야 하는지도 정의합니다. 도커 스웜에 대한 도커 컴포즈에서 정확한 복제본 수를 설정할 수 있습니다.
쿠버네티스. 쿠버네티스는 자체 API, 클라이언트를 갖고 있으며 YAML 파일을 구성해야 합니다. 이것은 도커 컴포즈와 도커 CLI가 이 경우 컨테이너를 배포하는 데 사용될 수 없다는 주요 차이 중 하나입니다. 쿠버네티스에서 서비스를 정의하는 시스템은 도커 컴포즈와 유사한 작동 원리를 따르지만 더 복잡합니다. 도커 컴포즈의 기능은 쿠버네티스에서 파드, 배포 및 서비스를 사용하여 수행됩니다. 각 레이어는 고유한 목적에 사용됩니다. 파드는 컨테이너 상호 작용을 담당하며, 배포는 클러스터 내 단일 노드에 대한 고가용성 및 네트워킹을 담당합니다(스웜 없이 독립적인 도커 애플리케이션에 대한 도커 컴포즈와 유사함). 쿠버네티스 서비스는 클러스터 내부에서 서비스 작동 구성, 내결함성 등을 담당합니다.
네트워킹
Docker Swarm. 클러스터 내 컨테이너 간 통신을 위한 기본 내부 네트워크가 하나 있으며 필요한 경우 더 많은 네트워크를 추가할 수 있습니다. 네트워크는 생성된 TLS 인증서로 보호됩니다. 컨테이너 데이터 트래픽의 암호화를 위해 수동으로 인증서를 생성하는 것이 지원됩니다.
Kubernetes. Kubernetes의 네트워크 모델은 상당히 다르며 플러그인을 사용하여 구현됩니다. 그 중 하나는 가장 인기 있는 옵션인 Flannel입니다. 파드는 서로 상호 작용하며 이 상호 작용은 정책으로 제한될 수 있습니다. etcd 서비스에 의해 관리되는 내부 네트워크가 있습니다. TLS 암호화도 사용할 수 있지만 수동으로 구성해야 합니다. Kubernetes 네트워킹 모델은 슈퍼네팅으로 알려진 CIDR(Classless Inter-Domain Routing)을 구성하는 것을 가정합니다.
모니터링
Docker Swarm. 모니터링 및 로깅을 위한 내장 도구가 없지만 수동으로 서드파티 모니터링 도구를 설정할 수 있습니다. 이를 위해 ELK 또는 Reimann을 사용할 수 있습니다.
Kubernetes. 로깅 및 모니터링을 위해 Kubernetes에서 내장 도구가 제공됩니다. Elasticsearch 및 Kibana(ELK)는 전체 클러스터 상태를 모니터링하는 데 사용될 수 있으며 Heapster, Grafana 및 Influx는 컨테이너 서비스를 모니터링하는 데 지원됩니다.
그래픽 사용자 인터페이스 (GUI)
Docker Swarm. GUI는 사용자 친화적인 웹 인터페이스를 제공하는 Portainer.io와 같은 서드파티 도구를 사용하여 활성화할 수 있습니다. 대안으로, 클러스터 관리를 위한 그래픽 인터페이스를 제공하는 Docker의 엔터프라이즈 에디션을 사용할 수 있습니다.
쿠버네티스. 쿠버네티스에서 제공하는 GUI는 웹 인터페이스를 통해 접근할 수 있는 신뢰할 수 있는 대시보드로, 클러스터를 쉽게 제어할 수 있습니다. CLI로 쿠버네티스를 관리하는 데 경험이 적은 사용자에게는 GUI가 매우 가치 있는 도구일 수 있습니다.
결론
도커 스웜은 주로 도커 API 및 CLI를 사용하는 네이티브 도커 솔루션입니다. 그에 반해, 쿠버네티스는 구글의 프로젝트로, 컨테이너가 실행되는 클러스터를 배포하는 데 사용됩니다.
도커 스웜과 쿠버네티스는 모두 고가용성, 부하 분산, 오버레이 네트워킹 및 확장성 기능을 제공합니다. 도커 스웜은 배포에 더 쉽고, 대부분의 기능 구성이 자동화되며, 하드웨어 리소스를 적게 소비합니다. 그러나 기능은 도커 API에 의해 제한되고, 네이티브 모니터링 도구가 없습니다.
한편, 쿠버네티스는 대다수의 대기업이 지원하는 고도로 유연한 모듈식 솔루션으로, 수 년 동안 지원되어 왔습니다. 쿠버네티스에는 서비스 및 전체 클러스터를 모니터링하기 위한 내장 도구가 있지만, 배포 및 구성은 더 어렵기 때문에 이 자원은 보다 요구되는 솔루션입니다. 쿠버네티스는 도커 CLI 및 도커 컴포즈와 호환되지 않습니다. 고부하의 멀티 컨테이너 애플리케이션이 실행되는 대규모 환경에서는 쿠버네티스를 사용하는 것이 좋습니다.