ハードウェア仮想化は、ハイパーバイザーを使用して物理ハードウェアを仮想マシン（VM）と共有することにより、スケーラビリティ、セキュリティ、分離などの利点のリストを提供します。現在、仮想マシンは仮想化の唯一の形式ではありません。コンテナも非常に人気があります。VMは基礎となるマシンの物理ハードウェアを共有しますが、コンテナは基礎となるオペレーティングシステムのカーネルを共有します。コンテナは軽量な仮想マシンではなく、アプリケーションを配信するために使用される標準化された実行可能パッケージであり、マイクロサービスベースのソフトウェアアーキテクチャを使用して開発されたアプリケーションなど、アプリケーションを実行するために必要なすべてのコンポーネントが含まれています。
Dockerエンジンは、コンテナを実行するための最も人気のあるプラットフォームです。Kubernetesは、コンテナ化とクラウドコンピューティングの領域で、ますます頻繁に聞かれる用語です。しかし、何が良いのか、DockerかKubernetesか？これはよく議論されるトピックですが、このように述べることは技術的には正しくありません。例えば、「何が良いのか – 熱いのか青いのか？」とは尋ねることはできません。
Dockerとは？
Dockerは、コンテナ化されたアプリケーションを実行するために使用されるエンジンとして機能するオープンソースのスタンドアロンアプリケーションです。これは、オペレーティングシステム（OS）にインストールされます（可能な限りLinux上に）、ただし、WindowsやmacOSにもインストールすることができます。そして、物理または仮想マシン上で実行されます。
コンテナ内で実行されているアプリケーションは、システムの残りの部分や他のコンテナから分離されていますが、独自のOSインスタンスで実行されているような錯覚を与えます。複数のDockerコンテナを単一のオペレーティングシステム上で同時に実行することができます。これらのコンテナはDockerで管理でき、KubernetesなしでDockerを実行することもできます。コンテナを実行するための複数のホストがある場合、それらを手動で管理することは難しい場合があります。通常は、中央集権的な管理ツールまたはオーケストレーションソリューションを選択する方が良いでしょう。
Docker Composeは、マルチコンテナDockerアプリケーションを実行するために使用される基本的なコンテナオーケストレーションツールです。個々のコンテナに個別にDockerfileを手動で設定する代わりに、1つのYAML（yml）Docker Compose構成ファイルを設定してマルチコンテナアプリケーションを定義できます。単一のYAMLファイルを設定した後は、Linuxコンソールで1つのコマンドを使用してすべての必要なコンテナを実行できます。Docker Composeを使用することは、Dockerコンテナをオーケストレートする方法の1つですが、Docker Composeの代替として利用可能な強力なオプションがあります。それがKubernetesと呼ばれるものです。
Kubernetesとは何ですか？
Kubernetesは、高度な自動化を備えたコンテナ化されたソフトウェアとサービスを管理するために使用されるオープンソースのコンテナオーケストレーションソリューションです。
Kubernetesは、コンテナ内で実行されているアプリケーションの展開、スケーリング、可用性を自動化するためのGoogleプロジェクトです。コンテナを実行するホストの数を最大11台以上に増やすことができます。さらに、Kubernetesを使用してDockerコンテナのクラスターを作成することで、高可用性と負荷分散を確保することができます。
クラスターで使用されるホストはノードと呼ばれます。Kubernetesのアーキテクチャタイプはマスター・スレーブであり、クラスターはマスターノードとワーキングノードで構成されています。Kubernetesが推奨するノードの最小数は4です。1台のマシンでクラスターを構築できますが、すべての例やテストを実行するには少なくとも4つのノードが必要です。本番トラフィックを処理するKubernetesクラスターには、最低3つのワーキングノードが必要です。マスターノードを2つ使用すると、1つのマスターノードの障害に対してクラスターを保護できます。必要に応じて2つ以上のマスターノードを使用できます。
- マスターノードは、クラスターの状態を管理するために使用され、クライアントリクエストの受け入れ、コンテナのスケジューリング操作、制御ループの実行などが含まれます。クラスターのすべてのデータを保存するetcdデータベースのコピーを各マスターノードで実行する必要があります。マスターノードはkube-apiserver、kube-controller-manager、kube-schedulerの3つのプロセスのセットを実行します。
- ワーキングノードは、コンテナを実行することでアプリケーションのワークロードを実行するために使用されます。非マスターノードで実行される2つのKubernetesプロセスは、kubelet（マスターノードとの通信に使用）とkube-proxy（各ノードでKubernetesネットワークサービスを反映するために使用）です。
- Replication Controllerは、指定された数のPodレプリカが常に稼働していることを保証するコンポーネントです。したがって、必要なときにいつでもPodが利用可能であることを確認できます。
Kubernetesを使用する場合、サービス間の通信には異なるCLIやAPIが使用されます。また、Kubernetesで構築されたクラスタのコンポーネントであるRESTful APIのオブジェクトやリソースには、特定の用語が使用されています。 - Podは、Kubernetesの基本的なスケジューリング単位です。これは複数のコンテナが動作できるリソースのグループです。1つのPodに属するコンテナは同じホストで実行され、同じリソースとローカルネットワークを使用します。Pod内のコンテナは隔離されていますが、容易に通信できます。したがって、通常、KubernetesではPodが使用されますが、独立したDockerアプリケーションを使用する場合は、コンテナプールのみが利用可能です。
- Serviceは、例えばマルチティアアプリケーションの機能を提供する一連のコンテナです。Kubernetesは、抽象化を使用してPodの動的な命名とロードバランシングをサポートします。このアプローチにより、サービス間の透明な接続が名前で可能になり、その現在の状態を追跡できます。
- Labelsは、Podや他のオブジェクトやサービスにバインドされたキー/値のペアであり、それらを簡単にグループ化し、タスクを割り当てることができます。
- 名前空間は、Kubernetes クラスターを論理的に複数の仮想クラスターに分割する方法です。各仮想クラスターは、他の仮想クラスターに影響を与えることなく、割り当てられたクォータ内の仮想環境内で存在することができます。
Kubernetes は Docker と共に使用することができますが、Docker は Kubernetes と使用できる唯一のコンテナプラットフォームではありません。Kubernetes はまた、Windows コンテナ、Linux コンテナ、rkt などとも連携することができます。 K8s は、技術文書で時々見られる Kubernetes の名前です。
Kubernetes と Docker: ネットワーキング比較
各ソリューションのネットワーキングオプションを見てみましょう。
Dockerは、コンテナ間のネットワーク通信のための 3 つのネットワークモードを提供します。
Bridge。このモードはデフォルトで使用され、仮想のレイヤー 3 ブリッジが作成されます。このネットワークのホスト上のネットワーク名は docker0 です。 Docker は自動的にレイヤー 3 ネットワークブリッジを作成し、外部ネットワークインターフェースのマスカレーディングルールを構成し、ネットワークアドレス変換（NAT）の原則を使用して、コンテナ間で通信し、外部ネットワークに接続することを可能にします。他のホストおよび外部ネットワークからコンテナに接続する場合は、ホストマシンのネットワークインターフェースのポート転送を構成することができます。したがって、ホストマシンの適切なポートに接続することで、必要な Docker コンテナのポートに転送されます。必要に応じて Docker コンテナのネットワークインターフェースを複数作成することができます。
ホスト。このモードでは、ホストネットワークドライバーがコンテナがDockerホストから孤立しないようにします。コンテナはホストネットワークスタックを共有し、コンテナのホスト名はホストオペレーティングシステムのホスト名と同じです。TCPポート8080がリッスンされているコンテナを実行すると、コンテナアプリケーションはホストマシンのIPアドレスのTCPポート8080で利用可能です。ホストネットワークドライバーはLinuxマシンにのみ使用できます。
なし。指定されたコンテナのネットワークインターフェイスには、ループバックインターフェイスの127.0.0.1アドレス以外のIPアドレスが構成されていません。 なしネットワークモードが設定されている場合、外部ネットワークへのアクセスはありません。
Dockerコンテナのマルチホストネットワーキング。コンテナが異なるホストで実行されている場合、オーバーレイネットワーキングを設定するとお互いに通信できます。有効なキー値ストアサービス（Consul、Etcd、またはZooKeeper）を構成する必要があります。
Kubernetes。スタンドアロンのDockerコンテナを使用している場合、各コンテナは適切なネットワークインターフェイスを使用してネットワークを介して通信する基本単位として考えることができます。 Kubernetesを使用している場合、Podはコンテナクラスターの基本単位です。各ポッドには独自のIPアドレスがあり、少なくとも1つのコンテナで構成されています。ポッドには関連するタスクに使用される複数のコンテナが含まれる場合があります。同じポッドのコンテナは同時に同じポートを開けません。この種の制限は、複数のコンテナで構成されるポッドでも単一のIPアドレスを持っているためです。
さらに、Kubernetesは各Podに特別な一時停止コンテナを作成します。この特別なコンテナは、他のコンテナにネットワークインターフェース（内部および外部通信用）を提供することを意図しており、通常は一時停止状態（スリープモード）になっています。これらの一時停止コンテナは、Kubernetesが「SIGTERM」シグナルを送信すると起動します。
Flannelは、ネットワークオーバーレイの原則を使用して、Kubernetes内のコンテナを接続するためのネットワークファブリックとして通常使用されます。オーバーレイネットワーキングにより、論理ネットワークを介して異なる物理ホスト（クラスタのノードと呼ばれる）間でコンテナを実行できます。オープンソースのetcdキー/値ストアは、コンテナにホストによって割り当てられた実際のIPアドレスと、オーバーレイネットワーク内のIPアドレスのマッピングを保存するために使用されます。
Kubernetesネットワーキングは、VMware NSX-Tと統合することができます。これは、NSX Container Pluginを使用して行います。この統合により、Kubernetesでは「箱から出してすぐに利用可能ではない」マルチテナントネットワークトポロジを使用できます。
Kubernetesネットワーキングモデルには、次の機能が提供されています:
- すべてのコンテナは、NATなしでクラスタ内の他のすべてのコンテナと通信できます。
- すべてのクラスタノードは、NATなしでクラスタ内のすべてのコンテナと通信できます。逆に、すべてのコンテナはすべてのクラスタノードと通信できます。
- コンテナは自分自身のIPアドレスを見ることができ、他のKubernetesコンポーネントによってそのIPアドレスが見えます。
Ingressは、クラスター外からのサービスへのアクセスを管理するために使用されるKubernetesのAPIオブジェクトです（主にHTTPおよびHTTPS）。Ingressを構成して、コンテナ化されたサービスへの外部アクセス、負荷分散、SSL終了、および名前ベースの仮想ホスティングを実行できます。Ingressルールが機能するためには、マスターノードにIngressコントローラを展開する必要があります。
使用例
単体のソフトウェアとしてDockerを使用することは、アプリケーションの開発に適しており、開発者はアプリケーションを孤立した環境で実行できます。さらに、テスターもDockerを使用してアプリケーションをサンドボックス環境で実行できます。Dockerを使用して本番環境で多数のコンテナを実行したい場合、いくつかの複雑さに遭遇するかもしれません。たとえば、一部のコンテナは簡単に過負荷になったり失敗したりする可能性があります。適切なマシンでコンテナを手動で再起動できますが、手動管理には多くの貴重な時間とエネルギーがかかる可能性があります。
Kubernetesは、高可用性、負荷分散、コンテナオーケストレーションツールなどの主要な機能を提供することで、これらの問題を解決できます。その結果、Kubernetesは、多数のDockerコンテナを備えた高負荷の本番環境に最も適しています。Kubernetesを展開するのは、単体のDockerアプリケーションをインストールするよりも難しいため、Kubernetesは常に開発やテストに使用されるわけではありません。
Kubernetes vs Docker Swarm
Docker Swarmは、Dockerのネイティブクラスタリングツールであり、Dockerホストのプールを単一の仮想ホストに変換することができます。Docker Swarmは、Docker Engineと完全に統合されており、標準のAPIやネットワーキングプロセスを使用できます。これは、Dockerコンテナを展開、管理、およびスケーリングするために意図されています。
マネージャーノードは、制御のオーケストレーション、クラスター管理、およびタスクの配布を行うために使用されます。
ワーカーノードは、マネージャーノードによって割り当てられたタスクを実行するために使用されます。各ノードは、マネージャーノード、ワーカーノード、またはその両方として構成できるため、マネージャーノードとワーカーノードの機能の両方を実行できます。なお、ワーカーノードはスワームサービスを実行します。
サービス。Docker Swarmのサービスは、各コンテナ化されたサービスの必要な最適な状態を定義します。サービスは、レプリカの数、利用可能なネットワークリソース、外部ネットワークからアクセス可能にする必要のあるポートなど、そのようなパラメーターを制御します。ネットワーク構成などのサービス構成は、手動でコンテナとサービスを再起動することなく、コンテナに適用および変更することができます。
タスク。タスクは、単一のコンテナが実行されるスロットです。タスクはSwarmサービスの一部です。
Docker SwarmとKubernetesは、類似した目的に使用される2つの異なるプラットフォームです。これらを適切なカテゴリで比較する時が来ました。
クラスターの展開
Docker Swarm。標準のDocker APIを使用して、標準のDocker CLI（コマンドラインインターフェース）を使用して、クラスターをデプロイできます。これにより、初めて使用する場合でも、デプロイメントが容易になります。Swarmのデプロイメントの容易さは、単一のDockerマスターがサービスの配布方法を決定できる能力によっても実現されます。Docker SwarmではPodは使用されません。
Kubernetesは、標準のDockerコマンドとは異なる指定されたコマンドを使用する必要があります。Kubernetesでは指定されたAPIが使用され、Dockerの管理コマンドを知っていても、Kubernetesのデプロイメントのために追加のツールセットを学ぶ必要があります。ノードはKubernetesクラスターで手動で定義する必要があります。マスターノードを選択し、コントローラー、スケジューラーなどを定義する必要があります。
拡張性
Docker Swarm。Dockerが提供するシンプルなAPIのおかげで、大規模なクラスターや小規模なクラスターでのコンテナの展開やサービスの更新が迅速に行えます。コマンドラインインターフェース（CLI）は非常にシンプルで理解しやすいです。その結果、SwarmはKubernetesと比較してより拡張性のあるソリューションと見なすことができます。
Kubernetesは比較的統一されたAPIを提供し、より遅い展開プロセスを引き起こすことがあるいくつかの機能を備えています。構成する必要がある3種類のコンポーネントがあります: Pod、Deploy、およびService。オートスケールに関しては、Kubernetesはサーバーロードを分析し、与えられた要件に応じて自動的にスケールをアップおよびダウンさせる能力を備えているため、好ましいです。Kubernetesは大規模な分散ネットワークや複雑なシステムにとって最適な選択肢です。
高可用性
両方のソリューションオプションは、類似のサービスレプリケーションおよび冗長性メカニズムを備えており、どちらの場合もシステムは自己調整され、障害ノードがクラスターに戻った後の手動の再構成は必要ありません。
Docker Swarm。マネージャーノードはワーカーノードとクラスター全体のリソースを処理します。Swarmクラスターノードはサービスのレプリケーションに参加します。
Kubernetes。Kubernetesの負荷分散サービスによって不健康なノードが検出され、クラスターから削除されます。すべてのPodはノード間で分散され、コンテナ化されたアプリケーションが実行されているノードが失敗した場合でも高可用性を提供します。
負荷分散
Docker Swarm。負荷分散は組み込みの機能であり、内部のSwarmネットワークを使用して自動的に実行できます。クラスターへのすべてのリクエストは分配され、クラスターノードにリダイレクトされます。任意のノードが任意のコンテナに接続できます。Docker Swarmはサービス名への着信リクエストを配布するためにDNS要素を使用します。
Kubernetes。ポッドで定義されたポリシーは、Kubernetesでのロードバランシングに使用されます。この場合、コンテナポッドはサービスとして定義する必要があります。ロードバランシングの設定を手動で構成する必要がありますが、Ingressを使用してロードバランシングを行うこともできます。
コンテナの作成と実行
Docker Swarm。 Docker Swarmを使用すると、Docker CLIで利用可能なほとんどのコマンドを利用できます。これは、Docker Swarmの標準化されたAPIのおかげです。 Docker Composeは、ボリュームと使用されるネットワークの操作を定義し、どのコンテナをグループ化するかを定義します。 Docker SwarmのためにDocker Composeでレプリカの正確な数を設定できます。
Kubernetes。 Kubernetesには独自のAPIとクライアントがあり、YAMLファイルで構成する必要があります。これは、Docker ComposeとDocker CLIを使用してコンテナをデプロイすることはできないという主要な違いの1つです。 Kubernetesでは、サービスを定義するシステムがDocker Composeと同様の動作原理に従いますが、より複雑です。 Docker Composeの機能は、KubernetesではPod、Deployments、およびServicesを使用して実行されます。各レイヤーはそれぞれ指定された目的に使用されます。ポッドはコンテナの相互作用を担当し、デプロイメントはクラスタ内の単一ノードの高可用性とネットワーキングを担当します（SwarmなしのスタンドアロンのDockerアプリケーションのDocker Composeと同様）、そしてKubernetesサービスはクラスタ内でのサービスの動作の構成、障害耐性などを担当します。
ネットワーキング
Docker Swarm。クラスタ内のコンテナ間の通信のためのデフォルトの内部ネットワークが1つあり、必要に応じて追加のネットワークを追加できます。ネットワークは生成されたTLS証明書で保護されています。コンテナデータトラフィックの暗号化のために手動で証明書を生成することもできます。
Kubernetes。Kubernetesのネットワークモデルはかなり異なり、プラグインを使用して実装されています。その1つがFlannelで、最も一般的なオプションです。ポッドはお互いに相互作用し、この相互作用はポリシーで制限できます。etcdサービスによって管理されている内部ネットワークがあります。TLS暗号化も利用可能ですが、手動で構成する必要があります。Kubernetesのネットワーキングモデルは、2つのCIDR（Classless Inter-Domain Routing）を構成することを前提としています。
モニタリング
Docker Swarm。監視やログのための組み込みツールはありませんが、サードパーティの監視ツールを手動で設定することができます。ELKやReimannをこの目的に使用できます。
Kubernetes。Kubernetesにはログとモニタリングのための組み込みツールが提供されています。ElasticsearchとKibana（ELK）を使用してクラスタ全体の状態を監視できます。また、Heapster、Grafana、Influxがコンテナサービスのモニタリングをサポートしています。
グラフィカルユーザーインターフェース（GUI）
Docker Swarm。GUIは、Portainer.ioなどのサードパーティツールを使用して有効にできます。これはユーザーフレンドリーなWebインターフェイスを提供します。代替として、クラスタ管理のためのグラフィカルインターフェイスを提供するDockerのエンタープライズエディションを使用できます。
Kubernetes。Kubernetesが提供するGUIは、Webインターフェース経由でアクセスできる信頼性の高いダッシュボードであり、これによりクラスターを簡単に制御できます。GUIは、CLIでKubernetesを管理する経験が少ないユーザーにとって非常に価値のあるツールです。
結論
Docker Swarmは、主にDocker APIとCLIを使用するネイティブのDockerソリューションです。一方、Kubernetesは、コンテナが実行されているクラスターをデプロイするために使用されるGoogleのプロジェクトです。
どちらも、高可用性、負荷分散、オーバーレイネットワーキング、およびスケーラビリティの機能を提供します。Docker Swarmは、デプロイメントの面ではより簡単であり、そのほとんどの機能構成が自動化されており、ハードウェアリソースをほとんど消費しません。ただし、Docker APIによって機能が制限され、ネイティブの監視ツールが欠落しています。
一方、Kubernetesは、多くの大規模企業によって数年間サポートされてきた高い柔軟性を持つモジュラーソリューションです。Kubernetes用の組み込みのサービスおよびクラスター全体の監視ツールが利用可能ですが、デプロイメントおよび構成はより困難であり、これによりこのリソースはより要求の厳しいソリューションとなります。Kubernetesは、Docker CLIおよびDocker Composeと互換性がありません。高負荷のマルチコンテナアプリケーションが実行されている大規模な環境では、Kubernetesの使用が推奨されます。