Am 2 clustere kubernetes în cloud-ul IBM, unul are 2 Noduri, celălalt 4.

Cel care are 4 Noduri funcționează corect, dar la celălalt a trebuit să elimin temporar nodurile de lucru din motive monetare (nu ar trebui plătit în timp ce sunt inactiv).

Când am reactivat cele două noduri, totul părea să pornească bine și atâta timp cât nu încerc să interacționez cu Pod-urile, tot arată bine la suprafață, fără mesaje despre indisponibilitate sau stare critică de sănătate. OK, am șters două învechite Spațiu de numes care s-a blocat în Încheiere stare, dar aș putea rezolva problema repornind un nod de cluster (nu mai știu exact care a fost).

Când totul părea în regulă, am încercat să accesez tabloul de bord kubernetes (tot ce s-a făcut înainte a fost la nivel de management IBM sau în linia de comandă), dar în mod surprinzător l-am găsit inaccesibil cu o pagină de eroare în browser care spunea:

503 Serviciu Indisponibil

Era un mic mesaj JSON în partea de jos a acelei pagini, care spunea:

{
  "kind": "Stare",
  "apiVersion": "v1",
  „metadate”: { },
  "status": "Eșec",
  "message": "eroare la încercarea de a ajunge la serviciu: citiți tcp 172.18.190.60:39946-\u003e172.19.151.38:8090: citiți: resetarea conexiunii de către peer",
  "motiv": "Serviciul indisponibil",
  „cod”: 503
}

am trimis un kubectl înregistrează kubernetes-dashboard-54674bdd65-nf6w7 --namespace=kube-system unde Pod a fost afișat ca rulând, dar rezultatul nu a fost jurnalele de vizualizat, a fost în schimb acest mesaj:

Eroare de la server: obțineți „https://10.215.17.75:10250/containerLogs/kube-system/kubernetes-dashboard-54674bdd65-nf6w7/kubernetes-dashboard”:
citiți tcp 172.18.135.195:56882->172.19.151.38:8090:
citiți: resetarea conexiunii de către peer

Apoi am aflat că nici nu pot obține jurnalele orice Pod rulează în acel cluster și nici nu pot implementa niciun obiect kubernetes personalizat nou care necesită programare (de fapt, aș putea aplica Servicius sau ConfigMaps, dar nu Pod, ReplicaSet, Implementare sau asemănător).

Am încercat deja

• reîncărcați nodurile de lucru din grupul de lucrători
• reporniți nodurile de lucru din grupul de lucrători
• a repornit tabloul de bord kubernetes Implementare

Din păcate, niciuna dintre acțiunile de mai sus nu a schimbat accesibilitatea Pods.

Mai este un lucru care ar putea avea legătură (deși nu sunt sigur că este de fapt):

În celălalt grup care funcționează bine, există trei calicoți Podrulează și toate trei sunt sus, în timp ce în grupul problematic doar 2 din cele trei calico Podsunt în funcțiune, al treilea rămâne înăuntru In asteptarea stat și a kubectl descrie pod calico-blablabla-blabla dezvăluie motivul, an Eveniment

Avertisment FailedScheduling 13s planificator implicit
Sunt disponibile 0/2 noduri: 2 noduri nu au avut porturi libere pentru porturile de pod solicitate.

Are cineva vreo idee despre ce se întâmplă în acel cluster și îmi poate indica soluții posibile? Nu vreau să șterg clusterul și să deschid unul nou.

Editați | ×

Rezultatul kubectl descrie pod kubernetes-dashboard-54674bdd65-4m2ch --namespace=kube-system:

Nume: kubernetes-dashboard-54674bdd65-4m2ch
Spațiu de nume: kube-system
Prioritate: 2000000000
Nume clasa prioritară: system-cluster-critical
Nod: 10.215.17.82/10.215.17.82
Ora de începere: Luni, 15 noiembrie 2021 09:01:30 +0100
Etichete: k8s-app=kubernetes-dashboard
                      pod-template-hash=54674bdd65
Adnotări: cni.projectcalico.org/containerID: ca52cefaae58d8e5ce6d54883cb6a6135318c8db53d231dc645a5cf2e67d821e
                      cni.projectcalico.org/podIP: 172.30.184.2/32
                      cni.projectcalico.org/podIPs: 172.30.184.2/32
                      container.seccomp.security.alpha.kubernetes.io/kubernetes-dashboard: runtime/default
                      kubectl.kubernetes.io/restartedAt: 2021-11-10T15:47:14+01:00
                      kubernetes.io/psp: ibm-privileged-psp
Stare: Running
IP: 172.30.184.2
IP-uri:
  IP: 172.30.184.2
Controlat de: ReplicaSet/kubernetes-dashboard-54674bdd65
Containere:
  Kubernetes-tabloul de bord:
    ID container: containerd://bac57850055cd6bb944c4d893a5d315c659fd7d4935fe49083d9ef8ae03e5c31
    Imagine: registry.eu-de.bluemix.net/armada-master/kubernetesui-dashboard:v2.3.1
    ID imagine: registry.eu-de.bluemix.net/armada-master/kubernetesui-dashboard@sha256:f14f581d36b83fc9c1cfa3b0609e7788017ecada1f3106fab1c9db35295fe523
    Port: 8443/TCP
    Port gazdă: 0/TCP
    Argumente:
      --auto-generate-certificates
      --namespace=kube-system
    Stare: alergare
      Început: Luni, 15 noiembrie 2021 09:01:37 +0100
    Gata: Adevărat
    Număr de reporniri: 0
    Cereri:
      CPU: 50m
      memorie: 100 Mi
    Liveness: http-get https://:8443/ delay=30s timeout=30s period=10s #success=1 #failure=3
    Pregătire: http-get https://:8443/ delay=10s timeout=30s period=10s #success=1 #failure=3
    Mediu: <niciun>
    Suporturi:
      /certs de la kubernetes-dashboard-certs (rw)
      /tmp din tmp-volume (rw)
      /var/run/secrets/kubernetes.io/serviceaccount de la kube-api-access-sc9kw (ro)
Conditii:
  Tastați Stare
  Adevărat inițializat 
  Gata Adevărat 
  ContainersReady Adevărat 
  PodScheduled Adevărat 
Volume:
  kubernetes-dashboard-certs:
    Tip: Secret (un volum populat de un Secret)
    SecretName: kubernetes-dashboard-certs
    Opțional: fals
  tmp-volum:
    Tip: EmptyDir (un director temporar care partajează durata de viață a unui pod)
    Mediu:     
    SizeLimit: <dezactivat>
  kube-api-access-sc9kw:
    Tip: Proiectat (un volum care conține date injectate din mai multe surse)
    TokenExpirationSeconds: 3607
    ConfigMapName: kube-root-ca.crt
    ConfigMapOptional: <nil>
    DownwardAPI: adevărat
Clasa QoS: Burstable
Selectori de noduri: <niciunul>
Tolerări: node-role.kubernetes.io/master:NoSchedule
                             node.kubernetes.io/not-ready:NoExecute op=Există pentru 600 de secunde
                             node.kubernetes.io/unreachable:NoExecute op=Există de 600 de secunde
Evenimente: <niciunul>