開発者ドキュメント

mesos-kubernetes-comparison

getdocs

メソス対 クベルネテス

1. 概要

このチュートリアルでは、コンテナオーケストレーションシステムの基本的な必要性を理解します。
このようなシステムの望ましい特性を評価します。 それから、今日使用されている最も人気のある2つのコンテナオーケストレーションシステム、https：//mesos.apache.org/ [Apache Mesos]とhttps://kubernetes.io/[Kubernetes]を比較してみます。

2. コンテナオーケストレーション

MesosとKubernetesの比較を始める前に、コンテナとは何か、結局コンテナオーケストレーションが必要な理由を理解するのに時間をかけましょう。

2.1. コンテナ

  • A * コンテナは、コードとそのすべての必要な依存関係をパッケージ化するソフトウェアの標準化されたユニットです。

    したがって、プラットフォームに依存せず、操作が簡単です。 Dockerは、使用されている最も人気のあるコンテナープラットフォームの1つです。
    https://www.docker.com [Docker]は、Linuxカーネル* CGroupsや名前空間などの機能を活用して、さまざまなプロセスを分離*します。 したがって、複数のコンテナを独立して安全に実行できます。
    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で問題ありません。 いくつかの単純な雑用も自動化できます。 しかし、*何百ものコンテナを管理しなければならない場合はどうなりますか？*
たとえば、いくつかのマイクロサービスを備えたアーキテクチャを考えてみましょう。すべてのマイクロサービスには、明確なスケーラビリティと可用性の要件があります。
その結果、物事はすぐに制御不能になる可能性があり、それがコンテナオーケストレーションシステムの利点が実現するところです。 * A * *コンテナオーケストレーションシステムは、マルチコンテナアプリケーションを持つマシンのクラスタを単一の展開エンティティとして扱います*。 初期展開、スケジューリング、監視、スケーリング、フェイルオーバーなどの他の機能の更新から自動化を提供します。

3. Mesosの簡単な概要

Apache Mesosは、* UC Berkeleyで開発されたオープンソースのクラスターマネージャーです。 クラスター全体のリソース管理とスケジューリングのためのAPIをアプリケーションに提供します。 Mesosは、コンテナ化されたワークロードとコンテナ化されていないワークロードの両方を分散的に実行する柔軟性を提供します。

3.1. 建築

Mesosアーキテクチャは、Mesos Master、Mesos Agent、およびApplication Frameworkで構成されています。
link:/uploads/Screenshot-2019-08-27-at-08.25.01-100x67.png%20100w []
ここでアーキテクチャのコンポーネントを理解しましょう：

  • Frameworks：これらは、実際に必要なアプリケーションです
    タスクまたはワークロードの分散実行    。 典型的な例は、HadoopまたはStormです。 Mesosのフレームワークは、2つの主要コンポーネントで構成されています。

  • Scheduler：これは*マスターへの登録を担当します
    マスター*がリソースの提供を開始できるノード*

  • Executor：これは*エージェントで起動されるプロセスです
    フレームワークのタスクを実行するノード*

  • Mesos Agents：これらは*実際に実行する責任があります
    タスク*。 各エージェントは、CPUやメモリなどの利用可能なリソースをマスターに公開します。 マスターからタスクを受信すると、必要なリソースをフレームワークのエグゼキューターに割り当てます。

  • Mesos Master：これは、*受信したタスクのスケジューリングを担当します
    使用可能なエージェントノードの1つにあるFrameworks *から。 マスターはフレームワークにリソースを提供します。 フレームワークのスケジューラは、これらの利用可能なリソースでタスクを実行することを選択できます。

3.2. マラソン

先ほど見たように、Mesosは非常に柔軟で、明確に定義されたAPIを通じてlink:/apache-mesos [フレームワークがタスクをスケジュールおよび実行できるようにします]。 ただし、これらのプリミティブを直接実装することは、特にカスタムアプリケーションをスケジュールする場合には便利ではありません。 たとえば、コンテナとしてパッケージ化されたアプリケーションのオーケストレーション。
これは、https：//mesosphere.github.io/marathon/ [Marathon]のようなフレームワークが役立つ場所です。 Marathonは、Mesosで実行されるコンテナオーケストレーションフレームワークです。 この点で、マラソンはMesosクラスターのフレームワークとして機能します。 Marathonは、サービス検出、負荷分散、メトリック、コンテナ管理APIなどのオーケストレーションプラットフォームに通常期待されるいくつかの利点を提供します。
Marathonは、長期実行サービスをアプリケーションとして、アプリケーションインスタンスをタスクとして扱います。 典型的なシナリオでは、https：//mesosphere.github.io/marathon/docs/application-groups.html [Application Groups]と呼ばれるものを形成する依存関係を持つ複数のアプリケーションを使用できます。

3.3. 例

それでは、先ほど作成したシンプルなDockerイメージをMarathonを使用して展開する方法を見てみましょう。 Mesosクラスターのインストールはほとんど関与しないため、https：//mesos.apache.org/blog/mesos-mini/ [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 \
  http://localhost:8080/v2/apps \
  -d @hello-marathon.json \
  -H "Content-type: application/json"

4. Kubernetesの簡単な概要

Kubernetesは、* Googleによって最初に開発されたlink:/kubernetes [オープンソースコンテナオーケストレーションシステム]です。 現在はhttps://www.cncf.io/[Cloud Native Computing Foundation]（CNCF）の一部です。 ホストのクラスター全体でアプリケーションコンテナーの展開、スケーリング、および操作を自動化するためのプラットフォームを提供します。

4.1. 建築

Kubernetesアーキテクチャは、KubernetesマスターとKubernetesノードで構成されます。
link:/uploads/Screenshot-2019-08-27-at-08.25.09-100x67.png%20100w []
この高レベルアーキテクチャの主要部分を見ていきましょう。

  • Kubernetes Master：* masterは、
    クラスターの望ましい状態*。 クラスタ内のすべてのノードを管理します。 ご覧のとおり、マスターは3つのプロセスの集合です。

  • kube-apiserver：これは*全体を管理するサービスです
    クラスター*（REST操作の処理、Kubernetesオブジェクトの検証と更新、認証と承認の実行を含む）

  • kube-controller-manager：これは、コアを埋め込むデーモンです
    Kubernetesに付属の制御ループ    。現在の状態をクラスターの目的の状態に一致させるために必要な変更を行います。

  • kube-scheduler：このサービスは、予定外のポッドを監視し、
    要求されたリソースおよびその他の制約に応じて、それらをノードにバインドします

  • Kubernetes Nodes：Kubernetesクラスターのノードはマシンです
    コンテナを実行します。 各ノードには、コンテナを実行するために必要なサービスが含まれています。

  • kubelet：これは*プライマリノードエージェント*であり、
    _kube-apiserver_が提供するPodSpecsで説明されているコンテナが実行されており、正常である

  • kube-proxy：これは*各ノードで実行されているネットワークプロキシ*および
    バックエンドのセット全体で単純なTCP、UDP、SCTPストリーム転送またはラウンドロビン転送を実行します

  • container runtime：これは、コンテナ内のコンテナのランタイムです
    ポッドは実行されます    、最も広く使用されているDockerランタイムを含むKubernetesのコンテナーランタイムがいくつかあります

4.2. Kubernetesオブジェクト

最後のセクションでは、Kubernetesシステムの永続的なエンティティであるKubernetesオブジェクトをいくつか見ました。 それらは、任意の時点でのクラスターの状態を反映します。
一般的に使用されるKubernetesオブジェクトのいくつかについて説明しましょう。

  • ポッド：ポッドは* Kubernetesの実行の基本単位*で構成できます
    1つ以上のコンテナの場合、Pod内のコンテナは同じホストにデプロイされます

  • 展開：展開は*ポッドを展開する推奨方法です
    Kubernetes *、ポッドの現在の状態を目的の状態に継続的に調整するなどの機能を提供します

  • サービス：Kubernetesのサービス*を公開する抽象的な方法を提供
    ポッドのグループ*。グループ化は、ポッドラベルをターゲットとするセレクターに基づいています。

    コンテナを効果的に分散して実行する目的に役立つ他のKubernetesオブジェクトがいくつかあります。

4.3. 例

したがって、DockerコンテナーをKubernetesクラスターに起動することができます。 Kubernetesは、https：//kubernetes.io/docs/tasks/tools/install-minikube/ [Minikube]を提供します。これは、仮想マシン上でシングルノードKubernetesクラスターを実行するツールです。 また、Kubernetesクラスターを使用するには、Kubernetesコマンドラインインターフェイスであるhttps://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux[kubectl]も必要です。
kubectlとMinikubeをインストールしたら、Minikube内の単一ノードKubernetesクラスターにコンテナーを展開できます。 YAMLファイルで基本的なKubernetesオブジェクトを定義する必要があります。
# 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
この定義ファイルの詳細な分析はここでは不可能ですが、ハイライトを見ていきましょう。

  • セレクターにラベルを持つ_Deployment_を定義しました

  • この展開に必要なレプリカの数を定義します

  • また、コンテナイメージの詳細をテンプレートとして提供しました
    配備

  • また、適切なセレクタで_Service_を定義しました

  • サービスの性質を_LoadBalancer_として定義しました

    最後に、コンテナをデプロイし、kubectlを使用してすべての定義済みKubernetesオブジェクトを作成できます。
kubectl apply -f yaml/hello-kubernetes.yaml

5. メソス対 クベルネテス

これで、十分なコンテキストを確認し、MarathonとKubernetesの両方で基本的な展開を実行しました。 私たちは、それらが互いに比較してどこに立つかを理解しようと試みることができます。
ただし、KubernetesとMesosを直接比較することは完全に公平ではありません。 探しているコンテナオーケストレーション機能のほとんどは、MarathonなどのMesosフレームワークの1つによって提供されます。 したがって、物事を正しい視点に保つために、直接Mesosではなく、KubernetesをMarathonと比較しようとします。
これらのオーケストレーションシステムを、そのようなシステムの望ましい特性のいくつかに基づいて比較します。

5.1. サポートされるワークロード

Mesosは、コンテナ化または非コンテナ化が可能な*さまざまな種類のワークロード*を処理するように設計されています。 使用するフレームワークに依存します。 これまで見てきたように、Marathonのようなフレームワークを使用してMesosでコンテナー化されたワークロードをサポートすることは非常に簡単です。
一方、Kubernetesは、*コンテナ化されたワークロードでのみ動作します*。 最も広くは、Dockerコンテナーで使用しますが、Rktなどの他のコンテナーランタイムをサポートしています。 将来、Kubernetesはより多くの種類のワークロードをサポートする可能性があります。

5.2. スケーラビリティのサポート

  • Marathonは、アプリケーション定義またはユーザーインターフェイスによるスケーリングをサポートしています*。 自動スケーリングは、マラソンでもサポートされています。 すべての依存関係を自動的にスケーリングするアプリケーショングループをスケーリングすることもできます。

    前に見たように、ポッドはKubernetesの実行の基本単位です。 *展開によって管理される場合、ポッドをスケーリングできます*。これが、ポッドが常に展開として定義される理由です。 スケーリングは手動でも自動でもかまいません。

5.3. 高可用性の処理

Marathonのアプリケーションインスタンスは、*高可用性を提供するMesosエージェント全体に分散されています*。 通常、Mesosクラスターは複数のエージェントで構成されます。 さらに、ZooKeeperは、定足数とリーダーの選出を通じてMesosクラスターの高可用性を提供します。
同様に、Kubernetesのポッドは*高可用性を提供する複数のノードに複製されます*。 通常、Kubernetesクラスターは複数のワーカーノードで構成されます。 さらに、クラスターは複数のマスターを持つこともできます。 したがって、Kubernetesクラスターはコンテナーに高可用性を提供できます。

5.4. サービス検出と負荷分散

  • Mesos-DNSは、アプリケーションのサービス検出と基本的な負荷分散*を提供できます。 Mesos-DNSは、各MesosタスクのSRVレコードを生成し、それらをタスクを実行しているマシンのIPアドレスとポートに変換します。 Marathonアプリケーションの場合、Marathon-lbを使用して、HAProxyを使用したポートベースの検出を提供することもできます。

    Kubernetesで展開すると、ポッドが動的に作成および破棄されます。 そのため、通常は* Serviceを介してKubernetesのポッドを公開します。これにより、サービスが検出されます*。 Kubernetesのサービスはポッドへのディスパッチャーとして機能し、したがって負荷分散も提供します。

5.5アップグレードとロールバックの実行

Marathonでのアプリケーション定義の変更は、展開として処理されます。 デプロイメント*アプリケーションの開始、停止、アップグレード、またはスケールをサポート*。 Marathonは、新しいバージョンのアプリケーションを展開するためのローリングスタートもサポートしています*。 ただし、ロールバックは簡単で、通常は更新された定義の展開が必要です。

  • Kubernetesでの展開は、アップグレードとロールバック*をサポートしています。 古いポッドを新しいポッドに置き換えながら展開するための戦略を提供できます。 典型的な*戦略は、再作成またはローリング更新*です。 Kubernetesでは、展開のロールアウト履歴がデフォルトで維持されているため、以前のリビジョンにロールバックするのは簡単です。

5.6. ロギングとモニタリング

Mesosには、すべてのクラスターコンポーネントをスキャンする*診断ユーティリティ*があり、ヘルスやその他のメトリックに関連するデータを利用できます。 データは、利用可能なAPIを介してクエリおよび集計できます。 このデータの多くは、Prometheusなどの外部ツールを使用して収集できます。
Kubernetesは、さまざまなオブジェクトに関連する詳細情報をリソースメトリックまたは完全なメトリックパイプラインとして公開します。 典型的な方法は、KubernetesクラスターにELKやPrometheus Grafanaなどの外部ツールを展開することです。 このようなツールは、クラスターメトリックを取り込み、ユーザーフレンドリな方法で表示できます。

5.7. ストレージ

Mesosには、*ステートフルアプリケーション用の永続的なローカルボリューム*があります。 予約済みリソースからのみ永続ボリュームを作成できます。 また、外部ストレージもサポートできますが、いくつかの制限があります。 Mesosはhttps://github.com/container-storage-interface/spec[Container Storage Interface]（CSI）を実験的にサポートしています。これは、ストレージベンダーとコンテナーオーケストレーションプラットフォーム間の共通APIセットです。
Kubernetesは、*ステートフルコンテナ用の複数の永続ボリューム*を提供しています。 これには、iSCSI、NFSなどのストレージが含まれます。 さらに、AWS、GCPなどの外部ストレージもサポートしています。 KubernetesのVolumeオブジェクトはこの概念をサポートし、CSIを含むさまざまなタイプがあります。

5.8. ネットワーキング

Mesosのコンテナランタイムは、* 2つのタイプのネットワークサポート、コンテナごとのIP、およびネットワークポートマッピング*を提供します。 Mesosは、コンテナのネットワーク情報を指定および取得するための共通インターフェースを定義します。 マラソンアプリケーションは、ホストモードまたはブリッジモードでネットワークを定義できます。
Kubernetesのネットワーキングは、各ポッドに一意のIPを割り当てます。*これにより、コンテナーポートをホストポートにマッピングする必要がなくなります。 さらに、これらのポッドがノード間で相互に通信する方法を定義します。 これは、Cilium、ContivなどのネットワークプラグインによってKubernetesに実装されています。

6. いつ使用するか

最後に、比較では、通常、明確な判定が期待されます！ ただし、あるテクノロジーを別のテクノロジーよりも優れていると宣言することは完全に公平ではありません。 これまで見てきたように、* KubernetesとMesosはどちらも強力なシステム*であり、非常に競合する機能を提供します。
ただし、パフォーマンスは非常に重要な側面です。 Kubernetesクラスターは5000ノードまで拡張できますが、Mesos上のMarathonクラスターは最大10,000のエージェントをサポートすることが知られています。 ほとんどの実際のケースでは、このような大規模なクラスターを扱っていません。
最後に、それは私たちが持っているワークロードの柔軟性と種類に要約されます。 新たに開始し、*コンテナ化されたワークロードのみを使用する予定の場合、Kubernetesはより迅速なソリューションを提供できます*。 ただし、コンテナと非コンテナが混在する既存のワークロードがある場合、Mesos with Marathonの方が適しています。

7. その他の選択肢

KubernetesとApache Mesosは非常に強力ですが、この分野で唯一のシステムではありません。 かなり有望な選択肢がいくつかあります。 詳細については説明しませんが、そのうちのいくつかを簡単にリストしましょう。

  • Docker Swarm：Docker Swarmは

  • Dockerコンテナ用のオープンソースのクラスタリングおよびスケジューリングツール*。 Dockerホストのクラスターを管理するコマンドラインユーティリティが付属しています。 KubernetesやMesosとは異なり、Dockerコンテナに制限されています。

  • Nomad：Nomadは柔軟なワークロードです
    HashiCorp *のオーケストレーターが、コンテナ化されたアプリケーションまたはコンテナ化されていないアプリケーションを管理します。 Nomadは、Dockerコンテナなどのアプリケーションをデプロイするための宣言型のコードとしてのインフラストラクチャを有効にします。

  • OpenShift：OpenShiftは*コンテナです
    Kubernetesが管理および管理するRed Hat *のプラットフォーム。 OpenShiftは、統合されたイメージレジストリ、ソースからイメージへのビルド、ネイティブネットワーキングソリューションなど、Kubernetesが提供する機能に加えて、多くの機能を提供します。

8. 結論

まとめると、このチュートリアルでは、コンテナとコンテナオーケストレーションシステムについて説明しました。 最も広く使用されている2つのコンテナオーケストレーションシステムであるKubernetesとApache Mesosについて簡単に説明しました。 また、いくつかの機能に基づいてこれらのシステムを比較しました。 最後に、この分野で他の選択肢のいくつかを見ました。
終了する前に、このような比較の目的はデータと事実を提供することであることを理解する必要があります。 これは、他のものよりも優れたものを宣言する方法ではなく、通常はユースケースに依存します。 そのため、問題のコンテキストを適用して、最適なソリューションを決定する必要があります。
モバイルバージョンを終了