Kubeadm: apiserver ne démarre pas car la sonde de vivacité est trop agressive

Il semble que nous définissions à la fois InitialDelaySeconds et TimeoutSeconds sur 15 pour les pods du plan de contrôle actuellement, ce qui correspond également à ce que fait kube-up.sh . Je comprends que le lancement initial est lent, toutes les images sont extraites en même temps, mais une fois que toutes les images ont été extraites, combien de temps faut-il à votre apiserver pour répondre aux chèques /healthz après leur lancement?

Il ne fait aucun doute que nous devrions probablement modifier ces deux valeurs pour s'adapter aux machines de faible puissance.

Une fois démarré, il peut répondre aux vérifications de santé en << 15s - c'est vraiment tout ce que l'apiserver fait entre exec () et être prêt à servir les afaics.

oh, et le temps de traction du docker ne compte pas dans les afaics InitialDelaySeconds (bon). Dans d'autres exemples avec des images plus grandes (ubuntu génériques) sur ma liaison réseau lente, l'extraction peut prendre plusieurs minutes, mais le minuteur initialDelaySeconds ne semble pas commencer à cocher tant que l'extraction n'est pas terminée et que l'exécution du docker n'a pas commencé. (Je n'ai pas regardé le code pertinent - juste une expérience anecdotique fréquente)

J'exécute le même problème. Avec des machines lentes, kubeadm est éternel. Utilisation de la v1.7.4

@anguslees et @koalalorenzo , pouvez-vous confirmer que si vous modifiez manuellement les paramètres de la sonde de vivacité (en éditant les fichiers manifestes dans /etc/kubernetes/manifests/ ), cela résout votre problème? J'ai également vu récemment un cas sur Slack où l'utilisateur présentait les mêmes symptômes mais rencontrait probablement des contraintes de mémoire, car le problème a disparu lorsqu'il est passé à un type d'hôte avec plus de mémoire.

Je veux simplement m'assurer que cette approche résoudra réellement le problème avant de consacrer du temps à le coder. Merci!

Je rencontre également ce problème lorsque je tente d'utiliser kubeadm dans QEMU sans virtualisation assistée par matériel (ce qui est une mauvaise idée car elle est terriblement lente). L'augmentation des valeurs InitialDelaySeconds et TimeoutSeconds aide; le cluster finira par apparaître.

@pipejakob Je peux confirmer que (sur mon bananapi) exécuter ceci dans un autre terminal au bon moment dans l'exécution de kubeadm fait que tout se déroule correctement:

sed -i 's/initialDelaySeconds: [0-9]\+/initialDelaySeconds: 180/' /etc/kubernetes/manifests/kube-apiserver.yaml

(Je généralement aussi manuellement docker kill l'ancien conteneur apiserver en boucle de redémarrage, je ne sais pas si cela est nettoyé automatiquement avec des pods statiques)

@anguslees Super! Merci pour la confirmation.

Je peux confirmer que je viens également d'avoir ce problème, dans mon cas sur un Raspberry Pi 3. Le passage à 180s l'a corrigé, mais je pense que j'ai également rencontré le problème # 106 car dans mon cas, il est simplement mort avec:

1 sept. 10:47:30 raspberrypi kubelet [6053]: W0901 10: 47: 30.020409 6053 kubelet.go: 1596] Suppression du module miroir "kube-apiserver-raspberrypi_kube-system (7c03df63-8efa-1
1e7-ae86-b827ebdd4b52) "car il est obsolète

J'ai dû HUP manuellement le processus kubelet pour le ramener à la vie.

Je peux également confirmer que j'avais cela et je voulais vous remercier d'avoir sauvé ma santé mentale. J'ai Raspberry Pi 2B et j'étais bloqué en phase d'initialisation le mois dernier. Après avoir utilisé ce one-liner une fois qu'il a commencé à attendre le plan de contrôle, je l'ai fait avancer.

Ce problème existe toujours dans kubeadm v1.8.0, et il est pire car kubeadm lui-même a maintenant un délai d'expiration de 1 min sur la plupart des actions. Le délai d'expiration de 1 min semble avoir été choisi arbitrairement, et malheureusement a) ne vous donne pas assez de temps pour vous lancer et déboguer / contourner le problème (par exemple: sed hack ci-dessus), b) assez de temps pour que l'apiserver démarre (~ 90s pour moi), même lorsque initialDelaySeconds a été étendu, et c) ne peut pas être augmenté sans piratage / reconstruction kubeadm afaics.

Les délais d'expiration cassent la logique par ailleurs correcte, en particulier dans les systèmes complexes finalement cohérents - nous ne devrions jamais les ajouter "juste parce que": (Je crois comprendre que kubeadm est censé être un élément de base sur lequel des systèmes de déploiement plus importants peuvent dépendre. Par conséquent, je propose hardiment de supprimer tous les délais d'expiration de kubeadm lui-même (les différentes phases devraient continuer à réessayer indéfiniment), et de m'appuyer sur le processus de niveau supérieur pour ajouter un délai d'expiration global si / lorsque cela est approprié dans ce contexte de niveau supérieur. Dans le cas d'utilisation simple / direct, ceci signifierait "réessayer jusqu'à ce que l'utilisateur abandonne et appuie sur ^ c". Un tel RP serait-il acceptable?

@anguslees Nous avons eu le comportement "attendre pour toujours" plus tôt; mais c'était très sous-optimal d'un PoV UX, donc maintenant nous avons des délais d'attente. Nous pourrions vouloir augmenter certains de ces délais si vous le souhaitez.

Le problème est que l'utilisation de kubeadm est double. Nous avons tous les deux des utilisateurs qui tapent kubeadm de manière interactive et qui veulent savoir si quelque chose se passe ou non _et_ des consommateurs de plus haut niveau.

.. Alors dans quelle direction allons-nous aller ici? Actuellement, j'utilise un fork de kubeadm qui a de nombreux délais d'expiration augmentés de 10x, et j'aime bien croire que je peux revenir à l'utilisation des binaires standard kubeadm à un moment donné.

@anguslees Nous avons eu le comportement "attendre pour toujours" plus tôt; mais c'était très sous-optimal d'un PoV UX, donc maintenant nous avons des délais d'attente. Nous pourrions vouloir augmenter certains de ces délais si vous le souhaitez.

Que diriez-vous de les rendre configurables? Est-il judicieux d'avoir une seule option qui les possède tous?

/ priorité important-bientôt

Est-il judicieux d'avoir une seule option qui les possède tous?

Probablement, ou une sorte de "poids" pour tous les délais à multiplier ... Sinon, nous entrerons dans l'enfer de la configuration avec 20 types différents d'indicateurs de délai d'attente :)

Rencontrer le même problème en utilisant la mise à niveau de kubeadm sur le cluster raspberry pi 2 La mise à niveau échoue en raison de délais d'attente agressifs. La modification des paramètres de la sonde de vivacité dans les manifestes n'aide pas. Des idées?

Je propose toujours un modèle dans lequel tout délai d'expiration de kubeadm est hérité du contexte d'appel (ou fait partie d'une stratégie de récupération d'erreur plus sophistiquée), plutôt que de saupoudrer des délais arbitraires dans les niveaux inférieurs de la base de code de kubeadm.

Dans sa forme la plus simple, cela se comporterait presque exactement comme supprimer tous les délais d'attente de kubeadm et les remplacer par une minuterie globale globale «exécuter pendant xx minutes, puis abandonner si ce n'est pas terminé» (car kubeadm ne peut pas faire grand-chose en termes d'erreur récupération autre que juste attendre plus longtemps).

Pour les délais d'expiration de la robe manifestes d'origine, c'est littéralement un patch à une seule ligne. Malheureusement, corriger le livenessProbe à lui seul n'est plus suffisant car l'erreur de "déviation par rapport à la normale == erreur" s'est répandue dans toute la base de code de kubeadm. Changer la conscience culturelle est difficile, donc en attendant, j'ai une version fourchue de kubeadm ici , si quelqu'un veut simplement installer sur un Raspberry Pi. (Construire avec make cross WHAT=cmd/kubeadm KUBE_BUILD_PLATFORMS=linux/arm )

@anguslees Avez-vous une version 1.9.4 compilée de votre kubeadm patché? J'ai du mal à compiler votre version corrigée.

Je suis surpris que kubeadm n'ait pas ce comportement derrière un drapeau. Peut-être qu'un PR est en ordre?

/ assign @liztio

Nous avons donc résolu deux problèmes dans 1.11 qui pourraient affecter cela.

1. Préremplissez l'image etcd avant le démarrage.
2. Correction de la vérification des conditions de concurrence au démarrage.
   ...

Si cela ne se produit que sur les engins pi-gear de la framboise, nous avons besoin d'un moyen de qualifier un plus petit dénominateur commun.

Quelle est la plate-forme cible la plus basse que nous prévoyons de prendre en charge?

Je pense que Raspberry Pi 2 est la plate-forme la plus basse sur laquelle vous voudriez exécuter Kubernetes. Mes tests avec QEMU non assisté par matériel sont trop exotiques pour être pris en compte.

Étant donné que le Pi souffre beaucoup d'E / S lentes, la pré-extraction de toutes les images aidera déjà beaucoup, mais nous aurons besoin de tests dans le monde réel pour déterminer les délais d'expiration réels.

imo rasberry pi2 est trop ancien pour être supporté - http://socialcompare.com/en/comparison/raspberrypi-models-comparison , sorti en 2015.

>= 3 semble plus raisonnable imo.

La pré-extraction des images n'aidera pas. Le minuteur livenessProbe ne démarre qu'après que l'image est tirée (comme je l'ai souligné ci-dessus ).

Le correctif consiste simplement à prolonger le (s) délai (s) initialDelaySeconds . Les valeurs de délai d'expiration actuelles dans kubeadm sont mal utilisées pour "appliquer" une expérience UX rapide, et non pour la détection d'erreurs.

Edit: Et pour être clair, ce n'est que le démarrage qui prend des années - mon cluster de contrôle fonctionne très bien sur 3xRPi2, une fois que j'augmente le délai d'expiration apiserver intialDelaySeconds (et d'autres délais d'installation uniquement utilisés dans kubeadm lui-même). Je ne comprends pas pourquoi on parle encore de ça: /

J'ai un cluster ARM64 sur 1.9.3 et mis à jour avec succès vers 1.9.7 mais j'ai un problème de délai d'expiration pour passer de 1.9.7 à 1.10.2.

J'ai même essayé d'éditer et de recompiler kubeadm en augmentant les délais (comme ces derniers commits https://github.com/anguslees/kubernetes/commits/kubeadm-gusfork) avec les mêmes résultats.

$ sudo kubeadm upgrade apply  v1.10.2 --force
[preflight] Running pre-flight checks.
[upgrade] Making sure the cluster is healthy:
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[upgrade/version] You have chosen to change the cluster version to "v1.10.2"
[upgrade/versions] Cluster version: v1.9.7
[upgrade/versions] kubeadm version: v1.10.2-dirty
[upgrade/version] Found 1 potential version compatibility errors but skipping since the --force flag is set:

   - Specified version to upgrade to "v1.10.2" is higher than the kubeadm version "v1.10.2-dirty". Upgrade kubeadm first using the tool you used to install kubeadm
[upgrade/prepull] Will prepull images for components [kube-apiserver kube-controller-manager kube-scheduler]
[upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.10.2"...
Static pod: kube-apiserver-kubemaster1 hash: ed7578d5bf9314188dca798386bcfb0e
Static pod: kube-controller-manager-kubemaster1 hash: e0c3f578f1c547dcf9996e1d3390c10c
Static pod: kube-scheduler-kubemaster1 hash: 52e767858f52ac4aba448b1a113884ee
[upgrade/etcd] Upgrading to TLS for etcd
Static pod: etcd-kubemaster1 hash: 413224efa82e36533ce93e30bd18e3a8
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/etcd.yaml"
[certificates] Using the existing etcd/ca certificate and key.
[certificates] Using the existing etcd/server certificate and key.
[certificates] Using the existing etcd/peer certificate and key.
[certificates] Using the existing etcd/healthcheck-client certificate and key.
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/etcd.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests190581659/etcd.yaml"
[upgrade/staticpods] Not waiting for pod-hash change for component "etcd"
[upgrade/etcd] Waiting for etcd to become available
[util/etcd] Waiting 30s for initial delay
[util/etcd] Attempting to get etcd status 1/10
[util/etcd] Attempt failed with error: dial tcp 127.0.0.1:2379: getsockopt: connection refused
[util/etcd] Waiting 15s until next retry
[util/etcd] Attempting to get etcd status 2/10
[util/etcd] Attempt failed with error: dial tcp 127.0.0.1:2379: getsockopt: connection refused
[util/etcd] Waiting 15s until next retry
[util/etcd] Attempting to get etcd status 3/10
[util/etcd] Attempt failed with error: dial tcp 127.0.0.1:2379: getsockopt: connection refused
[util/etcd] Waiting 15s until next retry
[util/etcd] Attempting to get etcd status 4/10
[upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148"
[controlplane] Wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/kube-apiserver.yaml"
[controlplane] Wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/kube-controller-manager.yaml"
[controlplane] Wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests346927148/kube-scheduler.yaml"
[upgrade/staticpods] The etcd manifest will be restored if component "kube-apiserver" fails to upgrade
[certificates] Using the existing etcd/ca certificate and key.
[certificates] Using the existing apiserver-etcd-client certificate and key.
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests190581659/kube-apiserver.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/apply] FATAL: couldn't upgrade control plane. kubeadm has tried to recover everything into the earlier state. Errors faced: [timed out waiting for the condition]

Dans le cas où kubeadm est utilisé et que l'apiserver est démarré, nous pouvons essayer de mesurer des points au premier démarrage. Peut-être que nous modifierons la configuration ultérieurement pour les timeouts adaptés aux mesures lors de la première initialisation. De plus, il est difficile de savoir que l'apiserver est expulsé par le contrôle healtz en regardant les journaux, nous pouvons au moins obtenir une meilleure connexion pour être conscient du problème. Il m'a fallu un certain temps pour découvrir que la sonde de vivacité était le problème. Je dois mentionner que je suis un débutant, et qu'il serait au moins utile d'être mentionné quelque part sur la sortie d'échec de kubeadm.

RaspberryPi 3 démontre toujours ce problème, même avec des images pré-extraites. Le serveur API prend 2-3 minutes pour arriver à un endroit où il peut servir une page ...

Ce serait génial que cela soit configurable, car pour le moment, je suis en train de patcher le fichier YAML en arrière-plan pendant que kubeadm s'exécute.

@carlosedp ce que je fais lors d'une mise à niveau est de supprimer le kubelet pendant le démarrage de l'apiserver. C'est un peu piraté, mais cela empêche le bilan de santé de se déclencher jusqu'à ce que l'apiserver soit activé.

Mais honnêtement, kubeadm upgrade et ARM ne fonctionnent tout simplement pas très bien ensemble d'après mon expérience ...

@brendandburns Cela a parfaitement fonctionné jusqu'au 1.9. J'ai déployé mon cluster 1.8 avec lui sans hoquet, puis mis à niveau vers 1.9 deux fois. Aucune idée de ce qui aurait pu changer dans la version 1.10 pour causer ces problèmes.

J'ai vu que le délai d'expiration a changé en 1,11 à 5 minutes (https://github.com/kubernetes/kubernetes/pull/64988/files#diff-2056df5f0c3a4828b3f9a2510a7533c7L45). Avez-vous essayé avec 1.11?

Je vais essayer ce truc après mon retour de vacances. Merci pour le conseil!

@brendandburns @carlosedp
oui, veuillez essayer 1.11 pour confirmer que l'augmentation du délai d'attente est une solution pour vous.

/ cc @ kubernetes / sig-cluster-lifecycle-bugs

Hey! Je rencontre également ce problème.
Fait intéressant cependant, j'arrive à créer un cluster master à partir de zéro sur mon Raspberry 3, mais j'échoue systématiquement sur mon 3+.
Quoi qu'il en soit, la version que j'utilise actuellement (selon la documentation étape par étape à https://blog.hypriot.com/post/setup-kubernetes-raspberry-pi-cluster/) est
kubeadm version: &version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"91e7b4fd31fcd3d5f436da26c980becec37ceefe", GitTreeState:"clean", BuildDate:"2018-06-27T20:14:41Z", GoVersion:"go1.10.2", Compiler:"gc", Platform:"linux/arm"}

Comme pour les autres, le conteneur apiserver finit par se lever, mais pas avant que kubeadm ne se retire, me laissant dans les limbes car je suis trop inexpérimenté pour ramasser manuellement à partir de là.

Mise à jour rapide: en cours d'exécution
watch -n 1.0 "sed -i 's/initialDelaySeconds: [0-9]\+/initialDelaySeconds: 180/' /etc/kubernetes/manifests/kube-apiserver.yaml"
dans un terminal séparé a permis à mon cluster de se lever.

@DJGummikuh
merci pour le test 1.11.

Comme pour les autres, le conteneur apiserver finit par se lever, mais pas avant que kubeadm ne se retire, me laissant dans les limbes car je suis trop inexpérimenté pour ramasser manuellement à partir de là.

combien de temps faut-il pour que l'apiserver démarre dans votre cas?
il semble que nous devrons peut-être rendre cela configurable.

C'est difficile à dire, je suppose environ 1 minute, mais je ne sais pas comment mesurer correctement cela.

De plus, maintenant que mon maître est opérationnel, je ne parviens pas à y ajouter un nœud avec ce qui semble être un autre problème de délai d'expiration.
`[Preflight] exécution des vérifications avant le vol
[AVERTISSEMENT RequiredIPVSKernelModulesAvailable]: le proxy IPVS ne sera pas utilisé, car les modules de noyau requis suivants ne sont pas chargés: [ip_vs_rr ip_vs_wrr ip_vs_sh ip_vs] ou aucun noyau intégré ipvs supporte: ip_vs_rr: {} ip_shwr} nf_conntrack_ipv4: {} ip_vs: {}]
vous pouvez résoudre ce problème avec les méthodes suivantes:

1. Exécutez 'modprobe -' pour charger les modules de noyau manquants;
   
   
   
   1. Fournir le support ipvs du noyau intégré manquant
   
   

I0708 19: 02: 20.256325 8667 kernel_validator.go: 81] Validation de la version du noyau
I0708 19: 02: 20.256846 8667 kernel_validator.go: 96] Validation de la configuration du noyau
[AVERTISSEMENT SystemVerification]: la version du docker est supérieure à la version la plus récemment validée. Version Docker: 18.03.1-ce. Version max validée: 17.03
[découverte] Tentative de connexion au serveur API "192.168.2.2:6443"
[découverte] Création d'un client de découverte d'informations sur le cluster, demandant des informations à " https://192.168.2.2 : 6443"
[découverte] Demander à nouveau des informations à " https://192.168.2.2 : 6443" pour valider TLS par rapport à la clé publique épinglée
[découverte] La signature et le contenu des informations de cluster sont valides et le certificat TLS est validé par rapport aux racines épinglées, utilisera le serveur API "192.168.2.2:6443"
[découverte] Connexion établie avec succès avec le serveur API "192.168.2.2:6443"
[kubelet] Téléchargement de la configuration pour le kubelet depuis le ConfigMap "kubelet-config-1.11" dans l'espace de noms kube-system
[kubelet] Ecriture de la configuration de kubelet dans le fichier "/var/lib/kubelet/config.yaml"
[kubelet] Ecriture du fichier d'environnement kubelet avec des indicateurs dans le fichier "/var/lib/kubelet/kubeadm-flags.env"
[Preflight] Activation du service kubelet
[tlsbootstrap] En attente que le kubelet effectue le bootstrap TLS ...
[kubelet-check] Il semble que le kubelet ne fonctionne pas ou ne fonctionne pas.
[kubelet-check] Il semble que le kubelet ne fonctionne pas ou ne fonctionne pas.
[kubelet-check] Il semble que le kubelet ne fonctionne pas ou ne fonctionne pas.
[kubelet-check] Il semble que le kubelet ne fonctionne pas ou ne fonctionne pas.
[kubelet-check] Il semble que le kubelet ne fonctionne pas ou ne fonctionne pas.
Malheureusement, une erreur s'est produite:
dépassé le délai d'attente de la condition

Cette erreur est probablement causée par:
- Le kubelet ne fonctionne pas
- Le kubelet est défectueux en raison d'une mauvaise configuration du nœud d'une manière ou d'une autre (groupes de contrôle requis désactivés)

Si vous utilisez un système alimenté par systemd, vous pouvez essayer de résoudre l'erreur avec les commandes suivantes:
- 'systemctl status kubelet'
- 'journalctl -xeu kubelet'
dépassé le délai d'attente de la condition`

Pendant ce temps, pas un seul conteneur Docker n'apparaît sur mon nœud.

[AVERTISSEMENT RequisIPVSKernelModulesAvailable]:

offtopic, nous en parlons ici:
https://github.com/kubernetes/kubeadm/issues/975

De plus, maintenant que mon maître est opérationnel, je ne parviens pas à y ajouter un nœud avec ce qui semble être un autre problème de délai d'expiration.
[kubelet-check] L'appel HTTP égal à 'curl -sSL http: // localhost : 10248 / healthz' a échoué avec l'erreur: Get http: // localhost : 10248 / healthz: dial tcp [:: 1]: 10248: connect : Connexion rejetée.

le kubelet n'a pas pu démarrer. mieux regarder les journaux kubelet.

- 'systemctl status kubelet'
- 'journalctl -xeu kubelet'

la sonde de vivacité devrait être configurable, mais nous devrions probablement parler de la meilleure façon de le faire dans la configuration de kubeadm.

Je pense que ce sont les valeurs utilisées, donc si vous construisez vous-même kubeadm, essayez de jouer avec:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L95 -L96
mais sachez que cela augmenterait les délais d'attente sur tous les composants du plan de contrôle.

Edit: je suis apparemment trop stupide pour formater correctement les commentaires dans Github :-(

Here are the log outputs of both systemctl status kubelet and journalctl -xeu kubelet. "No cloud provider specified is the only thing that springs to eye.

`root@djg-clusterpi3:/home/djgummikuh# systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
   Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/kubelet.service.d
           └─10-kubeadm.conf
   Active: active (running) since Sun 2018-07-08 19:55:15 CEST; 2min 12s ago
     Docs: http://kubernetes.io/docs/
 Main PID: 9233 (kubelet)
   Memory: 14.4M
      CPU: 17.064s
   CGroup: /system.slice/kubelet.service
           └─9233 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --cgroup-driver=cgroupfs --cni-bin-dir=/opt/cni/bin --cni-conf-dir=/etc/cni/net.d --network-pl

Jul 08 19:55:15 djg-clusterpi3 systemd[1]: Started kubelet: The Kubernetes Node Agent.
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more inform
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.665304    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more inform
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.675950    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.676273    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.963686    9233 server.go:408] Version: v1.11.0
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.964029    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.964378    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.965040    9233 plugins.go:97] No cloud provider specified.






Jul 08 19:55:15 djg-clusterpi3 systemd[1]: Started kubelet: The Kubernetes Node Agent.
-- Subject: Unit kubelet.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit kubelet.service has finished starting up.
-- 
-- The start-up result is done.
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more inform
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.665304    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more inform
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.675950    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:15 djg-clusterpi3 kubelet[9233]: I0708 19:55:15.676273    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.963686    9233 server.go:408] Version: v1.11.0
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.964029    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.964378    9233 feature_gate.go:230] feature gates: &{map[]}
Jul 08 19:55:31 djg-clusterpi3 kubelet[9233]: I0708 19:55:31.965040    9233 plugins.go:97] No cloud provider specified.`

Veuillez noter que ces journaux ne montrent aucune erreur.

Oui, mais cela fait partie du problème, je crois. Je ne trouve pas une seule ligne concluante de [ERROR] nulle part pour commencer. C'est ce qui me frustre tant :-)

Quoi qu'il en soit, merci d'avoir formaté ce gâchis à moi :-D

Alors, quelle serait une bonne prochaine étape?

Alors, quelle serait une bonne prochaine étape?

comme mentionné précédement:

la sonde de vivacité devrait être configurable, mais nous devrions probablement parler de la meilleure façon de le faire dans la configuration de kubeadm.

Je pense que ce sont les valeurs utilisées, donc si vous construisez vous-même kubeadm, essayez de jouer avec:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L95 -L96
mais sachez que cela augmenterait les délais d'attente sur tous les composants du plan de contrôle.

oof je ne construis pas kubeadm moi-même, je le tire via apt depuis apt.kubernetes.io. Je n'ai rien qui ressemble à distance à un pipeline de construction pour aller sur l'une de mes machines (jamais bricolé). J'espérais qu'il y aurait un fichier similaire à modifier lors de la jonction d'un cluster comme c'était le cas pour le créer, mais comme il semble que ces valeurs sont codées en dur dans le utils.go: - |

vous pouvez essayer cette solution, mais c'est délicat:
https://github.com/kubernetes/kubeadm/issues/413#issuecomment -402916173

le problème est que cela nécessite un changement de configuration et je ne pense pas qu'il puisse être inclus dans une version 1.11.X (mais nous pouvons essayer). il doit également être discuté en premier.

C'est ce que j'ai déjà fait dans le commentaire où je vous ai dit que le master est en place (c'est ce que faisait ma commande watch -n 1.0). Ce qui se passe maintenant, c'est que la jointure kubeadm ne fonctionne pas, et pour autant que je sache, la jointure kubeadm ne place pas de fichiers yaml pour que je puisse patcher n'importe où: - /

vous pourriez rencontrer un autre problème. dur à dire.

ce sont les valeurs utilisées, donc si vous construisez vous-même kubeadm, essayez de jouer avec:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L95 -L96

Je note donc que le délai d'expiration InitialDelaySeconds est encore de 15 secondes un an plus tard, et je ne comprends pas pourquoi il n'a pas été augmenté à quelque chose qui représente réellement la réalité. Ce rapport de bogue sert-il un but? Au départ, je n'avais pas proposé de PR pour changer simplement ce numéro moi-même parce que je sentais que quelqu'un déjà dans le cercle restreint de kubeadm pourrait le faire et fusionner en quelques minutes, mais je suis heureux de le faire si "l'absence de PR" est la seule raison pour laquelle nous n'avons pas avancé.

J'ai l'impression que tout le monde essaie de trouver des raisons pour déclarer le rapport de bogue original invalide (peut-être que nous ne devrions pas prendre en charge rPi2, peut-être devrions-nous rendre le délai initial configurable, peut-être devrions-nous pré-extraire des images ou un autre changement sans rapport, peut-être un un échec de timeout opaque rapide est un meilleur UX qu'un succès plus lent), au lieu d'augmenter simplement le délai initialDelay pour refléter le délai initial réel que nos binaires présentent clairement, puis de passer à autre chose qui mérite en fait la discussion.

Je note donc que le délai d'expiration InitialDelaySeconds est encore de 15 secondes un an plus tard, et je ne comprends pas pourquoi il n'a pas été augmenté à quelque chose qui représente réellement la réalité. Ce rapport de bogue sert-il un but? Au départ, je n'avais pas proposé de PR pour changer simplement ce numéro moi-même parce que je sentais que quelqu'un déjà dans le cercle restreint de kubeadm pourrait le faire et fusionner en quelques minutes, mais je suis heureux de le faire si "l'absence de PR" est la seule raison pour laquelle nous n'avons pas avancé.

Je ne peux pas répondre à vos questions car toute la question est nouvelle pour moi, mais nous pouvons essayer d'en parler cette semaine. veuillez noter que l'équipe derrière kubeadm est une petite équipe avec de grands objectifs et souvent il n'y a personne pour travailler sur une certaine tâche, comme celle-ci.

J'ai l'impression que tout le monde essaie de trouver des raisons pour déclarer le rapport de bogue original invalide (peut-être que nous ne devrions pas prendre en charge rPi2, peut-être devrions-nous rendre le délai initial configurable, peut-être devrions-nous pré-extraire des images ou un autre changement sans rapport, peut-être un un échec de timeout opaque rapide est un meilleur UX qu'un succès plus lent), au lieu d'augmenter simplement le délai initialDelay pour refléter le délai initial réel que nos binaires présentent clairement, puis de passer à autre chose qui mérite en fait la discussion.

oui, les options ont déjà été discutées dans ce fil. c'est une question de choisir la bonne option et de faire la mise en œuvre.

Je crois en fait qu'il serait logique de choisir par défaut "pas de délai" avec l'option de définir un délai pour l'ensemble du processus (comme cela a été suggéré quelque part plus tôt dans ce numéro).

La raison en est que la plupart des cas d'utilisation auxquels je peux penser ne se soucient en fait pas de savoir si une étape spécifique est exécutée en X secondes ou non, car tout ce qui importe dans un système distribué est la cohérence éventuelle (mettre en file d'attente un autre nœud juste au cas où cela coûterait moins cher que de jouer avec les paramètres).

Comme solution provisoire, il suffirait cependant de lire les paramètres de délai d'expiration pour la jointure kubeadm à partir d'un fichier de configuration, tout comme le fait kubeadm init pour que notre hack avec le remplacement du délai d'attente en vol fonctionne. C'est un hack, ne pensez pas différent - mais un hack terrible est toujours mieux que pas de solution de contournement du tout.

Je suis personnellement contre le fait d'essayer de «deviner» des délais d'attente raisonnables, car les suppositions peuvent toujours être fausses, ne serviraient pas vraiment un objectif dans ce cas (puisque la stratégie d'adaptation pour les délais d'attente écoulés consiste simplement à renflouer) et ferait de la reproduction des erreurs une douleur dans le cul puisque deux systèmes identiques pourraient commencer à se comporter différemment pour une myriade de raisons.

@anguslees @DJGummikuh nous en avons parlé lors de la récente réunion du SIG.

c'est un problème épineux, mais voici quelques notes aléatoires ci-dessous.

Remarques:

• certains de nos employés ont beaucoup d'expérience et ils disent que cela sent comme une condition de course qui bloque le départ de l'apiserver. ça ne devrait pas prendre si longtemps. cela pourrait être une chose ARM vs GOLANG.
• J'ai demandé à SIG API Machinery mais je n'ai obtenu aucune réponse sur les valeurs suggérées de la sonde de vivacité et s'ils soupçonnent un type de problème différent ici.
• nous avons convenu qu'exposer une option de configuration ou une variable d'environnement ou un paramètre de ligne de commande est une mauvaise idée pour kubeadm . le raisonnement derrière cela est que nous ne voulons pas exposer des paramètres qui peuvent avoir une signification complètement arbitraire pour les utilisateurs.
• personne dans l'équipe n'a jamais vu un tel problème sur des machines lentes (par exemple, des machines virtuelles lentes), ce qui signifie que cela pourrait être lié au RPi et que tout l'argument selon lequel cela est dû à un matériel "lent" est invalide.
• jetez un œil à ceci: https://github.com/kubernetes/kubernetes/issues/64357 l'utilisateur ne signale pas du tout un problème de sonde de vivacité. une idée pourquoi est-ce?
• Quelqu'un a-t-il vu un problème sur quelque chose comme https://www.scaleway.com/ , selon la théorie de ce fil, cela devrait également arriver?
• En fin de compte, nous avons discuté du fait que le codage en dur de plus grandes valeurs de délai d'expiration / délai n'aurait pas trop d'importance pour kubeadm, donc si quelqu'un veut soumettre un PR pour cela, allez-y. ( @anguslees )

jetez un œil à ceci: kubernetes / kubernetes # 64357 l'utilisateur ne signale pas du tout un problème de sonde de vivacité. une idée pourquoi est-ce?

Non, cela ne semble même pas vraiment reproductible sur mon matériel maintenant. Depuis que le jeton pour rejoindre les nœuds s'est écoulé, j'ai pensé "qu'est-ce que diable" et kubeadm a réinitialisé mon maître de cluster et a essayé de le redémarrer (en faisant fonctionner cette solution de contournement de la montre) - maintenant, même avec cette solution de contournement, je ne peux plus tirer vers le haut un maître sur mon Raspberry Pi 3+. J'ai même augmenté le délai d'attente configuré de 180 à 300 secondes sans aucune différence. Donc j'aime l'idée que ce soit une condition de course.
Je me réjouis toujours de votre suggestion de retirer des délais d'expiration plus élevés. Cela ne fera pas beaucoup de mal et donne au pi (qui EST un matériel lent, je pense que nous pouvons tous être d'accord sur cela :-)) un peu plus de répit.

problème lié sur ARM64 dans l'apiserver:
https://github.com/kubernetes/kubernetes/issues/64649

J'ai fait plus de recherches avec mon (toujours en échec :-() Pi Cluster au cours du week-end.

J'ai réinstallé l'un de mes nœuds car je soupçonnais que la mise à jour d'un Pi 2 vers un Pi 3+ sans réinstaller le système d'exploitation pourrait causer des problèmes. Ce n'est pas le cas, le problème est le même avec le tout nouvel OS.
De plus, j'ai pris l'effort de compiler kubernetes avec les délais d'expiration accrus et j'ai testé avec cela. De plus, cela n'a donné aucun résultat.
J'ai pu obtenir le maître (avec ma solution de contournement de montre pour patcher les fichiers de configuration), mais rejoindre le cluster avec le deuxième nœud ne réussit tout simplement jamais.

Il serait vraiment intéressant d'avoir une sortie de journal supplémentaire utile pour résoudre ce problème. Cependant, je ne comprends pas assez comment les composants de kubernetes interagissent pour savoir où ajouter des lignes.

Quelqu'un est-il prêt à relever le défi? ^^

c'est vraiment un problème en dehors de kubeadm ...

les gens des machines api n'ont pas regardé ma demande de commentaires sur le problème, donc à moins qu'un ticket ne soit déjà enregistré pour cela, quelqu'un devrait en enregistrer un dans le repo kubernetes/kubernetes et taguer /sig api-machinery .

Il serait vraiment intéressant d'avoir une sortie de journal supplémentaire utile pour résoudre ce problème. Cependant, je ne comprends pas assez comment les composants de kubernetes interagissent pour savoir où ajouter des lignes.

pour commencer, on peut activer --v 4 pour le kubelet dans le fichier de dépôt systemd, ce qui indiquera à l'enregistreur GLOG d'activer une verbosité élevée.
on peut également faire la même chose pour les composants du plan de contrôle de la configuration de kubeadm avec ceci:
https://kubernetes.io/docs/setup/independent/control-plane-flags/

Cela a résolu le problème sur mon cluster Raspberry Pi 3: https://github.com/kubernetes/kubernetes/pull/66264

@joejulian nice J'ai réussi à patcher ça et maintenant aussi mon cluster

@joejulian merci d'avoir enquêté!
un correctif potentiel peut être trouvé dans https://github.com/kubernetes/kubernetes/pull/66264

fermeture jusqu'à nouvel ordre.

/Fermer

existe-t-il un moyen de passer de tels paramètres dans le fichier d'initialisation de kubeadm? peut-être en apiServerExtraArgs ? c'est pénible de regarder les fichiers pour les patcher, un peu difficile à automatiser.

Il n'y a pas. Ce serait peut-être une bonne fonctionnalité à ajouter.

Les mises à jour ultérieures ont ajouté encore plus de choses à vérifier et le délai d'expiration prolongé fourni par mon PR n'était plus suffisant. J'ai renoncé à gérer le délai d'attente. La solution pour moi était d'utiliser des certificats ecdsa.

De plus, les services de contrôleur, y compris etcd, prennent plus de RAM, maintenant, qu'un Raspberry Pi n'en a donc plutôt que de doubler le nombre de nœuds pour héberger le plan de contrôle, j'ai mis à niveau vers Rock64s.

Excusez le jeu de mots, mais mon avion de contrôle est solide depuis lors.

Je viens d'essayer de faire une installation sur un Raspberry Pi 3+ et je peux confirmer que l'installation échoue effectivement. Utiliser l'astuce «watch» sur le kube-apiserver.yaml listée ci-dessus semble fonctionner de manière cohérente ... mais seulement si je change le initialDelaySeconds en 360. La valeur suggérée de 180 semble marginale sur mes machines.

Juste au moment où les choses devenaient trop faciles, kubeadm se plaint maintenant que la version de Docker (18.09) n'est pas prise en charge. Un rapide retour à 18.06 a résolu le problème.

dans kubeadm 1.13, nous ajoutons un indicateur de configuration sous ClusterConfig-> ApiServer qui peut contrôler le délai d'expiration du serveur api.
https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta1
timeoutForControlPlane

indicateur de configuration sous ClusterConfig-> ApiServer qui peut contrôler le délai d'expiration du serveur api.

En recherchant dans la base de code TimeoutForControlPlane , je pense que la valeur par défaut est de 4 min, et n'est utilisée que pour le délai utilisé par kubeadm lui-même pour attendre que l'apiserver devienne sain. En particulier, il ne modifie pas la sonde de vie apiserver utilisée par kubelet lui-même. Est-ce exact?

Je ne pense pas avoir vu un contre-argument soulevé nulle part dans la discussion sur cette question. Y a-t-il une raison pour laquelle nous n'augmentons pas simplement livenessProbe initialDelaySeconds et passons à un autre problème?

À part: Autant que je puisse le voir à partir d'une lecture rapide, TimeoutForControlPlane ne prend pas non plus en compte les autres causes de non-échec de l'augmentation du délai de démarrage d'Apiserver, comme la congestion lors de l'extraction de plusieurs images, ou un délai d'expiration supplémentaire + une boucle de relance itérations pendant que tout converge au moment de l'installation initiale (timeout + retry à plusieurs reprises est le modèle de conception de k8s ... et cela se produit parfois sur un système chargé, ce qui est attendu et très bien). Personnellement, je pense que 4 minutes est à la fois trop long pour les utilisateurs interactifs impatients qui s'attendent à un échec rapide et trop court pour un processus d'installation sur un système chargé / lent / automatisé qui est prêt à attendre plus longtemps pour le succès attendu. Comment est-ce arrivé, pouvons-nous par défaut à 5 minutes? Pouvons-nous continuer à réessayer jusqu'à SIGINT? Pourquoi imposons-nous une date limite artificielle d'horloge murale en interne plutôt que de l'hériter de l'environnement d'appel?

Afaics TimeoutForControlPlane expose simplement une échéance interne fatale arbitraire en tant que paramètre où le seul UX prévu est simplement d'augmenter le paramètre jusqu'à ce que l'échéance ne soit jamais atteinte. Alternativement, nous pourrions simplement _pas_ imposer cette échéance interne fatale arbitraire en premier lieu ...

C'est un excellent point et je suis tout à fait d'accord.

En particulier, il ne modifie pas la sonde de vie apiserver utilisée par kubelet lui-même. Est-ce exact?

oui, il n'est pas encore prévu de modifier les sondes de vivacité de kubeadm.

ce problème rpi a été qualifié lors d'une réunion sig-cluster-lifecyle comme "quelque chose qui ne devrait pas arriver", "ressemble presque à une condition de concurrence dans le kubelet", "pourquoi cela n'arrive-t-il que sur rpi et pas sur d'autres appareils plus lents". Je dois admettre que je n'ai pas testé moi-même des appareils lents.

c'est-à-dire qu'il y avait un accord pour augmenter cette valeur:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/util/staticpod/utils.go#L97
n'est pas une bonne solution et cela semble être une solution de contournement pour un autre bogue.

Comment est-ce arrivé, pouvons-nous par défaut à 5 minutes?

le délai d'attente était de 30 minutes avant d'être de 4 minutes, car il fallait prendre en compte le tirage d'images avant la 1.11.
si vous avez un avis sur 4 vs 5 minutes, un PR bien tracé avec des points forts sur le sujet pourrait le faire en 1.14.

ce problème rpi a été qualifié lors d'une réunion sig-cluster-lifecyle comme "quelque chose qui ne devrait pas arriver", "ressemble presque à une condition de concurrence dans le kubelet", "pourquoi cela n'arrive-t-il que sur rpi et pas sur d'autres appareils plus lents".

Ce sont toutes des raisons pour continuer à chercher un autre bogue ailleurs, mais aucune de ces raisons n'est _pas_ d'augmenter initialDelaySeconds. Y a-t-il réellement un inconvénient à augmenter initialDelaySeconds?

Pour l'aborder depuis une autre direction, si nous savons que nous avons un problème ailleurs dans kubernetes avec une solution de contournement qui peut être utilisée dans kubeadm - est-ce le rôle de kubeadm de "maintenir la ligne" sur la pureté et de produire un résultat connu-cassé? Cela semble entrer en conflit avec l'objectif d'être un outil que nous attendons des gens qu'ils utilisent réellement pour des déploiements réels. Jusqu'à présent, je n'ai pas pu utiliser kubeadm sur mon cluster sans le patcher pour augmenter les délais d'expiration (malgré le rapport, avec des correctifs, il y a plus d'un an), ce qui me rend triste.

(Toutes mes excuses pour avoir laissé une partie de ma frustration autour de ce problème s'infiltrer dans mon ton)

si vous avez un avis sur 4 vs 5 minutes

Soupir. J'essayais de défendre la cause de _no_ timeout dans kubeadm, mais je n'ai pas encore trouvé de moyen d'exprimer cette proposition de manière convaincante (voir ceci et d'autres tentatives infructueuses dans ce numéro, par exemple) :(

Ce sont toutes des raisons pour continuer à chercher un autre bogue ailleurs, mais aucune de ces raisons ne permet de ne pas augmenter initialDelaySeconds. Y a-t-il réellement un inconvénient à augmenter initialDelaySeconds?

c'est un petit changement, mais il a été convenu de ne pas ajouter cette augmentation car elle s'appliquera également aux systèmes qui n'exercent pas le problème.

Pour l'aborder depuis une autre direction, si nous savons que nous avons un problème ailleurs dans kubernetes avec une solution de contournement qui peut être utilisée dans kubeadm - est-ce le rôle de kubeadm de "maintenir la ligne" sur la pureté et de produire un résultat connu-cassé? Cela semble entrer en conflit avec l'objectif d'être un outil que nous attendons des gens qu'ils utilisent réellement pour des déploiements réels.

faire face à l'utilisateur final est un objectif pour kubeadm, c'est vrai.
mais encore une fois, ce n'est qu'un rapport pour rpis et le bogue réel devrait être remonté à sig-api-Machinery (serveur api) et sig-node (kubelet) et éventuellement reproduit en dehors de kubeadm.

Jusqu'à présent, je n'ai pas pu utiliser kubeadm sur mon cluster sans le patcher pour augmenter les délais d'expiration (malgré le rapport, avec des correctifs, il y a plus d'un an), ce qui me rend triste.

vous n'avez pas besoin de patcher kubeadm, vous pouvez corriger les fichiers manifestes à la place.
kubeadm 1.13 gradue les phases d'initialisation vers les commandes de niveau supérieur - par exemple kubeadm init phase [phase-name]
les phases sont là principalement parce que les utilisateurs veulent un contrôle personnalisé de la façon dont le nœud du plan de contrôle est créé.

si vous faites kubeadm init --help il vous montrera dans quel ordre les phases sont exécutées.

afin que vous puissiez décomposer votre commande kubeadm init en phases appropriées, vous utilisez des manifestes personnalisés pour les composants du plan de contrôle et ignorez la phase control-plane . il y a aussi --skip-phases maintenant.

vous pouvez déjà le faire dans 1.11 et 1.12, mais c'est moins simple.

car cela s'appliquera également aux systèmes qui n'exercent pas le problème.

Alors ... qu'est-ce qui ne va pas avec ça? Nous corrigeons constamment des bogues qui ne se déclenchent que sur certains systèmes. Partout où nous avons des délais d'attente, nous allons devoir les régler pour notre système le plus lent, pas seulement un sous-ensemble de nos environnements, non?

Un autre angle à ce sujet est qu'en tant que spécialiste des opérations, je suis terrifié par les échecs en cascade dans les situations de surcharge, en particulier avec l'apiserver lui-même. Afaics, le délai d'expiration de la sonde de vivacité ne devrait se déclencher que lorsque les choses ont clairement échoué , pas seulement quand il s'écarte de l'idée que quelqu'un de «normal». Afaics, nous devrions avoir une sonde de vie très détendue configurée, même sur notre matériel le plus rapide. Mon petit rpi démontre simplement cet échec de surcharge plus facilement - mais il s'applique également aux serveurs plus gros dans des scénarios de surcharge / DoS plus importants. Il n'y a aucun avantage à avoir un petit initialDelaySeconds . La sonde de vie par défaut de kubeadm est inutilement agressive sur toutes les plates-formes.

Je suis désolé de répéter les mêmes points, mais afaics il y a de fortes raisons pratiques et théoriques d'étendre initialDelaySeconds, et je ne comprends tout simplement pas l'argument opposé pour le garder petit :(

l'ajout d'une option de configuration kubeadm pour cela est peu probable à ce stade.

J'essaie d'expliquer que c'est déjà faisable avec 3 commandes en 1.13:

sudo kubeadm reset -f
sudo kubeadm init phase control-plane all --config=testkubeadm.yaml
sudo sed -i 's/initialDelaySeconds: 15/initialDelaySeconds: 20/g' /etc/kubernetes/manifests/kube-apiserver.yaml
sudo kubeadm init --skip-phases=control-plane --ignore-preflight-errors=all --config=testkubeadm.yaml

Je ne veux pas d'option, j'essaie de dire que la valeur fixe actuelle (15) doit être changée en une valeur fixe différente (360 a été suggéré ci-dessus).

.. Mais je ne veux pas traîner cela plus loin. Il est clair que la décision est de s'en tenir à la valeur actuelle, je vais donc me retirer vaincu. Merci pour votre patience :)

@ neolit123 cette combinaison a l'air géniale - beaucoup plus facile que ce que j'avais documenté - devoir attendre le jeu de plan de contrôle puis exécuter rapidement sed dans un autre terminal. https://github.com/alexellis/k8s-on-raspbian/blob/master/GUIDE.md

Je vais tester les instructions et chercher à mettre à jour le guide.

@ neolit123 c'est ce que j'ai obtenu en utilisant la configuration ci-dessus sur un RPi3 B +

[certs] apiserver serving cert is signed for DNS names [rnode-1 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.0.110 192.168.0.26 192.168.0.26]
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0xaa7204]

goroutine 1 [running]:
k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig.validateKubeConfig(0xfa93f2, 0xf, 0xfb3d32, 0x17, 0x4032210, 0x68f, 0x7bc)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go:236 +0x120
k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig.createKubeConfigFileIfNotExists(0xfa93f2, 0xf, 0xfb3d32, 0x17, 0x4032210, 0x0, 0xf7978)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go:257 +0x90
k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig.createKubeConfigFiles(0xfa93f2, 0xf, 0x3ec65a0, 0x3f71c60, 0x1, 0x1, 0x0, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go:120 +0xf4
k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig.CreateKubeConfigFile(0xfb3d32, 0x17, 0xfa93f2, 0xf, 0x3ec65a0, 0x1f7a701, 0xb9772c)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go:93 +0xe8
k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases.runKubeConfigFile.func1(0xf66a80, 0x4208280, 0x0, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/kubeconfig.go:155 +0x168
k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow.(*Runner).Run.func1(0x3cc2d80, 0x0, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow/runner.go:235 +0x160
k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow.(*Runner).visitAll(0x3ec9270, 0x3f71d68, 0x4208280, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow/runner.go:416 +0x5c
k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow.(*Runner).Run(0x3ec9270, 0x24, 0x416bdb4)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow/runner.go:208 +0xc8
k8s.io/kubernetes/cmd/kubeadm/app/cmd.NewCmdInit.func1(0x3e97b80, 0x3e900e0, 0x0, 0x3)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/cmd/init.go:141 +0xfc
k8s.io/kubernetes/vendor/github.com/spf13/cobra.(*Command).execute(0x3e97b80, 0x3e3ff80, 0x3, 0x4, 0x3e97b80, 0x3e3ff80)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/spf13/cobra/command.go:760 +0x20c
k8s.io/kubernetes/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0x3e96140, 0x3e97b80, 0x3e96780, 0x3d82100)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/spf13/cobra/command.go:846 +0x210
k8s.io/kubernetes/vendor/github.com/spf13/cobra.(*Command).Execute(0x3e96140, 0x3c8c0c8, 0x116d958)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/spf13/cobra/command.go:794 +0x1c
k8s.io/kubernetes/cmd/kubeadm/app.Run(0x3c9c030, 0x0)
    /workspace/anago-v1.13.1-beta.0.57+eec55b9ba98609/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/app/kubeadm.go:48 +0x1b0
main.main()
    _output/dockerized/go/src/k8s.io/kubernetes/cmd/kubeadm/kubeadm.go:29 +0x20

kubeadm version
kubeadm version: &version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"eec55b9ba98609a46fee712359c7b5b365bdd920", GitTreeState:"clean", BuildDate:"2018-12-13T10:36:44Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/arm"}

Dans kubeadm-config.yaml - 192.168.0.26 se trouve un LB pointant vers 192.168.0.110

apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
kubernetesVersion: stable
apiServer:
  certSANs:
  - "192.168.0.26"
controlPlaneEndpoint: "192.168.0.26:6443"

J'obtiens la même chose même sans la config externe / lb IP.

Alex

Je pousse les gens à utiliser kubeadm depuis un certain temps, même les écoles souhaitant l'exécuter sur leurs clusters pi. Bien que je comprenne ne pas vouloir compliquer la base de code, je pense que c'est probablement une bonne chose pour votre base d'utilisateurs de prendre en charge l'exécution sur ces petits appareils. il permet aux jeunes gens de donner un coup de pied aux pneus Kubernetes sur du matériel de cheep qui autrement ne le ferait pas. La solution de contournement ci-dessus, bien que valide, est beaucoup plus difficile pour ce cas d'utilisation.

Et un compromis? Au lieu de le rendre configurable, ajoutez une heuristique simple qui dit, sinon x86_64, définir le délai d'expiration par défaut plus élevé?

[kubeconfig] Ecriture du fichier kubeconfig "admin.conf"
[kubeconfig] Ecriture du fichier kubeconfig "kubelet.conf"
panique: erreur d'exécution: adresse mémoire invalide ou déréférence de pointeur nul
[signal SIGSEGV: code de violation de segmentation = 0x1 addr = 0x8 pc = 0xaa7204]

étrange, le admin.conf est généré par la machine et doit contenir un type Config valide avec un current-context pointant vers un contexte.

la panique vient de cette ligne:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/kubeconfig/kubeconfig.go#L236

Je vois exactement la même erreur que: point_up: ci -

modify_kube_apiserver_config(){
  sed -i 's/failureThreshold: [0-9]/failureThreshold: 15/g' /etc/kubernetes/manifests/kube-apiserver.yaml && \
  sed -i 's/timeoutSeconds: [0-9][0-9]/timeoutSeconds: 20/g' /etc/kubernetes/manifests/kube-apiserver.yaml && \
  sed -i 's/initialDelaySeconds: [0-9][0-9]/initialDelaySeconds: 120/g' /etc/kubernetes/manifests/kube-apiserver.yaml
}
kubeadm init phase control-plane all --config=$${KUBEADM_CONFIG_FILE} && \
modify_kube_apiserver_config && \
kubeadm init \
--skip-phases=control-plane \
--ignore-preflight-errors=all \
--config=$${KUBEADM_CONFIG_FILE} \
--v 4

Le script suivant résout le problème pour moi en utilisant les versions 1.12, 1.13 de kubeadm (la plupart du temps)

modify_kube_apiserver_config(){
  while [[ ! -e /etc/kubernetes/manifests/kube-apiserver.yaml ]]; do
    sleep 0.5s;
  done && \
  sed -i 's/failureThreshold: [0-9]/failureThreshold: 18/g' /etc/kubernetes/manifests/kube-apiserver.yaml && \
  sed -i 's/timeoutSeconds: [0-9][0-9]/timeoutSeconds: 20/g' /etc/kubernetes/manifests/kube-apiserver.yaml && \
  sed -i 's/initialDelaySeconds: [0-9][0-9]/initialDelaySeconds: 240/g' /etc/kubernetes/manifests/kube-apiserver.yaml
}

# ref https://github.com/kubernetes/kubeadm/issues/413 (initialDelaySeconds is too eager)
if [[ ${var.arch} == "arm" ]]; then modify_kube_apiserver_config & fi

kubeadm init \
  --config=$${KUBEADM_CONFIG_FILE} \
  --v ${var.kubeadm_verbosity}

J'étais dans la même situation, obtenant la même erreur avec l'approche suggérée par @ neolit123 .
Je n'ai pas pu exécuter le script par @stephenmoloney , je ne suis pas vraiment familier avec les scripts bash, probablement de ma faute.

J'ai donc porté le script en python (qui est installé par défaut sur Raspbian, donc pas besoin de dépendances supplémentaires), au cas où quelqu'un serait intéressé:

import os
import time
import threading

filepath = '/etc/kubernetes/manifests/kube-apiserver.yaml'

def replace_defaults():
    print('Thread start looking for the file')
    while not os.path.isfile(filepath):
        time.sleep(1) #wait one second
    print('\033[94m -----------> FILE FOUND: replacing defaults \033[0m')
    os.system("""sed -i 's/failureThreshold: [0-9]/failureThreshold: 18/g' /etc/kubernetes/manifests/kube-apiserver.yaml""")
    os.system("""sed -i 's/timeoutSeconds: [0-9][0-9]/timeoutSeconds: 20/g' /etc/kubernetes/manifests/kube-apiserver.yaml""")
    os.system("""sed -i 's/initialDelaySeconds: [0-9][0-9]/initialDelaySeconds: 240/g' /etc/kubernetes/manifests/kube-apiserver.yaml""")

t = threading.Thread(target=replace_defaults)
t.start()
os.system("kubeadm init")

Pour l'exécuter: sudo python however_you_name_the_file.py
Merci de m'avoir indiqué la solution, @ neolit123 !

Salut! cette question a été d'une grande aide

J'ai trouvé un moyen sophistiqué de résoudre ce problème en utilisant kustomize

mkdir /tmp/kustom

cat > /tmp/kustom/kustomization.yaml <<EOF
patchesJson6902:
- target:
    version: v1
    kind: Pod
    name: kube-apiserver
    namespace: kube-system
  path: patch.yaml
EOF

cat > /tmp/kustom/patch.yaml <<EOF
- op: replace
  path: /spec/containers/0/livenessProbe/initialDelaySeconds
  value: 30
- op: replace
  path: /spec/containers/0/livenessProbe/timeoutSeconds
  value: 30
EOF

sudo kubeadm init --config config.yaml -k /tmp/kustom