Kubernetesとは何ですか? ビジネスが知っておくべきすべてのこと

Kubernetesとは何ですか?

Kubernetes が成長し続けるにつれて、Kubernetes の周囲の世界も変化するため、Kubernetes の定義は変わり続けています。 2019 年秋版は次のとおりです。Kubernetes は ワークロードの分散とオーケストレーションのメカニズム データセンター内のクラスタ化されたサーバー向けに、リソースの可用性、アクセス性、および複数のサービスのバランスのとれた実行を同時に確保します。

このスキームでは、Kubernetes により、さまざまな種類の任意の数のサーバーを任意の距離で同時に接続し、共通のテナントのワークロードを共有できます。 次に、それらのワークロードをサービスとしてクライアントに提示します。つまり、クライアント システムはクライアントにアクセスできます。 ネットワーク経由でデータを渡し、1 ～ 2 分待った後、 応答。

これは分散データ処理であり、かつては 1 つのネットワーク内で行われていました。 モノリシックアプリケーション. Kubernetes は、このプロセス全体を可観測性と管理性で実現します。

これらのサービスを管理する際、Kubernetes は必要に応じてネットワークのレイアウトを変更します。 特定の種類またはクラスのワークロードのリクエストを行うクライアントが増えると、オーケストレーターは利用可能なそのレプリカをさらに多く作成します。 同様に、リクエストが減少すると、レプリカの数が減ります。 これは Kubernetes の名声をもたらしたプロセスであり、IT オペレーターはそれぞれスケールアウトとスケールバックと呼んでいます。 サービスを細分化すると、 個々の機能、またはマイクロサービス、本来であれば共有するメモリやプロセッサを介するのではなく、ネットワークを介して相互に通信することで、Kubernetes は次のことが可能になります。 個々のマイクロサービスを、あたかも完成したかのようにスケールアウトし、需要の増減に応じてスケールバックします。 アプリケーション。

Kubernetes のビジネスケース

私たちのビジネス、商取引システム、そして社会のかなりの部分が構築されている情報技術プラットフォームは、老朽化を見せています。 それらを置き換えるには、コストを上回るメリットが問題になります。 として 5G ワイヤレス移行に取り組んでいる通信サービス プロバイダー が証明するように、短期的なビジネス モデルが確実な収益性を確保できない限り、組織がインフラストラクチャ全体を交換するコストを正当化することは困難です。

Kubernetes はビジネスの収益性について主張しているだけでなく、それ自体を証明するためにいくつかのテスト ケースを積み上げています。 これに有利なのは、組織が今日、既存のインフラストラクチャを維持するために支払うコストが増え続けており、その正当性がますます薄れてきているという証拠が増えていることです。

• クラウドは第一世代の仮想化に基づいています、それは時代遅れになり、おそらくやがて無関係になりつつあります。 通常、サーバーのメイン ハード ドライブにインストールされるソフトウェアのイメージは、次のとおりです。 リモート サーバーのメモリとストレージにレンダリングされるため、ソフトウェアはそこでいつものように実行できます。 前に。 これまでのように、ソフトウェアを実行するように作成する必要はなくなりました。 モノリシック アプリケーションを作成し続けるためのビジネス ケースは消滅しました。 大規模マルチプレイヤーオンラインゲームその基盤となる独自のプラットフォームはメーカーの独占的ドメインです。
• インターネットはドメイン システムを使用してマッピングされます 使用されている機能やサービスではなく、アドレスをその登録所有者にマッピングします。 サービスメッシュ これらのマップをより関連性の高いマップでオーバーレイすることで、分散アプリケーションが広範囲に分散したネットワーク上で相互に検索できるようになります。 これらのサービス メッシュは Kubernetes に緊密にバインドされており、ワークロード オーケストレーションに次いで 2 番目に関連性の高いシステム サービスを提供します。
• モバイルデバイスはモバイルアプリに依存しています 主にクライアントとサーバー間で交換される情報を最小限に抑えるために、「スマート」機能をクライアント側に配布します。 無線帯域幅がもはや特別な商品ではなくなったため、その機能をサーバー側に戻して、新たな通信を可能にする方がより実用的かつコスト効率が良くなる可能性があります。 非常に優れたカメラを搭載しているにもかかわらず、前世代よりも大幅に「鈍い」デバイスのクラスでありながら、おそらくより高いレベルで同じタスクを実行します スピード。
• パブリッククラウドデータセンターは、 大規模な「ハイパースケール」施設 多くの場合、数百マイル離れた距離から、数万のテナントに同時にサービスを提供します。 より分散性の高いコンピューティングが可能になると、より小規模なデータ センターを多数、ユーザーの近くに分散配置することがより現実的でより望ましいものになる可能性があります。
• 人工知能はソフトウェアの上位クラスを構成します、主にその相対的な理由により、 メモリ、ストレージ、その他のリソースのコストが高い. それぞれのフットプリントがはるかに小さい無数のコンテナで構成される分散サービス モデルを使用すると、AI はさらに一般的になる可能性があります。 より適切な推論を引き出すソフトウェア (例: 「30 ヤード離れたあの木に気をつけてください!」) は、「標準動作」と呼ばれるほど「スマート」とは呼ばれません。 装置。"
• コンテナ化により、ビジネス ソフトウェアの管理が容易になります。 サーバーベースのコンピューティングのコンテキストでは、コンテナーはワークロードの仮想化を可能にするパッケージです。 (ポータブル、自己完結型、単独で実行) オペレーティング システムによってホストされている間 (オペレーティング システムとは対照的に) ハイパーバイザー)。 最新のアプリケーションは、単にパッケージ化して展開するだけではなく、コンテナ化することでサーバー間で移植可能になります。 コンテナ化された環境では、ソフトウェアのコードがリポジトリ (一部はパブリック、その他はプライベート) から取得または「プル」され、すぐに運用環境にデプロイされて実行されます。 この自動展開方法により、ソフトウェアは 18 か月ごとだけでなく、場合によっては毎日、作成者だけでなくユーザーによっても改善されるようになります。 これにより、データセンター システムの完全性とセキュリティが劇的に向上します。

「オーケストレーション」とは

オーケストレーションとは、IT プラットフォームに共存する複数のワークロードを効果的に管理および実行することです。 Kubernetes の場合、特定のワークロードはすでにマイクロサービスに分割された状態でプラットフォームに到着する可能性があります。 彼らは依然として連携していますが、独立したユニットとして活動しています。 Kubernetes オーケストレーションにより、必要に応じてこれらのユニットを増やしたり再配布したり、使用されなくなったら段階的に廃止したりできます。

オーケストラの指揮者みたいな？

間違った例えです。 指揮者は、曲が適切な時間とリズムで演奏されるようにします。 データセンターでは、オペレーティング システムが引き続きその役割を果たします。Kubernetes によってこれは変わりません。 オーケストレーターは、最大限の効率とスムーズさを実現するために、構成内のすべてのパートの実行を調整します。 そのため、ある部分が他の部分をかき消してしまうことはなく、すべての部分がそれぞれの役割を果たします。 効果的に。 これらのパーツは複数の場所に広く分散されている可能性があるため、オーケストレーターは、目の前の同じタスクに貢献するためにパーツが必要とする可能性のあるすべてのリソースもまとめます。

オーケストレーターとオペレーティング システムの対比

コンピューター上のオペレーティング システムなどにより、プロセッサーでプログラムを安全かつ期待どおりに実行できるようになります。 Kubernetes は、クラスター内の複数のサーバーに分散される複数のワークロードに対してその役割を同時に果たします。

これは、Kubernetes がスケールアップされたオペレーティング システムであると言っているわけではありません。 OS は依然として各プログラムの実行を整理する役割を果たします。 また、コンテナ化された環境 (少なくとも、当初設計されたネイティブ環境) では、各コンテナのホストは、vSphere や KVM の場合のようにハイパーバイザーではなく、OS になります。

ただし、ある点では、単一のコンピューターにとってのオペレーティング システムと同じようなもの、サーバーのクラスターにとってのオーケストレーターのようなものがあります。オーケストレーターは、実行を監督します。 インフラストラクチャ リソース (処理能力、メモリ、ストレージ、ネットワーク機能) がすべて機能しなくなったシステム内のソフトウェアの割合 合併した。 Kubernetes は、クウェートを解放した連合国軍のように、データセンターがどのオーケストレーターを優先するかという問題を非常に短期間で解決しました。 Operation Desert Shield と同様に、Kubernetes には迅速に実行されるシンプルな戦略がありました。

すべてのソフトウェアはどこに行くのでしょうか?

最新のデータセンターでは、ソフトウェアをコンピュータに「インストール」する必要はありません。 むしろ、図書館から借りる本に似ており、貸し出す前に本を出版できるのは図書館だけです。 コンテナ化の領域では、このライブラリはレジストリと呼ばれます。 レジストリから貸与されたオープンソース パッケージは、完全に組み立てられたコンテナで提供されます。 Kubernetes が管理する環境に導入するためにレジストリを介してアプリケーションまたはサービスを利用可能にする行為は、デプロイメントと呼ばれます。 したがって、「ワークロードの展開」について話すときは、サーバー クラスターにソフトウェアを配信し、そこで管理および調整されるソフトウェアを準備する行為を指します。

Kubernetes は、ワークロード パッケージをレジストリから取得し、それらをシステムにデプロイするためにキューに入れ、管理するために構築されています。 クラスタ間の分散を監視し、これらを通じて利用可能なリソースへのアクセスを管理します。 クラスター。

コンテナ化にこのようなひどい名前が付けられるのに、なぜコンテナ化がそれほど重要なのでしょうか?

コンテナ化は、Docker Inc. によって正式に開始されたトレンドであり、その後 Google によって猛スピードで推進され、現在では Microsoft や VMware を含むプラットフォーム分野のほとんどすべての企業が参加しています。 これはデータセンター管理の難解な側面であり、日常のユーザーには気付かれないものだと 4 年前に言われていました。 しかし、Netflix と Amazon Prime のすべての視聴者、そして Alexa と Siri のすべてのユーザーは、たとえその原因を特定できなかったとしても、この影響を直接感じたことがあるでしょう。 データセンター管理の焦点がマシンからワークロードに移ったことで、アプリケーションとサービスの提供方法に革命が起こりました。

タッパーウェア パーティーを産業化する方法のように聞こえる「コンテナ化」ではなく、 「ワークロード革命」と呼ばれる。 ネットワークは現在、機能ではなく機能に向けてルーティングされています。 機械。 現実世界の十分な例えがなければ、このアイデアの重要性を実際に理解することは困難です。つまり、頭の中で電話番号をいくつ思い出せますか? スマートフォンには連絡先リストがあり、あなたの声に応答できるようになった今、頭の中にある数字のパターンは増えましたか、それとも減りましたか?

この「ワークロード」ビジネスとは何でしょうか?

コンピュータ上で動作するプログラムは依然として「ソフトウェア」であり、NASA の技術者がもともとアポロ時代に語呂合わせとして作った用語を引用しています。 また、アプリケーションは依然として複数のユーザーによって操作され、名前で参照されるように設計されたプログラムです。

それに比べて、「ワークロード」は少しあいまいです。 1 つまたは複数のソフトウェアで構成されます。 データベースを使用する場合もありますが、他のワークロードが使用しているのと同じデータベースである可能性もあります。 レジストリ内の複数のパッケージで構成され、オンザフライで組み立てられ、クラスター内で機能を共有する場合があります。 しかし、通常は 1 つの主要な目的があり、複合部品がいくつあっても、1 つのまとまりのあるユニットとして動作できます。

ソフトウェア開発者は通常、机に座ってワークロードを作成することはありません。 彼らは今でもプログラムを書いています。 しかし、これらのプログラムを中心に組み立てられたコンテナをデプロイするプロセスにおいて、Kubernetes などのオーケストレーターに与えられる指示は、アクティブなワークロードの動作パラメーターを宣言することになります。 したがって、展開の際、ソフトウェアはワークロードになります。 データセンターのリソース消費に対する影響は、 人や物の日常領域におけるワークロードの影響を測定し、軽減することができます。 従業員。

さて、それでは「サービス」とは何でしょうか？

最新のデータセンターのサービスは、アプリケーションとはまったく異なります。 アプリケーションは便利なサービスを実行するものとして説明されることが多いため、これは賢明ではないように思われるかもしれません。 しかし、アーキテクチャ的に言えば、サービスとは、指定された入力が与えられ、関連データが指定されると、予測可能な一連の出力を生成するソフトウェアです。 データベースはサービスを使用してクエリされることがよくあります。

アプリケーションは、サービスを使用できる環境 (通常は視覚的な環境) をユーザーに提供します。 サービス自体がその機能に関与する必要はありません。

現在、オーケストレーションされたコンテナ化されたプログラムのほとんどはサービスです。 これらはアプリケーションの最も重要な業務を実行しますが、独立したユニットです。 マイクロサービスは、自己完結型の個別の自立したサービスであり、規模が小さい傾向があります (ただし、最近、ソフトウェア アーキテクトは、そうである必要はない、と主張しています)。 オーケストレーターは、必要な数、または許可される数のマイクロサービスのクローンを呼び出し (または「インスタンス化」) して、それらに向けられたリクエストに応答することができます。

API (元々は「Application Program Interface」の略) は、指定された通信プロトコルを備えた一連のサービスです。 ネットワーク コンピューティングでは、API は、コマンドまたはステートメントを受信サーバーに中継するために作成された URL を使用して、通常は Web ブラウザからリモートでアクセスできるように設計されています。 このコマンドは、途中でデータ パッケージをアップロードすることもあります。 そのコマンドに対する応答者はサービスです。 Kubernetes の強みはサービスのオーケストレーションです。

はい、サービスはワークロードの一種です。 おそらく、最新のサービス アーキテクチャの最も顕著な例は次のとおりです。 いわゆるサーバーレス機能. これは、そのソース (それをホストするサーバーまたはサーバー クラスター) が、別のサービスやそのユーザーによって呼び出されるときに、名前で、または間接的にさえ指定する必要がないため、このように呼ばれます。 代わりに、これらの詳細はリクエスターに代わって入力され、その結果、その関数のユーザーはその関数がクライアント上でローカルに存在するかのように振る舞うことができます。 スマートフォンの連絡先リストと同じように、数字は無関係になったと考えるようになります。

Kubernetes のコンポーネント

お気づきかもしれませんが、この記事は最初の 10 段落まで「コンテナ」という言葉もそれ以下の言葉も引用せずに省略されています。 「コンテナ化」という言葉は一目瞭然です。 Kubernetes のコンテナからの切り離しは、ここ数か月で最も予期せぬ変更の 1 つです。 Kubernetesの。 しばらくすると、その理由がわかります。

オーケストレーションの重要な目的の 1 つは、ネットワーク内で物事を利用できるようにすることです。 これまで、私たちはこれらのものを主に「コンテナ」と呼んできましたが、それ以来、 Kubernetes は当初、調整し効果的にオーケストレーションするエンティティを次のように呼んでいました。 ポッド。 この文脈では、「ポッド」という用語は単に「コンテナのグループ」として定義されています。

コントロール プレーン上のポッドとリソース

Kubernetes クラスター内の各サーバー (物理または仮想) はノードと呼ばれます。 Kubernetes の一部の側面をホストし、オーケストレーターによって維持されるネットワークを通じてアドレス指定できる場合、それはノードです。 マスター ノードと任意の数のワーカー ノード (ミニオンと呼ばれることもあります) があります。 システムの制御を担当するコンポーネントのネットワークは、他のすべてのネットワークから分離され、コントロール プレーンを形成します。 この特別なプレーンには、次の 3 つのコンポーネントがあります。

• APIサーバー(kube-apiserver)、ポッド内で実行されているサービスを含むすべての受信リクエストを検証します。
• コントローラーマネージャー(kube-コントローラー-マネージャー). システム内の一部のリソースの管理を直接担当する Kubernetes の個々のコンポーネントは、コントローラーと呼ばれます。 たとえば、ポッドベースのサービスが実行するジョブのプロビジョニングは、ジョブ コントローラーのタスクです。 ここが興味深いところです。Kubernetes は、さらにコントローラーを追加することで拡張され、単なるコンテナー以外のもののオーケストレーターになる可能性があります。
• スケジューラー (kube-scheduler)これは時間の問題ではなく、ポッドへのワークロードの委任の問題です。 ポッドがプロビジョニングされると、スケジューラは、現在の可用性状態を考慮して、ポッドを処理するのに最適なワーカー ノードにポッドを委任します。

コントローラーは Kubernetes コントロール プレーン内にあります。 Kubernetes に同梱されているものの主な機能は、ネットワーク インフラストラクチャ上のリソースの状態を監視し、変更がないかどうかを確認することです。 最善の対応方法を決定する評価関数をトリガーするには、そのような変化の信号であるイベントが必要です。 応答タスクを委任できるサービス クラスはオペレータです。 オーケストレーターがより複雑なシステムを自動化できるようにするために、サービス アーキテクトは次のことを追加します。 コントローラーはコントロール プレーンに接続して意思決定を行い、バックエンドのオペレーターはそれらに基づいて行動します。 決断。

カスタムリソース

このコントローラー スキームの拡張性が、最終的にはデータセンターにおける Kubernetes の地位を確固たるものにするマスターストロークとなる可能性があります。 カスタム リソース定義 (CRD) と呼ばれるアーキテクチャの追加の結果、 Kubernetes はこれらのコンテナ以外のものをオーケストレーションできます. 言い換えれば、他のものをオーケストレーションされたリソースとして認識するように Kubernetes に効果的に教えるコントローラーを作成できれば、そうすることになります。 ここで私たちは何を話しているのでしょうか?「他の何か」とは何でしょうか?

• 仮想マシン (VM) -- 世界中のエンタープライズ ワークロードの大部分をサポートする、古典的なハイパーバイザー駆動のエンティティ。 VMware は、その vSphere プラットフォームが VM 管理の有力な商業的リーダーであり、 Kubernetes を主な VM オーケストレーターにするプロジェクトをすでに開始しています.
• 大規模なデータベース そのエンジンと制御ジョブは近年、Hadoop や Apache Spark などの専用システムに移行しています。 開発者が Java、Scala などの選ばれた少数の言語以外の言語を使用してワークロードを再び自由に記述できるようになったら、これらのプラットフォームから移行します。 R.
• ハイパフォーマンス コンピューティング (HPC) ワークロード スーパーコンピュータの場合、歴史的には次のように管理されてきました。 Slurm などの専用スケジューラー そして、さらに最近では、 Apache メソス. Kubernetes がほぼユビキタスに近づくにつれ、データセンターにおける時間指向のスケジューリング エージェントとしての利点が疑問視されています。
• 機械学習モデル、これには、並列アクセスと決定論的なスケジューリングによる大量のデータが必要です。 これらの要因だけでは、Kubernetes はオーケストレーターまたはインフラストラクチャーのファシリテーターとして失格であると思われるかもしれませんが、次のようなプロジェクトがあります。 キューブフロー これらの機能を提供するデータベース プロバイダーとスケジューラー自体は、Kubernetes によってプロビジョニングされます。

データプレーン上のオブジェクト

ポッドに収集されるワークロードを担うエンティティのこれらすべてのクラスと、将来的に Kubernetes がオーケストレーションする可能性のあるその他のすべてのクラスは、 オブジェクト、より適切な言葉が見つからない.

これらのオブジェクトの 1 つをオーケストレーターに説明するのは、マニフェストと呼ばれる、その ID 書類として機能するファイルです。 これは、YAML と呼ばれる言語を使用して記述されたコードの要素であり、オブジェクトが使用することが予期されるリソースを宣言します。 ここで、コントローラーは、必要に応じて、オブジェクトが消費する燃料、つまりストレージの量、データベースのどのクラス、ネットワーク上のどのポートを消費するかをプレビューできます。 コントローラーは、クラスターがすでに過負荷になっている場合は、そのクラスターが備えているもので最善を尽くす必要があることを認識して、これらの要件を満たすためにベストエフォート型の試みを行います。

各ポッド内には、と呼ばれるリモート エージェントがあります。 キュベレット、オペレーターからのリクエストを受け取り、ポッドのコンポーネントを管理します。 従来のコンテナベースのシステムでは、 キュベレット コンテナ エンジンのプロセスを生成します。 これは、Docker が Kubernetes のテーブルで予約された場所であり、コンテナ エンジンの事実上の独占プロバイダーでした。 というユニバーサル ランタイムも作成されました。 ランC (「実行・参照」と発音します) し、オープンソース コミュニティにリリースしました。 現在、Kubernetes プロジェクトは、と呼ばれる独自の代替案を生み出しています。 CRI-O (「クライ・オー」ですが、「クレオール」のように言われることもあります)。これは、 Red Hat OpenShift などの Kubernetes ベースのプラットフォーム.

Kubernetes の競合他社の敗北

サーバー クラスター オーケストレーション スペースが現代のデータ センターで最も熱い戦場であるということをテクノロジー プレスの多くが集団的に認識する前に、戦いはすでに終わっていました。 商品市場では、競合する規格が長期間にわたって容認されることはほとんどありません。 HTML、Facebook、Kubernetes が 1 つずつ存在するのはこのためです。

Docker Swarm

コンテナ革命を引き起こしたエンジニアを擁するDocker Inc.がビジネスを設立 無料でオープンソースの大規模な導入、セキュリティ、サポートの商業化に基づいた哲学を早い段階から構築 芯。 収益は、「バッテリー」と呼ばれるビジネス モデルのため、Docker ブランドでありながら代替品が一般的に入手可能な Docker コアの付属品や補強材から得られます。 同梱されているが交換可能。」Docker のリーダーらは、コンテナがユビキタスになったとしても、知的かどうかにかかわらず、コンテナを機能させるものに対してコンテナが何の主張もすべきではないと主張しました。 商品。 市場が広がれば、より多くの意欲的な顧客が得られると同社は考えた。

そのために、2015 年に Docker が支援しました。 オープンコンテナイニシアチブの創設 (OCI、元々は Open Container Project または Open Container Foundation のいずれかでしたが、さまざまな理由からすぐに名前の変更が必要になりました)、Linux Foundation の後援の下にあります。 社内カンファレンスでの発表では、 当時の最高技術責任者（CTO）ソロモン・ハイクス氏は聴衆にこう語った。 彼は規格戦争を好まなかった。規格戦争は「箱のサイズや形状などの詳細」をめぐって議論されるものだと説明した。 そのため、中でも、 その他、Hykes は、Docker コンテナのランタイム コンポーネント (コンテナをネットワーク上で動作可能にする部分) の置き換えを発表しました。 と ランC.

まさに同じ週に、OCI の同じ創設メンバーの多くが次のことを発表しました。 クラウドネイティブコンピューティング財団の設立、Linux Foundation の別のプロジェクト。 表向き、CNCF の使命は、オープンソース アプリケーション展開テクノロジの使用を促進し、進歩させることです。 CNCFが管理する最初のプロジェクトは翌年3月に始まり、 Kubernetesになります、Google発のプロジェクト。

その間、あまり汎用性のないものでいくつかの実験を行った後、場合によっては、 導入プラットフォームでの厄介な試み, Swarm は Docker のオーケストレーターになりました。 ほとんどの人の見方によれば、Swarm は有力な候補者でした。 管理者らは、学習曲線はそれほど難しくないと述べた。 そのオーバーレイ ネットワーキング モデルは、コンテナ間トラフィックをホスト トラフィックから分離し、それぞれのプレーン内で それらの間の橋渡しとなるものは、特に Kubernetes のフラット ネットワーク オーバーレイ モデルと比較して、賢明であると認識されていました。 マルチクラウド展開モデルでは、Swarm コンテナ クラスターを低速のパブリック クラウドに委任し、コントロール プレーン上のトラフィックをより低遅延のクラスターに密接に封じ込めることができます。 パフォーマンスと管理のしやすさの点で、専門家はお気に入りを選ぶのに時間がかかりました。

もしパフォーマンスだけがテクノロジーの戦いの勝敗を決めるとしたら、Sun Microsystems はとっくの昔にデスクトップを征服しており、私たちは皆 BlackBerry でそのことについて話し合っていたでしょう。

CNCF は、以下を含むオープンソース エコシステム全体の広範な展開を推進し、促進することを使命としました。 パフォーマンス監視、サービス検出、データボリューム管理、セキュリティはすべて 1 つのワークロード展開を中心に行われます。 エンジン。 Docker はすでに拡張モデルを立ち上げ始めていましたが、 すぐに難解で哲学的な泥沼に巻き込まれた 拡張可能なアーキテクチャが「ステートレス性」と呼ばれるアプリケーション設計の特定の定説に違反しているかどうかをめぐって。

同時に、Kubernetes は純粋にベンダーに依存しないプラットフォームとして期待されていましたが、初期の頃、Google はその全容を重視し、 消費者とジャーナリストの両方に向けてテーマと一貫した売り込みを調整し、Kubernetes の名前をそのマーケティングの背後に織り込みます。 ブランド化。 2017 年を通じて、Kubernetes を評価する企業は、Kubernetes を Google 製品として認識しました。 合法性や手続きについて説明すると、多くの人は、最終結果が次のようなものであれば、どれも問題ではないと言って、彼らを振り払いました。 Google Kubernetes エンジン. 私が参加したいくつかの会話の中で、IT 管理者やその他のエンタープライズ専門家は、結局のところ、Google と Google の対立について私に言いました。 ドッカー、サム・ヒルってドッカーって何ですか？

しかし、Google はオーケストレーション信仰を唯一擁護する立場を長く維持することはできませんでした。 遡ること2015年、 Red Hat は重大な決定を下しました OpenShift コンテナ デプロイメント プラットフォームのエンジンを Kubernetes に置き換えます。 2017 年までに、その決断は多大な成果を上げました。 Red Hat は、トップレベルの Kubernetes コントリビューターになりました。 北のマイクロソフト社は、企業内の新たな変化の波から締め出される可能性を回避するために、オープンソース コミュニティで最も著名なエンジニア 2 人を雇用しました。 Gabe Monroy 氏は、コンテナ化されたアプリケーションを構築およびデプロイするための Kubernetes エコシステムの重要な要素である Deis の共同創設者兼 CTO でした (Docker が防御することを望んでいた防波堤) 自体）; そして、Brendan Burns 氏は、Kubernetes プロトタイプである Borg を作成した Google エンジニアの 1 人です [PDF]. 今回マイクロソフトは、新入社員を研究部門のサイドプロジェクトのクローゼットの奥に隠すつもりはなかった。 彼らは、Kubernetes のイメージで Azure の重要な部分を再作成することに率先して取り組みました。

ダムは決壊し、いくつかの場所で同時に決壊した。

Apache メソス

分散サーバー クラスターのワークロード スケジューリングにおける確立されたリーダーは、Apache Mesos でした。 これはマスター/ワーカー アーキテクチャの先駆者であり (ただし、Mesos は「ワーカー」に別の言葉を使用しました)、Marathon と呼ばれるプライベート PaaS プラットフォームに拡張された最初のスケジューラーの 1 つです。 Mesos の最初の大規模な展開は、Ben Hindman がエンジニアだった Twitter でした。 2013 年にハインドマン氏は退職し、Mesos の主要商業ベンダーである Mesosphere を設立しました。 Mesosphere は Microsoft と協力して、調整されたハイブリッド展開を可能にする初のパブリック クラウド ベースの PaaS の 1 つを作成しました。 DC/OS、これは Azure のワークロード展開プラットフォームの選択肢となるかのように見えました。 Mesos には数年間の導入経験があったため、誰もが最初から理解する必要がなかったプラットフォームでした。

しかし現職のメソスは、全力を尽くした反乱軍の挑戦者の影響から逃れることはできなかった。 2017 年 8 月、VMware は姉妹会社である Pivotal のリソースを活用して、 Pivotal Container Service と呼ばれるクラウドベースの Kubernetes プラットフォーム、Cloud FoundryからランクアップしたKuboと呼ばれる自動デプロイメントメカニズムを備えています。 Azure もすぐにこれに追随し、事実上 DC/OS プロジェクトを後回しにしてしまいました。 そして2018年6月、この屈強な アマゾンは守備の立場を放棄した、Kubernetes デプロイメント プラットフォームをオープンにします。 そして最後に、それを信じている人はほとんどいません IBMによるRed Hat買収、昨年7月に完了は、IBM がより優れた Linux ディストリビューションを必要としているという内容でした。 OpenShift はすでに分散データセンターへのルートを舗装していましたが、IBM はそれを再度舗装する必要がなくなったと判断しました。

あまりにも完全な敗北だったので、メソスフィアはもはやその名前で取引することができなくなりました。 昨年8月にD2IQと改名、そして独自の「Ksphere」を設立することを誓います。 そして10月初旬、 ドッカーが提案した ユーザーは Kubernetes と Swarm を並行して実行してみてください。 同社のブログ投稿には「新規ユーザーは Docker Swarm を理解するのがはるかに簡単だと感じています」と書かれている。 「しかし、Kubernetes は進化して多くの機能を追加しました。」

Kubernetes の今後の方向性

これまで、データセンターの再アーキテクチャに関する議論の多くは、古いワークロードを新しいモデルに移行するというトピックに集中してきました。 私たちが知るようになったアプリケーションは「モノリス」と呼ばれています。 なぜなら、映画「2001年」の謎の物体のように、それらは特異で、実質的に固体であり、劇場に4時間座っていた後でも、最初と同じように説明がつかないからです。 これらは、作成者だけが変更方法を知っているコードで構成されています。

Kubernetes への移行は、モノリスを移行するプロセスとして説明されています。 これは、モノリシックな前任者と同様に動作するが、完全に置き換えられるマイクロサービス ネットワークを再構築することによってのみ可能であると言う人もいます。 モノリシック サービスの周りに API をラップし、その API をマイクロサービス形式でネットワーク経由で配布することが可能だという人もいます。 企業がすでに所有しているのと同じ機能を複製するほうが簡単で、それほど労力もかからないでしょう。

現在、Kubernetes の CRD のおかげで、Arlo Guthrie の言葉を借りれば、誰も期待すらしていなかった 3 番目の可能性が生まれています。それは、Kubernetes 自体を移行して既存のワークロードのニーズを満たすことができるということです。 おそらく世界で最も活発なオープンソース ソフトウェア プロジェクトである Kubernetes は、文字通り何百人もの専門家によって保守されています。 企業がソフトウェアを自動化するために必要なコントローラーとオペレーターを考案または適応させるのを支援できるエンジニア サプライチェーン。

Kubernetes を作成した人々は、数年前に、自分たちの作成したものが次のような時代になるだろうと語っていました。 すべてのデータセンターの一部となっているため、退屈で誰も記事を読まなくなるでしょう。 それ。 私が目撃している限り、その日は少なくとも数年は先のことだ。

さらに詳しく -- CBS インタラクティブ ネットワークより

• Kubernetes の次のステップは、他のすべてをオーケストレーションしてみることかもしれません スコット M. フルトン三世、 ZDNet
• 5G はクラウド内の Kubernetes に依存します スティーブン・J. ヴォーン・ニコルズ ZDNet Linux とオープンソース
• Red Hat が Knative を Kubernetes オーケストレーションへの答えとみなしている理由 James Sanders、TechRepublic Cloud 著

他の場所

• Kubernetes カスタム リソース定義: CRD の説明 BMC ソフトウェアによる
• Kubernetes アーキテクチャ 101 by アクアコンテナセキュリティ
• Kubernetes アーキテクチャを理解する エドゥレカ著