牛のいる牧場主vsKubernetesのある牧場主vsスタンドアロンのKubernetes
私はRancherを掘り下げようとしていますが、RancherをKubernetesに接続することで、RancherのホームオーケストレーションフレームワークであるCattleに比べて追加のメリットがあるかどうか疑問に思いました。これまでのところ、誰かがKubernetesでRancherを選ぶ理由を理解できていません。 Kubernetesの初期設定を簡単にするだけですか？これらのオプションは、Kubernetesのスタンドアロンセットアップとどのように異なりますか？
これに対する非常に良い答えがあります。 Rancherは、Rancher 2.0を発表することで100％Kubernetesに移行しました： http://rancher.com/announcing-rancher-2-0/ 。牛はもう使用していません。
生産でRancher + CattleとKubernetesを同時に1年以上使用した後、いくつかの個人的な観察を共有できますが、最初にKubernetesとRancher + Cattleについての考えを共有します。
- Kubernetesは驚くほど柔軟性があり、拡張できるように設計されています。 Kubernetesクラスターが立つ2つの柱がありますkube-apiserverをメインユニットとして、etcdをストレージとして。その他の基本的なコンポーネントはクラスターに不可欠ですが、Kubernetes拡張機能と同様にkube-apiserverのAPIを使用するように設計されています。必要な方法でクラスターを設計し、さまざまなネットワークプロバイダー、認証/承認サービス、ボリュームプロバイダーを使用して、クラスター内のほぼすべてのコンポーネントを置き換えることができます。正しく構成されている場合、拡張Kubernetesクラスターはほとんどの場合基本的なCattleクラスターよりも安定します。 、牛の拡張については言えません。
- Kubernetesには、データを永続化し、データを秘密に保ち、データへのアクセスを制御するための、すぐに使用できる便利な機能が多数あります。これは重要な部分です。rancher-nfsは非常に壊れやすい、さらに、NFSストレージはボリュームを維持するためにCattleで持っている唯一の多かれ少なかれ安定したオプションです、ローカルストレージについては言及していません。
- Kubernetesは、小規模なチームでの頻繁でない展開と開発には行き過ぎです。間違いなく、CattleはKubernetesの単純なクローンとして作成され、名前空間、ポッド、スケジューリングなどの基本概念を継承していますが、クラスターのデプロイと保守が非常に簡単であるため、理解していない開発者にとって便利です。コンテナ化とネットワーキング。その単純さのために、それは重くて動的に変化する生産プロジェクトにはかなり使用できなくなりました。
- Kubernetesコミュニティは急速に成長しており、クラウドプロバイダーや、数え切れないほどの数のオープンソースプロジェクトやスタートアップによってサポートされているため、現在Graveに足を踏み入れているCattleよりもKubernetesを学ぶ方が賢明です。
- そして最後に-牛は不安定で、非常に不安定です。特にベアメタルで使用する場合は。私を信じてください、あなたは生産で牛を使いたくないです。
そして、RancherとKubernetesが結びついていることについて言えば、これは非常に優れた組み合わせです。RancherWebUIを使用すると、Kubernetesの概念が簡単になり、クラスターのメンテナンスとプロビジョニングがはるかに簡単になりますが、常にいくつかの「欠点」があります。 、バグにより、現在は本番環境で使用できなくなります。 Rancher 1.x + Kubernetesについては何も言えません。
私たちの経験では、牛は単なるおもちゃです。開発や小さな環境にぴったりです。 PRODでCattleを使用した場合は、私が言っていることがわかります。
しかし、Rancherはk8sよりもはるかに簡潔でシンプルです。
だから私は Rancher 2. を楽しみにしています、
Rancher 2.0は、Kubernetes上に構築された完全なコンテナ管理プラットフォームです