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アーキテクチャは次のようになります。
このソリューションの他の機能には次のものがあります。
- 図に示されているNetesエージェントは、KubernetesポッドでRancherコンテナ定義を実装するコンポーネントです。 このエージェントはすべてのKubernetesクラスターに接続し、それらを管理可能にします。
- Rancher 2.0に組み込まれているKubernetes Wizardは、 API Server 、 Scheduler 、 Controller Managerを含む独自の配布キットです。 これら3つのコンポーネントは、1つのコンテナで実行される単一のプロセスに結合されます。 デフォルトでは、すべてのクラスターのデータベースからのバックエンドは1つのデータベースに配置されます（「これにより、Rancherの組み込みクラスターの管理が大幅に簡素化されます」）。
- Rancherには、Javaで記述されたコンポーネントが1つしか残っていません（残りはすべてGoで記述されています）。これはCoreコントローラーです。 サービス、ロードバランサー、DNSレコードなど、KubernetesポッドにRancherサービスを実装します。 WebsocketプロキシとCompose executorとともに、これはRancherサーバー上で実行されるRancher Controllerの一部です（上の図を参照）。
- トムランチャーはPersistentVolumeClaims （PVC）です。 ライフサイクルが異なる3種類のボリュームがあります： コンテナスコープ （ コンテナの作成時に作成、コンテナの削除時に削除）、 サービススコープ （ サービスに類似）、 環境スコープ （ 環境が存在する間）
- このネットワークは、Rancher IPSecまたはVXLANオーバーレイソリューション（以前のバージョン）、および組み込みクラスター用のサードパーティCNIプラグインをサポートしています 。 隔離されたスペースでコンテナを起動するために、2つの新しいネットワークモードも提供されます：「レイヤー3ルーティング」（ホストサブネットごと）と「レイヤー2フラット」。
- Rancher 2.0は、「MySQLなどの標準SQL-DBMS」で動作するソリューションとして位置付けられています。 これを行うには、既製のDatabase-as-a-Serviceソリューション（AWSのRDSなど）を使用し、MySQL用のGalera ClusterまたはMySQL NDB Clusterを使用して自分で構成することをお勧めします。
- 計画されているスケーラビリティの制限：1000クラスター、クラスターあたり1000ホスト（およびクラスターあたり1万ホスト）、クラスターあたり3万コンテナー（およびクラスターあたり30万コンテナー）。
- 現在サポートされているDockerのバージョン：1.12.6、1.13.1、17.03-ce、17.06-ce （ Kubernetes 1.8によって最近リリースされた互換性リストに近い） 。
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
ブログもご覧ください。