$ kubectl enregistre l'application de débogage

2020-02-28 16:05:48 00:00 [Note] [Entrypoint] : Le script Entrypoint pour MySQL Server 1:10.4.12 maria~bionic a démarré.

2020-02-28 16:05:49 00:00 [Note] [Entrypoint] : Passer à l'utilisateur dédié 'mysql'

2020-02-28 16:05:49 00:00 [Remarque] [Entrypoint] : Le script Entrypoint pour MySQL Server 1:10.4.12 maria~bionic a démarré.

2020-02-28 16:05:49 00:00 [ERREUR] [Entrypoint] : la base de données n'est pas initialisée et l'option de mot de passe n'est pas spécifiée

Vous devez spécifier l'un des MYSQL_ROOT_PASSWORD, MYSQL_ALLOW_EMPTY_PASSWORD et MYSQL_RANDOM_ROOT_PASSWORD

$

$ kubectl logs -n kube-system kube-scheduler-$(nom d'hôte)

I0225 19:54:25.957861 1 portion.go:312] Certificat auto-signé généré en mémoire

W0225 19:54:26.142234 1 configmap_cafile_content.go:102] impossible de charger le bundle CA initial pour : "client-ca::kube-system::extension-apiserver-authentication::client-ca-file" en raison de : configmap " extension-apiserver-authentification" introuvable

W0225 19:54:26.142423 1 configmap_cafile_content.go:102] impossible de charger le bundle CA initial pour : "client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file" en raison de : configmap "extension-apiserver-authentication" introuvable

W0225 19:54:26.157329 1 authorisation.go:47] L'autorisation est désactivée

W0225 19:54:26.157413 1 authentication.go:92] L'authentification est désactivée

I0225 19:54:26.157435 1 deprecated_insecure_serving.go:51] Servir healthz de manière non sécurisée sur [::]:10251

I0225 19:54:26.159618 1 configmap_cafile_content.go:205] Démarrage du client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file

I0225 19:54:26.159658 1 shared_informer.go:197] En attente de la synchronisation des caches pour client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file

I0225 19:54:26.159628 1 secure_serving.go:178] Service sécurisé sur 127.0.0.1:10259

$

Dépannage de l'échec du nœud de travail

Un nœud qui exécute des pods dans un cluster Kubernetes est représenté par un kubelet. Chaque kubelet nécessite un environnement d'exécution de conteneur (comme Docker) pour exécuter des conteneurs. Étant donné que l'environnement d'exécution de kubelet et de conteneur s'exécute en tant qu'agents système, vous devez utiliser des outils au niveau de l'hôte tels que systemctl ou journalctl pour afficher leurs journaux.

$ sudo systemctl status kubelet

● kubelet.service - kubelet : l'agent de nœud Kubernetes

Chargé : chargé (/lib/systemd/system/kubelet.service ; activé ; préréglage du fournisseur : activé)

Drop-In : /etc/systemd/system/kubelet.service.d

10-kubeadm.conf

Actif : activation (redémarrage automatique) (Résultat : code de sortie) depuis le ven 2020-02-28 08:08:03 PST ; il y a 8s

Documents : https://kubernetes.io/docs/home/

Processus : 2175 ExecStart = / usr / bin / kubelet $ KUBELET_KUBECONFIG_ARGS $ KUBELET_CONFIG_ARGS $ KUBELET_KUBE

PID principal : 2175 (code=sorti, état=255)

28 février 08:08:03 labsys systemd[1] : kubelet.service : processus principal terminé, code=exited, status=255/n/a

28 février 08:08:03 labsys systemd[1] : kubelet.service : l'unité est entrée en état d'échec.

28 février 08:08:03 labsys systemd[1] : kubelet.service : Échec avec le résultat 'exit-code'.

$ journalctl -u kubelet | queue -5

28 février 08:09:15 labsys kubelet[2771]: I0228 08:09:15.417176 2771 server.go:641] --cgroups-per-qos activé, mais --cgroup-root n'a pas été spécifié. par défaut à /

28 février 08:09:15 labsys kubelet[2771]: F0228 08:09:15.417372 2771 server.go:273] n'a pas réussi à exécuter Kubelet : l'exécution avec swap activé n'est pas prise en charge, veuillez désactiver le swap ! ou définissez l'indicateur --fail-swap-on sur false. /proc/swaps contenu : [nom de fichier Type Taille Priorité utilisée /dev/dm-1 partition 4194300 0 -1]

28 février 08:09:15 labsys systemd[1] : kubelet.service : processus principal terminé, code=exited, status=255/n/a

28 février 08:09:15 labsys systemd[1] : kubelet.service : l'unité est entrée en état d'échec.

28 février 08:09:15 labsys systemd[1] : kubelet.service : échec avec le résultat « exit-code ».

$

Les Kubelets (et donc les nœuds de travail) nécessitent des environnements d'exécution de conteneur fonctionnels pour faire fonctionner les pods. Dans les installations par défaut, la permutation du système doit également être désactivée.

Résoudre les problèmes de mise en réseau

Chaque pod exécuté dans un cluster Kubernetes doit avoir sa propre adresse IP. Les pods reçoivent leurs adresses IP uniques du plug-in CNI (Container Network Interface) du cluster. Afin d'utiliser correctement un plugin CNI, chaque Kubelet doit être configuré pour s'attendre à des plugins CNI dans leur service systemd.

Sans CNI fonctionnel, le kubelet est incapable de configurer le réseau du runtime du conteneur et ne signale pas un état « prêt » au cluster :

$ sudo systemctl status kubelet

● kubelet.service - kubelet : l'agent de nœud Kubernetes

Chargé : chargé (/lib/systemd/system/kubelet.service ; activé ; préréglage du fournisseur : activé)

Drop-In : /etc/systemd/system/kubelet.service.d

10-kubeadm.conf

Actif : actif (en cours d'exécution) depuis le ven 2020-02-28 08:50:27 PST ; il y a 5 minutes

Documents : https://kubernetes.io/docs/home/

PID principal : 19302 (cube)

Tâches : 16 (limite : 512)

Mémoire : 45,2 M

CPU : 3.761s

Groupe C : /system.slice/kubelet.service

└─19302 / usr / bin / kubelet --bootstrap-kubeconfig = / etc / kubernetes / bootstrap-kubelet.conf --kubeconfig = / etc / kubernetes / kubelet.conf --config = / var / lib / kubelet / config. yaml --cgroup-driver = cgroupfs

28 février 08:55:58 labsys kubelet[19302]: E0228 08:55:58.668145 19302 kubelet.go:2183] Le réseau d'exécution du conteneur n'est pas prêt : NetworkReady=false Reason : NetworkPluginNotReady message : docker : plug-in réseau i

28 février 08:56:02 labsys kubelet[19302]: W0228 08:56:02.452412 19302 cni.go:237] Impossible de mettre à jour la configuration cni : aucun réseau trouvé dans /etc/cni/net.d

$

28 février 08:09:15 labsys kubelet[2771]: I0228 08:09:15.417176 2771 server.go:641] --cgroups-per-qos activé, mais --cgroup-root n'a pas été spécifié. par défaut à /

28 février 08:09:15 labsys kubelet[2771]: F0228 08:09:15.417372 2771 server.go:273] n'a pas réussi à exécuter Kubelet : l'exécution avec swap activé n'est pas prise en charge, veuillez désactiver le swap ! ou définissez l'indicateur --fail-swap-on sur false. /proc/swaps contenu : [nom de fichier Type Taille Priorité utilisée /dev/dm-1 partition 4194300 0 -1]

28 février 08:09:15 labsys systemd[1] : kubelet.service : processus principal terminé, code=exited, status=255/n/a

28 février 08:09:15 labsys systemd[1] : kubelet.service : l'unité est entrée en état d'échec.

28 février 08:09:15 labsys systemd[1] : kubelet.service : échec avec le résultat « exit-code ».

$

Les autres symptômes d'un plugin CNI non fonctionnel ou mal configuré incluent :

Pods recevant un IP local Docker Les nouveaux pods restent dans la phase ContainerCreating même si l'image est extraite

D'autres défaillances de réseau peuvent impliquer des facteurs au sein de l'infrastructure sous-jacente du cluster, tels que des règles de pare-feu ou des partitions réseau complètes empêchant la communication.

Exercice d'entraînement

Exécutez la commande suivante. Cette commande démarrera un pod qui ne s'exécutera pas :

kubectl run --restart Jamais --image redis:0.2 redispod

Récupérez les événements associés à ce pod (listés dans n'importe quel ordre) et écrivez-les dans un fichier : /tmp/troubleshooting-answer.txt