ここには多くの可動部分があります。すでに投稿された回答は非常に優れています。どんな回答にも意見はあると思います。100バウンティポイントを目指して、あなたのパンチリストを調べてみようと思いました:-)
CoreOS/Flannel/Kubernetes/Fleet を毎日約 6 か月使用しています。紹介にURLを載せてくださったので、見ることにしました。うわー、素晴らしいプレゼンテーション。Brandon Philips はとても良い先生だと思います。彼がそれぞれのテクノロジーを導入する際に、その上に築き上げた方法が気に入っています。そのチュートリアルを誰にでもお勧めします。
CoreOS は Linux ベースのオペレーティング システムです。それは非常に簡素化されており、余分な実行はありません。私にとって、それはこれらのことをします：
- 自動更新。これはうまくいきます。デュアル パーティション、非アクティブな更新、アクティブなスワップ、フォールバック (フォールバックを経験したことがないと思います)。「展開後にオペレーティング システムを更新する方法」の問題に取り組み、比較的簡単に行えるようにしました。
- systemd 初期化システム。これは私が好きになるのに少し時間がかかりました (/etc/init.d の人なので) が、しばらくすると気に入ってしまいます。かなり急な学習曲線があります。何が起こっているかを理解したら、systemd がどのようにマシンで特定のもの、依存関係、再起動 (必要に応じて) を実行し続けるか、ソケット (スーパー initd など) をリッスンし、プロセス、d-bus を生成するか (わかりませんが) を気に入るはずです。この部分についてはまだたくさん）。systemd では「ユニット」を指定でき、ユニットには依存関係、前後のプロセスなどを含めることができます。
- 基本的なサービス。CoreOS システムで実行されている各サービスから簡単な説明行をコピーしました。
- systemd - PID 1 として実行され、システムの残りの部分を起動するシステムおよびサービス マネージャーを提供します。
- docker - Docker は、あらゆるアプリケーションを軽量コンテナとしてパック、出荷、実行するためのオープンソース プロジェクトです
- etcd - etcd は、共有構成とサービス検出のための分散型の一貫したキー値ストアです
- sshd - sshd (OpenSSH デーモン) は、ssh(1) のデーモンプログラムです。これらのプログラムは一緒に rlogin と rsh を置き換え、安全でないネットワークを介して 2 つの信頼できないホスト間で安全な暗号化通信を提供します。
- locksmithd - locksmith は CoreOS 更新エンジンの再起動マネージャーであり、etcd を使用して、マシンのクラスターのサブセットのみが常に再起動されるようにします。locksmithd は CoreOS マシンでデーモンとして実行され、更新後の再起動動作を制御します。
- journald - systemd-journald は、ログ データを収集して保存するシステム サービスです。
- timesyncd - systemd-timesyncd は、ローカル システム クロックをリモート ネットワーク タイム プロトコル サーバーと同期するために使用できるシステム サービスです。
- update_engine
- udevd - systemd-udevd はカーネル uevent をリッスンします。イベントごとに、systemd-udevd は udev ルールで指定された一致する命令を実行します。udev(7) を参照してください。
- logind - systemd-logind は、ユーザーのログインを管理するシステム サービスです。
- resolve - systemd-resolved は、ネットワークの名前解決を管理するシステム サービスです。キャッシング DNS スタブ リゾルバーと LLMNR リゾルバーおよびレスポンダーを実装します。
- hostnamed - これは、ユーザー プログラムからホスト名と関連するマシン メタ データを制御するために使用できる小さなデーモンです。
- networkd - systemd-networkd は、ネットワークを管理するシステム サービスです。仮想ネットワーク デバイスを作成するだけでなく、表示されるネットワーク デバイスを検出して構成します。
CoreOS では、実行するすべてのものをコンテナーにする必要はありません。UNIXボックスが実行するものは何でも実行します。yum と apt-get が目立って欠落していますが、wget は含まれています。したがって、プログラム、ライブラリ、さらには wget を介して apt-get を「インストール」して、CoreOS ベースを汚染することができます。しかし、それは良いことではありません。あなたは本当にそれを元の状態に保ちたいと思っています。そのために、サンドボックスのようなコンテナーを実行して、ログアウトすると消える作業を実行できる「ツールボックス」が含まれています。
CoreOS の私のお気に入りの部分は、cloud-config です。最初の起動時に、cloud-config と呼ばれる user_data を提供できます。これは、最初の起動時にベース CoreOS に何をすべきかを指示する yaml ファイルです。これは、フリート、フランネル、kubernetes などをインストールする場所です。選択した組み合わせを VM に繰り返しインストールするための非常に簡単な方法です。典型的な cloud-config では、構成ファイルを作成し、他のマシンからファイルをコピーして新しいマシンにインストールし、CoreOS の systemd に管理させたい他のプロセス (フランネル、フリートなど) を制御するユニット ファイルを作成します。そして、それは完全に再現可能です。
CoreOS に関するもう 1 つの興味深い点を次に示します。既存のユニットの依存関係と構成を変更できます。たとえば、CoreOS は docker を起動します。しかし、docker の起動シーケンスを変更したいので、既存のシステム docker 構成を補強するドロップイン構成を追加できます。これを使用して、docker が起動する前にflannelの依存関係をドロップインするため、flannel が提供するネットワークを使用するように docker を構成できます。これは必ずしも CoreOS である必要はありませんが、すべてが適合します。
CoreOSだけでなく、Ubuntuでもcloud-configを使用できると思いますが、同じことができます。したがって、Ubuntu よりも CoreOS から得られる利点は、頻繁に新しいリリースを取得し、オペレーティング システムが自動更新され、「余分な」実行が何もないことです (無駄がなく、攻撃ベクトルが減少します)。フォールアウトです）。CoreOS は docker 用に調整されており (既に実行されています)、ubuntu ではまだ実行されていません。ただし、ubuntuでdockerを実行するcloud-configファイルを作成できます...要約すると、CoreOSを理解していると思います。
CoreOS で得られるもう 1 つのことは、有料または無料の会社からの直接のサポートです。このフォーラムと CoreOS Dev/CoreOS User Google グループを通じて、CoreOS の人々から多くの質問に答えてもらいました。
あなたの艦隊の説明もかなり良いです。フリートはクラスターを管理します。クラスターは、1 つ以上の CoreOS マシンです。したがって、フリートを使用する場合は、CoreOS を使用する必要があります。これは、Ubuntu に対する CoreOS の利点の 1 つになると思います。
systemd のユニット ファイルがホストでのプロセスの実行を制御する方法と同様に、フリートのユニット ファイルはクラスターでのプロセスの実行を制御します。少し複雑な構文がありますが、フリートのユニット ファイルは systemd のユニット ファイルとほぼ同じです。それらは非常によく合います。フリートのユニット ファイルは etcd のデータベースに保存されるため、ユニット サービスをホストするマシンがダウンした場合でも、取り込まれたユニットは永続的です。ユニットの説明は etcd に存在します。
Fleet には、クラスター内のマシンの一覧表示、ユニット ファイルの一覧表示、実行中のユニットの表示などを行うコマンドもあります。基本的に、クラスター (またはすべてのマシン、または特定の種類のマシン ( ssd ドライブを使用する)、または他の何かが実行されているのと同じマシン (アフィニティ) など)。
フリートはそれを実行し続けます。マシンがなくなると、そのユニットはクラスター内の他のマシンで実行されます。
チュートリアルでは、Brandon が Fleet を使用して Kubernetes を起動しています。やり方はとても簡単です。フリート ユニット ファイルがフリート クラスター内のすべてのマシンに Kubernetes を配置するようにすることで、マシンがフリート クラスターに追加および削除されると、Kubernetes は自動的にそのマシンを使用し、Kubernetes がそれらで実行されるようにスケジュールします。私もこのように Kubernetes クラスターを実行しました。とはいえ、今はあまりやっていません。目に見えない利点があると確信していますが、私の環境では必要ないように感じます。既にクラウド構成ファイルを使用してマシンを起動しているため、そこに Kubernetes ノード サービスを直接配置するのは簡単です。実際、cloud-config では、Fleet を使用して Kubernetes を起動したい場合、Fleet ユニット ファイルを作成し、Fleet を開始し、作成したユニット ファイルを Fleet に送信する必要があります。Kubernetes ノードを開始するためのユニット ファイルを作成できたときです。しかし、私は脱線します...
フリートは、Kubernetes と同様のスケジューリング メカニズムです。ただし、Fleet は、Kubernetes がコンテナーを対象としている場合、ユニット ファイルを介して systemd のように任意の実行可能ファイルを開始できます。Kubernetes では、次の定義が可能です。
（他のものも）。
したがって、フリートはスケジューリングの別の「レイヤー」に過ぎないという主張は適切です。フリートがさまざまなことをスケジュールしていることを付け加えることができます。私の仕事では、フリート レイヤーは使用しません。コンテナーのみを使用しているため、Kubernetes に直接ジャンプするだけです。
最後に、フランネルに関する主張は正しくありません。Flannel はデータベースに etcd を使用しています。Flannel は、ホスト間でルーティングする各ホストのプライベート ネットワークを作成します。flannel ネットワークは docker に渡され、docker はそのネットワークを使用して IP アドレスを割り当てるように指示されます。そのため、flannel を使用する Docker プロセスは IP 経由で相互に通信できます。各コンテナは独自の IP アドレスを取得するため、すべてのポート マッピングをスキップできます。これらの docker プロセスは、flannel ネットワーク上のインフラおよびマシン内で通信できます。私は間違っているかもしれませんが、フリートとフランネルの間には何の関係もないと思います. また、etcd や Fleet が flannel を使用してデータをルーティングするとは思わない。フランネルが使用されているかどうかに関係なく、Etcd とフリート ルート。Docker コンテナーは、flannel 経由でトラフィックをルーティングします。
-g