Kubernetes 学習ノートの Pod 記事 (5)

ポッドとは何ですか?

ポッドを知り、理解する

Pod は、kubernetes で作成および管理される展開可能な最小のコンピューティングユニットです。
Pod はエンドウ豆のさやのようなもので、エンドウ豆のさやに含まれる Bean はコンテナと呼ばれることが多く、コンテナのグループ (1 つまたは複数) である場合があります。これらのコンテナは、ストレージ、ネットワーク、CPU、メモリなどのリソースを共有し、Pod Pod 内のコンテナーは、仮想マシンで実行されるアプリケーションとして理解できます。これらのコンテナは比較的緊密に結合されています。これらのアプリケーションは、同じ物理ホストまたは仮想マシン上にある場合があります。
通常、Kubernetes はコンテナーを直接管理するのではなく、Pod を介して管理します。

Pod のコンテキストは、複数の Linux 名前空間の結合として理解できます。

PID 名前空間 (同じ Pod 内のアプリケーションは他のプロセスを参照できます)
ネットワーク名前空間 (同じ Pod 内のアプリケーションは、同じ IP アドレスとポートへのアクセス許可を持っています)
IPC 名前空間 (同じ Pod 内のアプリケーションは VPC または POSIX を介して通信できます)
UTS 名前空間 (同じ Pod 内のアプリケーションはホスト名を共有します)

ポッドには通常、

(1 つ以上の) コンテナーのセット (通常は 1 つ) は、結合が比較的強く、共有リソースが必要でない限り、Pod に配置されます。
共有ストレージリソース (データボリューム vloume など) の場合、Pod 内のコンテナーはストレージスペースを共有できます。
各 Pod には独立した IP アドレスが割り当てられ、Pod 内のコンテナーは同じ Pod IP とネットワークポートを共有し、Pod 内のコンテナーは localhost を使用して相互に通信できます。

Pod 内のコンテナーは、次の 2 つのタイプに分けることができます。

作業コンテナ: アプリケーションコンテナも
初期化コンテナ: 一部の初期化操作を完了する責任があります. 初期化コンテナは作業コンテナの前に実行されるため, 初期化コンテナが正常に実行されるまで作業コンテナは開始されません.

Pod の管理と使用

ポッドを使用する

実際に kubernetes を使用する場合、Pod のライフサイクルが最も短く、使用後に破棄されるため、通常、Pod を直接作成することはありません。
Pod はそれ自体を修復しません。Pod が配置されている Node ノードのリソースが不足している場合、または Pod がメンテナンス状態にある場合、Pod も削除されます。Kubernetes は、上位レベルのコントローラー (コントローラー) 抽象化レイヤーを使用して Pod インスタンスを管理します. Pod は直接使用できますが、Kubernetes は通常コントローラーを使用して Pod を管理します.

kubernetes の Pod コントローラー (コントローラー)

Pod コントローラーはワークロード (workload) とも呼ばれ、複数の Pod を作成および管理し、クラスターレベルでコピー管理、ローリングアップグレード、および自己修復機能を提供できます。たとえば、ノードに障害が発生した場合、コントローラーはノード上のポッドを他の正常なノードに自動的にスケジュールします。
ポッド共通コントローラー

展開: ステートレス Pod アプリケーションの管理に使用され、現在最も広く使用されている最適なコントローラーです。ローリング更新とロールバック機能をサポートし、宣言的な構成も提供します。ReplicaSet と Deployment の 2 つのリソースオブジェクトは、以前の RC の役割を徐々に置き換えます。
StatefulSet: ステートフル Pod アプリケーションを管理します。
DaemonSet: デーモンクラスの管理に使用される Pod アプリケーション。
ジョブ : 1 回限りのタスクを実行する Pod アプリケーションを管理するために使用されます. 作成された Pod は、再起動または再構築せずにタスクを実行した直後に終了します;
Cronjob: 定期的なタスクを管理するために使用され、Pod アプリケーションを継続的に実行する必要はありません。
ReplicaSet: レプリカコントローラ。Pod の数を期待値セットに維持するために使用されます。

ポッドを作成する

リソースリストから Pod を作成する

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment # 工作负载名称
  labels:
    app: nginx 
spec:
  replicas: 3 # 期望pod数量
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx # 容器名称
        image: nginx:1.14.2 # 容器镜像
        ports:
        - containerPort: 80 # 容器端口

kubectl apply -f nginx-deployment.yaml

コマンドラインから Pod を作成する

kubectl run nginx-deploy --image=nginx:1.14.2 --port=80 --dry-run=true

Pod ステータス
Pod 共通ステータスには、通常、次の種類があります。

Pending: The Pod has been created, but the Scheduling has not been completed. 通常、この状態は、クラスター内に十分な作業ノードがない場合に表示されます。
実行中: Pod が作成され、特定のノードに割り当てられました。Pod 内のすべてのコンテナーが作成されました。実行中または開始中のコンテナーは 1 つだけです。
成功: Pod 内のすべてのコンテナーが正常に終了され、再起動できません。
失敗: Pod 内のすべてのコンテナーが終了され、少なくとも 1 つのコンテナーが失敗または終了しました。
Unkonwn: apiserver は Pod の現在のステータスを取得できません。これは通常、マスターと Pod が配置されているノードホスト間の接続が失われたことが原因です。
ImagePullBackOff: イメージのプルが失敗します。これは通常、イメージ名の構成とイメージプルキーの構成が正しくないことが原因です。
CrashLoopBackOff: Pod 内のコンテナーを開始できませんでした。これは、ヘルスチェックの失敗とコンテナーの不適切な構成が原因である可能性があります。
終了中: Pod は削除されています。
完了: コンテナ内のメインプロセスが終了しました. 通常、このステータスは、ジョブアプリケーションがタスクの実行を終了した後に表示されます。
ContainerCreating: Pod が作成されています。
PodInitializing: Pod が初期化されています。

コンテナの再起動戦略

Always: コンテナーに障害が発生すると、kubelet はコンテナーを自動的に再起動します。
OnFailure: コンテナに障害が発生すると、kubelet はコンテナを自動的に再起動します。
なし: コンテナーの実行状態に関係なく、kubelet はコンテナーを再起動しません。

コンテナイメージのプル戦略
イメージのプル戦略を指定しない場合、デフォルトの戦略は Always
15. Always (常にイメージをプル);
16. IfNotPresent (ローカルイメージが優先され、ローカルイメージがある場合、イメージは
17. Never (ローカルミラーリングのみを使用し、ローカルがなくてもプルしない)
ヘルスチェックヘルスチェック (ヘルスチェック) は、
アプリケーションインスタンスが正常に動作しているかどうかを検出するために使用され、ビジネスの可用性を確保するための手段です。 . デフォルトでは、kubelet はコンテナーの実行状態をヘルスベースとして使用し、コンテナー内のアプリケーションプログラムの状態を監視することはできません. プログラムがフリーズすると、サービスの提供に失敗したり、トラフィックの損失につながります. kubernetes のヘルスチェックメカニズムを導入することで、コンテナの健全な存続を保証できます。

ヘルスチェックには主に 3 つのタイプがあります。

startupProbe (起動検出): コンテナー内のアプリケーションが起動されているかどうかを示します。起動プローブが提供されている場合、他のすべてのプローブは成功するまで無効になります。start プローブが失敗した場合、kubelet は再起動ポリシーの対象となるコンテナーを強制終了します。コンテナーが開始プローブを提供しない場合、デフォルトの状態はです。成功;
readinessProbe (準備プローブ): コンテナーが要求に応答する準備ができているかどうかを示します。準備プローブが失敗した場合、エンドポイントコントローラーは、ポッドに一致するすべてのサービスのエンドポイントからポッドの IP アドレスを削除します。デフォルトの初期遅延の前の準備完了状態はです。コンテナが準備プローブを提供しない場合、デフォルトの状態はです。失敗成功;
livenessProbe (インベントリ検出): コンテナーが実行されているかどうかを示します。liveness 検出が失敗した場合、Kubelet は再起動ポリシーによってバインドされているコンテナーを強制終了します。コンテナが liveness プローブを提供しない場合、デフォルトの状態はです。成功

ヘルスチェックメカニズムプローブ
を使用してコンテナーをチェックする方法は 4 つあります。各プローブは、次の 4 つのメカニズムのいずれかを正確に定義する必要があります。

exec は、コンテナー内で指定されたコマンドを実行します。診断ステータスコード 0 で終了した場合、コマンドは成功したと見なされます。
grpc は、gRPC を使用してリモートプロシージャコールを実行します。ターゲットは gRPC ヘルスチェックを実装する必要があります。応答が成功した場合、診断は成功したと見なされます。gRPC プローブはアルファ版の機能であり、次の場合にのみ使用できます。機能エントリが有効になっている。statusSERVINGGRPCContainerProbe
httpGet は、パス上のポートとアドレスを指定して、Pod の IP に対して HTTP リクエストを実行します。応答のステータスコードが 200 以上 400 未満の場合、診断は成功したと見なされます。
TcpSocket は、
指定されたポートで Pod の IP アドレスに対して TCP チェックを実行します。次の条件が満たされている場合、診断は成功したと見なされます。ポートが開いています。リモートシステム (コンテナ) が接続を開いた直後に接続を閉じると、正常と見なされます。調査結果

健康診断の結果は以下の3種類に分けられます

成功: コンテナがヘルスチェックに合格したことを示します。
失敗: コンテナがヘルスチェックに合格しなかったことを示し、ポッドはこの時点で再デプロイまたは削除されます。
不明: 現在の実行メカニズムが完了していないことを意味し、現時点では操作は行われず、次のメカニズムのチェックを待機します。

一般的な Pod 分析コマンド:

kubectl describe -n "namespace_name" pod "pod_name" # ポッドの詳細を照会します。
kubectl logs -n "namespace_name" pod "pod_name" # pod ログの詳細を照会します。
kubectl get pods -A -owide |grep “pod_name” # ポッドの実行ステータスと詳細情報のクエリ