Einführung
Pods sind flüchtig. Ein Deployment kann Pods während eines Rollouts, Neustarts oder bei der Skalierung ersetzen, daher sollten sich Clients nicht direkt mit den IP-Adressen einzelner Pods verbinden. Ein Service bietet Clients einen stabilen Namen sowie eine virtuelle IP-Adresse und verwendet Labels, um den Datenverkehr an die aktuell passenden Pods weiterzuleiten.
In diesem Lab erstellen Sie ein kleines Web-Deployment, machen es über einen ClusterIP-Service verfügbar, untersuchen, wie der Service seine Backend-Pods auswählt, testen den Service von einem Client-Pod aus und skalieren das Deployment, um zu sehen, wie sich die Service-Endpunkte aktualisieren.
Ein Web-Deployment erstellen
In diesem Schritt bereiten Sie einen Namespace vor und erstellen ein Deployment, das später über einen Service verfügbar gemacht werden kann.
Beginnen Sie in /home/labex/project:
mkdir -p /home/labex/project
cd /home/labex/project
Überprüfen Sie, ob der Kubernetes API-Server erreichbar ist. Falls die VM gerade erst gestartet wurde und der Node noch nicht bereit ist, warten Sie einige Sekunden und führen Sie den Befehl erneut aus.
kubectl get nodes --request-timeout=5s
Die erwartete Ausgabe sieht in etwa so aus:
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35...
Warten Sie, bis der Cluster-Networking-Pod bereit (Ready) ist. Da dieses Lab Datenverkehr über einen Service zwischen Pods sendet, muss das Cluster-Netzwerk funktionsfähig sein, bevor Sie den Zugriff testen.
kubectl wait --namespace kube-system --for=condition=Ready pod -l k8s-app=calico-node --timeout=120s
Erwartete Ausgabe:
pod/calico-node-... condition met
Erstellen Sie einen Namespace namens ckad-prep-service und legen Sie diesen als aktuellen Namespace fest:
kubectl create namespace ckad-prep-service
kubectl config set-context --current --namespace=ckad-prep-service
Erstellen Sie ein Deployment namens web-front mit einem NGINX-Pod. Das Flag --port=80 speichert den Container-Port in der Pod-Vorlage. Es erstellt jedoch nicht automatisch einen Service.
kubectl create deployment web-front --image=nginx:1.25 --port=80
Warten Sie, bis das Deployment verfügbar ist, und untersuchen Sie dann das Pod-Label. Das Label app=web-front ist wichtig, da der Service es verwenden wird, um die Backend-Pods zu finden.
kubectl rollout status deployment/web-front --timeout=120s
kubectl get pods -l app=web-front --show-labels
Die erwartete Ausgabe enthält:
deployment "web-front" successfully rolled out
NAME READY STATUS RESTARTS AGE LABELS
web-front-... 1/1 Running 0 ... app=web-front,...
Das Deployment mit einem ClusterIP-Service verfügbar machen
In diesem Schritt erstellen Sie einen Service für das Deployment und untersuchen die Felder, die den Service mit den Pods verbinden.
Verwenden Sie kubectl expose deployment, um einen ClusterIP-Service zu erstellen. Der Service-Port ist 80, und --target-port=80 weist den Service an, den Datenverkehr an Port 80 der passenden Pods weiterzuleiten.
kubectl expose deployment web-front --name=web-front --port=80 --target-port=80
Erwartete Ausgabe:
service/web-front exposed
Untersuchen Sie den Service:
kubectl get service web-front
Die erwartete Ausgabe enthält:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
web-front ClusterIP ... <none> 80/TCP ...
Untersuchen Sie nun den Service-Selektor und das Port-Mapping. Der Selektor bestimmt, wie der Service Pods findet; das Port-Mapping legt fest, wie der Client-Datenverkehr den Container erreicht.
kubectl get service web-front -o jsonpath='{.spec.selector.app}{" "}{.spec.ports[0].port}{":"}{.spec.ports[0].targetPort}{"\n"}'
Erwartete Ausgabe:
web-front 80:80
Kubernetes speichert die ausgewählten Backend-Adressen in EndpointSlices. Listen Sie das für diesen Service erstellte EndpointSlice auf:
kubectl get endpointslice -l kubernetes.io/service-name=web-front
Die erwartete Ausgabe enthält:
NAME ADDRESSTYPE PORTS ENDPOINTS AGE
web-front-... IPv4 80 ... ...
Den Service von innerhalb des Clusters testen
In diesem Schritt erstellen Sie einen temporären Client-Pod und senden eine HTTP-Anfrage an den Service. Ein ClusterIP-Service ist für den Zugriff innerhalb des Clusters vorgesehen, daher ist das Testen von einem anderen Pod aus der direkteste Weg, um dies zu verifizieren.
Erstellen Sie einen Client-Pod, der dauerhaft läuft:
kubectl run service-client --image=busybox:1.36 --restart=Never --command -- sleep 3600
Warten Sie, bis der Client-Pod bereit ist:
kubectl wait --for=condition=Ready pod/service-client --timeout=120s
Erwartete Ausgabe:
pod/service-client condition met
Verwenden Sie wget innerhalb des Client-Pods, um http://web-front abzufragen. Der Name web-front wird innerhalb des Namespaces in die Service-IP aufgelöst.
kubectl exec service-client -- wget -qO- http://web-front | head -n 5
Die erwartete Ausgabe zeigt den Anfang der Standard-NGINX-Seite:
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
Dies beweist, dass der Client den stabilen Service-Namen erreicht hat und der Service den Datenverkehr an den aktuellen Backend-Pod weitergeleitet hat.
Das Backend skalieren und Endpunkte erneut prüfen
In diesem Schritt skalieren Sie das Deployment und bestätigen, dass der Service dieselbe stabile Schnittstelle beibehält, während sich seine Backend-Endpunkte ändern.
Skalieren Sie das Deployment auf zwei Replikate:
kubectl scale deployment web-front --replicas=2
kubectl rollout status deployment/web-front --timeout=120s
Die erwartete Ausgabe enthält:
deployment.apps/web-front scaled
deployment "web-front" successfully rolled out
Listen Sie die Pods auf. Es sollten nun zwei laufende Backend-Pods mit demselben app=web-front Label vorhanden sein.
kubectl get pods -l app=web-front
Die erwartete Ausgabe enthält zwei Pods:
NAME READY STATUS RESTARTS AGE
web-front-... 1/1 Running 0 ...
web-front-... 1/1 Running 0 ...
Zählen Sie die Endpunkte hinter dem Service. Der Befehl gibt für jede Endpunkt-Adresse eine Zeile aus und zählt anschließend die Zeilen.
kubectl get endpointslice -l kubernetes.io/service-name=web-front -o jsonpath='{range .items[*].endpoints[*]}{.addresses[0]}{"\n"}{end}' | wc -l
Erwartete Ausgabe:
2
Fragen Sie den Service erneut vom selben Client-Pod aus ab:
kubectl exec service-client -- wget -qO- http://web-front | grep '<title>Welcome to nginx'
Erwartete Ausgabe:
<title>Welcome to nginx!</title>
Zusammenfassung
Sie haben ein Deployment mit einem ClusterIP-Service verfügbar gemacht und den vollständigen Zugriffspfad innerhalb des Clusters verifiziert. Sie haben ein Backend-Deployment erstellt, einen Service mit Selektor und Port-Mapping konfiguriert, das für den Service generierte EndpointSlice untersucht, den Zugriff von einem Client-Pod aus getestet, das Deployment skaliert und bestätigt, dass der Service weiterhin Datenverkehr an die aktualisierte Backend-Gruppe weiterleitet.
