Bei der Bereitstellung von Arbeitslasten kann es zu Warnungen oder Störungen kommen. Kubernetes Pods bilden hier keine Ausnahme. Probleme lassen sich leichter lösen, indem man einen Blick in die Logs wirft. Doch wie findet man die neuesten Logs eines bestimmten Pods?
Das Basiskommando hierfür lautet:
kubectl get events
Wir können die Ausgabe nach Timestamp sortieren und auf einen bestimmten Pod filtern.
kubectl get events --sort-by=.metadata.creationTimestamp -n <podname>
kubectl get events --sort-by=.metadata.creationTimestamp -n <podname> | nl
Live Anzeige der Events
In der Linux Welt gibt es das tail Kommando um die letzten (neuesten) Einträge einer Logdatei anzuzeigen. In Kubernetes lautet das analoge Kommando
Ich möchte hier ein nützliches neues Feature vorstellen, das seit vSphere 7 Update 2 verfügbar ist. Es wird bei der Fülle an Neuerungen leicht übersehen, leistet aber sehr gute Dienste im Vorfeld eines vCenter Updates.
Voraussetzung für den Update Planner ist die Teilnahme am Customer Experience Improvement Program (CEIP).
Das erste Anzeichen für ein neues vCenter Updates ist eine Benachrichtigung am oberen Rand des vSphere-Clients.
Durch Klick auf „View Updates“ gelangt man direkt in den Update Planner. Dieser ist auch über das Menü erreichbar. Dazu wählt man in der Ansicht Hosts & Clusters das vCenter aus und selektiert in der Menüleiste oben rechts „Updates“ > vCenter Server > Update Planner.
Es werden alle aktuell verfügbaren Updates angezeigt. Um unten dargestellten Fall ist das vCenter bereits auf Stand 7.0 Update 2. Daher wird nur ein mögliches Update gelistet. Sind mehrere mögliche Updates vorhanden kann der Update Planner die Kompatibilität gegen alle diese Updates prüfen. Dazu wählt man den Radiobutton des gewünschten Updates aus (rote Markierung).
Ist ein Update ausgwählt, so wird das Aktionsfeld „Generate Report“ blau und zeigt die zwei möglichen Unterpunkte „Interoperability“ und „Pre-Update Checks„.
Interoperabilty Check
Der Interoperability Ckeck prüft neben den ESXi Hosts auch die Kompatibilität zu weiteren im vCenter registrierten VMware Produkten.
In meinem Homelab hatte ich vor einigen Wochen Tanzu mit NSX-T aktiviert. Nach einigen Hürden in der Planungsphase funktionierte die Konfiguration und auch das Nord-Süd Routing funktionierte tadellos. Die Edge-Nodes peerten über BGP mit dem physischen Router und machten die Routen in neue Segmente dort bekannt, so dass sie ohne weitere Konfiguratiom im Router sofort verfügbar waren.
Eine Besonderheit, die mein Lab von einer Produktivumgebung unterscheidet, ist dass es nicht 24/7 durchläuft. D.h. nach getaner Arbeit wird der gesamte Cluster herunter gefahren und die Anlage abgeschaltet. Schließlich verursacht ein Cluster im Leerlauf viel Lärm und verbraucht unnötig Energie.
Kürzlich startete ich das Lab neu und musste feststellen, daß aus den NSX Segmenten kein Kontakt zum Router oder DNS Server möglich war. Ein Fall fürs Troubleshooting.
Zunächst prüfte ich die Geneve-Tunnel zwischen den Transport-Nodes. Hier war alles in Ordnung und jeder Transport-Node konnte mit jedem anderen kommunizieren. Die Ursache wurde schnell in den Edge-Nodes lokalisiert. Ein Reboot der Edges oder ein vMotion auf einen anderen Host brachten keine Verbesserung.
Die Edges waren nicht komplett offline. Über das Management-Network waren sie administrierbar. Traceroute funktionierte über T1 und T0 Servicerouter bis zum Fastpath Interface fp-eth0. Ab dort wurde kein Paket weitergeleitet.
Das Interface fp-eth0 ist mit der verteilten Portgruppe Edge-Trunk auf vSwitch VDS-NSX verbunden. Ein Kontrollblick im vSphere-Client zeigte schnell, dass die Uplink Ports der Edges blockiert waren. Nicht im Status „down“, sondern geblockt.
Einen Kunden würde ich an dieser Stelle fragen, was er verändert habe. Ich bin mir aber sehr sicher, keine Veränderung am System oder der Konfiguration gemacht zu haben. Ja, das sagen sie alle 😉
Die Konformität eines Clusters in Bezug auf Sicherheit oder versteckte Probleme zu überprüfen gehört inzwischen zum Standard. Hierfür gibt es automatisierte Hilfsmittel wie zum Beispiel VMware Skyline oder Runecast Analyzer. Letzterer kann neben klassischen vSphere Clustern auch vSAN, NSX-T, AWS, Kubernetes und seit Version 5.0 auch Azure auf Konfomität prüfen.
Ich möchte in diesem Beitrag die Anbindung einer vSphere with Tanzu [*] Umgebung an Runcast Analyzer beschreiben. [* native Kubernetes Pods und TKG auf vSphere]
Einige Schritte sind vereinfacht, da es sich um eine Lab Infrastruktur handelt. Ich werde zu gegebenem Zeitpunkt darauf hinweisen.
Bevor wir Tanzu in Runecast registrieren können, benötigen wir ein paar Informationen.
IP Adresse oder FQDN der SupervisorControlPlane
Dienstkonto mit Zugriff auf die SupervisorControlPlane
