kubernetes Cluster-Master-Knoten nicht bereit
ich weiß nicht warum, mein Masterknoten ist nicht bereit, alle Pods im Cluster werden normal ausgeführt, und ich verwende Cabernets v1.7.5. Das Netzwerk-Plugin verwendet Calico. Die OS-Version ist "centos7.2.1511".
# kubectl get nodes
NAME STATUS AGE VERSION
k8s-node1 Ready 1h v1.7.5
k8s-node2 NotReady 1h v1.7.5
# kubectl get all --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system po/calico-node-11kvm 2/2 Running 0 33m
kube-system po/calico-policy-controller-1906845835-1nqjj 1/1 Running 0 33m
kube-system po/calicoctl 1/1 Running 0 33m
kube-system po/etcd-k8s-node2 1/1 Running 1 15m
kube-system po/kube-apiserver-k8s-node2 1/1 Running 1 15m
kube-system po/kube-controller-manager-k8s-node2 1/1 Running 2 15m
kube-system po/kube-dns-2425271678-2mh46 3/3 Running 0 1h
kube-system po/kube-proxy-qlmbx 1/1 Running 1 1h
kube-system po/kube-proxy-vwh6l 1/1 Running 0 1h
kube-system po/kube-scheduler-k8s-node2 1/1 Running 2 15m
NAMESPACE NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default svc/kubernetes 10.96.0.1 <none> 443/TCP 1h
kube-system svc/kube-dns 10.96.0.10 <none> 53/UDP,53/TCP 1h
NAMESPACE NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
kube-system deploy/calico-policy-controller 1 1 1 1 33m
kube-system deploy/kube-dns 1 1 1 1 1h
NAMESPACE NAME DESIRED CURRENT READY AGE
kube-system rs/calico-policy-controller-1906845835 1 1 1 33m
kube-system rs/kube-dns-2425271678 1 1 1 1h
aktualisieren
es scheint, dass der Master-Knoten das Calico-Netzwerk-Plugin nicht erkennen kann. Ich benutze Kubeadm, um den K8s-Cluster zu installieren, da kubeadm auf 127.0.0.1:2379 auf dem Master-Knoten gestartet wird .yaml wie folgt, und alle Kalikoschoten laufen gut, ich kenne mich mit Kaliko nicht so gut aus, wie ich ihn reparieren kann?
apiVersion: v1
kind: Pod
metadata:
annotations:
scheduler.alpha.kubernetes.io/critical-pod: ""
creationTimestamp: null
labels:
component: etcd
tier: control-plane
name: etcd
namespace: kube-system
spec:
containers:
- command:
- etcd
- --listen-client-urls=http://127.0.0.1:2379,http://10.161.233.80:2379
- --advertise-client-urls=http://10.161.233.80:2379
- --data-dir=/var/lib/etcd
image: gcr.io/google_containers/etcd-AMD64:3.0.17
livenessProbe:
failureThreshold: 8
httpGet:
Host: 127.0.0.1
path: /health
port: 2379
scheme: HTTP
initialDelaySeconds: 15
timeoutSeconds: 15
name: etcd
resources: {}
volumeMounts:
- mountPath: /etc/ssl/certs
name: certs
- mountPath: /var/lib/etcd
name: etcd
- mountPath: /etc/kubernetes
name: k8s
readOnly: true
hostNetwork: true
volumes:
- hostPath:
path: /etc/ssl/certs
name: certs
- hostPath:
path: /var/lib/etcd
name: etcd
- hostPath:
path: /etc/kubernetes
name: k8s
status: {}
[[email protected] calico]# kubectl describe node k8s-node2
Name: k8s-node2
Role:
Labels: beta.kubernetes.io/Arch=AMD64
beta.kubernetes.io/os=linux
kubernetes.io/hostname=k8s-node2
node-role.kubernetes.io/master=
Annotations: node.alpha.kubernetes.io/ttl=0
volumes.kubernetes.io/controller-managed-attach-detach=true
Taints: node-role.kubernetes.io/master:NoSchedule
CreationTimestamp: Tue, 12 Sep 2017 15:20:57 +0800
Conditions:
Type Status LastHeartbeatTime LastTransitionTime Reason Message
---- ------ ----------------- ------------------ ------ -------
OutOfDisk False Wed, 13 Sep 2017 10:25:58 +0800 Tue, 12 Sep 2017 15:20:57 +0800 KubeletHasSufficientDisk kubelet has sufficient disk space available
MemoryPressure False Wed, 13 Sep 2017 10:25:58 +0800 Tue, 12 Sep 2017 15:20:57 +0800 KubeletHasSufficientMemory kubelet has sufficient memory available
DiskPressure False Wed, 13 Sep 2017 10:25:58 +0800 Tue, 12 Sep 2017 15:20:57 +0800 KubeletHasNoDiskPressure kubelet has no disk pressure
Ready False Wed, 13 Sep 2017 10:25:58 +0800 Tue, 12 Sep 2017 15:20:57 +0800 KubeletNotReady runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
Addresses:
InternalIP: 10.161.233.80
Hostname: k8s-node2
Capacity:
cpu: 2
memory: 3618520Ki
pods: 110
Allocatable:
cpu: 2
memory: 3516120Ki
pods: 110
System Info:
Machine ID: 3c6ff97c6fbe4598b53fd04e08937468
System UUID: C6238BF8-8E60-4331-AEEA-6D0BA9106344
Boot ID: 84397607-908f-4ff8-8bdc-ff86c364dd32
Kernel Version: 3.10.0-514.6.2.el7.x86_64
OS Image: CentOS Linux 7 (Core)
Operating System: linux
Architecture: AMD64
Container Runtime Version: docker://1.12.6
Kubelet Version: v1.7.5
Kube-Proxy Version: v1.7.5
PodCIDR: 10.68.0.0/24
ExternalID: k8s-node2
Non-terminated Pods: (5 in total)
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits
--------- ---- ------------ ---------- --------------- -------------
kube-system etcd-k8s-node2 0 (0%) 0 (0%) 0 (0%) 0 (0%)
kube-system kube-apiserver-k8s-node2 250m (12%) 0 (0%) 0 (0%) 0 (0%)
kube-system kube-controller-manager-k8s-node2 200m (10%) 0 (0%) 0 (0%) 0 (0%)
kube-system kube-proxy-qlmbx 0 (0%) 0 (0%) 0 (0%) 0 (0%)
kube-system kube-scheduler-k8s-node2 100m (5%) 0 (0%) 0 (0%) 0 (0%)
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
CPU Requests CPU Limits Memory Requests Memory Limits
------------ ---------- --------------- -------------
550m (27%) 0 (0%) 0 (0%) 0 (0%)
Events: <none>
Es empfiehlt sich, einen Befehl zum Ausführen eines Befehls auszuführen, um festzustellen, was mit Ihrem Knoten nicht stimmt:
kubectl describe nodes <NODE_NAME>
beispiel: kubectl, beschreiben die Knoten k8s-node2 Sie können Ihre Untersuchungen von dort aus starten und bei Bedarf weitere Informationen zu dieser Frage hinzufügen.
Sie müssen einen Netzwerkrichtlinienanbieter installieren. Dies ist einer der unterstützten Anbieter: Weave Net für NetworkPolicy . Befehlszeile zur Installation:
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
Nach einigen Sekunden sollte auf jedem Knoten ein Weave Net-Pod ausgeführt werden, und alle weiteren von Ihnen erstellten Pods werden automatisch an das Weave-Netzwerk angeschlossen.
Ich denke, Sie müssen möglicherweise Toleranzen hinzufügen und die Anmerkungen für den Calico-Knoten in dem von Ihnen verwendeten Manifest aktualisieren, damit er auf einem von kubeadm erstellten Master ausgeführt werden kann. Kubeadm verblüfft den Meister, so dass die Hülsen nicht darauf laufen können, es sei denn, sie haben eine Toleranz für diese Verunreinigung.
Ich glaube, Sie verwenden das https://docs.projectcalico.org/v2.5/getting-started/kubernetes/installation/hosted/calico.yaml manifest, das die Anmerkungen (einschließlich Toleranzen) für K8s v1 enthält .5, sollten Sie https://docs.projectcalico.org/v2.5/getting-started/kubernetes/installation/hosted/kubeadm/1.6/calico.yaml überprüfen und die Toleranzsyntax für K8s v1 haben .6+.
Hier ist ein Ausschnitt von oben mit Anmerkungen und Toleranzen
Metadaten: Etiketten: k8s-app: calico-node Anmerkungen: # Markieren Sie diesen Pod als kritisches Add-On. Wenn aktiviert, wird der kritische Add-On-Scheduler # reserviert Ressourcen für kritische Add-On-Pods, damit sie nach .__ umgeplant werden können. # ein Fehler. Diese Anmerkung arbeitet mit der folgenden Toleranz zusammen . scheduler.alpha.kubernetes.io/critical-pod: '' spec: hostNetwork: true Toleranzen: - Schlüssel: node-role.kubernetes.io/master Wirkung: NoSchedule # Erlaube eine Neuplanung dieses Pods, während sich der Knoten im Modus "Nur kritische Add-Ons" befindet. # Dies markiert zusammen mit der obigen Anmerkung diesen Pod als kritisches Add-On . - Schlüssel: CriticalAddonsOnly Operator: Existiert