colección de errores k8s-kubernetes
Ensayos, concluyó el estudio, después de verse a sí mismo escribió, por lo que el artículo será más informal
①
[root @ centos7 K8S-Auto] # kubectl GET Nodes
at The Connection at The Server to localhost: 8080 FUE rechazado The - the Specify HIZO bien en el host o el puerto? El
error anterior, verifique si la variable de entorno está configurada, verifique los pasos de la siguiente manera
env | grep -i kube
Si no lo está, está vacío o la ruta es incorrecta, el archivo es incorrecto, etc. Simplemente corrija y corrija el error. El método de adición es el siguiente:
Método temporal
export KUBECONFIG=/etc/kubernetes/admin.conf
Modificación permanente
echo "export KUBECONFIG=/etc/kubernetes/admin.conf" > /etc/profile.d/kubeconfig.sh
source /etc/profile.d/kubeconfig.sh
Cámbielo y vuelva a intentarlo. ②La razón por la que el nodo no está listo. Los
pasos de solución de problemas, verifique el estado de los pods de la siguiente manera, coredns está pendiente (suspendido), describa para ver la información detallada
kubectl describe pods coredns-546565776c-bkhvx -n kube-system
Esto es lo que dije en la parte inferior. Agreguemos un nodo aquí y luego miremos el registro para solucionar el problema, porque solo tengo un nodo maestro.
Problema: omítalo primero y luego resuélvelo más tarde. Ahora ve a otro host para unirte a un nuevo nodo
③
kubeadm join 192.168 .40.130: 6443 --token hdp0kg.ac73i5ms09kuvqbx --discovery-token-ca-cert-hash sha256: 5026d0d1673e55ae99bdbf74d6633988d3e9d76a70903adae9e5bdf el
valor no es el mismo, y el último token no es el mismo. Consulte
ERROR: No se puede conectar al demonio de Docker en unix: ///var/run/docker.sock. ¿Se está ejecutando el demonio de Docker?
Errores bastante información de impresión
, error: estado de salida 1
[ERROR Service-Docker]: el servicio de Docker no está activo, ejecute 'systemctl start docker.service'
[ERROR IsDockerSystemdCheck]: no se puede ejecutar'docker info -f {
{.CgroupDriver}} ': estado de salida 2
[ERROR FileContent – proc-sys-net-ipv4-ip_forward]: el contenido de / proc / sys / net / ipv4 / ip_forward no está configurado en 1
[ERROR SystemVerification]: error al verificar la información de Docker: “No se puede conectar al demonio de Docker en unix : ///var/run/docker.sock. ¿Se está ejecutando el daemon de la ventana acoplable? ”
[Preflight] Si sabe lo que está haciendo, puede hacer una comprobación no fatal con --ignore-preflight-errors=...
Para ver el seguimiento de la pila de este error, ejecute con- -v = 5 o superior
, dijo que el servicio de la ventana acoplable de figuras no se reproducía, no se reproducía, intentaba iniciar con éxito, pero también dio el comando de inicio es muy fácil _
systemctl start docker.service
Éxito
④ Regrese al host maestro
ok, ahora resuelva el error en ②, verifique el registro del sistema,
puede ver que este error ha sido
eliminado : No se puede actualizar la configuración de cni: no se encontraron redes en /etc/cni/net.d
La red en tiempo de ejecución del contenedor no está lista: NetworkReady = razón falsa: NetworkPluginNotReady mensaje: docker: el complemento de red no está listo: cni config no inicializado Esto
muestra que es un problema de red. Este es un servicio de planificación de red que debe implementarse. Estoy aquí porque Yo uso el pod de coredns, así que estoy aquí Flannel está implementado. Los pasos son los siguientes:
wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml para
descargar, aquí hay otro documento mío, y el archivo también se proporciona a los recursos de csdn En
este yaml, puede modificar una configuración para vincular la tarjeta de red para evitar un error cuando se implementa la máquina con tarjetas de red duales;
busque la palabra clave masq, agregue -iface en la posición de la figura, donde ens33 aquí corresponde al nombre de mi tarjeta de red, lo modifica en consecuencia Sí;
implementar en maestro
kubectl apply -f kube-flannel.yml
Inicializando, describa para ver los detalles. La
imagen se está extrayendo, a veces informará ImagePullBackOff, la mayoría de los cuales son
causados por el tiempo de espera de la extracción de la imagen , la velocidad de la red (reemplace la fuente de espejo) o el servicio systemd es anormal o memoria de disco, etc.Espere, dependiendo del mensaje de error correspondiente a la solución;
si se trata del problema de tiempo de espera del servicio systemd1, debe eliminar manualmente el proceso de kubelet, corregir el error de acuerdo con el registro del sistema (mensaje y dmesg), y luego reinicie la computadora; después de que se corrija el error
como se muestra
en la siguiente figura, la siguiente figura muestra
Este pod de otro nodo se está inicializando
ABRT has detected 1 problem(s). For more info run: abrt-cli list --since 1597805286
[root@k8s-node2 ~]# abrt-cli list --since 1597805286
id 0770fc07826bfb4326df323a5bc3e3bdc9c54cc8
reason: NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [flannel:6611]
time: 2020年08月19日 星期三 15时49分39秒
cmdline: BOOT_IMAGE=/vmlinuz-3.10.0-1062.el7.x86_64 root=/dev/mapper/centos-root ro crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rhgb quiet LANG=zh_CN.UTF-8
package: kernel
uid: 0 (root)
count: 1
Directory: /var/spool/abrt/oops-2020-08-19-15:49:39-6633-0
已报告: 无法报告
已禁用自动报告功能。请考虑启用该功能,方法是
作为有 root 特权的用户使用命令 'abrt-auto-reporting enabled'
Esta tasa de ocupación de la CPU es demasiado alta, lo que lleva a un bloqueo suave de un solo núcleo ("punto muerto"), esto sucederá con frecuencia, la razón específica debe analizarse en detalle, lo siguiente dará un ejemplo lentamente y el análisis se
completará, pero los núcleos aún no está listo, verifique el registro del sistema Buscar
Aug 19 15:55:39 k8s-master flanneld-start: E0819 15:55:39.713690 8277 network.go:102] failed to retrieve network config: client: etcd cluster is unavailable or misconfigured; error #0: dial tcp 192.168.161.131:2379: i/o timeout
Aug 19 15:55:41 k8s-master flanneld-start: E0819 15:55:41.714940 8277 network.go:102] failed to retrieve network config: client: etcd cluster is unavailable or misconfigured; error #0: dial tcp 192.168.161.131:2379: i/o timeout
Aug 19 15:55:43 k8s-master flanneld-start: E0819 15:55:43.717839 8277 network.go:102] failed to retrieve network config: client: etcd cluster is unavailable or misconfigured; error #0: dial tcp 192.168.161.131:2379: i/o timeout
El error anterior, aquí se debe a que instalé etcd y franela (necesarios al compilar docker-swarm) en estas tres máquinas. Cuando se agregó etcd al clúster, informó un error y eliminé las cosas almacenadas, pero no lo hice Piense en franela. Todavía está encendida; y he cambiado esta IP, así que, por supuesto, informará un error si se conecta a una IP que no está en línea en absoluto, verifique / etc / hosts y búsquelo.
192.168.161.131 etcd #Esto se eliminará y las tres máquinas seguirán
informando un error. Resuma el registro en el mensaje
Aug 19 16:33:55 k8s-master flanneld-start: E0819 16:33:55.743196 15589 network.go:102] failed to retrieve network config: client: etcd cluster is unavailable or misconfigured; error #0: dial tcp: lookup etcd on 114.114.114.114:53: no such host
Aug 19 16:32:03 k8s-master flanneld-start: E0819 16:32:03.592101 15556 network.go:102] failed to retrieve network config: client: etcd cluster is unavailable or misconfigured; error #0: dial tcp 192.168.161.127:2379: getsockopt: connection refused
La siguiente figura es mi registro de visualización del clúster.
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling <unknown> default-scheduler 0/1 nodes are available: 1 node(s) had taint {
node.kubernetes.io/not-ready: }, that the pod didn't tolerate.
Warning FailedScheduling <unknown> default-scheduler 0/2 nodes are available: 2 node(s) had taint {node.kubernetes.io/not-ready: }, that the pod didn't tolerate.
Warning FailedScheduling <unknown> default-scheduler 0/3 nodes are available: 3 node(s) had taint {
node.kubernetes.io/not-ready: }, that the pod didn't tolerate.
Normal Scheduled <unknown> default-scheduler Successfully assigned kube-system/coredns-546565776c-6mvpj to k8s-node2
Normal Pulling 10m kubelet, k8s-node2 Pulling image "registry.cn-hangzhou.aliyuncs.com/google_containers/coredns:1.6.7"
Normal Pulled 10m kubelet, k8s-node2 Successfully pulled image "registry.cn-hangzhou.aliyuncs.com/google_containers/coredns:1.6.7"
Normal Created 10m kubelet, k8s-node2 Created container coredns
Normal Started 10m kubelet, k8s-node2 Started container coredns
Warning Unhealthy 8m34s kubelet, k8s-node2 Readiness probe failed: Get http://10.18.1.2:8181/ready: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
Warning Unhealthy 10s (x55 over 10m) kubelet, k8s-node2 Readiness probe failed: HTTP probe failed with statuscode: 503
Se puede ver que debido a esta razón, el hilo está bloqueado y el uso de la CPU es demasiado alto. En este momento, puede detener el entorno del clúster k8s (solo para pruebas y aprendizaje), pero incluso si detiene kubelet y docker, no dejará de informar errores. Debido a que la causa raíz no está en el clúster; después de
desinstalar directamente etcd y flannel en las tres máquinas, el registro de errores no se actualizará; el
paso de desinstalación está aquí
hoy