Kubernetesとは何ですか?次のアプリケーションプラットフォーム

Kubernetesは、コンテナオーケストレーション、つまり、コンテナと呼ばれる複数の大部分が自己完結型のランタイムから構築されたアプリケーションの管理に人気のあるオープンソースプラットフォームです2013年にDockerコンテナ化プロジェクトが開始されて以来、コンテナの人気はますます高まっていますが、大規模な分散コンテナ化アプリケーションの調整はますます困難になる可能性があります。コンテナ化されたアプリケーションを大規模に管理しやすくすることで、Kubernetesはコンテナ革命の重要な部分になりました。

コンテナオーケストレーションとは何ですか?

コンテナは、VMのような関心の分離をサポートしますが、オーバーヘッドがはるかに少なく、柔軟性がはるかに高くなります。その結果、コンテナは、ソフトウェアの開発、展開、および保守についての人々の考え方を一新しました。コンテナ化されたアーキテクチャでは、アプリケーションを構成するさまざまなサービスが個別のコンテナにパッケージ化され、物理マシンまたは仮想マシンのクラスタ全体に展開されます。しかし、これにより、コンテナーオーケストレーション(コンテナーベースのアプリケーションの展開、管理、スケーリング、ネットワーキング、および可用性を自動化するツール)が必要になります。

Kubernetesとは何ですか?

Kubernetesはオープンソースプロジェクトであり、最も人気のあるコンテナオーケストレーションツールの1つになっています。マルチコンテナアプリケーションを大規模にデプロイおよび管理できます。実際には、Kubernetesは最も人気のあるコンテナ化プラットフォームであるDockerで最も頻繁に使用されますが、コンテナイメージ形式とランタイムに関するOpen Container Initiative(OCI)標準に準拠する任意のコンテナシステムでも機能します。また、Kubernetesはオープンソースであり、使用方法の制限が比較的少ないため、コンテナーを実行したい人なら誰でも、オンプレミス、パブリッククラウド、またはその両方で、コンテナーを実行したい場所ならどこでも自由に使用できます。 。

GoogleとKubernetes

Kubernetesは、Google内のプロジェクトとして誕生しました。これは、Googleが内部で使用していた以前のコンテナ管理ツールであるGoogle Borgの後継ですが、直接の子孫ではありません。Googleは2014年にKubernetesをオープンソース化しました。これは、Kubernetesが促進する分散型マイクロサービスアーキテクチャにより、クラウドでのアプリケーションの実行が容易になるためです。Googleは、コンテナ、マイクロサービス、Kubernetesの採用が、顧客をクラウドサービスに誘導する可能性があると考えています(ただし、Kubernetesは確かにAzureとAWSでも機能します)。Kubernetesは現在、LinuxFoundationの傘下にあるCloudNative ComputingFoundationによって管理されています。

Kubernetes vs.DockerおよびKubernetesvs。Docker Swarm

KubernetesはDockerに取って代わるものではありませんが、それを補強します。ただし、Kubernetes、Dockerの周りに出現した高レベルのテクノロジーの一部に取って代わります。

そのようなテクノロジーの1つに、DockerにバンドルされているオーケストレーターであるDockerSwarmがあります。Kubernetesの代わりにDockerSwarmを使用することは引き続き可能ですが、Docker Inc.は、今後、KubernetesをDockerCommunityおよびDockerEnterpriseエディションの一部にすることを選択しました。

KubernetesがDockerSwarmのドロップイン代替品であるというわけではありません。KubernetesはSwarmよりもはるかに複雑であり、デプロイするためにより多くの作業が必要です。しかし、繰り返しになりますが、この作業は、長期的には大きな見返りを提供することを目的としています。つまり、より管理しやすく、復元力のあるアプリケーションインフラストラクチャです。開発作業や小規模なコンテナークラスターの場合、DockerSwarmはより簡単な選択肢を提供します。 

KubernetesとMesos

Kubernetesの競合相手として聞いたことがあるかもしれないもう1つのプロジェクトは、Mesosです。Mesosは、もともとTwitterの開発者から生まれたApacheプロジェクトです。それは実際にはGoogleBorgプロジェクトへの答えと見なされていました。

Mesosは実際にはコンテナオーケストレーションサービスを提供していますが、その野心はそれをはるかに超えています。コンテナ化されたコンポーネントとコンテナ化されていないコンポーネントの両方を調整できる一種のクラウドオペレーティングシステムを目指しています。そのために、Kubernetes自体を含め、Mesos内でさまざまなプラットフォームを実行できます。

Kubernetesアーキテクチャ:Kubernetesの仕組み

Kubernetesのアーキテクチャは、さまざまな概念と抽象化を利用しています。これらの一部は、既存の使い慣れた概念のバリエーションですが、その他はKubernetesに固有のものです。

Kubernetesクラスター

最高レベルのKubernetes抽象化であるクラスターは、Kubernetes(それ自体がクラスター化されたアプリケーション)を実行しているマシンのグループと、それによって管理されるコンテナーを指します。Kubernetesクラスタには、クラスタ内の他のすべてのKubernetesマシンをコマンドおよび制御するシステムであるマスターが必要です。高可用性Kubernetesクラスターは、マスターの機能を複数のマシンに複製します。ただし、一度に1つのマスターのみがジョブスケジューラとコントローラマネージャを実行します。

Kubernetesノードとポッド

各クラスターにはKubernetesノードが含まれています。ノードは、物理マシンまたはVMである可能性があります。繰り返しになりますが、アイデアは抽象化です。アプリが実行されているものが何であれ、Kubernetesはそのサブストレートへのデプロイを処理します。 Kubernetesを使用すると、特定のコンテナがVM上でのみ実行されるようにすることも、ベアメタル上でのみ実行されるようにすることもできます。

ノードはポッドを実行します。ポッドは、作成または管理できる最も基本的なKubernetesオブジェクトです。各ポッドは、Kubernetesで実行されているアプリケーションまたはプロセスの単一のインスタンスを表し、1つ以上のコンテナで構成されます。 Kubernetesは、ポッド内のすべてのコンテナをグループとして開始、停止、複製します。ポッドは、コンテナー自体ではなく、アプリケーションにユーザーの注意を向け続けます。ポッドの状態からKubernetesを構成する必要がある方法の詳細は、分散型Key-ValueストアであるEtcdに保持されます。

ポッドは、ポッド定義でユーザーが指定した目的の状態に準拠するために、必要に応じてノード上で作成および破棄されます。Kubernetesは、ポッドのスピンアップ、ロールアウト、スピンダウンの方法のロジスティクスを処理するためのコントローラーと呼ばれる抽象化を提供します。コントローラには、管理するアプリケーションの種類に応じて、いくつかの異なる種類があります。たとえば、最近導入された「StatefulSet」コントローラーは、永続的な状態を必要とするアプリケーションを処理するために使用されます。別の種類のコントローラーであるデプロイメントは、アプリをスケールアップまたはスケールダウンしたり、アプリを新しいバージョンに更新したり、問題が発生した場合にアプリを正常なバージョンにロールバックしたりするために使用されます。

Kubernetesサービス

ポッドは必要に応じて存続し、消滅するため、アプリケーションのライフサイクルを処理するには別の抽象化が必要です。アプリケーションを構成するコンテナーを実行しているポッド自体が永続的でない場合でも、アプリケーションは永続的なエンティティであると想定されます。そのために、Kubernetesはサービスと呼ばれる抽象化を提供します。

Kubernetesのサービスは、特定のポッドグループ(または他のKubernetesオブジェクト)にネットワーク経由でアクセスする方法を記述します。Kubernetesのドキュメントに記載されているように、アプリケーションのバックエンドを構成するポッドは変更される可能性がありますが、フロントエンドはそれを認識したり追跡したりする必要はありません。サービスはこれを可能にします。

Kubernetesの内部にあるさらにいくつかの部分が全体像を締めくくっています。スケジューラノードへのワークロードのうち小包彼らは、リソース全体バランスしていると展開がアプリケーション定義の要件を満たすようになるように。コントローラマネージャシステム・アプリケーション、ワークロードの状態等がマッチ所望の状態がEtcdの構成設定で定義されたことを確実にします。

Docker自体など、コンテナーで使用される低レベルのメカニズムがKubernetesに置き換えられていないことを覚えておくことが重要です。むしろ、Kubernetesは、アプリを大規模に実行し続けるために、これらのメカニズムを使用するためのより多くの抽象化セットを提供します。

Kubernetes Ingress

Kubernetesサービスは、クラスター内で実行されていると見なされます。ただし、これらのサービスには外部からアクセスできるようにする必要があります。Kubernetesには、NodePortやLoadBalancerなど、さまざまな程度の単純さと堅牢性でこれを容易にするいくつかのコンポーネントがありますが、最も柔軟性のあるコンポーネントはIngressです。Ingressは、通常はHTTPを介してクラスターのサービスへの外部アクセスを管理するAPIです。

Ingressを適切にセットアップするには、少し設定が必要です。Kubernetesの開発に関する本を書いたMatthew Palmerが、彼のWebサイトでプロセスを順を追って説明します。

Kubernetesダッシュボード

これらの他のすべてのコンポーネントを把握するのに役立つKubernetesコンポーネントの1つは、アプリのデプロイとトラブルシューティング、およびクラスターリソースの管理を行うことができるWebベースのUIであるダッシュボードです。ダッシュボードはデフォルトではインストールされていませんが、追加してもそれほど問題はありません。

関連動画:Kubernetesとは何ですか?

この90秒のビデオでは、コンテナ化されたアプリケーションを自動化するためのオープンソースシステムであるKubernetesについて、テクノロジーの発明者の1人であるHeptioの創設者兼CTOであるJoeBedaから学びます。

Kubernetesの利点

Kubernetesは新しい抽象化と概念を導入し、Kubernetesの学習曲線が高いため、Kubernetesを使用することの長期的な見返りを尋ねるのは普通のことです。Kubernetes内でアプリを実行するのが簡単になる具体的な方法のいくつかを以下に示します。

Kubernetesは、アプリの正常性、レプリケーション、負荷分散、ハードウェアリソースの割り当てを管理します

Kubernetesがあなたの手を離す最も基本的な義務の1つは、アプリケーションを稼働させ、実行し、ユーザーの要求に対応するという忙しい仕事です。「不健康」になったアプリ、またはあなたが説明した健康の定義に準拠していないアプリは、自動的に修復できます。

Kubernetesが提供するもう1つの利点は、メモリ、ストレージI / O、ネットワーク帯域幅などのハードウェアリソースを最大限に活用できることです。アプリケーションには、リソース使用量にソフト制限とハード制限を設定できます。最小限のリソースを使用する多くのアプリは、同じハードウェアにまとめてパックできます。拡張する必要のあるアプリは、成長の余地があるシステムに配置できます。また、クラスター全体で更新をロールアウトしたり、更新が壊れた場合にロールバックしたりすることも自動化できます。

Kubernetesは、Helmチャートを使用して事前構成されたアプリケーションのデプロイを容易にします

Debian LinuxのAPTやPythonのPipなどのパッケージマネージャーは、ユーザーがアプリケーションを手動でインストールして構成する手間を省きます。これは、アプリケーションに複数の外部依存関係がある場合に特に便利です。

Helmは、基本的にKubernetesのパッケージマネージャーです。多くの一般的なソフトウェアアプリケーションは、相互に依存するコンテナのグループとしてKubernetesで実行する必要があります。Helmは、アプリケーションまたはサービスをKubernetes内のコンテナのグループとして実行する方法を説明する定義メカニズムである「チャート」を提供します。

独自のHelmチャートを最初から作成できます。また、内部にデプロイするカスタムアプリを作成する場合は、作成する必要があります。ただし、一般的な展開パターンを持つ人気のあるアプリケーションを使用している場合は、誰かがすでにそのアプリケーションのHelmチャートを作成し、公式のHelmチャートリポジトリに公開している可能性があります。公式のヘルムチャートを探すもう1つの場所は、Kubeapps.comディレクトリです。

Kubernetesは、ストレージ、シークレット、その他のアプリケーション関連リソースの管理を簡素化します

コンテナは不変であることが意図されています。あなたがそれらに入れたものは何でも変わるべきではありません。ただし、アプリケーションには状態が必要です。つまり、外部ストレージボリュームを処理するための信頼できる方法が必要です。これは、アプリの存続期間を通じてコン​​テナーが存続し、消滅し、生まれ変わる方法によって、さらに複雑になります。

Kubernetesは、コンテナとアプリが他のリソースと同じように分離された方法でストレージを処理できるようにするための抽象化を提供します。 Amazon EBSボリュームからプレーンな古いNFS共有まで、多くの一般的な種類のストレージには、ボリュームと呼ばれるKubernetesストレージドライバーを介してアクセスできます。通常、ボリュームは特定のポッドにバインドされますが、「永続ボリューム」と呼ばれるボリュームサブタイプは、ポッドとは独立して存在する必要があるデータに使用できます。

多くの場合、コンテナは「シークレット」(APIキーやサービスパスワードなど、コンテナにハードコードしたり、ディスクボリュームにオープンに隠したくない資格情報)を処理する必要があります。これには、DockerシークレットやHashiCorp Vaultなどのサードパーティソリューションが利用できますが、Kubernetesには、慎重に構成する必要がありますが、シークレットをネイティブに処理するための独自のメカニズムがあります。たとえば、Etcdは、プレーンテキストではなく、ノード間でシークレットを送信するときにSSL / TLSを使用するように構成する必要があります。 

Kubernetesアプリケーションは、ハイブリッド環境とマルチクラウド環境で実行できます

クラウドコンピューティングの長年の夢の1つは、任意のクラウドで、またはパブリックまたはプライベートのクラウドの任意の組み合わせで任意のアプリを実行できるようにすることです。これは、ベンダーロックインを回避するだけでなく、個々のクラウドに固有の機能を利用するためでもあります。

Kubernetesは、複数のリージョンとクラウド間で複数のクラスターの同期を維持するために、まとめてフェデレーションと呼ばれる一連のプリミティブを提供します。たとえば、特定のアプリのデプロイを複数のクラスター間で一貫性を保つことができ、異なるクラスターがサービスディスカバリを共有できるため、任意のクラスターからバックエンドリソースにアクセスできます。フェデレーションを使用して、複数のクラウド環境にまたがっているかどうかに関係なく、可用性またはフォールトトレラントなKubernetesデプロイメントを作成することもできます。

フェデレーションはまだKubernetesにとって比較的新しいものです。すべてのAPIリソースがフェデレーションインスタンス全体でまだサポートされているわけではなく、アップグレードにはまだ自動テストインフラストラクチャがありません。ただし、これらの欠点は、Kubernetesの将来のバージョンで対処される予定です。

Kubernetesの入手先