Después de instalar el clúster de Kubernetes a través de kubeadm, cuando el clúster de Kubernetes comience a volar, primero mire lo que hay en el clúster. Los clústeres de Kubernetes se pueden implementar en tres modos: 1) Modo de formación independiente. Cada componente del nodo maestro y del nodo se ejecuta directamente como un demonio. La implementación de programas binarios cae en este tipo. 2) Modo Pod estático. Cada componente del plano de control se ejecuta en el host del nodo maestro en forma de un objeto Pod estático. El kubelet y el contenedor en el host del nodo se ejecutan como procesos a nivel de demonio del sistema. kube-proxy está alojado en el Controlador DaemonSet en el clúster. 3) Modo autohospedado, similar al Tipo 2, pero cada componente del plano de control se ejecuta como objetos Pod (no estáticos), y estos objetos Pod también se alojan y ejecutan en el clúster, y también están controlados por un tipo DaemonSet. controlador. Dado que el clúster experimental se instaló a través de kubeadm y la opción selfHosting no estaba activada, pertenecía al segundo modo de implementación anterior.
Primero, enumere todos los pods y el resultado será el siguiente.
zhangzk@zzk-1:~$ kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE
kube-flannel kube-flannel-ds-5v98d 1/1 Running 1 (<invalid> ago) 28h 192.168.19.131 zzk-3
kube-flannel kube-flannel-ds-7p4mt 1/1 Running 1 (<invalid> ago) 28h 192.168.19.133 zzk-5
kube-flannel kube-flannel-ds-d2qzw 1/1 Running 1 (<invalid> ago) 28h 192.168.19.130 zzk-2
kube-flannel kube-flannel-ds-j42lk 1/1 Running 1 (<invalid> ago) 28h 192.168.19.132 zzk-4
kube-flannel kube-flannel-ds-q6fkt 1/1 Running 1 (11h ago) 28h 192.168.19.134 test
kube-flannel kube-flannel-ds-x464d 1/1 Running 2 (<invalid> ago) 28h 192.168.19.128 zzk-1
kube-system coredns-7bdc4cb885-2qgtj 1/1 Running 1 (11h ago) 41h 10.244.0.5 test
kube-system coredns-7bdc4cb885-wj5cr 1/1 Running 1 (11h ago) 41h 10.244.0.4 test
kube-system etcd-test 1/1 Running 1 (11h ago) 41h 192.168.19.134 test
kube-system kube-apiserver-test 1/1 Running 7 (4h59m ago) 41h 192.168.19.134 test
kube-system kube-controller-manager-test 1/1 Running 8 (139m ago) 41h 192.168.19.134 test
kube-system kube-proxy-8hkml 1/1 Running 1 (11h ago) 41h 192.168.19.134 test
kube-system kube-proxy-kzspb 1/1 Running 1 (<invalid> ago) 28h 192.168.19.132 zzk-4
kube-system kube-proxy-l9tz7 1/1 Running 1 (<invalid> ago) 28h 192.168.19.133 zzk-5
kube-system kube-proxy-qs8bt 1/1 Running 1 (<invalid> ago) 28h 192.168.19.131 zzk-3
kube-system kube-proxy-xgvz8 1/1 Running 2 (<invalid> ago) 28h 192.168.19.128 zzk-1
kube-system kube-proxy-xxbdn 1/1 Running 1 (<invalid> ago) 28h 192.168.19.130 zzk-2
kube-system kube-scheduler-test 1/1 Running 8 (139m ago) 41h 192.168.19.134 test 1. espacio de nombres kube-franela
El pod cuyo espacio de nombres es kube-flannel es fácil de entender: dado que el complemento de red usa franela, cada nodo debe tener un proceso de franela para implementar la red superpuesta.
Los pods en kube-flannel son administrados por DaemonSet y se pueden ver de la siguiente manera.
zhangzk@zzk-1:~$ kubectl get ds -n kube-flannel -o wide
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE CONTAINERS IMAGES SELECTOR
kube-flannel-ds 6 6 6 6 6 <none> 29h kube-flannel docker.io/flannel/flannel:v0.22.0 app=flannel,k8s-app=flannel2. espacio de nombres del sistema kube
Hay muchos pods en el espacio de nombres kube-system, entre los cuales los pods de kube-proxy-XXX son fáciles de entender. Cada nodo debe tener kube-proxy, que también es administrado por DaemonSet.
zhangzk@zzk-1:~$ kubectl get ds -n kube-system -o wide
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE CONTAINERS IMAGES SELECTOR
kube-proxy 6 6 6 6 6 kubernetes.io/os=linux 42h kube-proxy registry.aliyuncs.com/google_containers/kube-proxy:v1.27.0 k8s-app=kube-proxyHay 4 pods en el espacio de nombres kube-system cuyos nombres terminan con el sufijo test. La lista de nombres es la siguiente:
prueba-etcd
prueba-kube-apiserver
prueba-administrador-controlador-kube
prueba-programador-kube
Estos son pods del plano de control, que son pods estáticos y solo existen en el nodo maestro. A diferencia de DaemonSet, ReplicaSet, etc., que son administrados por el plano de control, kubelet los administra directamente localmente.
Consulte la documentación oficial: detalles de implementación de kubeadm
Los Static Pods son administrados directamente por el demonio kubelet en el nodo especificado y no requieren supervisión del servidor API. A diferencia de los Pods administrados por el plano de control (por ejemplo, Implementación), el kubelet monitorea cada Pod estático (y lo reinicia después de que falla).
Los Static Pods siempre están vinculados al Kubelet de un nodo específico.
Kubelet intentará crear automáticamente un Pod espejo para cada Pod estático a través del servidor API de Kubernetes. Esto significa que los pods estáticos que se ejecutan en el nodo son visibles para el servicio API, pero el servidor API no los puede controlar. Los nombres de los pods tendrán como sufijo el nombre de host del nodo y comenzarán con un guión.
Hay dos pods en el espacio de nombres kube-system cuyos nombres comienzan con "coredns-", es fácil entender que pertenecen a coredns y también están administrados por Deployment/ReplicaSet.
zhangzk@test:~$ kubectl get deployment -n kube-system -o wide
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
coredns 2/2 2 2 44h coredns registry.aliyuncs.com/google_containers/coredns:v1.10.1 k8s-app=kube-dns
3. Procesos en nodos de Kubernetes
Los procesos de kube en el nodo maestro son los siguientes, incluidos kubelet, kube-proxy, flanneld, etcd, fkube-apiserver, kube-controller-manager y kube-scheduler.
Entre ellos, kubelet y kube-proxy son procesos del plano de control para cada nodo de Kubernetes, flanneld es el proceso de la franela del complemento de red y los cuatro procesos restantes, etc.d, fkube-apiserver, kube-controller-manager y kube-scheduler. son controlados únicamente por el maestro. El proceso plano corresponde al Pod estático anterior.
zhangzk@test:~$ ps -aef|grep kube
root 761 1 1 10:40 ? 00:03:08 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --container-runtime-endpoint=unix:///var/run/containerd/containerd.sock --pod-infra-container-image=registry.aliyuncs.com/google_containers/pause:3.9
root 1326 1122 1 10:40 ? 00:02:52 etcd --advertise-client-urls=https://192.168.19.134:2379 --cert-file=/etc/kubernetes/pki/etcd/server.crt --client-cert-auth=true --data-dir=/var/lib/etcd --experimental-initial-corrupt-check=true --experimental-watch-progress-notify-interval=5s --initial-advertise-peer-urls=https://192.168.19.134:2380 --initial-cluster=test=https://192.168.19.134:2380 --key-file=/etc/kubernetes/pki/etcd/server.key --listen-client-urls=https://127.0.0.1:2379,https://192.168.19.134:2379 --listen-metrics-urls=http://127.0.0.1:2381 --listen-peer-urls=https://192.168.19.134:2380 --name=test --peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt --peer-client-cert-auth=true --peer-key-file=/etc/kubernetes/pki/etcd/peer.key --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt --snapshot-count=10000 --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
root 1639 1449 0 10:40 ? 00:00:01 /usr/local/bin/kube-proxy --config=/var/lib/kube-proxy/config.conf --hostname-override=test
root 1866 1411 0 10:40 ? 00:00:13 /opt/bin/flanneld --ip-masq --kube-subnet-mgr
root 18419 1094 2 11:39 ? 00:04:30 kube-apiserver --advertise-address=192.168.19.134 --allow-privileged=true --authorization-mode=Node,RBAC --client-ca-file=/etc/kubernetes/pki/ca.crt --enable-admission-plugins=NodeRestriction --enable-bootstrap-token-auth=true --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key --etcd-servers=https://127.0.0.1:2379 --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key --requestheader-allowed-names=front-proxy-client --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6443 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/etc/kubernetes/pki/sa.pub --service-account-signing-key-file=/etc/kubernetes/pki/sa.key --service-cluster-ip-range=10.96.0.0/12 --tls-cert-file=/etc/kubernetes/pki/apiserver.crt --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
root 57299 1107 0 14:08 ? 00:00:12 kube-controller-manager --allocate-node-cidrs=true --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf --bind-address=127.0.0.1 --client-ca-file=/etc/kubernetes/pki/ca.crt --cluster-cidr=10.244.0.0/16 --cluster-name=kubernetes --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt --cluster-signing-key-file=/etc/kubernetes/pki/ca.key --controllers=*,bootstrapsigner,tokencleaner --kubeconfig=/etc/kubernetes/controller-manager.conf --leader-elect=true --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt --root-ca-file=/etc/kubernetes/pki/ca.crt --service-account-private-key-file=/etc/kubernetes/pki/sa.key --service-cluster-ip-range=10.96.0.0/12 --use-service-account-credentials=true
root 57379 1116 0 14:08 ? 00:00:04 kube-scheduler --authentication-kubeconfig=/etc/kubernetes/scheduler.conf --authorization-kubeconfig=/etc/kubernetes/scheduler.conf --bind-address=127.0.0.1 --kubeconfig=/etc/kubernetes/scheduler.conf --leader-elect=true
zhangzk 64806 60598 0 14:37 pts/0 00:00:00 grep --color=auto kubeTambién hay 2 procesos coredns en el nodo maestro, la referencia es la siguiente:
zhangzk@test:~$ ps -aef|grep core
root 2093 2034 0 10:40 ? 00:00:24 /coredns -conf /etc/coredns/Corefile
root 2214 2161 0 10:40 ? 00:00:25 /coredns -conf /etc/coredns/CorefileLos procesos del nodo trabajador son los siguientes, solo hay tres procesos: kubelet, kube-proxy y flanneld.
zhangzk@zzk-1:~$ ps -aef |grep kube
root 755 1 0 11:42 ? 00:01:43 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --container-runtime-endpoint=unix:///var/run/containerd/containerd.sock --pod-infra-container-image=registry.aliyuncs.com/google_containers/pause:3.9
root 1176 1079 0 11:42 ? 00:00:01 /usr/local/bin/kube-proxy --config=/var/lib/kube-proxy/config.conf --hostname-override=zzk-1
root 1442 1090 0 11:42 ? 00:00:15 /opt/bin/flanneld --ip-masq --kube-subnet-mgrNota: Todos los nodos anteriores tienen el proceso Dockerd, que no se explica aquí.