CKAD Selbststudien Mod 4

In diesem Modul des Online-CKAD-Vorbereitungskurses Broad Skills behandeln wir die Kernkonzepte und Konfigurationsthemen, die im CNCF CKAD-Prüfungscurriculum identifiziert wurden. Wenn Sie mit dem Lehrplan noch nicht vertraut sind, nehmen Sie sich einen Moment Zeit, um sich vertraut zu machen, da Sie Ihr Wissen zu jedem Thema nachweisen müssen, um die Prüfung zu bestehen.

Dienstleistungen

Ein Service ist eine Abstraktion eines logischen Satzes von Pods, die bei der Definition des ein- und ausgehenden Netzwerkzugriffs hilft. Ein Dienst verwendet einen Selektor, um Pods mithilfe des Pod-Labels als Ziel zu verwenden. Ein Dienst stellt einen logischen Satz von Pods als Netzwerkdienst bereit, der eine einzelne IP-Adresse, einen DNS-Namen oder einen Lastausgleich für den Zugriff auf die Pods bereitstellt. Der Diensttyp ist im Manifest definiert. Folgende Servicetypen stehen zur Verfügung:

ClusterIP – stellt den Dienst auf einer internen IP im Kubernetes-Cluster bereit (Standard)NodePort – stellt den Dienst auf demselben Port jedes Knotens im Kubernetes-Cluster bereitExternalName – stellt den Dienst unter Verwendung eines beliebigen Namens bereitLoadBalancer – erstellt einen externen Lastenausgleich bei einem Cloud-Anbieter (z. B. GCE ForwardingRules, AWS Elastic Load Balancer, Azure Load Balancer) und weist dem Dienst eine öffentliche IP zu

Auf ClusterIP Services kann nur innerhalb des Kubernetes-Clusters zugegriffen werden; alle anderen Optionen können Anfragen an den Dienst von außerhalb des Kubernetes-Clusters verarbeiten. Dienste können zwingend für eine laufende Ressource erstellt werden. Mindestens die Ressource, das Objekt und der exponierte Proxy-Port des Dienstes sind erforderlich, zB kubectl Expose [Ressource] [Objekt] --port=[Portnummer] . Wenn keine anderen Optionen angegeben werden, wird standardmäßig ein ClusterIP-Dienst erstellt und der angegebene Port ist sowohl der Proxy-Port des Dienstes auf dem lokalen Knoten als auch der Zielport des Containers. Im folgenden Beispiel wird ein Dienst für eine Bereitstellung von zwei nginx-Pods erstellt. Der Proxy-Port des Dienstes ist 8080 zum Port 80 des Containers. Erstellen Sie zuerst die Bereitstellung von 3 Replikaten von nginx und rufen Sie die Endpunkte der Pods der Bereitstellung ab. Wir können das Ausführungslabel der Bereitstellung verwenden, um nur die Pods der Bereitstellung auszugeben.

$ kubectl Create Deployment nginx --image=nginx:latest --replicas=3

Bereitstellung.apps/nginx erstellt

$ kubectl get deploy --show-labels

NAME BEREIT AKTUELL VERFÜGBARE ALTERSETIKETTEN

nginx 3/3 3 3 7s run=nginx

$ kubectl get pods -l run=nginx -o wide

NAME BEREIT STATUS NEU STARTET ALTER IP NODE NOMINIERTER NODE READINESS GATES

nginx-9ffc7d87b-c6rmj 1/1 Läuft 0 79s 10.32.0.7 ubuntu

nginx-9ffc7d87b-rnfq4 1/1 Läuft 0 79s 10.32.0.5 ubuntu

nginx-9ffc7d87b-xq5r5 1/1 Läuft 0 79s 10.32.0.6 ubuntu

$

Netzwerkrichtlinien

Netzwerkrichtlinien legen fest, wie Pod-Gruppen miteinander und mit anderen Netzwerkendpunkten kommunizieren. Die Netzwerkrichtlinienspezifikation verwendet Labelselektoren, um Pods als Ziel zu verwenden, und definiert Regeln für eingehenden und ausgehenden Datenverkehr für diese Pods. Standardmäßig akzeptieren Pods Datenverkehr aus jeder Quelle. Wenn eine Netzwerkrichtlinie Pods im selben Namespace auswählt, lehnt die Netzwerkrichtlinie alle Verbindungen ab, die von der Netzwerkrichtlinie nicht zugelassen werden. Netzwerkrichtlinien steuern eingehenden (eingehenden), ausgehenden (ausgehenden) oder beide Arten von Datenverkehr zwischen Pods. Ein Container Network Interface (CNI)-Netzwerk-Plugin implementiert Netzwerkrichtlinien, daher ist ein CNI-Plugin erforderlich. Netzwerkrichtlinien funktionieren nicht in Clustern, die kein kompatibles CNI-Plugin verwenden. Die folgenden Selektoren werden von Netzwerkrichtlinien für das Targeting von Pods verwendet:

podSelector – wählt Pods mithilfe von Labels aus (Pods müssen sich im selben Namespace wie die Netzwerkrichtlinie befinden)namespaceSelector – wählt Pods in einem gesamten Namespace für die Eingangsquelle oder das Ausgangsziel auspodSelector und namespaceSelector – wählt Pods aus einem bestimmten NamespaceipBlock – wählt zuzulassende IP-CIDR-Bereiche aus als Eingangsquelle oder Ausgangsziel

Netzwerkrichtlinien können nicht zwingend erstellt werden. Die Kubernetes-Dokumentation enthält mehrere Beispiele. In diesem Beispiel wird der gesamte eingehende Datenverkehr zu Pods im Namespace verweigert:

apiVersion: network.k8s.io/v1

Art: NetworkPolicy

Metadaten:

Name: default-deny-ingress

spezifikation:

PodSelector: {}

Richtlinientypen:

- Eindringen