Resumen de los aspectos más destacados del error k8s-kubernetes

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

Inserte la descripción de la imagen aquí
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


Inserte la descripción de la imagen aquí
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
Inserte la descripción de la imagen aquí

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
Inserte la descripción de la imagen aquíInserte la descripción de la imagen aquí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

Inserte la descripción de la imagen aquíÉxito
④ Regrese al host maestro
Inserte la descripción de la imagen aquí
ok, ahora resuelva el error en ②, verifique el registro del sistema,
Inserte la descripción de la imagen aquí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í;
Inserte la descripción de la imagen aquí
implementar en maestro

kubectl apply -f kube-flannel.yml

Inserte la descripción de la imagen aquíInicializando, describa para ver los detalles. La
Inserte la descripción de la imagen aquí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
Inserte la descripción de la imagen aquíInserte la descripción de la imagen aquíen la siguiente figura, la siguiente figura muestra

Inserte la descripción de la imagen aquíInserte la descripción de la imagen aquíEste pod de otro nodo se está inicializando
Inserte la descripción de la imagen aquí

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
Inserte la descripción de la imagen aquí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

Inserte la descripción de la imagen aquí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
Inserte la descripción de la imagen aquípaso de desinstalación está aquí
Inserte la descripción de la imagen aquí
Inserte la descripción de la imagen aquíhoy

Supongo que te gusta

Origin blog.csdn.net/qq_38774492/article/details/108010359
Recomendado
Clasificación