Kubernetesノート(六)−静的Pod
4368 ワード
静的Pod
前回の授業ではYAMLファイルの使用について説明し、手動で簡単なPodを作成しました.この授業から私たちはPodを深く勉強しました.Kubernetesクラスタでは、私たちがよく使う普通のPodのほかに、Static Podという特殊なPodがあります.つまり、私たちが言っている静的Podです.静的Podにはどんな特殊な場所がありますか.
静的Podは、masterノード上のapiserverではなく、特定のノード上のkubeletプロセスによって直接管理されます.私たちがよく使うコントローラDeploymentやDaemonSetと関連付けることはできません.それはkubeletプロセス自身が監視し、podが崩壊したときにpodを再起動し、kubeletも健康診断を行うことができません.静的podは常にkubeletにバインドされ、常に同じノードで実行されます.kubeletは、静的podごとにKubernetesのapiserver上にミラーPod(Mirror Pod)を自動的に作成するので、apiserverでpodをクエリーできますが、apiserverでは制御できません(削除できません).
静的Podの作成には、プロファイルとHTTPの2つの方法があります.
プロファイル
プロファイルとは、特定のディレクトリの下に置かれた標準のJSONまたはYAML形式のpod定義ファイルです.kubelet--pod-manifest-path=でkubeletプロセスを開始し、kubeletは定期的にこのディレクトリをスキャンし、このディレクトリの下に現れるか消えたYAML/JSONファイルに基づいて静的podを作成または削除します.
例えば、node 01というノードで静的podでnginxのサービスを開始します.Node 01ノードにログインし、次のコマンドでkubelet対応の起動プロファイルを見つけることができます.
プロファイルのパスは次のとおりです.
このファイルを開くと、次の環境変数構成が表示されます.
したがって、kubeadm方式でインストールされたクラスタ環境では、対応するkubeletが静的Podファイルのパスを構成しています.それは/etc/kubernetes/manifestsです.そのため、このディレクトリの下に標準PodのJSONまたはYAMLファイルを作成するだけです.
クbelet起動パラメータに上記の-pod-manifest-pathパラメータが構成されていない場合は、このパラメータを追加してクbeletを再起動すればいいです.
HTTPによる静的Podsの作成
kubeletは、-manifest-url=パラメータで指定されたアドレスから定期的にファイルをダウンロードし、JSON/YAML形式のpod定義に翻訳します.その後の動作は–pod-manifest-path=と同様で、kubeletは時々ファイルを再ダウンロードし、ファイルが変化すると対応して静的podを終了または起動します.
静的podsの動作挙動
kubeletが起動すると、–pod-manifest-path=or--manifest-url=パラメータで指定されたディレクトリで定義されたすべてのpodが自動的に作成されます.たとえば、私たちの例のstatic-webなどです.(nginxミラーを引くのに時間がかかるかもしれませんが、辛抱強く待っています...)
ここで、kubectlツールを使用すると、新しいミラーPodが作成されていることがわかります.
静的podのラベルはミラーPodに渡され、フィルタまたはフィルタリングに使用できます.APIサーバを介して静的podを削除することはできません(たとえば、kubectlコマンドを介して)、kebeletは削除しません.
手動でコンテナを終了しようとすると、kubeletはすぐに自動的にコンテナを再起動することがわかります.
静的podsの動的増加と削除
実行中のkubeletサイクルスキャン構成のディレクトリ(この例では/etc/kubernetes/manifests)のファイルの変化は、このディレクトリにファイルが表示または消失した場合にpodsを作成または削除します.
実は私たちはkubeadmでインストールしたクラスタを使っています.masterノードの上のいくつかの重要なコンポーネントは静的Podで実行されています.masterノードにログインして/etc/kubernetes/manifestsディレクトリを表示します.
分かったでしょう.この方法はクラスタのいくつかのコンポーネントをコンテナ化する可能性を提供しています.これらのPodはapiserverの制御を受けないからです.そうしないと、私たちのところでkube-apiserverはどのように自分で自分を制御しますか.もしうっかりこのPodを削除したら?だからkubelet自身で制御するしかありません.これが私たちが言っている静的Podです.
前回の授業ではYAMLファイルの使用について説明し、手動で簡単なPodを作成しました.この授業から私たちはPodを深く勉強しました.Kubernetesクラスタでは、私たちがよく使う普通のPodのほかに、Static Podという特殊なPodがあります.つまり、私たちが言っている静的Podです.静的Podにはどんな特殊な場所がありますか.
静的Podは、masterノード上のapiserverではなく、特定のノード上のkubeletプロセスによって直接管理されます.私たちがよく使うコントローラDeploymentやDaemonSetと関連付けることはできません.それはkubeletプロセス自身が監視し、podが崩壊したときにpodを再起動し、kubeletも健康診断を行うことができません.静的podは常にkubeletにバインドされ、常に同じノードで実行されます.kubeletは、静的podごとにKubernetesのapiserver上にミラーPod(Mirror Pod)を自動的に作成するので、apiserverでpodをクエリーできますが、apiserverでは制御できません(削除できません).
静的Podの作成には、プロファイルとHTTPの2つの方法があります.
プロファイル
プロファイルとは、特定のディレクトリの下に置かれた標準のJSONまたはYAML形式のpod定義ファイルです.kubelet--pod-manifest-path=でkubeletプロセスを開始し、kubeletは定期的にこのディレクトリをスキャンし、このディレクトリの下に現れるか消えたYAML/JSONファイルに基づいて静的podを作成または削除します.
例えば、node 01というノードで静的podでnginxのサービスを開始します.Node 01ノードにログインし、次のコマンドでkubelet対応の起動プロファイルを見つけることができます.
$ systemctl status kubelet
プロファイルのパスは次のとおりです.
$ /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
このファイルを開くと、次の環境変数構成が表示されます.
Environment="KUBELET_SYSTEM_PODS_ARGS=--pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true"
したがって、kubeadm方式でインストールされたクラスタ環境では、対応するkubeletが静的Podファイルのパスを構成しています.それは/etc/kubernetes/manifestsです.そのため、このディレクトリの下に標準PodのJSONまたはYAMLファイルを作成するだけです.
クbelet起動パラメータに上記の-pod-manifest-pathパラメータが構成されていない場合は、このパラメータを追加してクbeletを再起動すればいいです.
[root@ node01 ~] $ cat </etc/kubernetes/manifest/static-web.yaml
apiVersion: v1
kind: Pod
metadata:
name: static-web
labels:
app: static
spec:
containers:
- name: web
image: nginx
ports:
- name: web
containerPort: 80
EOF
HTTPによる静的Podsの作成
kubeletは、-manifest-url=パラメータで指定されたアドレスから定期的にファイルをダウンロードし、JSON/YAML形式のpod定義に翻訳します.その後の動作は–pod-manifest-path=と同様で、kubeletは時々ファイルを再ダウンロードし、ファイルが変化すると対応して静的podを終了または起動します.
静的podsの動作挙動
kubeletが起動すると、–pod-manifest-path=or--manifest-url=パラメータで指定されたディレクトリで定義されたすべてのpodが自動的に作成されます.たとえば、私たちの例のstatic-webなどです.(nginxミラーを引くのに時間がかかるかもしれませんが、辛抱強く待っています...)
[root@node01 ~] $ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c
ここで、kubectlツールを使用すると、新しいミラーPodが作成されていることがわかります.
[root@node01 ~] $ kubectl get pods
NAME READY STATUS RESTARTS AGE
static-web-my-node01 1/1 Running 0 2m
静的podのラベルはミラーPodに渡され、フィルタまたはフィルタリングに使用できます.APIサーバを介して静的podを削除することはできません(たとえば、kubectlコマンドを介して)、kebeletは削除しません.
[root@node01 ~] $ kubectl delete pod static-web-my-node01
[root@node01 ~] $ kubectl get pods
NAME READY STATUS RESTARTS AGE
static-web-my-node01 1/1 Running 0 12s
手動でコンテナを終了しようとすると、kubeletはすぐに自動的にコンテナを再起動することがわかります.
[root@node01 ~] $ docker ps
CONTAINER ID IMAGE COMMAND CREATED ...
5b920cbaf8b1 nginx:latest "nginx -g 'daemon of 2 seconds ago ...
静的podsの動的増加と削除
実行中のkubeletサイクルスキャン構成のディレクトリ(この例では/etc/kubernetes/manifests)のファイルの変化は、このディレクトリにファイルが表示または消失した場合にpodsを作成または削除します.
[root@node01 ~] $ mv /etc/kubernetes/manifests/static-web.yaml /tmp
[root@node01 ~] $ sleep 20
[root@node01 ~] $ docker ps
// no nginx container is running
[root@node01 ~] $ mv /tmp/static-web.yaml /etc/kubernetes/manifests
[root@node01 ~] $ sleep 20
[root@node01 ~] $ docker ps
CONTAINER ID IMAGE COMMAND CREATED ...
e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago
実は私たちはkubeadmでインストールしたクラスタを使っています.masterノードの上のいくつかの重要なコンポーネントは静的Podで実行されています.masterノードにログインして/etc/kubernetes/manifestsディレクトリを表示します.
[root@master ~]# ls /etc/kubernetes/manifests/
etcd.yaml kube-apiserver.yaml kube-controller-manager.yaml kube-scheduler.yaml
分かったでしょう.この方法はクラスタのいくつかのコンポーネントをコンテナ化する可能性を提供しています.これらのPodはapiserverの制御を受けないからです.そうしないと、私たちのところでkube-apiserverはどのように自分で自分を制御しますか.もしうっかりこのPodを削除したら?だからkubelet自身で制御するしかありません.これが私たちが言っている静的Podです.