<p>kubeadm devrait rendre l'option --node-ip disponible</p>

Je rencontre actuellement des problèmes pour configurer un cluster Kubernetes dans DigitalOcean à cause de cela. Par défaut, kubelet liera et exposera / diffusera l'IP de la passerelle par défaut, qui dans ces cas est l'IP publique face au trafic Internet. Ensuite, en arrivant au point de mettre en place un module complémentaire de réseau de pod (comme Weave), tout l'enfer se déchaîne parce que l'adresse IP de publicité du maître est l'adresse IP du réseau interne, mais les nœuds de travail essaient d'exposer le public: /

La solution est de mettre à jour le fichier d'unité déposé sous /etc/systemd/system/kubelet.service.d/10-kubeadm.conf pour ajouter le --node-ip=<private_worker_ip> , recharger les unités et redémarrer kubelet pour le faire fonctionner.

Si kubeadm peut le faire par défaut en passant l'option comme @nkratzke a suggéré que ce serait génial!

Je voulais juste confirmer que l'ajout de l'option --node-ip=<private-worker-ip> aux paramètres du fichier /etc/systemd/system/kubelet.service.d/10-kubeadm.conf ne résoudra pas ce problème pour la configuration que j'ai déjà expliquée. Même si les nœuds écoutent sur cette interface, Kubernetes continue d'utiliser la passerelle par défaut pour communiquer entre les nœuds, qui dans ce cas est l'adresse IP publique.

J'ai le même problème. J'ai essayé votre méthode et cela n'a pas fonctionné pour moi non plus. Avez-vous réussi à le faire fonctionner?

@agsergi J'essayais de configurer un cluster k8s dans DigitalOcean avec l'option de réseau privé activée, ce qui m'a conduit à ce problème. La désactivation de cette fonctionnalité l'a fait pour moi, mais je ne sais pas si vous êtes sur le même bateau.

Je suppose que ce problème sera toujours présent si vous avez plus de deux cartes réseau connectées à la machine.

Les gars,
J'ai deux interfaces sur ma VM, une pour NAT et une seconde pour hostonly-adapter. Par défaut, kubeadmin prenait l'adresse IP de l'interface par défaut (NAT dans mon cas) si vous souhaitez utiliser une autre interface, utilisez:
$ sudo kubeadm init --apiserver-advertise-address =

Et cela a fonctionné pour moi.

@luxas Pourquoi est-ce étiqueté comme kind / support? Existe-t-il un moyen d'utiliser kubeadm avec une adresse IP de nœud qui n'est pas la source de la route par défaut?

@evocage il n'y a pas --apiserver-advertise-address =

Merci beaucoup.

J'ai rencontré le même problème sur Scaleway.

Quand j'ai initialisé le maître, j'ai passé --apiserver-advertise-address=<private_net_IP> mais quand je veux ajouter un nœud ( kubeadm join --toke=<token> <master_private_IP>:6443 ) les pods kube-proxy et weave-net ne démarrent pas (pod de synchronisation d'erreur)

Mais quand j'attache une IP publique à mon nœud et que je le redémarre, tout se passe bien: penser:

Une idée?

Même problème lors de la tentative de configuration de kubernetes sur un hôte de machine virtuelle avec une seule adresse IP où seuls certains ports peuvent être transférés vers les machines virtuelles. Une solution de contournement pour le faire fonctionner?

Je voulais juste +1. J'essaie de courir sur un ensemble de machines virtuelles Digitalocean avec une adresse IP privée sur chacune d'elles, mais l'adresse publique continue de se frayer un chemin dans le cluster d'une manière ou d'une autre.

J'ai réussi à faire fonctionner les adresses IP privées en exécutant ceci sur le maître:

kubeadm init --apiserver-advertise-address=<private-master-ip> init

Ajout de --node-ip=<private-node-ip> à /etc/systemd/system/kubelet.service.d/10-kubeadm.conf , rechargement du démon, redémarrage de kubelet, puis exécution:

kubeadm join --token <token> <private-master-ip>:6443 --discovery-token-ca-cert-hash sha256:<hash>

@mongrelion Quel type de communication entre le nœud maître <-> utilise encore les interfaces publiques? Je n'ai pas pu reproduire cela, donc je serais intéressé de savoir si Kubernetes se comporte de manière inattendue.

Cela l'a fait! La combinaison de --apiserver-advertise-address pour s'assurer que le maître démarre au bon endroit, et --node-ip dans la configuration de kubelet était la combinaison magique.

Cependant, pour cette demande, avoir cette option --node-ip directement dans kubeadm pour que les fichiers de configuration soient correctement initialisés serait utile pour les débutants sans aucune idée comme moi qui essaient de créer des clusters :)

Merci @jamiehannaford pour ce résumé. Pensons-nous que nous devrions documenter cela de manière plus visible?

@luxas Oui, je pense qu'il serait utile d'avoir ce cas d'utilisation explicitement documenté

@jamiehannaford Si vous souhaitez ajouter également ceci au remaniement des documents pour la v1.9, veuillez m'envoyer un paragraphe à ajouter à https://github.com/kubernetes/website/pull/6103

@fabriziopandini Bien sûr! Fait

Salut,

Je souhaite également faire part de vos commentaires. J'essaie d'utiliser kubeadm pour créer un cluster à nœud unique sécurisé.
Je voudrais que tous les services kubernetes se lient à localhost, mais cela ne fonctionne pas.

J'utilise cette commande et le cluster est créé:
kubeadm init \ --pod-network-cidr=10.244.0.0/16 \ --apiserver-advertise-address=127.0.0.1 \ --apiserver-cert-extra-sans=127.0.0.1,staging.my-server.net
Cependant /etc/kubernetes/admin.conf et les amis contiennent l'adresse IP publique du maître.
server: https://75.xx.yy.zz:6443

J'essaierai l'approche --node, mais j'apprécierais que vous puissiez m'aider à trouver une solution à cela.

Mon cas d'utilisation:

J'ai une machine robuste que je souhaite utiliser comme environnement de mise en scène et peut-être comme environnement de production pour de petits projets où je ne me soucie pas de HA. Je peux utiliser SSH et utiliser kubectl pour contrôler le cluster.

Merci,

J'ai eu exactement le même problème que @ Mosho1 ici et je suis allé au fond des choses.

J'utilise DO et CoreOS mais cela n'est vraiment lié à aucun des deux et pourrait se produire sur d'autres fournisseurs et distributions. Il n'est pas non plus lié à l'activation ou à la désactivation des réseaux privés de DO: j'ai reproduit le problème dans les deux cas.

Ce qui se passe, c'est que kubelet tel que configuré par kubeadm regarde les interfaces et décide d'apporter son propre sous-réseau privé au mix, quelles que soient les adresses IP attribuées ou les interfaces disponibles, et souhaite le faire le même qu'il considère comme "principal" (le premier? WAN? Je ne sais pas). Celui-ci n'est pas visible via ifconfig mais facilement via ip addr , et une route est également configurée, mais il n'y a aucune chance que cela survole le réseau DO qui relie les nœuds eth0 .

EDIT: Grâce à @klausenbusk , il semble que kubelet choisisse l'adresse IP d'ancrage en supposant que cela pourrait être utile quand ce n'est pas le cas. Voir les détails ci-dessous.

La solution est en effet de dire à kubelet quelle est l'IP à utiliser. Il peut s'agir du réseau public ou privé si vous utilisez le réseau privé optionnel.

Voici comment j'ai utilisé --node-ip . Attention, cela suppose que KUBELET_EXTRA_ARGS n'a pas déjà été défini dans le fichier d'unité.

$ DROPLET_IP_ADDRESS=$(ip addr show dev eth0 | awk 'match($0,/inet (([0-9]|\.)+).* scope global eth0$/,a) { print a[1]; exit }')
$ echo $DROPLET_IP_ADDRESS  # check this, jus tin case
$ echo "Environment=\"KUBELET_EXTRA_ARGS=--node-ip=$DROPLET_IP_ADDRESS\"" >> /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
$ systemctl daemon-reload
$ systemctl restart kubelet

@lloeki Merci pour la rédaction. Pourriez-vous mettre à jour la documentation, peut-être ici: https://github.com/kubernetes/website/blob/master/docs/setup/independent/troubleshooting-kubeadm.md

Il choisit donc celui du WAN (eth0), voit (ou ignore) une adresse IP publique et décide d'ajouter un deuxième sous-réseau privé (comme 10.19.0.0/255 dans mon cas), probablement en pensant que tous les nœuds eth0 sont sur le même lien.

Êtes-vous sûr de cela? Cela pourrait simplement être l'IP d'ancrage (comparez avec curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address )

@klausenbusk vous avez tout à fait raison, c'était une spéculation amusante de ma part, désolé! Ce qui suit provient du nœud maître, utilisant maintenant --node-ip .

Il semble donc que Kubelet choisisse celui-là en supposant que cela pourrait être utile quand ce n'est pas le cas?

$ curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address
10.19.0.39
$ ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet yyy.yyy.yyy.yyy/20 brd yyy.yyy.yyy.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 10.19.0.39/16 brd 10.19.255.255 scope global eth0
       valid_lft forever preferred_lft forever

Pourriez-vous mettre à jour les documents

@jamiehannaford On dirait que je peux faire ça :)

/ assign @liztio

J'ai jeté un coup d'œil à cela et je pense que le consensus, même si les utilisateurs demandent l'ajout de l'argument --node-ip à kubeadm, est que la modification de la configuration de kubelet et l'utilisation des paramètres tels que @jamiehannaford suggèrent voici l'approche conseillée:
https://github.com/kubernetes/kubeadm/issues/203#issuecomment -335416377

(ou peut-être en ajoutant à $ KUBELET_EXTRA_ARGS avant de redémarrer le kublet).

étant donné la décision de s'éloigner de l'ajout d'arguments cmd supplémentaires à kubeadm, je pense qu'il pourrait être sûr de fermer ce problème .... à moins qu'il ne soit prévu de l'activer avec les options de kubeadm MasterConfig (d'une manière ou d'une autre ?? ... comme nous comptons sur l'utilisateur éditant la configuration de kubelet et se reposant manuellement sur les modifications).

edit: ou peut-être avec la configuration dynamique de kubelet si c'est possible?

toutes les suggestions de modifications de la documentation ci-dessus semblent avoir été fusionnées.

@timstclair @liztio

Je suis d'accord pour fermer celui-ci.

Notez simplement que dans Kubernetes 1.11, le réglage de KUBELET_EXTRA_ARGS dans /etc/systemd/system/kubelet.service.d/20-custom.conf ne fonctionne plus: il devrait être défini dans / etc / sysconfig / kubelet (syntaxe un peu différente de ces fichiers).

@stepin Je viens de configurer un cluster 1.11 en utilisant kubeadm et je l'ai obtenu par la suite cat: /etc/sysconfig/kubelet: No such file or directory

/etc/systemd/system/kubelet.service.d/20-custom.conf n'existe pas non plus, donc je ne suis pas sûr de ce que vous faisiez là-bas.

Si ce que vous avez dit était vrai, il semble que le jeu de configuration de la patate chaude continue.

J'ai pu trouver un autre emplacement pour la configuration de kubelet ici: /etc/default/kubelet

Pour les futurs voyageurs (au moins pour la semaine prochaine), cela semble fonctionner:

PRIVATE_IP=10.99.0.0
echo "KUBELET_EXTRA_ARGS=--node-ip=$PRIVATE_IP" > /etc/default/kubelet
systemctl daemon-reload
systemctl restart kubelet

De toute évidence, vous devrez changer l'adresse IP pour qu'elle soit la vôtre sur ce nœud particulier.

Avertissement: Je suis juste en train de vérifier Kubernetes, donc je ne garantis pas que cela ne fasse pas quelque chose de terrible. Cependant, /etc/systemd/system/kubelet.service.d/10-kubeadm.conf pointe vers /etc/default/kubelet , donc je suppose que c'est la bonne chose à faire.

@jazoom - Merci pour votre commentaire, cela m'a finalement amené à lire de plus près le fichier de l'unité systemd. Je pensais que je devenais fou car je pouvais afficher la même configuration en 1.10, et tout fonctionnait ... faire apparaître la configuration en 1.11 et la personnalisation --node-ip je définissais ne s'appliquait pas du tout. Le passage à l'ajout d'arguments supplémentaires dans /etc/default/kubelet résolu le problème pour moi.

@geerlingguy De rien .

Au moins, ce n'était pas un cas de "ça marche toutes les deux fois que j'évoque un cluster 1.11". Ces problèmes non reproductibles vous rendront vraiment fou.

Je viens de rencontrer ça dans "Kubeadm 1.13". Correction du problème en utilisant les éléments suivants:

1) Ajoutez "--node-ip" à '/var/lib/kubelet/kubeadm-flags.env':

[root@Node-18121 ~]# cat /var/lib/kubelet/kubeadm-flags.env
KUBELET_KUBEADM_ARGS=--cgroup-driver=systemd --network-plugin=cni --pod-infra-container-image=k8s.gcr.io/pause:3.1 --node-ip=10.10.10.1

2) Redémarrez Kubelet:

systemctl daemon-reload && systemctl restart kubelet

^ Si quelqu'un sait comment faire fonctionner cela avec des adresses IP flottantes qui n'apparaissent pas sur la carte réseau, veuillez me le faire savoir. Succès autrement.

Salut,

Veuillez essayer ceci https://wiki.hetzner.de/index.php/Cloud_floating_IP_persistent/en .
Cela fonctionne pour Hetzner mais je pense que c'est générique.
Eugen

Cela a parfaitement fonctionné. Merci.

Je viens de rencontrer ce problème dans "Kubeadm 1.13". Le problème a été résolu à l'aide des méthodes suivantes:

1. Ajoutez "--node-ip" dans "/var/lib/kubelet/kubeadm-flags.env":

[root@Node-18121 ~]# cat /var/lib/kubelet/kubeadm-flags.env
KUBELET_KUBEADM_ARGS=--cgroup-driver=systemd --network-plugin=cni --pod-infra-container-image=k8s.gcr.io/pause:3.1 --node-ip=10.10.10.1

1. Redémarrez Kubelet:

systemctl daemon-reload && systemctl restart kubelet

merci beaucoup, bouger