Kubernetes ポッドオーケストレーションとライフサイクルの詳細な説明

K8Sマスター基本アーキテクチャ

K8S クラスターの動作は、マスターノードとノードノード間の通信に依存します。パート 4 では、ポッドのライフサイクルをよりよく理解するために、まず K8S マスターの簡単なアーキテクチャ図を示します。以降の記事では、マスター、ノード、ポッドの関係を分析します。

マスターアーキテクチャ図:

で：

API サーバーは HTTP REST インターフェイスを提供します。これは、k8s 内のすべてのリソースを追加、削除、変更、およびチェックするための唯一のエントリ ポイントであり、クラスター制御のエントリ ポイントでもあります。

スケジューラは、リソースのスケジュール設定を担当するプロセスです。

コントローラ マネージャーは、すべてのリソース オブジェクトの自動化制御センターです。

Etcdはリソースオブジェクトのデータストレージサービスを提供します

各コンポーネントには多くの知識ポイントがあります。ここではマクロ的な印象を持つだけで十分です。今後の記事では、それらを 1 つずつ分析します。

ポッドオーケストレーションコンセプト

前回の記事の最後で、アプリケーションをk8sに移行する際の注意点について触れました。ここでもう一度強調しておきますが、仮想マシン上のアプリケーションを k8s に移行する場合は、Pod を使用してアプリケーション モジュールを構築する必要があります。この時点では、コンテナと仮想マシンの設計パターンが異なるため、アプリケーション モジュールを分割することの方が重要ですが、両者の関係をよりよく理解して比較するために、次の対応を想像することができます。

k8s-----オペレーティング システム

ポッド - 仮想マシン

コンテナプロセス

1. k8sは物理マシンのオペレーティングシステムに相当し、Podのk8s管理は仮想マシンを管理する物理マシンのオペレーティングシステムに相当する

2. Pod は仮想マシンに相当します。Pod には、仮想マシン内の多数のプロセスに対応する複数のコンテナを含めることができます。

3. コンテナはプロセスと同等です。コンテナの本質は実際にはプロセスです。

この概念により、Pod をより鮮明に理解できるかもしれません。アプリケーションの移行に戻りましょう。アプリケーションが存在すると仮定します。

Web サービス、ログ分析、MySQL データベース

3 つの主要モジュール:

ログ分析モジュールは Web サービス モジュールによって生成されたログを消費するため、Web サービスとログ分析は「非常に密接な関係」があり、同じサーバーに展開する必要があります。逆に、Web サービスと MySQL データベースは TCP-IP 経由でアクセスできるため、同じマシンに展開する必要はありません。このアプリケーションをコンテナ内で実行する場合、Web サービスはログ分析モジュールと同じ Pod にパッケージ化する必要があり、MySQL データベース サービスは別の Pod にデプロイできます。アプリケーションを k8s に移行すると、次のような構造になります。

異なるプロセスまたはタスクを同じ Pod 内に配置することは、基本的に Pod 配置の概念です。

Pod オブジェクトのプロパティとコンテナのプロパティは何ですか?

上記の分析から、コンテナが Pod に属する要素であることは簡単にわかります。YAML ファイルから見ると、コンテナは Pod の YAML ファイル全体のフィールドです。それでは、ポッドとコンテナの重要なプロパティを見てみましょう。

まず、ポッドのプロパティを見てみましょう。

1. スケジューリング、ネットワーク、ストレージ、セキュリティに関連するすべての属性は、基本的に Pod に関連しています。

スケジューリングは言うまでもありません。Pod は k8s の最小のスケジューリング単位です。ネットワークでは、同じ Pod 内のコンテナが Pod のネットワークを共有します。ストレージでは、異なるコンテナが Pod にボリュームをマウントすることで Pod のストレージを共有できます。セキュリティも Pod ディメンションに基づいて制御されます。

2. コンテナの Linux 名前空間に関連するすべての属性も Pod レベルにあります。

Pod 設計の本来の目的は、コンテナ間で名前空間を共有することです。

3. Pod 内のすべてのコンテナは、Pod レベルでホストのネームスペースを共有する必要があります。

これは理解しやすいです。Pod はホストのネームスペースを共有する必要があるため、Pod 内のコンテナは同じネームスペースを共有する必要があり、この設定は Pod レベルで行う必要があります。

コンテナの 2 つの重要なプロパティを見てみましょう。

1. ImagePullPolicy: この属性は、イメージのプル ポリシーを定義します。デフォルト値は always で、これは Pod が作成されるたびにイメージがプルされることを意味します。他に never と ifnotpresent という 2 つの値があります。これら 2 つの値は理解しやすいです。1 つはイメージをプルしないこと、もう 1 つはイメージが存在しない場合にのみイメージをプルすることです。ここで注意すべき点は、バージョン番号が最新に設定されている場合、ImagePullPolicy は常にデフォルト値に設定されることです。

2. ライフサイクル: 名前が示すように、コンテナのライフサイクル中に特定のアクションを実行します。コンテナの起動後または終了前に実行される特定の操作である postStart と preStop という 2 つの共通パラメータがあります。

ポッドのライフサイクル

Pod のライフサイクルは、主に Pod API のステータス部分に反映されます。Pod のライフサイクルには、開始から終了までの次のプロセスが含まれます。

1. 保留中。Pod の yaml ファイルが k8s に引き渡され、etcd に保存されたことを示します (etcd は k8s のメタ情報リポジトリです)。しかし、スケジュールの都合がつかなかったなどの理由で作成されませんでした。

2. 実行中。この言葉は誤解を招きやすいです。これは、Pod が正常にスケジュールされ、特定のノード サーバーにバインドされていることを意味します。Pod 内のすべてのコンテナーが正常に実行されているわけではありませんが、少なくとも 1 つは実行されています。

3. 成功: このステータスは、すべてのコンテナが起動され、終了したことを意味します。

4. 失敗: これは簡単に理解できます。これは、ポッド内のコンテナの少なくとも 1 つがゼロ以外のステータスで終了した、つまり異常終了したことを意味します。

5. 分からない。これは異常な状態であり、現在の Pod ステータスを kube-apiserver に正常に報告できないことを示しています。これは、マスター ノードとスレーブ ノード間の通信に問題がある可能性があります。

以下は実行状態の Pod です。

[root@VM-16-13-centos ~]# kubectl ポッドを取得します
名前 準備完了 ステータス 再起動 年齢
mysql-pd7jr 1/1 実行中 0 118d
myweb-60r22 1/1 実行中 0 80d

[root@VM-16-13-centos ~]#
 [root@VM-16-13-centos ~]# kubectl get pod mysql-pd7jr -o yaml
APIバージョン: v1
種類: ポッド
メタデータ:
  ...
仕様:
  ...
状態：
  ...
  ホストIP: 127.0.0.1
  フェーズ: 実行中
  ポッドIP: 172.17.0.2
  開始時間: 2020-11-20T09:01:39Z

以上がkubernetes podのオーケストレーションとライフサイクルの詳細な説明です。kubernetes podのオーケストレーションとライフサイクルの詳細については、123WORDPRESS.COMの他の関連記事に注目してください。