Kubernetes と Docker を 1 つの記事で理解する

クラウド コンピューティングで最も影響力のある 2 つのオープン ソース プロジェクトの類似点と相違点。

Kubernetes と Docker は、クラウド コンピューティング業界で何度も取り上げられてきたトピックです。技術的なバックグラウンドを持たない方、簡単な紹介が必要な方、ビジネス上の決定を下す必要がある方など、どのような場合でも、以下のポイントが疑問を一気に解消してくれることを願っています。

Kubernetes と Docker を取り巻く誇大宣伝を乗り越える必要があります。これらの言葉を使ってビジネスを展開する前に、その意味を理解しておくことが重要です。

KubernetesとDockerの共生関係

「Kubernetes と Docker のどちらが良いか?」という疑問それ自体は、リンゴとオレンジを比較するのと同じくらいばかげています。一方が他方の代わりとなるものではありません。まったく逆に、Kubernetes は Docker なしでも実行でき、Docker は Kubernetes なしでも実行できます。しかし、Kubernetes は Docker から大きなメリットを得ることができ (実際に得ています)、その逆もまた同様です。

Docker は、コンテナ化されたアプリケーションを実行するために任意のコンピューターにインストールできるスタンドアロン アプリケーションです。コンテナ化とは、アプリケーションをシステムの他の部分から分離して、オペレーティング システム上でアプリケーションを実行する方法です。同じシステム上で他のコンテナが実行されている場合でも、アプリケーションには独自のオペレーティング システムのインスタンスを取得しているという錯覚が生じます。 Docker を使用すると、単一のオペレーティング システム上でコンテナーを実行、作成、管理できます。

Kubernetes ではこれが 11 に増加します。多数のホスト (異なるオペレーティング システム) に Docker がインストールされている場合は、Kubernetes を活用できます。これらのノードまたは Docker ホストは、ベアメタル サーバーまたは仮想マシンにすることができます。 Kubernetes を使用すると、単一のコマンド ラインまたはダッシュボードから、これらすべてのノードにわたってコンテナ構成、ネットワーク、負荷分散、セキュリティ、スケーリングを自動化できます。単一の Kubernetes インスタンスによって管理されるノードのコレクションは、Kubernetes クラスターと呼ばれます。

さて、そもそもなぜ複数のノードが必要なのでしょうか?その背後にある主な動機は次の 2 つです。

1. インフラストラクチャをより堅牢にします。一部のノードがオフラインであってもアプリケーションはオンラインになり、高可用性が実現します。

2. アプリケーションのスケーラビリティを高める - ワークロードが増加した場合は、コンテナをさらに生成したり、Kubernetes クラスターにノードを追加したりするだけです。

Kubernetes と Docker の違い

原則として、Kubernetes はあらゆるコンテナ化テクノロジーを使用できます。 Kubernetes と統合できる最も一般的な 2 つのオプションは、rkt と Docker です。しかし、Docker は最大の市場セグメントを獲得し、他のどのコンテナ化技術よりも Docker と Kubernetes の統合を完璧にするための多大な努力が払われました。

同様に、Docker を開発する Docker Inc. も、Docker Swarm と呼ばれる独自のコンテナ オーケストレーション エンジンを提供しています。しかし、彼らでさえ、Docker for Desktop (MacOS および Windows) に独自の Kubernetes ディストリビューションが付属するほど Kubernetes が普及していることを認識しています。

Docker ベースの製品に Kubernetes を導入することに不安を感じている人にとって、この最後のポイントはすべての疑問を解消するでしょう。両方のプロジェクトは心からお互いを受け入れ、この共生関係から大きな利益を得ています。

Kubernetes と Docker の類似点

これらのプロジェクトは単なるテクノロジーではなく、違いはあっても業界で最も優秀な人材で構成された人々のコミュニティです。志を同じくする人々が協力すると、素晴らしいアイデアを交換し、お互いのベストプラクティスから学ぶことができます。

Kubernetes と Docker が共有するアイデアの一部を以下に示します。

1. マイクロサービス ベースのアーキテクチャに対する愛情 (これについては後で詳しく説明します)。

2. オープンソース コミュニティに対する愛情。どちらも主要なオープンソース プロジェクトです。

3. 主に Go で記述されているため、小さく軽量なバイナリとして出荷できます。

4. 人間が読める YAML ファイルを使用して、アプリケーション スタックとそのデプロイメントを指定します。

理論的には、一方を理解しなくてももう一方は理解できます。ただし、実際には、単一のマシンで Docker を実行するという単純なケースから始めて、Kubernetes がどのように機能するかを徐々に学習すると、より多くのメリットが得られることを覚えておいてください。

Dockerとは何ですか?

Docker を見るには 2 つの方法があります。最初のアプローチでは、Docker コンテナを真の軽量仮想マシンとして扱います。 2 番目のアプローチは、Docker をソフトウェアのパッケージ化および配信プラットフォームとして見ることです。後者のアプローチは人間の開発者にとってより有益であることが証明され、この技術の広範な採用につながりました。

Docker コンテナの概要:

従来、クラウド サービス プロバイダーは、実行中のアプリケーションを相互に分離するために仮想マシンを使用してきました。ハイパーバイザー、つまりホスト オペレーティング システムは、多くのゲスト オペレーティング システムに仮想 CPU、メモリ、およびその他のリソースを提供します。各ゲスト オペレーティング システムは、実際の物理ハードウェア上で実行されているかのように動作し、理想的には、同じ物理サーバー上で実行されている他のゲスト オペレーティング システムを認識しません。 VMware はこの概念を普及させた最初の企業の 1 つです。

ただし、このタイプの仮想化にはいくつかの問題があります。まず、リソースの提供には時間がかかります。各仮想ディスク イメージは大きくて扱いにくく、VM を使用できるように準備するのに最大 1 分かかることもありました。 2 番目でより重要な問題は、システム リソースの非効率的な使用でした。オペレーティング システム カーネルは制御にこだわり、利用可能とみなされるものすべてを管理しようとします。

したがって、ゲスト オペレーティング システムが 2 GB のメモリが使用可能であると判断すると、そのオペレーティング システムで実行されているアプリケーションがその半分しか使用していなくても、そのメモリが制御されます。一方、コンテナ化されたアプリケーションを実行する場合、ハードウェアではなく、オペレーティング システム (標準ライブラリ、パッケージなど) 自体を仮想化します。

ここで、VM に仮想ハードウェアを提供する代わりに、アプリケーションに仮想オペレーティング システムを提供します。必要に応じて、複数のアプリケーションを実行し、それらのリソース使用率に制限を課すことができます。各アプリケーションは、実行中に同時に実行されている他の何百ものコンテナを無視します。

開発者ツールとしての Docker:

開発者が直面する問題の 1 つは、アプリケーションを実行する運用サーバーと、アプリケーションを開発する独自の開発マシン (通常はラップトップとワークステーション) の違いです。デスクトップで Windows 10 を実行しているが、Ubuntu 18.04 用のアプリケーションを作成したいとします。おそらく、アプリケーションの作成に Python v3.6 を使用しているのに、Ubuntu サーバーではまだ 3.4 が実行されているのでしょう。

考慮すべき変数が多すぎるため、この複雑さを抽象化するために Docker を使用します。 Docker はどのオペレーティング システムにもインストールでき、Windows や Mac OS X でも十分にサポートされています。したがって、コードを Docker イメージにパッケージ化し、Docker を使用してローカルで実行およびテストすることで、その Docker イメージから作成されたコンテナーが本番環境で同じように動作することを確認できます。

注: プログラミング言語のバージョン、標準ライブラリなどのすべての依存関係がイメージに含まれています。

Docker イメージをソフトウェア パッケージとして考えるこの考え方から、次のような有名な引用が生まれました。

パッケージ マネージャー Apt は内部的にはまだ tar を使用していますが、ユーザーが心配する必要はありません。同様に、Docker を使用する場合、パッケージ マネージャーは存在しますが、それについて心配する必要はありません。 Node.js テクノロジーをベースに開発する場合でも、開発者は Node の公式 Docker イメージをベースに Docker イメージを構築することを好みます。

以上が、Docker とは何か、そして DevOps に関わっていない人でも Docker について学ぶべき理由についての簡単な概要です。それでは、Kubernetes に移りましょう。

Kubernetes とは何ですか?

Kubernetes は、上で説明したコンテナ化テクノロジーをさらに進化させ、複数のコンピューティング ノード (仮想マシンまたはベアメタル サーバー) にわたってコンテナを実行できるようにします。 Kubernetes がノードのセットを制御すると、コンテナはいつでもニーズに応じて起動または終了できます。

Kubernetes の公式 Web サイトにアクセスすると、Kubernetes の目的が非常に明確に説明されています。

これまでは、一連のコンテナ作成を自動化する Kubernetes の概要についてのみ簡単に説明しました。アプリケーションには、管理するためのストレージ スペースといくつかの DNS レコードが必要です。とりわけ、参加しているコンピューティング ノードが互いに安全に接続されていることを確認する必要があります。単一のホストではなく多様なノード セットを使用すると、まったく異なる一連の問題が発生します。

Kubernetes アーキテクチャの簡単な概要を説明すると、これらすべてとそれ以上のことを Kubernetes がどのようにして実現するのかが明らかになります。

Kubernetes アーキテクチャ — 簡単な概要:

Kubernetes クラスターについて理解する必要がある基本的な概念が 2 つあります。最初はノードです。これは、Kubernetes によって管理される VM および/またはベアメタル サーバーの総称です。 2 番目の用語はポッドです。これは Kubernetes の基本的なデプロイメント ユニットです。 Pod は、共存する必要がある関連する Docker コンテナのコレクションです。たとえば、Web サーバーを Redis キャッシュ サーバーと一緒にデプロイする必要がある場合、両方を 1 つの Pod にパッケージ化できます。 Kubernetes はそれらを並行してデプロイします。これがより単純で、ポッドが完全に 1 つのコンテナーで構成されていると想像できる場合は、それで問題ありません。

ノードに戻ると、ノードには 2 つの種類があります。 1 つはマスター ノードです。Kubernetes のコアがインストールされており、アプリケーションが実際に実行されるワーカー ノード間のポッドのスケジュールを制御します。マスターノードの役割は、クラスターの望ましい状態が維持されるようにすることです。

以下は、上記の Kubernetes 図の簡単な概要です。

Kubernetes マスターには次のものがあります。

1. kube-controller-manager: クラスターの現在の状態 (実行中のポッドの数が X 個など) を考慮し、望ましい状態 (アクティブなポッドの数が Y 個など) を実現するための決定を下す役割を担います。 kube-apiserverでクラスターのステータスに関する情報をリッスンします。

2. kube-apiserver: この API サーバーは、Kubernetes のギアとレバーを公開します。これは、WebUI ダッシュボードや kubeclt などのコマンドライン ユーティリティによって使用されます。これらのユーティリティは、人間のオペレーターが Kubernetes クラスターと対話するために使用されます。

3. kube-scheduler: リソースの可用性、オペレーターが設定したポリシーなどに基づいて、クラスター内でイベントとジョブをスケジュールする方法を決定します。また、クラスターの状態に関する情報を取得するために、kube-apiserver をリッスンします。

4. etcd: これは Kubernetes マスターノードの「ストレージ スタック」です。キーと値のペアを使用して、ポリシー、定義、シークレット、システム状態などを保存します。

複数のマスターノードを持つことができるため、1 つのマスターノードに障害が発生しても Kubernetes は存続できます。

ワーカーノードには次のものがあります:

1. kubelet: ノードの健全性に関する情報をマスターノードに中継し、マスターノードから与えられた指示を実行します。

2. kube-proxy: このネットワーク プロキシを使用すると、アプリケーションのさまざまなマイクロサービスがクラスター内で相互に通信できるようになり、必要に応じてアプリケーションを世界中に公開することもできます。原則として、すべての Pod はこのプロキシを介して他のすべての Pod と通信できます。

3. Docker: これはパズルの最後のピースです。各ノードにはコンテナを管理するための Docker エンジンがあります。

もちろん、Kubernetes には他にもたくさんの機能があるので、ぜひすべてを調べてみることをお勧めします。

業界全体でのDockerとKubernetesの採用

これまで議論してきたコンセプトの多くは、理論上は良さそうに聞こえますが、経済的でしょうか?これらは本当にビジネスの成長、ダウンタイムの削減、人的資源とコンピューティング能力の両面でのリソースの節約に役立つでしょうか?

実稼働環境の Docker:

Docker の導入に関しては、答えは簡単です。特に、ソフトウェアにマイクロサービス ベースのアーキテクチャを採用する場合は、各マイクロサービスに Docker コンテナを使用する必要があります。

この技術はかなり成熟しており、これに反対する点はほとんどありません。コードを単にコンテナ化しても、コードが改善されるわけではないことに注意してください。コンテナ化されたプラットフォームを本当に使用したい場合は、モノリシック設計を避け、マイクロサービスを使用するようにしてください。

実稼働中の Kubernetes:

本番環境での Kubernetes について不満を言う人を責めることはできませんが、私の個人的な意見では、その理由は 2 つあります。

まず、ほとんどの組織は、分散システムの基本的な概念をまったく理解せずに分散システムを導入します。独自の Kubernetes クラスターをセットアップし、それを使用してシンプルな Web サイトや小規模でスケーラブルなアプリケーションをホストしようとします。

2 つ目は、Kubernetes が急速に進化しており、他の組織がサービス メッシュやネットワーク プラグインなど、独自の特別な機能を Kubernetes に追加していることです。その多くはオープンソースであるため、オペレーターにとって魅力的です。ただし、本番環境で実行することはお勧めしません。これらに対応するには、クラスターの継続的なメンテナンスとより多くの人的時間が必要になります。

ただし、組織はクラウドでホストされる Kubernetes プラットフォームを使用してアプリケーションを実行できます。 AWS、Azure、Joyent、GCE などの企業が提供するデータセンターのグローバルな可用性は、Kubernetes の分散特性を最大限に活用するのに役立ちます。もちろん、クラスターのメンテナンスについて心配する必要はありません。

これは、中小企業では見落とされがちなことです。ノード障害に耐え、高いスケーラビリティを実現したい場合は、単一の 1U ラックや単一のデータセンターで Kubernetes を実行すべきではありません。

では、Kubernetes は実稼働環境で使用されていますか?はい、しかしほとんどの人にはクラウドホスト型ソリューションをお勧めします。

コンテナとクラウドコンピューティングの新時代

Docker は、オペレーティング システム レベルの仮想化ソフトウェアとしてではなく、ソフトウェアのパッケージ化および配信メカニズムとして販売されています。 Docker コンテナが競合他社の注目を集めた唯一の理由は、このソフトウェア配信方法にあります。

Dockerfiles のおかげで、ビルドの自動化が非常に簡単になりました。 docker-compose のおかげで、複雑なマルチコンテナのデプロイメントが標準化されました。 Docker イメージの構築とテスト、パブリックまたはプライベートの Docker レジストリの管理を含む完全な CI/CD ソリューションを提供することで、ソフトウェア エンジニアはコンテナーを論理的に極限まで活用しています。

Kubernetes は、コンテナを単一のコンピューターに閉じ込められることなく解放し、クラウドをこのテクノロジーにとってより魅力的な場所にします。ゆっくりと、しかし確実に、コンテナ化はクラウドに依存するすべてのサービスの標準となるため、このテクノロジーを早めに導入することが重要です。そうすることで、移行コストとそれに伴うリスクを最小限に抑えることができます。

分散オペレーティングシステムの例

Kubernetes を十分に理解せずに導入している企業について長々と述べてきましたが、Kubernetes を導入すべき理由について説明させてください。クラウド コンピューティングは、Google、Microsoft、Amazon などの多くの企業が互いに競い合う、非常に競争の激しい市場へと進化しました。

これにより、クラウドにソフトウェアを導入するコストが大幅に削減されます。 Kubernetes の最も優れた点は、大部分がオープンソースであるため、詳細にこだわることなく何が起こっているかを理解できることです。

Azure が Kubernetes サービスを宣伝する方法は次のとおりです。

表面的にどのように動作するかを知るだけで、分散システムで実行されるソフトウェアについて推論できるようになります。しかし、基盤となるクラスターを実際に管理することについて心配する必要はありません。

Amazon、Google、DigitalOcean も同様のソリューションを提供しています。中小企業や個人の開発者でも、アプリケーションを地球全体に拡張できるようになりました。どのように行われるかを少し知っておいても損はないので、少なくとも Kubernetes と Docker についてはある程度の知識が必要です。

「Kubernetes と Docker のどちらが良いか?」と考えるたびに、反対派は、Docker は素晴らしいが、Kubernetes はちょっと極端だと反論します。しかし、コンピューター サイエンスのすべては極端な自動化に関するものであり、Kubernetes はコンテナー化モデルを論理的に極限まで推し進めています。

より細かい区別 - ネットワーク

Kubernetes と Docker の議論の多くは、ストレージ スタックやネットワークの実装などの基本的な点から生じています。 Docker と Kubernetes はどちらも異なる方法で物事を行います。

コンテナが機能するには、CPU とメモリ以上のものが必要です。 Kubernetes や Docker ホストなどのプラットフォーム上でアプリケーションを実行する場合、多くの微妙な違いがあります。違いは多すぎてここで簡潔に述べることはできませんが、私が常に注目するのはネットワーク面の違いです。

Kubernetes では、各ポッドが特定の名前空間内のクラスター内の他のすべてのポッドと自由に通信できることが規定されています。 Docker には仮想ネットワーク トポロジを作成するという概念があり、コンテナーを接続するネットワークを指定する必要があります。このような違いは、試しに使ってみようという人にとっては本当に気が進まないものかもしれませんが、Kubernetes が Docker と根本的にどう違うかを考えると、これらは非常に重要です。

このジレンマを解決するには他に選択肢はなく、学習曲線に耐えるしかありません。徐々に、全体像がより鮮明に見えてくるでしょう。

Docker と Kubernetes 導入の考え方

Docker を使用すると、その利点は明らかです。アプリケーションを Docker コンテナで公開すると、任意の Linux ディストリビューションでも実行できます。 Illumos ベースのオペレーティング システム (Linux ではありません) でも Docker をサポートしており、Docker コンテナーを実行できます。

アプリケーションは実際には複数のマイクロサービスに分割できるため、各マイクロサービスは Docker コンテナとしてパッケージ化できます。明確に定義された API を使用すると、既存の機能に新しい機能を簡単に追加できます。たとえば、分析が必要な場合は、データベースと通信できる Hadoop コンテナを起動するだけです。

同様に、Kubernetes に関しては、ユーザーとクラウド サービス プロバイダーの両方が、Kubernetes を導入することで実際に大きなメリットを得ることができます。従来の仮想マシンとは異なり、コンテナ化に基づいているため、クラウド サービス プロバイダーはリソースを効率的に活用して高密度のコンテナを実現できます。これにより、価格を大幅に下げることができます。

一方、ユーザーはアプリケーションをグローバルに展開できるため、レイテンシが短縮され、ユーザー エクスペリエンスが向上します。

この変化の唯一の例外は、デスクトップ アプリケーション開発者です。ほとんどのデスクトップ アプリケーションは更新やバックアップにクラウドを使用する可能性があるため、主に単一のマシンで実行するように設計されています。

結論は

コンテナは素晴らしいです！これらにより、サービスやシステムをまったく新しいデジタルの方法で考えることができるようになります。 Docker と Kubernetes はどちらも今後も存在し続けるでしょう。彼らは将来、より良いものへと変身するために絶えず変化し続けています。企業をテクノロジー時代に対応させ、インフラストラクチャが最も必要とする場所にコンテナを実装します。

コンテナ中心のプラットフォーム向けに新しいソフトウェアを設計すると、アプリケーションのスケーラビリティが向上するだけでなく、将来性も高まります。古い VM を使い続けることは一時的には機能するかもしれませんが、数年後にはすべてをコンテナに移行するための多額のコストを負担するか、プロジェクトを完全に放棄しなければならなくなります。これで、誰かが「Kubernetes vs Docker」という話題を持ち出しても、専門用語に圧倒されることはなくなるでしょう。

オリジナルリンク: https://dzone.com/articles/kubernetes-vs-docker