xDev Asia

Kubernetes の基本的なデプロイメント単位である Pod について詳しく説明します。マルチコンテナポッド、サイドカーコンテナ GA (K8s 1.33)、Init コンテナ、デバッグ用の一時コンテナ、ポッドのライフサイクルおよびリソース管理。

🎯 レッスンの目的

このレッスンを終えると、Pod が Kubernetes の最も基本的なユニットであること、Pod がネットワーク名前空間を共有する方法、Sidecar コンテナ (GA K8s 1.33)、Init コンテナ、デバッグ用の一時コンテナの使用方法、および Pod のライフサイクルとリソースの管理方法を理解できるようになります。

1.ポッドとは何ですか?

Pod は、Kubernetes の最小のスケジューリング単位です。ポッドは、同じノード上で実行され、共通に共有される1 つ以上のコンテナ で構成されます:

ネットワーク名前空間: 同じ IP アドレス、同じポート空間 - コンテナは localhost
ストレージボリューム: ポッドにマウントされたボリュームには多くのコンテナからアクセスできます
Linux 名前空間 (構成による): PID 名前空間、IPC 名前空間

コンテナを直接デプロイしてみませんか? Kubernetes はコンテナではなくポッドを管理します。ポッドは、密接に関連するプロセスをグループ化するのに役立つ抽象化レイヤーです。

2.単純なポッドの例

___コードブロック_0___ ___コードブロック_1___

3.マルチコンテナポッド

マルチコンテナ Pod には 3 つの一般的なパターンがあります:

3.1 サイドカーパターン

セカンダリコンテナはメインコンテナ (ログフォワーダー、プロキシ、OTel コレクター) をサポートします。

3.2 アンバサダーパターン

プロキシコンテナは、メインコンテナに代わって外部と通信します。

3.3 アダプターパターン

Container は、メインコンテナからの出力を標準形式に正規化します。

4.サイドカーコンテナ GA — K8s 1.33

K8s 1.33 より前は、サイドカーコンテナが通常の初期化コンテナとして実装されていたため、ライフサイクルの問題が発生していました。メインコンテナが終了しても、サイドカーはまだ実行中であり、ジョブは完了しませんでした。

K8s ソリューション 1.33: 公式サイドカーコンテナーは initContainer で、__HTMLTAG_56___restartPolicy: Always です。 Kubernetes は次のことを行います:

メインコンテナの前にサイドカーを開始__HTMLTAG_61___
クラッシュした場合はサイドカーを再起動します (メインコンテナとは独立して)
メインコンテナの終了後にサイドカーを終了
サイドカーはジョブの完了をブロックしません

___コードブロック_2___

Sidecar コンテナのユースケース: Grafana Alloy ログエージェント、OpenTelemetry Collector、Envoy プロキシ (サービスメッシュ内)、Vault エージェントインジェクタ。

5.コンテナの初期化

Init コンテナは、メインコンテナが起動する前に run-to-completion を実行します。使用目的:

アプリを開始する前にデータベースの準備ができるまで待ちます
外部ソースから構成またはシークレットをダウンロード__HTMLTAG_81___
ファイル権限の設定、データベース移行

___コードブロック_3___

6.一時コンテナ — デバッグポッド

エフェメラルコンテナを使用すると、Pod を再起動することなく、実行中の Pod にデバッグコンテナをアタッチできます。 Pod がシェルなしで distroless イメージを使用する場合に非常に便利です。

___コードブロック_4___

7.ポッドのライフサイクル

Pod は次のフェーズを経ます:

保留中: ポッドが作成されました。スケジューラがノードを選択するのを待っているか、イメージをプルしています
実行中: ポッドがノードにバインドされており、少なくとも 1 つのコンテナが実行中
成功: すべてのコンテナが正常に終了しました (終了 0)
失敗: 少なくとも 1 つのコンテナがエラーで終了しました (0 以外で終了)
不明: ポッドのステータスを取得できません (通常はノードの問題が原因です)

ポッドの条件 (__HTMLTAG_118___kubectl によるポッドから):

PodScheduled: スケジューラが選択したノード
PodReadyToStartContainers: サンドボックスが作成され、ネットワークが構成されました
初期化: すべての初期化コンテナが正常に実行されました
ContainersReady: すべてのコンテナの準備が完了しました
_準備完了: ポッドはトラフィックを受信する準備ができています

8。リソースのリクエストと制限

___コードブロック_5___

Requests は、スケジューラが保証するリソースの量です。制限は最大上限です。制限を超えた CPU はスロットルされ (強制終了されません)、制限を超えたメモリは OOMKilled されます。

9. QoS クラス

保証: すべてのコンテナに対するリクエスト == 制限。優先度が最も高く、ノードにメモリ不足がある場合は削除されません。
_バースト可能: リクエスト <;限界。限界。ノードにメモリが不足している場合に削除される可能性があります。
BestEffort: リクエスト/制限はありません。ノードにリソースが不足している場合は、最初にエビクトします。

10.プローブ — ヘルスチェック

___コードブロック_6___

livenessProbe: ポッドが失敗した場合は再起動されます
readinessProbe: 失敗した場合 (トラフィックを受信しない場合)、ポッドはサービスエンドポイントから削除されます
startupProbe: 起動が遅いアプリに使用され、待機中に liveness/readiness プローブをオフにします

11.静的ポッド

静的ポッドは、API サーバーを経由せずに、__HTMLTAG_186___/etc/kubernetes/manifests/ の YAML ファイルから kubelet によって直接作成されます。 Kubernetes コントロールプレーンコンポーネント (kube-apiserver、etcd、スケジューラー、コントローラーマネージャー) は、マスターノード上で静的ポッドとして実行されます。

概要

Pod = ネットワークとストレージを共有するコンテナのグループ
サイドカーコンテナ (K8s 1.33 GA): initContainer (__HTMLTAG_197___restartPolicy 付き): 常に
初期コンテナ: メインコンテナの前の実行から完了まで
一時的なコンテナ: 再起動せずにポッドをデバッグ__HTMLTAG_203___
_実稼働ワークロードのリソース要求/制限を常に設定__HTMLTAG_205___
readinessProbe を使用してトラフィックを制御し、livenessProbe を使用して自動再起動

レッスン 5: ポッド