Clever Geek Handbook

Rancher 2.0で何が起こり、なぜKubernetesに移行するのですか？





1週間前、Rancherの開発者は 、コンテナオーケストレーションの単一基盤としてKubernetesへの移行を発表すると同時に、将来のメジャーバージョン2.0の予備リリースを発表しました。 開発者がこのように進んだ理由は何ですか？



背景：牛



Rancher 1.0は昨年3月にリリースされましたが、今日の世界では、Rancher Labsによると、1万を超える既存のインストールと100を超える商用ユーザーがいます。 Rancherの最初のバージョンにはCattleが含まれていました。これは、「Javaで記述された高レベルコンポーネント」として、「オーケストレーションの基本エンジン」および「システム全体のメインサイクル」と呼ばれていました。 本質的に、Cattleはコンテナオーケストレーションのフレームワークではなく、メタデータ（+リソース、関係、状態など）を管理し、すべての実際のタスクを外部システムに転送する特別なレイヤーです。



Cattleは、Docker Swarm、Apache Mesos、Kubernetesなどの市場で利用可能な多くのソリューションをサポートしました。著者が書いているように、「Rancherユーザーは、コンテナオーケストレーションのフレームワークを自由に選択できる管理プラットフォームを導入するアイデアが好きだったからです」



ただし、Kubernetesの人気の高まりは、このシステムとの機能と対話の容易さに関してRancherユーザーから課せられる新しい要件の出現に貢献しています。 同時に、Kubernetesの現在の問題とその展望に関するRancher Labsの経営陣の見解は変わりました。



Kubernetes：昨日、今日、明日



2015年、Rancher LabsがKubernetesとの連携を開始したとき、つまり 開発者によると、K8sの主な問題はプラットフォームにサポートを追加することで、システムのインストールと初期構成でした。 したがって、Rancher v0.63リリース（2016年3月17日）でのKubernetes の主要なサポートの発表の誇りは、「ワンクリックでKubernetes環境を開始でき、5〜10分後に完全にデプロイされたクラスターにアクセスできるようになりました。」



時間が経ち、Kubernetesの次の主要な障害は、Rancher Labsの責任者によると、クラスターの継続的な運用と更新でした。 昨年末までに、この問題も深刻になりました。kopsのようなユーティリティの積極的な開発と、Kubernetesをサービス（Kubernetes-as-a-Service）として提供する傾向のおかげです 。 これにより、GoogleのKubernetesプロジェクトの創設者であり、現在Heptioの責任者であるJoe Bedaは、最新のアプリケーションを起動するための次のプラットフォームはKubernetesである、または「Kubernetesはこのプラットフォームの重要な部分になるが、これは間違いなく終わりません。」



また、MesosphereのDC / OS でのKubernetesのサポートや、 MicrosoftやOracleなどのIT巨人のKubernetesエコシステムへの公式な接続など、ごく最近のイベントにより 、より客観的な確認が提供され ます 。 CNCFのみとの最新の提携により、オンライン出版物であるARCHITECHTは、「Oracleが搭載されれば、Kubernetesはコンテナオーケストレーションの事実上の標準になるはずです」と述べました。



Rancher Labsでは、Kubernetesへの道の次のステップは「インフラストラクチャのユニバーサル標準」への転換であると「賭け」ます。



「DevOpsチームは、Kubernetesクラスターを個別に管理する必要がなくなります。 残る唯一の困難は、どこでも利用できるKubernetesクラスターを管理して使用することです。


これを念頭に置いて、同社のエンジニアはRancherのメジャーアップデート-バージョン2.0を採用しました。



ランチャー2.0



Rancher 1.0と同様に、バージョン2.0では、プラットフォームはサーバー（インストール全体を管理するため）とエージェント（すべてのホストされたホストにインストールされる）で構成されます。 Rancher 2.0と1.0の主な違いは、Kubernetesがサーバーに組み込まれたことです。 これは、 rancher/server



Dockerイメージを実行すると、Kubernetesクラスターが起動し、追加した各新しいホストがその一部になる（ kubeletを持つ ）ことを意味します。 さらに、このウィザードに加えて追加のクラスターを作成したり、kopsを使用したり、Google（GKE）などの外部プロバイダーから既存のクラスターをインポートしたりできます。 Rancher Agentは、すべての組み込みおよびインポートされたクラスターで実行されます。



このすべてのKubernetesクラスターのなかで、Rancherは、集中管理（認証とRBAC、プロビジョニング、更新、監視、バックアップ）およびそれらとの対話（Webベースのユーザーインターフェイス、API、CLI）のための共通レイヤーを実装します。







より詳細に（ホストレベルまで）、Rancher 2.0アーキテクチャは次のようになります。







このソリューションの他の機能には次のものがあります。





Rancher 2.0テクニカルデバイスの詳細については、 このPDFをご覧ください。



さらに、もちろん、開発者はエンドユーザーのインターフェイスの改善を行い、Rancher UI（およびアプリケーションディレクトリ）をさらに簡単にし、上級ユーザーがkubectlとKubernetesダッシュボードにアクセスできるようにしました。 Rancher 2.0の 15分間のプレゼンテーションが YouTubeに投稿されており、内部および外部の両方の変更を示しています。



技術プレビューとして販売され、1週間前にリリースされたRancher 2.0の現在のバージョンはv2.0.0-alpha6です。 最終リリースは2017年の第4四半期に予定されています。



CoreOSおよびフリート



Rancher 2.0の話は、CoreOSとはまったく異なる例で締めくくります。 実際のところ、DevOpsの世界ではかなり有名なオープンソース製品であるフリートでは、Kubernetesの普遍的な適応のコンテキストから見ると同様の話が発生しました。 「分散initシステム」として特徴付けられ、フリートはsystemdとetcdをリンクし、（単一のマシンの代わりに）クラスタ全体のsystemdを使用します。 「高レベルのオーケストレーションの基礎」になるために作成されました。



昨年の終わりに、フリートプロジェクトのステータスは「チェックインプロダクション」から「開発および保守されていません」に変更され、今年の初めに、フリートのイメージは2018年2月1日からContainer Linuxの一部ではなくなることが明らかになりました。 なんで？



代わりに、すべてのクラスターのニーズに対して、CoreOSはKubernetesのインストールを推奨しています。


このテーマに関するCoreOSのブログ投稿（2017年2月）では、Kubernetesが「オープンソースコンテナを統合するための事実上の標準になりつつある」ことが明らかにされています。 著者はまた、「多くの技術的および市場的理由から、Kubernetesはコンテナインフラストラクチャを管理し、大規模に自動化するための最良のツールです」と主張しています。



PS



ブログもご覧ください。





More articles:


All Articles