文書ディレクトリ

深入浅出Kubernetes:初識Pod(上)

コンセプト

二Podのいくつかの重要なフィールドの意味と使い方

三関連資源

深入浅出Kubernetes:初識Pod(上)

一つの概念

Podの中国語の意味は:莢、字面の意味から理解しにくくなくて、それは1つの莢のようで、中には多くの豆が含まれて、これらの豆はcontainerに類比することができます.実際、Podは論理概念であり、Kubernetesが本当に処理しているのか、ホストオペレーティングシステム上のLinuxコンテナのNamespaceとCgroupsなのか、いわゆるPodの境界や隔離環境は存在しない.Podは、いくつかのリソースを共有するコンテナのセットであり、Pod内のすべてのコンテナは、同じNetwork Namespaceを共有し、同じVolumeを共有することを宣言することができます.Kubernetesプロジェクトでは、Podの実装には、Infraコンテナ(Infraコンテナk 8 s.gcr.io/pause)という中間コンテナが必要です.このコンテナは、ミラーリング時にアセンブリ言語で記述され、永遠に「一時停止」状態にあるコンテナです.Podでは、Infraコンテナは常に最初に作成されたコンテナであり、他のユーザー定義のコンテナでは、join Network NamespaceによってInfraコンテナに関連付けられ、同じPod内のすべてのユーザーコンテナについて、それらの出入り流量はInfraコンテナによって完了します.同じPod内のすべてのユーザコンテナにとって,それらの出入り流量はInfraコンテナによって達成されると考えられる.スケジューリング、ネットワーク、ストレージ、およびセキュリティ関連のプロパティは、基本的にPodレベルです.

二Podのいくつかの重要なフィールドの意味と使い方

NodeSelector:Podをノードにバインドするためのフィールドです.次のように使用します.

apiVersion: v1
kind: Pod
metadata:
  name: gysl-nodeselect
spec:
  nodeSelector:
    kubernetes.io/hostname: 172.31.2.12
  containers:
  - name: gysl-nginx
    image: nginx

これはこのPodがkubernetesを携帯するしかないことを意味します.io/hostnameラベルのノードで実行されました.そうしないと、スケジュールに失敗します.
NodeName:Podのこのフィールドが割り当てられると、KubernetesプロジェクトはこのPodがスケジューリングされていると考えられ、スケジューリングの結果、割り当てられたノード名になります.したがって、このフィールドは一般的にスケジューラによって設定されますが、ユーザーはスケジューラを「騙す」ように設定することもできます.もちろん、この方法はテストやデバッグ時に使用されます.

apiVersion: v1
kind: Pod
metadata:
  name: gysl-nodename
spec:
  nodeName: 172.31.2.12
  containers:
  - name: gysl-nginx
    image: nginx

HostAliases:Podのhostsファイル(例えば/etc/hosts)の内容を定義します.

apiVersion: v1
kind: Pod
metadata:
  name: gysl-hostaliases
spec:
  hostAliases:
  - ip: "10.0.0.20"
    hostnames:
    - "test.gysl"
    - "app.gysl"
  containers:
  - name: gysl-nginx
    image: nginx

一番下の2行の記録は、HostAliasesフィールドでPodに設定したものです.Kubernetesプロジェクトではhostsファイルの内容を設定するには、必ずこの方法を使用します.そうでなければ、hostsファイルを直接修正すると、Podが削除されて再構築された後、kubeletは修正された内容を自動的に上書きします.
コンテナのLinux Namespaceに関連する属性は、Podレベルに違いありません.この理由も分かりやすい:Podの設計は、その中の容器ができるだけ多くLinux Namespaceを共有し、必要な隔離と制限能力だけを維持することである.
次の例を続けます.

apiVersion: v1
kind: Pod
metadata:
  name: gysl-shareprocessnamespace
spec:
  shareProcessNamespace: true
  containers:
  - name: nginx
    image: nginx
  - name: busybox
    image: busybox
    tty: true
    stdin: true

次のコマンドを使用して、指定したcontainerにアクセスします.

kubectl attach -it gysl-shareprocessnamespace -c busybox

プロセスの共有を確認します.

/ # ps aux
PID   USER     TIME  COMMAND
    1 root      0:00 /pause
    6 root      0:00 nginx: master process nginx -g daemon off;
   11 101       0:00 nginx: worker process
   12 root      0:00 sh
   32 root      0:00 ps aux

このコンテナでは,それ自体のps aux命令だけでなく,nginxコンテナのプロセス,およびInfraコンテナの/pauseプロセスも見ることができる.これは、Pod内の各コンテナのプロセス全体が、すべてのコンテナに対して表示されることを意味します.同じPID Namespaceを共有しています.PodのコンテナがホストホストのNamespaceを共有するのは、Podレベルの定義に違いありません.
もう1つの例を見てみましょう.

apiVersion: v1
kind: Pod
metadata:
  name: gysl-share-namespace
spec:
  hostPID: true
  hostIPC: true
  hostNetwork: true
  nodeName: 172.31.2.11
  shareProcessNamespace: true
  containers:
  - name: nginx-gysl
    image: nginx
    imagePullPolicy: IfNotPresent
  - name: busybox-gysl
    image: busybox
    stdin: true
    tty: true
    imagePullPolicy: Always
    lifecycle:
      postStart:
        exec:
          command: ['/bin/sh','-c','echo "This is a test of gysl. ">/gysl.txt']
      preStop:
        exec:
          command: ['/bin/sh','-c','echo "This is a demo of gysl."']

上記の例では、共有ホストのNetwork、IPC、PID Namespaceが定義されています.これは、このPod内のすべてのコンテナが、直接ホストのネットワークを使用し、ホストと直接IPC通信を行い、ホストで実行されているすべてのプロセスを見ることを意味します.
このほか、ImagePullPolicyとLifecycleも注目すべき2つのフィールドです.
ImagePullPolicyフィールドは、ミラー・プルのポリシーを定義します.コンテナミラーがContainer定義の一部であるため、Containerレベルのプロパティです.ImagePullPolicyの値のデフォルトはAlwaysです.つまり、Podを作成するたびにミラーを再プルします.値がNeverまたはIfNotPresentとして定義されている場合、Podはこのミラーをアクティブに引き出しないか、ホスト上にこのミラーが存在しない場合にのみ引き出します.
Lifecycleフィールド.Container Lifecycle Hooksを定義します.文字通り、Container Lifecycle Hooksの役割は、容器の状態が変化したときに一連の「フック」をトリガーすることです.このフィールドではpostStartとpresStopの2つのパラメータを見ました.postStartパラメータは、コンテナが起動すると、すぐに指定した操作を実行します.明確にする必要があるのは、DockerコンテナENTRYPOINTが実行した後であるが、順序は厳密に保証されていないpostStartが定義した操作である.つまり、postStart起動時にENTRYPOINTがまだ終わっていない可能性があります.postStartがタイムアウトまたはエラーを実行した場合、KubernetesはPodのEventsにコンテナの起動に失敗したエラーメッセージを報告し、Podも失敗した状態になります.presStopが発生するタイミングは、容器が殺される前(例えばSIGKILL信号が受信された)である.一方、presStop操作の実行は、同期されていることを明確にする必要があります.したがって、このHook定義操作が完了するまで、postStartとは異なり、現在のコンテナ殺しプロセスがブロックされます.

三関連資源

本文の中の関連する資源は本人GitHubから取得することができて、リンクは以下の通りです:
KubernetesのPod