le nœud maître du cluster Kubernetes n'est pas prêt
je ne sais pas pourquoi, mon nœud maître n'est pas prêt, tous les pods du cluster fonctionnent normalement, et j'utilise des cabernets v1.7.5, et le plugin réseau utilise calico, et la version os est "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
mettre à jour
il semble que le noeud principal ne reconnaisse pas le plugin réseau calico, j’utilise kubeadm pour installer le cluster k8s, à cause de kubeadm start etcd sur 127.0.0.1:2379 sur le noeud principal et calico sur d’autres noeuds ne peut pas parler avec etcd, je modifie donc .yaml comme suit, et tous les pods calicot fonctionnent bien, je ne suis pas très familier avec calico, comment le réparer?
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: {}
[root@k8s-node2 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>
C'est une bonne pratique d'exécuter une commande describe afin de voir ce qui ne va pas avec votre nœud:
kubectl describe nodes <NODE_NAME>
par exemple: kubectl décrit les nœuds k8s-node2Vous devriez pouvoir commencer vos investigations à partir de là et ajouter plus d’informations à cette question si nécessaire.
Vous devez installer un fournisseur de stratégie réseau. Il s’agit d’un des fournisseurs pris en charge: Weave Net for NetworkPolicy . ligne de commande à installer:
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
Après quelques secondes, un pod Weave Net devrait être en cours d'exécution sur chaque nœud et tous les pods que vous créez seront automatiquement attachés au réseau Weave.
Je pense que vous devrez peut-être ajouter des tolérances et mettre à jour les annotations pour calico-node dans le manifeste que vous utilisez afin qu'il puisse s'exécuter sur un maître créé par kubeadm. Kubeadm souille le maître afin que les gousses ne puissent pas être exécutées à moins que l'utilisateur ne tolère cette souillure.
Je crois que vous utilisez le https://docs.projectcalico.org/v2.5/getting-started/kubernetes/installation/hosted/calico.yaml qui contient les annotations (qui incluent les tolérances) pour K8s v1 .5, vous devriez vérifier https://docs.projectcalico.org/v2.5/getting-started/kubernetes/installation/hosted/kubeadm/1.6/calico.yaml , il a la syntaxe de tolérance pour K8s v1 .6+.
Voici un extrait de ce qui précède avec des annotations et des tolérances
métadonnées: Étiquettes: k8s-app: calico-node annotations: # Marquer ce module comme un ajout critique; lorsqu'il est activé, le planificateur d'extensions critique # réserve des ressources pour des modules complémentaires critiques afin qu'ils puissent être replanifiés après # un échec. Cette annotation fonctionne en parallèle avec la tolérance ci-dessous . scheduler.alpha.kubernetes.io/critical-pod: '' spec: hostNetwork: true tolérances: - clé: node-role.kubernetes.io/master effet: NoSchedule # Permet de replanifier ce module alors que le nœud est en mode "Add-ons critiques uniquement" . # Ceci, avec l'annotation ci-dessus, marque ce module comme un ajout critique . - clé: CriticalAddonsOnly opérateur: Existe