Kubernetes デプロイメントのビジュアルマップ

Kubernetes でコンテナを使用する場合、多くの場合、アプリケーションをポッドにグループ化します。コンテナまたはポッドを本番環境にリリースすることをデプロイメントと呼びます。 Kubernetes を毎日または毎週使用している場合は、おそらくこれを何百回も実行したことがあるでしょうが、ポッドまたはデプロイメントを作成すると実際に何が起こるのか疑問に思ったことはありませんか?

一連の出来事を大まかに理解しておくと役に立つと思います。もちろん、理解する必要はありません。理由がわからなくても、それはまだ機能しています。起こった細かいことすべてを列挙するつもりはありませんが、重要なことはすべて網羅することを目指します。

これは、Kubernetes のさまざまなコンポーネントがどのように相互作用するかを示す視覚的なマップです。

ポッドチェーン上記の図では、etcd が含まれていないことに気付いたかもしれません。 API サーバーは、etcd と直接通信できる唯一のコンポーネントであり、etcd に変更を加えることができる唯一のコンポーネントです。したがって、この図では、etcd は (隠し) API サーバーの背後に存在すると考えることができます。

また、ここでは 2 つのメインコントローラー (デプロイメントコントローラーとレプリカセットコントローラー) についてのみ説明しました。他のコントローラーも同様に動作します。

次の手順では、kubectl create コマンドを実行したときに何が起こるかについて説明します。

ステップ1

kubectl create コマンドを使用すると、デプロイメントマニフェストを含む API サーバーに HTTP POST リクエストが送信されます。 API サーバーはそれを etcd データストアに保存し、kubectl に応答を返します。

ステップ2と3

API サーバーには監視メカニズムがあり、それを監視しているすべてのクライアントに通知されます。クライアントは、通知をストリーミングする API サーバーへの HTTP 接続を開いて変更を監視します。これらのクライアントの 1 つはデプロイメントコントローラーです。デプロイメントコントローラーはデプロイメントオブジェクトを検出し、デプロイメントの現在の仕様でレプリカセットを作成します。リソースは API サーバーに送り返され、etcd データストアに保存されます。

ステップ4と5

前の手順と同様に、API サーバーの変更についてはすべてのオブザーバーに通知されます。今回は、レプリカセットコントローラーが変更を取得します。コントローラーは、必要なレプリカ数とオブジェクト仕様で定義されたポッドセレクターを理解し、ポッドリソースを作成し、この情報を API サーバーに送り返して etcd データストアに保存します。

ステップ6と7

Kubernetes にはポッドを実行するために必要なすべての情報が揃いましたが、ポッドはどのノードで実行すればよいでしょうか?スケジューラは、まだノードに割り当てられていないポッドを監視し、すべてのノードのフィルタリングとソートを開始して、ポッドを実行するのに最適なノードを選択します。ノードが選択されると、この情報がポッド仕様に追加されます。そして、API サーバーに送り返され、etcd データストアに保存されます。

ステップ8、9、10

これまでのすべての手順は、コントロールプレーン自体で実行されました。ワーカーノードはまだ作業を行っていません。ただし、ポッドの作成はコントロールプレーンでは処理されません。代わりに、すべてのノードで実行されている kubelet サービスは、API サーバーのポッド仕様を監視して、ポッドを作成する必要があるかどうかを判断します。スケジューラによって選択されたノード上で実行されている kubelet サービスは、ポッド仕様を取得し、ワーカーノード上のコンテナランタイムにコンテナを作成するように指示します。この時点で、コンテナイメージがダウンロードされ (まだ存在しない場合)、コンテナが実際に実行を開始します。