KCNA: Warum und wie Sie die Prüfung bestehen!

Hinweis: Dieser Beitrag wurde aus dem Englischen übersetzt. Fachbegriffe, Code und Befehle wurden bewusst im Original belassen.

Das Prüfungsformat

Die Prüfung ist ein Multiple-Choice-Test mit 60 Fragen. Sie haben 90 Minuten Zeit und müssen mindestens 75 % erreichen, um zu bestehen. Ich hatte zuvor die Gelegenheit, die drei anderen Kubernetes-Zertifizierungen abzulegen (CKA, CKAD und CKS). Alle waren sehr praxisnah und liefen in dedizierten Arbeitsumgebungen ab. Bei der CKA-Prüfung musste ich beispielsweise als eine der Aufgaben Kubernetes mit kubeadm installieren.

P.S.: Wenn Sie sich gerade auf die CKA-Prüfung vorbereiten – mein Kollege Nils hat dazu hier einen ausführlichen Blogbeitrag geschrieben.

Auch wenn das Prüfungsformat einer der Gründe war, diesen Test abzulegen, war es nicht mein Hauptgrund.

Mein Hauptgrund waren die Prüfungsinhalte und das erforderliche Fachwissen. Außerdem wollte ich schon immer am Shadowing-Programm des Kubernetes-Release-Teams teilnehmen und mich zu den geschätzten Kolleginnen und Kollegen gesellen, die dort bereits mitwirken oder mitgewirkt haben. Meiner bescheidenen Meinung nach ist diese Prüfung die perfekte Vorbereitung für alle, die zum Release-Team stoßen möchten. Erstens, um sich im Kubernetes- und Cloud-Native-Ökosystem zu engagieren, und zweitens, wenn sie sich für das Shadowing-Programm anmelden wollen. Warum?

Für Grund Nummer eins müssen Sie im Kern verstehen, was die Cloud Native Computing Foundation genau tut, wie sie arbeitet und wie sie ihr Board wählt. Darüber hinaus sollten Sie wissen, wie viele Kubernetes-Releases pro Jahr erscheinen, wie lange es dauert, bis ein stabiles API-Objekt in Kubernetes als deprecated markiert werden darf, und – besonders wichtig – wie heute alles als Schnittstelle abgebildet wird: CRI (Container Runtime Interface), CNI (Container Network Interface), CSI (Container Storage Interface), SMI (Service Mesh Interface) und ClusterAPI – als einheitlicher Weg, ein Kubernetes-Cluster on-premises oder bei einem beliebigen Public-Cloud-Anbieter bereitzustellen.

Der folgende Artikel beschreibt den Aufbau der Plugin-Schnittstellen im Kubernetes-Ökosystem im Detail: Interoperability of open-source tools: the emergence of interfaces

Die Prüfungsinhalte

Wie oben dargestellt, entfiel fast die Hälfte der Prüfungsfragen auf Kubernetes-Grundlagen – keine besonders tiefgehenden Fragen, sondern solche, die das Wissen abprüfen: etwa, wann ein StatefulSet und wann ein Deployment einzusetzen ist, oder welche Befehle mit kubectl zu verwenden sind. Das offizielle kubectl-Cheatsheet hier ist sowohl für die Prüfung als auch für die tägliche Arbeit hilfreich.

Bei der Container-Orchestrierung liegt der Schwerpunkt, wie bereits erwähnt, stärker auf CRI, CNI und CSI: Wie nutzt die CNCF den offenen Standard, um zu bestimmen, welche Schnittstelle kompatibel ist und welche abgekündigt wird (wie im Fall von Docker und dockershim)? Der Release-Team-Lead von Kubernetes 1.23 hat das in diesem Podcast weiter vertieft.

Die Cloud-Native-Architektur befasst sich mit Microservices und den Vorteilen von Cloud Native unter dem Aspekt „Cloud First". Was bedeutet das? Dass Sie Ihre Anwendung so bauen, dass sie in der Cloud läuft und Cloud-Ressourcen wie Datenbanken, Service Bus und Queues, Load Balancer sowie Authentifizierung und Autorisierung nutzt – und, besonders wichtig, wie Sie Ihre Anwendung containerisieren und im Rahmen Ihrer CI/CD ausliefern.

Bei Cloud Native Observability geht es um die Nutzung eines offenen Standards für Monitoring und Observability innerhalb Ihrer cloud-nativen Architektur. Zu diesem Zweck hat die Open-Source-Community OpenTelemetry geschaffen – eine Implementierung, die das Erfassen und Messen von Performancedaten sowie deren Übermittlung an ein Backend-System zur Verarbeitung vereinheitlicht und standardisiert. Hier ein Artikel der CNCF dazu, warum und wie man OpenTelemetry einsetzt.

Und selbstverständlich gilt: Monitoring und Observability sind für jedes System auf der Welt unverzichtbar – was man nicht messen kann, kann man nicht verbessern.

Prometheus wird als CNCF-Projekt für Monitoring in der Prüfung ebenso erwähnt wie Distributed Tracing. Über die Vorteile von Jaeger als Tracing-Werkzeug habe ich in diesem Artikel geschrieben.

Und schließlich Cloud Native Application Delivery: Hier müssen Sie CI/CD kennen und wissen, wie damit cloud-native Anwendungen gebaut und ausgeliefert werden. Machen Sie sich klar, wie häufig Sie Features im System ausliefern – es geht nicht darum, viele Hundert Releases pro Woche zu integrieren oder auszuliefern, sondern um bedeutsame Releases als Teil Ihrer CI/CD-Pipeline.

Darüber hinaus wurde der Einsatz von GitOps erwähnt. Einfach gesagt: Sie legen Ihre Kubernetes-Objekte in einem Git-Repository ab, das als Single Source of Truth dient, um den Zustand dieser Objekte im Kubernetes-Cluster über einen dort als DaemonSet betriebenen Agenten aufrechtzuerhalten.

Fazit

• Die Prüfung ist auf Einstiegsniveau angesiedelt – es geht also vor allem darum, mit Kubernetes und Cloud Native vertraut zu werden.

• Die Prüfung kostet 250 US-Dollar inklusive einer Wiederholung. (Tipp: Halten Sie vor der Buchung nach den üblichen CNCF-Rabatten Ausschau.)

• Das Ergebnis erhalten Sie 24 Stunden nach Abschluss der Prüfung (was ich für einen Multiple-Choice-Test etwas lang finde)

• Viel Erfolg bei der Prüfung!