Mesosvs.Kubernetes

投稿日: 2022-10-23 2022-10-23
タグ: DevOps, Kubernetes

1. 概要

このチュートリアルでは、コンテナオーケストレーションシステムの基本的な必要性を理解します。

このようなシステムの望ましい特性を評価します。それから、現在使用されている最も人気のある2つのコンテナーオーケストレーションシステムである ApacheMesosとKubernetesを比較してみます。

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

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

2.1. コンテナ

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

したがって、プラットフォームの独立性と運用の簡素化を提供します。 Dockerは、使用されている最も人気のあるコンテナープラットフォームの1つです。

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

したがって、これらの数行は、DockerCLIを使用してSpringBootアプリケーションのDockerイメージを作成するのに十分です。

docker build -t hello_world .

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

そのため、コンテナによってアプリケーションのデプロイの信頼性と再現性がどのように向上するかを見てきました。しかし、なぜコンテナオーケストレーションが必要なのですか？

これで、管理するコンテナーがいくつかありますが、DockerCLIは問題ありません。いくつかの簡単な雑用も自動化できます。しかし、何百ものコンテナを管理しなければならない場合はどうなりますか？

たとえば、いくつかのマイクロサービスを備えたアーキテクチャを考えてみてください。これらはすべて、明確なスケーラビリティと可用性の要件を備えています。

その結果、物事はすぐに制御不能になる可能性があり、そこでコンテナオーケストレーションシステムの利点が実現します。 A コンテナーオーケストレーションシステムは、マルチコンテナーアプリケーションを備えたマシンのクラスターを単一のデプロイメントエンティティとして扱います。初期展開、スケジューリング、監視、スケーリング、フェイルオーバーなどの他の機能の更新までの自動化を提供します。

3. Mesosの簡単な概要

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

3.1. 建築

Mesosアーキテクチャは、Mesosマスター、Mesosエージェント、およびアプリケーションフレームワークで構成されています。

ここでアーキテクチャのコンポーネントを理解しましょう：

Frameworks ：これらはタスクまたはワークロードの分散実行を必要とする実際のアプリケーションです。典型的な例は、HadoopまたはStormです。 Mesosのフレームワークは、次の2つの主要コンポーネントで構成されています。
- スケジューラー：これはマスターノードに登録して、マスターがリソースの提供を開始できるようにする責任があります。
- Executor ：これはフレームワークのタスクを実行するためにエージェントノードで起動されるプロセスです
Mesosエージェント：これらは実際にタスクを実行する責任があります。各エージェントは、CPUやメモリなどの利用可能なリソースをマスターに公開します。マスターからタスクを受け取ると、フレームワークのエグゼキュータに必要なリソースを割り当てます。
Mesos Master ：これは利用可能なエージェントノードの1つでFrameworksから受信したタスクのスケジューリングを担当します。マスターはフレームワークにリソースを提供します。フレームワークのスケジューラーは、これらの利用可能なリソースでタスクを実行することを選択できます。

3.2. マラソン

先ほど見たように、Mesosは非常に柔軟性があり、フレームワークが明確に定義されたAPIを介してタスクをスケジュールおよび実行できるようにします。ただし、特にカスタムアプリケーションをスケジュールする場合は、これらのプリミティブを直接実装するのは便利ではありません。たとえば、コンテナとしてパッケージ化されたアプリケーションのオーケストレーション。

これは、Marathonのようなフレームワークが私たちを助けることができるところです。 Marathon は、Mesosで実行されるコンテナーオーケストレーションフレームワークです。この点で、MarathonはMesosクラスターのフレームワークとして機能します。 Marathonは、サービスディスカバリ、負荷分散、メトリック、コンテナ管理APIなどのオーケストレーションプラットフォームに通常期待されるいくつかの利点を提供します。

Marathon は、長時間実行されるサービスをアプリケーションとして扱い、アプリケーションインスタンスをタスクとして扱います。一般的なシナリオでは、アプリケーショングループと呼ばれるものを形成する依存関係を持つ複数のアプリケーションが存在する可能性があります。

3.3. 例

それでは、Marathonを使用して、前に作成した単純なDockerイメージをデプロイする方法を見てみましょう。 Mesosクラスターのインストールはほとんど必要ないため、 MesosMiniのようなより簡単なソリューションを使用できることに注意してください。 Mesos Miniを使用すると、Docker環境でローカルのMesosクラスターを起動できます。これには、Mesosマスター、単一のMesosエージェント、およびマラソンが含まれます。

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が提供するRESTAPIを使用して、このアプリケーションを起動できます。

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

4. Kubernetesの概要

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

4.1. 建築

Kubernetesアーキテクチャは、KubernetesマスターノードとKubernetesノードで構成されています。

この高レベルのアーキテクチャの主要部分を見ていきましょう。

Kubernetesマスター：マスターは、クラスターの目的の状態を維持する役割を果たします。クラスタ内のすべてのノードを管理します。ご覧のとおり、マスターは3つのプロセスのコレクションです。
- kube-apiserver ：これはクラスター全体を管理するサービスで、REST操作の処理、Kubernetesオブジェクトの検証と更新、認証と承認の実行を含みます
- kube-controller-manager ：これは Kubernetesに付属のコア制御ループを組み込んだデーモンであり、現在の状態をクラスターの目的の状態に一致させるために必要な変更を加えます
- kube-scheduler ：このサービスは、スケジュールされていないポッドを監視し、要求されたリソースやその他の制約に応じて、それらをノードにバインドします
Kubernetesノード：Kubernetesクラスター内のノードは、コンテナーを実行するマシンです。各ノードには、コンテナを実行するために必要なサービスが含まれています。
- kubelet ：これはプライマリノードエージェントであり、kube-apiserverによって提供されるPodSpecsに記述されているコンテナーが実行され正常であることを保証します
- kube-proxy ：これは各ノードで実行されているネットワークプロキシであり、一連のバックエンド間で単純なTCP、UDP、SCTPストリーム転送またはラウンドロビン転送を実行します
- コンテナランタイム：これはポッド内のコンテナが実行されるランタイムであり、最も広く使用されているDockerランタイムを含むKubernetesのコンテナランタイムがいくつかあります。

4.2. Kubernetesオブジェクト

前のセクションでは、Kubernetesシステムの永続エンティティであるいくつかのKubernetesオブジェクトを見ました。これらは、任意の時点でのクラスターの状態を反映します。

一般的に使用されるKubernetesオブジェクトのいくつかについて説明しましょう。

ポッド：ポッドは Kubernetes の実行の基本単位であり、1つ以上のコンテナーで構成でき、ポッド内のコンテナーは同じホストにデプロイされます
デプロイ：デプロイは Kubernetes でポッドをデプロイするための推奨される方法であり、ポッドの現在の状態を目的の状態と継続的に調整するなどの機能を提供します
サービス：Kubernetes のサービスは、ポッドのグループを公開する抽象的な方法を提供します。グループ化は、ポッドラベルを対象とするセレクターに基づいています。

コンテナを分散して効果的に実行する目的で使用されるKubernetesオブジェクトは他にもいくつかあります。

4.3. 例

これで、DockerコンテナをKubernetesクラスタに起動してみることができます。 Kubernetesは、仮想マシン上でシングルノードのKubernetesクラスターを実行するツールであるMinikubeを提供します。また、Kubernetesクラスターと連携するには、Kubernetesコマンドラインインターフェイスであるkubectlも必要です。

kubectlとMinikubeをインストールしたら、Minikube内のシングルノードKubernetesクラスターにコンテナーをデプロイできます。基本的なKubernetesオブジェクトをYAMLファイルで定義する必要があります。

# 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. Mesos vs. Kubernetes

これで、十分なコンテキストを経て、MarathonとKubernetesの両方で基本的なデプロイも実行しました。それらが互いに比較してどこに立っているのかを理解することを試みることができます。

ただし、注意点として、KubernetesとMesosを直接比較することは完全に公平ではありません。私たちが求めるコンテナオーケストレーション機能のほとんどは、MarathonのようなMesosフレームワークの1つによって提供されます。したがって、物事を正しい視点に保つために、Kubernetesを直接MesosではなくMarathonと比較しようとします。

このようなシステムの望ましい特性のいくつかに基づいて、これらのオーケストレーションシステムを比較します。

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

Mesosは、さまざまなタイプのワークロードを処理するように設計されており、コンテナ化することも、コンテナ化しないこともできます。使用するフレームワークによって異なります。これまで見てきたように、Marathonのようなフレームワークを使用して、Mesosでコンテナー化されたワークロードをサポートするのは非常に簡単です。

一方、Kubernetesは、コンテナ化されたワークロードでのみ機能します。最も広く使用されているのはDockerコンテナーですが、Rktなどの他のコンテナーランタイムもサポートしています。将来的には、Kubernetesはより多くの種類のワークロードをサポートする可能性があります。

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

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

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

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でのデプロイは、アップグレードとロールバックをサポートします。古いポッドを新しいポッドに交換しながら、展開を行うための戦略を提供できます。典型的な戦略は、RecreateまたはRollingUpdateです。 Kubernetesでは、デプロイのロールアウト履歴がデフォルトで維持されるため、以前のリビジョンにロールバックするのは簡単です。

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

Mesosには、すべてのクラスターコンポーネントをスキャンし、ヘルスおよびその他のメトリックに関連するデータを利用できるようにする診断ユーティリティがあります。データは、利用可能なAPIを介してクエリおよび集計できます。このデータの多くは、Prometheusなどの外部ツールを使用して収集できます。

Kubernetes は、さまざまなオブジェクトに関連する詳細情報をリソースメトリックまたは完全なメトリックパイプラインとして公開します。一般的な方法は、ELKやPrometheus+Grafanaなどの外部ツールをKubernetesクラスターにデプロイすることです。このようなツールは、クラスターメトリックを取り込み、非常にユーザーフレンドリーな方法でそれらを表示できます。

5.7. 保管所

Mesosには、ステートフルアプリケーション用の永続的なローカルボリュームがあります。予約されたリソースからのみ永続ボリュームを作成できます。また、いくつかの制限付きで外部ストレージをサポートすることもできます。 Mesosは、 Container Storage Interface （CSI）を実験的にサポートしています。これは、ストレージベンダーとコンテナーオーケストレーションプラットフォームの間の共通のAPIセットです。

Kubernetesは、ステートフルコンテナ用の複数のタイプの永続ボリュームを提供します。これには、iSCSI、NFSなどのストレージが含まれます。さらに、AWS、GCPなどの外部ストレージもサポートしています。 KubernetesのVolumeオブジェクトはこの概念をサポートしており、CSIを含むさまざまなタイプがあります。

5.8. ネットワーキング

Mesosのコンテナランタイムは、 2種類のネットワークサポート、コンテナごとのIP、およびネットワークポートマッピングを提供します。 Mesosは、コンテナのネットワーク情報を指定および取得するための共通インターフェースを定義します。 Marathonアプリケーションは、ホストモードまたはブリッジモードでネットワークを定義できます。

Kubernetesのネットワーキングは、各ポッドに一意のIPを割り当てます。これにより、コンテナポートをホストポートにマッピングする必要がなくなります。さらに、これらのポッドがノード間で相互に通信する方法を定義します。これは、Cilium、ContivなどのネットワークプラグインによってKubernetesに実装されます。

6. いつ何を使うの？

最後に、比較すると、私たちは通常、明確な評決を期待しています！ただし、あるテクノロジーを別のテクノロジーよりも優れていると宣言することは、完全に公平ではありません。これまで見てきたように、 KubernetesとMesosはどちらも強力なシステムであり、非常に競合する機能を提供します。

ただし、パフォーマンスは非常に重要な側面です。 Kubernetesクラスターは5000ノードまで拡張できますが、Mesosクラスター上のMarathonは最大10,000のエージェントをサポートすることが知られています。ほとんどの場合、このような大規模なクラスターは扱いません。

最後に、それは私たちが持っているワークロードの柔軟性とタイプに要約されます。新たに開始し、コンテナ化されたワークロードのみを使用する予定の場合、Kubernetesはより迅速なソリューションを提供できます。ただし、コンテナーと非コンテナーが混在する既存のワークロードがある場合は、MesoswithMarathonの方が適しています。

7. その他の選択肢

KubernetesとApacheMesosは非常に強力ですが、この分野のシステムはこれらだけではありません。私たちが利用できる有望な選択肢はかなりあります。それらの詳細については説明しませんが、それらのいくつかを簡単にリストしましょう。

Docker Swarm ：Docker Swarmは、Dockerコンテナー用のオープンソースのクラスタリングおよびスケジューリングツールです。 Dockerホストのクラスターを管理するためのコマンドラインユーティリティが付属しています。 KubernetesやMesosとは異なり、Dockerコンテナに制限されています。
Nomad ：Nomadは、 HashiCorp の柔軟なワークロードオーケストレーターであり、コンテナー化されたアプリケーションまたはコンテナー化されていないアプリケーションを管理します。 Nomadは、Dockerコンテナなどのアプリケーションをデプロイするための宣言型Infrastructure-as-Codeを有効にします。
OpenShift ：OpenShiftは Red Hat のコンテナープラットフォームであり、その下のKubernetesによって調整および管理されます。 OpenShiftは、統合されたイメージレジストリ、ソースからイメージへのビルド、ネイティブネットワーキングソリューションなど、Kubernetesが提供する機能に加えて多くの機能を提供します。

8. 結論

要約すると、このチュートリアルでは、コンテナーとコンテナーオーケストレーションシステムについて説明しました。最も広く使用されている2つのコンテナオーケストレーションシステムであるKubernetesとApacheMesosについて簡単に説明しました。また、いくつかの機能に基づいてこれらのシステムを比較しました。最後に、このスペースで他のいくつかの選択肢を見ました。

最後に、このような比較の目的はデータと事実を提供することであることを理解する必要があります。これは、他のものよりも優れていると宣言することは決してなく、通常はユースケースによって異なります。したがって、問題のコンテキストを適用して、最適なソリューションを決定する必要があります。

getdocs

13036