Mesos 대 Kubernetes

1. 개요

이 자습서에서는 컨테이너 오케스트레이션 시스템의 기본 요구 사항을 이해합니다.

그러한 시스템의 원하는 특성을 평가할 것입니다. 그로부터 오늘날 사용되는 가장 인기있는 컨테이너 오케스트레이션 시스템 인 Apache Mesos와 Kubernetes를 비교해 보겠습니다.

2. 컨테이너 오케스트레이션

Mesos와 Kubernetes를 비교하기 전에 컨테이너가 무엇이며 결국 컨테이너 오케스트레이션이 필요한 이유를 이해하는 데 시간을 투자 해 보겠습니다.

2.1. 컨테이너

컨테이너는 소프트웨어의 표준화 된 단위 패키지 코드와 모든 필요한 의존성이 .

따라서 플랫폼 독립성과 운영 단순성을 제공합니다. Docker는 가장 많이 사용되는 컨테이너 플랫폼 중 하나입니다.

Docker 는 CGroups 및 네임 스페이스와 같은 Linux 커널 기능을 활용 하여 다양한 프로세스를 격리 합니다. 따라서 여러 컨테이너를 독립적이고 안전하게 실행할 수 있습니다.

Docker 이미지를 만드는 것은 매우 간단하며 Dockerfile 만 있으면됩니다.

FROM openjdk:8-jdk-alpine VOLUME /tmp COPY target/hello-world-0.0.1-SNAPSHOT.jar app.jar ENTRYPOINT ["java","-jar","/app.jar"] EXPOSE 9001

따라서 다음 몇 줄은 Docker CLI를 사용하여 Spring Boot 애플리케이션의 Docker 이미지를 생성하기에 충분합니다.

docker build -t hello_world .

2.2. 컨테이너 오케스트레이션

따라서 컨테이너가 애플리케이션 배포를 안정적이고 반복 가능하게 만드는 방법을 살펴 보았습니다. 하지만 컨테이너 오케스트레이션이 필요한 이유는 무엇입니까?

이제 관리 할 컨테이너가 몇 개 있지만 Docker CLI는 괜찮습니다. 간단한 집안일도 자동화 할 수 있습니다. 하지만 수백 개의 컨테이너를 관리해야한다면 어떻게 될까요?

예를 들어, 모두 고유 한 확장 성과 가용성 요구 사항이있는 여러 마이크로 서비스가있는 아키텍처를 생각해보십시오.

결과적으로 상황이 빠르게 제어되지 않을 수 있으며 컨테이너 오케스트레이션 시스템의 이점이 실현됩니다. 컨테이너 오케스트레이션 시스템은 단일 배포 엔티티와 같은 멀티 컨테이너 응용 프로그램과 기계의 클러스터를 처리합니다 . 초기 배포, 예약, 모니터링, 확장 및 장애 조치와 같은 다른 기능에 대한 업데이트에서 자동화를 제공합니다.

3. Mesos의 간략한 개요

Apache Mesos는 원래 UC Berkeley에서 개발 된 오픈 소스 클러스터 관리자입니다 . 클러스터 전체에서 리소스 관리 및 스케줄링을위한 API를 애플리케이션에 제공합니다. Mesos는 분산 방식으로 컨테이너화 된 워크로드와 컨테이너화되지 않은 워크로드를 모두 실행할 수있는 유연성을 제공합니다.

3.1. 건축물

Mesos 아키텍처는 Mesos Master, Mesos Agent 및 애플리케이션 프레임 워크로 구성됩니다.

여기서 아키텍처의 구성 요소를 이해해 보겠습니다.

  • 프레임 워크 : 작업 또는 워크로드의 분산 실행이 필요한 실제 애플리케이션입니다 . 일반적인 예는 Hadoop 또는 Storm입니다. Mesos의 프레임 워크는 두 가지 기본 구성 요소로 구성됩니다.
    • 스케줄러 : 마스터가 리소스 제공을 시작할 수 있도록 마스터 노드에 등록하는 역할을 합니다.
    • Executor : 프레임 워크의 작업을 실행하기 위해 에이전트 노드 에서 시작되는 프로세스입니다.
  • Mesos Agents : 이들은 실제로 작업을 실행하는 역할을합니다 . 각 에이전트는 CPU 및 메모리와 같은 사용 가능한 리소스를 마스터에 게시합니다. 마스터로부터 작업을 받으면 필요한 리소스를 프레임 워크의 실행기에 할당합니다.
  • Mesos Master : 사용 가능한 에이전트 노드 중 하나 에서 프레임 워크 에서 수신 한 작업을 예약합니다 . 마스터는 프레임 워크에 리소스를 제공합니다. 프레임 워크의 스케줄러는 이러한 사용 가능한 리소스에서 작업을 실행하도록 선택할 수 있습니다.

3.2. 마라톤

방금 본 것처럼 Mesos는 매우 유연하며 프레임 워크가 잘 정의 된 API를 통해 작업을 예약하고 실행할 수 있습니다. 그러나 특히 사용자 지정 응용 프로그램을 예약하려는 경우 이러한 기본 요소를 직접 구현하는 것은 편리하지 않습니다. 예를 들어, 컨테이너로 패키징 된 애플리케이션을 오케스트레이션합니다.

마라톤과 같은 프레임 워크가 우리를 도울 수있는 곳입니다. Marathon 은 Mesos에서 실행되는 컨테이너 오케스트레이션 프레임 워크입니다 . 이와 관련하여 Marathon은 Mesos 클러스터의 프레임 워크 역할을합니다. Marathon은 서비스 검색,로드 밸런싱, 메트릭 및 컨테이너 관리 API와 같은 오케스트레이션 플랫폼에서 일반적으로 기대하는 몇 가지 이점을 제공합니다.

Marathon 은 장기 실행 서비스를 애플리케이션 으로, 애플리케이션 인스턴스를 태스크로 취급합니다. 일반적인 시나리오에는 애플리케이션 그룹이라는 것을 형성하는 종속성이있는 여러 애플리케이션이있을 수 있습니다.

3.3. 예

이제 Marathon을 사용하여 앞서 만든 간단한 Docker 이미지를 배포하는 방법을 살펴 보겠습니다. Mesos 클러스터를 설치하는 것은 거의 관여 할 수 없으므로 Mesos Mini와 같은보다 간단한 솔루션을 사용할 수 있습니다. Mesos Mini를 사용하면 Docker 환경에서 로컬 Mesos 클러스터를 가동 할 수 있습니다. 여기에는 Mesos Master, 단일 Mesos Agent 및 Marathon이 포함됩니다.

Marathon을 사용하여 Mesos 클러스터를 실행하고 나면 컨테이너를 장기 실행 애플리케이션 서비스로 배포 할 수 있습니다. 작은 JSON 애플리케이션 정의 만 있으면됩니다.

#hello-marathon.json { "id": "marathon-demo-application", "cpus": 1, "mem": 128, "disk": 0, "instances": 1, "container": { "type": "DOCKER", "docker": { "image": "hello_world:latest", "portMappings": [ { "containerPort": 9001, "hostPort": 0 } ] } }, "networks": [ { "mode": "host" } ] }

여기서 정확히 무슨 일이 일어나고 있는지 이해합시다.

  • 애플리케이션에 대한 ID를 제공했습니다.
  • 그런 다음 애플리케이션에 대한 리소스 요구 사항을 정의했습니다.
  • 또한 실행할 인스턴스 수를 정의했습니다.
  • 그런 다음, 앱을 시작하기위한 컨테이너 세부 정보를 제공했습니다.
  • 마지막으로 애플리케이션에 액세스 할 수 있도록 네트워크 모드를 정의했습니다.

Marathon에서 제공하는 REST API를 사용하여이 애플리케이션을 시작할 수 있습니다.

curl -X POST \ //localhost:8080/v2/apps \ -d @hello-marathon.json \ -H "Content-type: application/json"

4. Kubernetes의 간략한 개요

Kubernetes는 Google에서 처음 개발 한 오픈 소스 컨테이너 조정 시스템 입니다. 이제 CNCF (Cloud Native Computing Foundation)의 일부입니다. 호스트 클러스터에서 애플리케이션 컨테이너의 배포, 확장 및 운영을 자동화하기위한 플랫폼을 제공합니다.

4.1. 건축물

Kubernetes 아키텍처는 Kubernetes 마스터 및 Kubernetes 노드로 구성됩니다.

이 고급 아키텍처의 주요 부분을 살펴 보겠습니다.

  • Kubernetes Master: The master is responsible for maintaining the desired state of the cluster. It manages all nodes in the cluster. As we can see, the master is a collection of three processes:
    • kube-apiserver: This is the service that manages the entire cluster, including processing REST operations, validating and updating Kubernetes objects, performing authentication and authorization
    • kube-controller-manager: This is the daemon that embeds the core control loop shipped with Kubernetes, making the necessary changes to match the current state to the desired state of the cluster
    • kube-scheduler: This service watches for unscheduled pods and binds them to nodes depending upon requested resources and other constraints
  • Kubernetes Nodes: The nodes in a Kubernetes cluster are the machines that run our containers. Each node contains the necessary services to run the containers:
    • kubelet: This is the primary node agent which ensures that the containers described in PodSpecs provided by kube-apiserver are running and healthy
    • kube-proxy: This is the network proxy running on each node and performs simple TCP, UDP, SCTP stream forwarding or round-robin forwarding across a set of backends
    • container runtime: This is the runtime where container inside the pods are run, there are several possible container runtimes for Kubernetes including the most widely used, Docker runtime

4.2. Kubernetes Objects

In the last section, we saw several Kubernetes objects which are persistent entities in the Kubernetes system. They reflect the state of the cluster at any point in time.

Let's discuss some of the commonly used Kubernetes objects:

  • Pods: Pod is a basic unit of execution in Kubernetes and can consist of one or more containers, the containers inside a Pod are deployed on the same host
  • Deployment: Deployment is the recommended way to deploy pods in Kubernetes, it provides features like continuously reconciling the current state of pods with the desired state
  • Services: Services in Kubernetes provide an abstract way to expose a group of pods, where the grouping is based on selectors targetting pod labels

There are several other Kubernetes objects which serve the purpose of running containers in a distributed manner effectively.

4.3. Example

So, now we can try to launch our Docker container into the Kubernetes cluster. Kubernetes provides Minikube, a tool that runs single-node Kubernetes cluster on a Virtual Machine. We'd also need kubectl, the Kubernetes Command Line Interface to work with the Kubernetes cluster.

After we've kubectl and Minikube installed, we can deploy our container on the single-node Kubernetes cluster within Minikube. We need to define the basic Kubernetes objects in a YAML file:

# hello-kubernetes.yaml apiVersion: apps/v1 kind: Deployment metadata: name: hello-world spec: replicas: 1 template: metadata: labels: app: hello-world spec: containers: - name: hello-world image: hello-world:latest ports: - containerPort: 9001 --- apiVersion: v1 kind: Service metadata: name: hello-world-service spec: selector: app: hello-world type: LoadBalancer ports: - port: 9001 targetPort: 9001

A detailed analysis of this definition file is not possible here, but let's go through the highlights:

  • We have defined a Deployment with labels in the selector
  • We define the number of replicas we need for this deployment
  • Also, we've provided the container image details as a template for the deployment
  • We've also defined a Service with appropriate selector
  • We've defined the nature of the service as LoadBalancer

Finally, we can deploy the container and create all defined Kubernetes objects through kubectl:

kubectl apply -f yaml/hello-kubernetes.yaml

5. Mesos vs. Kubernetes

Now, we've gone through enough context and also performed basic deployment on both Marathon and Kubernetes. We can attempt to understand where do they stand compared to each other.

Just a caveat though, it's not entirely fair to compare Kubernetes with Mesos directly. Most of the container orchestration features that we seek are provided by one of the Mesos frameworks like Marathon. Hence, to keep things in the right perspective, we'll attempt to compare Kubernetes with Marathon and not directly Mesos.

We'll compare these orchestration systems based on some of the desired properties of such a system.

5.1. Supported Workloads

Mesos is designed to handle diverse types of workloads which can be containerized or even non-containerised. It depends upon the framework we use. As we've seen, it's quite easy to support containerized workloads in Mesos using a framework like Marathon.

Kubernetes, on the other hand, works exclusively with the containerized workload. Most widely, we use it with Docker containers, but it has support for other container runtimes like Rkt. In the future, Kubernetes may support more types of workloads.

5.2. Support for Scalability

Marathon supports scaling through the application definition or the user interface. Autoscaling is also supported in Marathon. We can also scale Application Groups which automatically scales all the dependencies.

As we saw earlier, Pod is the fundamental unit of execution in Kubernetes. Pods can be scaled when managed by Deployment, this is the reason pods are invariably defined as a deployment. The scaling can be manual or automated.

5.3. Handling High Availability

Application instances in Marathon are distributed across Mesos agents providing high availability. Typically a Mesos cluster consists of multiple agents. Additionally, ZooKeeper provides high availability to the Mesos cluster through quorum and leader election.

Similarly, pods in Kubernetes are replicated across multiple nodes providing high availability. Typically a Kubernetes cluster consists of multiple worker nodes. Moreover, the cluster can also have multiple masters. Hence, Kubernetes cluster is capable of providing high availability to containers.

5.4. Service Discovery and Load Balancing

Mesos-DNS can provide service discovery and a basic load balancing for applications. Mesos-DNS generates an SRV record for each Mesos task and translates them to the IP address and port of the machine running the task. For Marathon applications, we can also use Marathon-lb to provide port-based discovery using HAProxy.

Deployment in Kubernetes creates and destroys pods dynamically. Hence, we generally expose pods in Kubernetes through Service, which provides service discovery. Service in Kubernetes acts as a dispatcher to the pods and hence provide load balancing as well.

5.5 Performing Upgrades and Rollback

Changes to application definitions in Marathon is handled as deployment. Deployment supports start, stop, upgrade, or scale of applications. Marathon also supports rolling starts to deploy newer versions of the applications. However, rolling back is as straight forward and typically requires the deployment of an updated definition.

Deployment in Kubernetes supports upgrade as well as rollback. We can provide the strategy for Deployment to be taken while relacing old pods with new ones. Typical strategies are Recreate or Rolling Update. Deployment's rollout history is maintained by default in Kubernetes, which makes it trivial to roll back to a previous revision.

5.6. Logging and Monitoring

Mesos has a diagnostic utility which scans all the cluster components and makes available data related to health and other metrics. The data can be queried and aggregated through available APIs. Much of this data we can collect using an external tool like Prometheus.

Kubernetes publish detailed information related to different objects as resource metrics or full metrics pipelines. Typical practice is to deploy an external tool like ELK or Prometheus+Grafana on the Kubernetes cluster. Such tools can ingest cluster metrics and present them in a much user-friendly way.

5.7. Storage

Mesos has persistent local volumes for stateful applications. We can only create persistent volumes from the reserved resources. It can also support external storage with some limitations. Mesos has experimental support for Container Storage Interface (CSI), a common set of APIs between storage vendors and container orchestration platform.

Kubernetes offers multiple types of persistent volume for stateful containers. This includes storage like iSCSI, NFS. Moreover, it supports external storage like AWS, GCP as well. The Volume object in Kubernetes supports this concept and comes in a variety of types, including CSI.

5.8. Networking

Container runtime in Mesos offers two types of networking support, IP-per-container, and network-port-mapping. Mesos defines a common interface to specify and retrieve networking information for a container. Marathon applications can define a network in host mode or bridge mode.

Networking in Kubernetes assigns a unique IP to each pod. This negates the need to map container ports to the host port. It further defines how these pods can talk to each other across nodes. This is implemented in Kubernetes by Network Plugins like Cilium, Contiv.

6. When to Use What?

Finally, in comparison, we usually expect a clear verdict! However, it's not entirely fair to declare one technology better than another, regardless. As we've seen, both Kubernetes and Mesos are powerful systems and offers quite competing features.

Performance, however, is quite a crucial aspect. A Kubernetes cluster can scale to 5000-nodes while Marathon on Mesos cluster is known to support up to 10,000 agents. In most practical cases, we'll not be dealing with such large clusters.

Finally, it boils down to the flexibility and types of workloads that we've. If we're starting afresh and we only plan to use containerized workloads, Kubernetes can offer a quicker solution. However, if we've existing workloads, which are a mix of containers and non-containers, Mesos with Marathon can be a better choice.

7. Other Alternatives

Kubernetes and Apache Mesos are quite powerful, but they are not the only systems in this space. There are quite several promising alternatives available to us. While we'll not go into their details, let's quickly list a few of them:

  • Docker Swarm: Docker Swarm is an open-source clustering and scheduling tool for Docker containers. It comes with a command-line utility to manage a cluster of Docker hosts. It's restricted to Docker containers, unlike Kubernetes and Mesos.
  • Nomad: Nomad is a flexible workload orchestrator from HashiCorp to manage any containerized or non-containerised application. Nomad enables declarative infrastructure-as-code for deploying applications like Docker container.
  • OpenShift: OpenShift is a container platform from Red Hat, orchestrated and managed by Kubernetes underneath. OpenShift offers many features on top of what Kubernetes provide like integrated image registry, a source-to-image build, a native networking solution, to name a few.

8. Conclusion

요약하자면이 자습서에서는 컨테이너 및 컨테이너 오케스트레이션 시스템에 대해 설명했습니다. 가장 널리 사용되는 두 가지 컨테이너 오케스트레이션 시스템 인 Kubernetes와 Apache Mesos를 간단히 살펴 보았습니다. 또한 여러 기능을 기반으로 이러한 시스템을 비교했습니다. 마지막으로 우리는이 공간에서 다른 대안을 보았습니다.

종료하기 전에 그러한 비교의 목적이 데이터와 사실을 제공하는 것임을 이해해야합니다. 이것은 다른 것보다 더 나은 것을 선언하는 방법이 아니며 일반적으로 사용 사례에 따라 다릅니다. 따라서 우리를위한 최상의 솔루션을 결정할 때 문제의 맥락을 적용해야합니다.