Kubernetes がビジネスに不可欠な理由

サーバー アプリケーションをコンテナ経由でクラウドに移行する場合は、コンテナ オーケストレーションを行う必要があり、Kubernetes がここで重要な役割を果たします。

[[283663]]

AWS、IBM/Red Hat、Microsoft、VMware など、多くの企業が Kubernetes を採用していることに気付いたかもしれません。Docker Swarm と呼ばれる独自のコンテナ オーケストレーターを持つ Docker も、Kubernetes をサポートするようになりました。では、なぜみんなそうするのでしょうか?

サーバーや仮想マシンからコンテナにアプリケーションを移行する企業が増えるにつれて、Kubernetes が採用されることが多くなります。

かつて、企業はサーバー ハードウェア上でサーバー プログラムを実行していました。その後、単一のプラットフォーム上で複数のオペレーティング システムとアプリケーションを実行できる仮想マシン (VM) が登場しました。これにより、企業は単一のサーバー上で 10 個以上のサーバー インスタンスを実行できるようになります。これにより、企業はこれらの仮想マシン上でオンデマンドで実行できるようになり、コストが削減され、柔軟性が大幅に向上します。

企業は単一のサーバー上でより多くのサーバー プログラムを実行できるため、コストの削減と柔軟性が向上します。これはまさにコンテナが提供する利点です。

Hyper-V、KVM、Xen などのハイパーバイザーは、仮想ハードウェアをエミュレートすることで動作します。これにより、システム要件の点では過剰にプロビジョニングされますが、コンテナーは共有オペレーティング システムを使用します。つまり、ハイパーバイザーよりも効率的です。

コンテナは仮想化されたハードウェアではなく、単一の Linux インスタンス上に配置されます。つまり、企業は小さなコンテナ内でアプリケーションを実行できるということです。実際、ユーザーは同じハードウェア上で仮想化されたサーバー アプリケーションのインスタンスを 4 ～ 10 倍実行できます。

コンテナは継続的インテグレーション (CI)/継続的デプロイメント (CD) にも適しています。これは、開発者がコードを早期かつ頻繁に共有リポジトリに統合し、コードを迅速かつ効率的にデプロイすることを推奨する DevOps アプローチです。

最後に、コンテナを使用すると、開発者は軽量でポータブル、自己完結型で、事実上どこでも実行できる方法で、あらゆるアプリケーションを簡単にパッケージ化、転送、実行できるようになります。

そこで質問なのですが、これらすべてのコンテナをどのように管理するのでしょうか?コンテナを使用すると、単一のサーバーで数十のワークロードを開始、実行、終了することができます。ここで Kubernetes が役立ちます。

Kubernetesの歴史

Kubernetes の起源は Google の Borg から始まります。 Google での大規模なジョブ管理に使用される大規模な内部クラスタ管理システムです。その後すぐに、2014 年に Google は Kubernetes の最初のバージョンをリリースしました。このオープンソースのコンテナ オーケストレーション プログラムは、コンテナをマシンのクラスターにデプロイし、ヘルス管理とレプリケーション機能を提供し、コンテナが互いに、および他のプログラムに簡単に接続できるようにします。

したがって、Kubernetes には主に 2 つの利点があります。 Borg の系譜のおかげで、世界最大のコンテナ ユーザーである Google によってテストされました。また、Kubernetes をオープンソースにすることで、Google 固有のプログラムであるという負担から解放されます。特に、Google が 2018 年 8 月に Kubernetes プロジェクトのクラウド コンピューティング リソースを新しい拠点である独立した Cloud Native Computing Foundation (CNCF) に移行したときはそうでした。

CNCF が Kubernetes を引き継いで以来、Kubernetes は Google と Red Hat が主導するプロジェクトから、何千人もの貢献者が参加するプロジェクトへと変化しました。この間、事実上すべての競争相手が排除されました。競合企業はまだ存在するが、調査会社 Red Monk によれば、2017 年時点でも Fortune 100 企業の 50% 以上がコンテナ オーケストレーション プラットフォームとして Kubernetes を使用している。

Kubernetesでできること

Google の Kubernetes 主席エンジニア兼チーフアーキテクトである Brian Grant 氏は、次のように述べています。「Kubernetes は、宣言型の構成と自動化を促進しながら、コンテナ化されたワークロードとサービスを管理するための、移植可能で拡張可能なオープンソース プラットフォームです。」それはどういう意味ですか?

Kubernetes は Linux 上で実行され、1 つ以上のコンテナのグループであるポッドを使用して、単一のノード、物理サーバー、または仮想マシンにデプロイできます。コマンドは通常、ジョブのメタデータと仕様を定義する Kubernetes のコマンドライン構成ツールである kubectl を介して送信されます。これらの説明は、JavaScript Object Notation (JSON) または YAML で記述された宣言文で構成されます。これらは、Kubernetes API を介して、実行する必要があるアプリケーション、それらに必要なコンテナ イメージ、およびクラスターの望ましい状態を作成するために必要なネットワーク リソースとストレージ リソースを記述します。

Kubernetes マスターはコマンドを受け取り、利用可能なリソースを使用してコマンドを最適な方法で実行する方法を判断し、Pod Lifecycle Event Generator (PLEG) を介してユーザーの指示コマンドを Pod に中継します。ユーザーは正確な詳細について心配する必要はありません。

Kubernetes はタスクに最適なノードを見つけます。 Kubernetes はリソースを割り当て、作業を完了するために必要なポッドを割り当てます。したがって、Kubernetes はコンテナを自動的にセットアップ、監視、管理できます。

具体的には、Kubernetes を使用すると、ユーザーは次のタスクを実行できます。

• アプリケーションの展開と更新を制御および自動化します。これを使用すると、デプロイされたコンテナの望ましい状態を記述できます。次に、Kubernetes は、コンテナ化されたアプリケーションの実際の状態を、制御された速度で目的の状態に変更します。たとえば、ユーザーは新しいコンテナを作成したり、既存のコンテナを削除したり、コンテナのソフトウェア コンテンツを更新したりできます。
• コンテナの自動構成。ユーザーは、コンテナ化されたタスクを実行するために使用できるノードのクラスターを Kubernetes に提供します。次に、各コンテナに必要な CPU とメモリ (RAM) の量を Kubernetes に伝えます。 Kubernetes は、利用可能なリソースを最大限に活用するために、コンテナをノードに自動的にインストールします。つまり、コンテナ化されたアプリケーションとそのリソースの動的なスケーリングが可能になります。
• ストレージオーケストレーション。 Kubernetes を使用すると、ユーザーはローカル ストレージ、パブリック クラウド プロバイダー、ストレージ エリア ネットワークなど、任意のストレージ システムを自動的にマウントできます。
• ノード間でコンテナをオーケストレーションします。コンテナーは、ドメイン ネーム サーバー (DNS) ID または IP アドレスを使用して公開されます。コンテナのトラフィックが多い場合、Kubernetes はネットワーク トラフィックの負荷を分散して分散し、安定性を維持することもできます。
• 自己治癒。 Kubernetes は、障害が発生したコンテナを再起動し、コンテナを置き換え、ユーザー定義のヘルスチェックに応答しないコンテナをシャットダウンし、準備ができるまでコンテナをクライアントにアドバタイズしません。
• 安全管理。 Kubernetes を使用すると、ユーザーはパスワード、OAuth トークン、SSH キーなどの認証データを保存および管理できます。

これらすべてをまとめると、Kubernetes には 3 つの大きな利点があります。

1つ目は安定性です。 Kubernetes はユーザーのコンテナを管理します。仮想マシン、サーバー、またはクラスターに障害が発生した場合、Kubernetes は負荷を処理するために追加のコンテナを自動的に起動します。

そして継続性があります。 Kubernetes を使用すると、ユーザーは操作に影響を与えることなく、アプリケーションにパッチを適用したり、アプリケーションを完全に変更したりできます。新しいコンテナはオンラインで購入され、古いコンテナの有効期限が切れても、それらが提供するサービスは引き続き実行されます。かつて、IT の安定性はサーバーの稼働時間に完全に依存していました。現在、コンテナと Kubernetes では、サービスの稼働時間がすべてです。

関連するもう 1 つの利点は弾力性です。 Kubernetes はアクティブなコンテナを自動的に維持します。これらはレプリカ セットと呼ばれます。ポッドがコンテナ化されたアプリケーションをすべて持ち運ぶことができない場合、レプリカ セットには負荷を引き継ぐために必要なコンテナがすでに稼働しています。

つまり、Kubernetes ベースの IT 構造は、以前のアプローチが失敗したり、大幅なダウンタイムが必要になったりした場合でも、新しいソフトウェアで実行されます。

Kubernetes ではできないこと

Kubernetes は万能薬ではなく、すべてを実行できるわけではありません。

たとえば、Kubernetes は Platform as a Service (PaaS) システムではありません。 Kubernetes は PaaS のようなサービスの構成要素を提供しますが、Cloud Foundry とは異なり、クラウドネイティブ アプリケーションの構築に必要なプログラミング ツールは提供しません。また、Kubernetes 上で CI/CD システムを構築して使用することは確かに可能ですが、それは本質的に CI/CD ではありません。また、コンテナを管理する方法として、ミドルウェアやデータベースなどのアプリケーションレベルのサービスは付属していません。

このため、Amazon Elastic Container Service (EKS)、Azure Kubernetes Service (AKS)、Google Kubernetes Engine (GKE)、IBM Cloud Kubernetes Service、Red Hat の OpenShift、Pivo​​tal Container Service (PKS)、VMware Kubernetes Engine for Kubernetes など、Kubernetes ディストリビューションが数多く存在します。 Kubernetes を特定のクラウドにデプロイするために必要なツールを提供することに加えて、それぞれに独自の特別な追加機能があります。

Kubernetesが未来である理由

アプリケーションをサーバーや仮想マシンからコンテナに移行し続けるには、Kubernetes が不可欠です。 Ansible、Puppet、Salt などの DevOps ツールを使用したとしても、システム管理者が数百または数千の一時的なコンテナを管理する実用的な方法はありません。専用のツールが必要であり、そのツールが Kubernetes です。他にもコンテナ オーケストレーション ツールは存在し、現在も存在しています。特殊な目的の場合、一部の企業にはより適している可能性があります。ただし、一般的に言えば、Kubernetes はほとんどの企業にとってデフォルトのコンテナ管理の選択肢となるでしょう。

Kubernetes は、競合するクラウド企業によって運営されている場合でも複数のプラットフォームで実行できるため、ハイブリッド クラウドの人気のある選択肢になりつつあります。簡単ではありませんが、多くの Kubernetes ディストリビューターが、簡単に導入できる Kubernetes ベースのハイブリッド クラウドの提供に取り組んでいます。これにより、ユーザーは、パブリック クラウドをフロントエンド インターフェイスとして使用しながら、バックエンド データをプライベート クラウドに保持するプロセスであるハイブリッド クラウドの実行などが可能になります。

まとめると、Kubernetes をまだ実行していない場合でも、すぐに実行することになるでしょう。 Linux がサーバー オペレーティング システム領域を根本的に変え、仮想マシンがクラウド コンピューティングの台頭をもたらしたのと同様に、Kubernetes はユーザーをコンテナー ベースの分散コンピューティングへと導きます。