Ich versuche, einen kubernetes-Cluster nach dem Dokument zu erstellen: Ссылка
Zuerst habe ich kubeadm mit docker image auf Coreos (1520.9.0) in VirtualBox mit Vagrant installiert:
%Vor%Das war mein kubeadm init:
kubeadm init --pod-network-cidr=10.244.0.0/16
Wenn der Befehl ausgeführt wird:
%Vor%Es gibt zurück:
%Vor%Aber wenn ich "kubectl get pods --all-namespaces" überprüfe
Es gibt zurück:
%Vor% Mit journalctl -f -u kubelet kann ich diesen Fehler sehen: Unable to update cni config: No networks found in /etc/cni/net.d
Ich vermute, dass etwas mit dem Befehl kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/v0.9.1/Documentation/kube-flannel.yml
Gibt es eine Möglichkeit zu wissen, warum dieser Befehl nicht funktioniert? Kann ich irgendwo Logs bekommen?
Gerade heute Abend habe ich kubespray verwendet, um einen Vagrant-Cluster auf CoreOS mit Hilfe von Flanell (vxlan) und Ich war auch verwirrt, wie Flanell könnte eine Pod innerhalb Kubernetes sein
Es stellt sich heraus, wie hier zu sehen , dass sie flanell-cni image von quay.io um CNI-Dateien mit einem Flanell-Seitenwagen zu schreiben plus hostDir Datenträger-Mounts; es gibt cni-conf.json aus (das CNI so konfiguriert, dass es flanel verwendet) und dann net-conf.json (das das von flanel verwendete Subnetz und Backend konfiguriert).
Ich hoffe, dass die jinja2-Schnurrbart-Syntax die Antwort nicht verschleiert, aber ich fand es sehr interessant zu sehen, wie die Kubernetes-Leute es taten, um es "echt" zu vergleichen und gegen das im Flannel angegebene Beispiel DaemonSet zu kontrastieren -cni README. Ich denke, das ist der lange Weg zu sagen: probiere die Deskriptoren in der flanel-cni README aus, dann, wenn es nicht funktioniert, sieh zu, ob sie sich in irgendeiner Weise von der bekannten Kubespray-Konfiguration unterscheiden.
update: Beachten Sie als konkretes Beispiel, dass Die Dokumentation Yaml enthält nicht die --iface= wechseln, und wenn Ihr Vagrant-Setup sowohl NAT als auch" private_network "verwendet, bedeutet dies wahrscheinlich, dass Flanell an eth0 (die NAT-Datei) und nicht eth1 bindet mit einer statischen IP. Ich habe diesen Vorbehalt gesehen, den ich in den Dokumenten erwähnt habe, kann mich aber nicht sofort daran erinnern, wo ich ihn zitieren sollte
update 2
Gibt es eine Möglichkeit zu wissen, warum dieser Befehl nicht funktioniert? Kann ich irgendwo Logs bekommen?
Man kann fast immer auf die Logs eines Pods zugreifen (sogar auf ein statisch definiertes wie kube-controller-manager-coreos1 ): kubectl --namespace=kube-system logs kube-controller-manager-coreos1 , und in den Umständen von CrashLoopBackOff fügen wir -p für "-p hinzu "revious zeigt die Logs des letzten Absturzes an (aber nur für ein paar Sekunden, nicht unbegrenzt), und gelegentlich zeigt kubectl --namespace=kube-system describe pod kube-controller-manager-coreos1 hilfreiche Informationen entweder im Abschnitt Ereignisse unten oder im Block" Status "in der Nähe des oben, wenn es aus Gründen beendet wurde
Im Falle eines sehr schlechten Fehlers, wie zum Beispiel wenn der Apizerver nicht auftaucht (und somit kubectl logs nichts tut), dann wird eine Verbindung zum% Node hergestellt und eine Mischung aus journalctl -u kubelet.service --no-pager --lines=150 und% verwendet co_de%, um einen Fehlertext zu sehen. Sie werden fast sicher docker logs ${the_sha_or_name} brauchen, um den Sha oder den Namen des verlassenen Containers zu finden, aber das selbe "nur für ein paar Sekunden" gilt auch, da tote Container nach einiger Zeit beschnitten werden.
Im Fall von Landstreicher kann man auf eine von mehreren Arten in die VM ssh:
docker ps -a vagrant ssh coreos1 vagrant ssh-config > ssh-config && ssh -F ssh-config coreos1 , aber eines der ersten beiden sind fast immer bequemer Tags und Links kubernetes flannel