$ kubectl create deploy Webserver --image nginx

Bereitstellung.apps/webserver erstellt

$ kubectl stellen den Webserver bereitstellen --port 80

Dienst/Webserver ausgesetzt

$ kubectl get svc

NAME TYP CLUSTER-IP EXTERNAL-IP PORT(S) ALTER

Regler ClusterIP 10.96.0.1 443 / TCP 33d

Webserver ClusterIP 10.103.175.171 80/TCP 4s $

Dienste wählen Pods mithilfe von Labels aus und erstellen für jeden Pod eine Endpunktressource. Die Endpunktressource beschreibt alle aktiven Netzwerkziele (Pods), an die der Dienst den Datenverkehr weiterleitet. Jedes Endpunktobjekt in einem Cluster platziert eine zusätzliche iptables-Regel mit der IP eines Ziel-Pods. Eine Alternative zu Endpunkten sind EndpointSlices. EndpointSlices ähneln konzeptionell und funktional Endpunkten, sind jedoch auf bis zu 100 Endpunkte beschränkt, um die Verwaltung im großen Maßstab zu verbessern.

$ kubectl Get Endpoints Webserver

NAME ENDPUNKTE ALTER

Webserver 10.32.0.8:80 43s

$ kubectl get pods -o wide -l app=webserver

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

webserver-d698d7bd6-ktxvn 1/1 Läuft 0 83s 10.32.0.8 ubuntu

$

Ingresses sind eine weitere Ressource, die mit Diensten interagiert. Ingresse binden Dienste an externe Endpunkte, die ein Ingress-Controller im Cluster dann der Außenwelt zugänglich macht. Ingresse verweisen direkt in ihren Manifesten auf Services, wie hier gezeigt:

apiVersion: network.k8s.io/v1beta1

Art: Ingress

Metadaten:

Name: webserver-ingress

Anmerkungen:

spezifikation:

Regeln:

- http:

Pfade:

- Pfad: /testpfad

Backend:

Dienstname: Webserver

ServicePort: 80

Ingress-Controller und Ingress-Ressourcen

Die Ingress-Ressource verwaltet den externen Zugriff auf Kubernetes-Dienste über HTTP- und HTTPS-Routen. Ein Ingress-Controller ist erforderlich, um einen Ingress zu erfüllen. Der Ingress-Controller liest und implementiert die Regeln der Ingress-Ressource. Verwenden Sie den folgenden Befehl, um einen Ingress-Controller in Ihrem Kubernetes-Cluster einzurichten:

$ kubectl apply -f https://rx-m-k8s.s3-us-west-2.amazonaws.com/ingress-drill-setup.yaml

Namespace/nginx-ingress erstellt

serviceaccount/nginx-ingress erstellt

clusterrole.rbac.authorization.k8s.io/nginx-ingress erstellt

service/nginx-ingress erstellt

clusterrolebinding.rbac.authorization.k8s.io/nginx-ingress erstellt

Geheimnis/Standard-Server-Geheimnis erstellt

Bereitstellung.apps/nginx-ingress erstellt

$

Rollen und ClusterRoles werden Benutzern und Prozessen mithilfe von RoleBindings und ClusterRoleBindings zugewiesen. RoleBindings verknüpfen einen Benutzer wie ein Dienstkonto mit einer Rolle. Alle von einer Rolle gewährten Berechtigungen werden über die RoleBinding an den Benutzer weitergegeben. Erstellen Sie die folgende Bereitstellung des Apache-Webservers, die den Container-Port 80 verfügbar macht:

$ kubectl create deploy Apache-Webserver --image=httpd --port=80

deploy.apps/apache-webserver erstellt

$

Erstellen Sie einen NodePort-Dienst, um die Apache-Webserver-Bereitstellung auf dem Knoten-Port 30111 bereitzustellen und Port 80 auf der ClusterIP dem Port 80 auf dem Container zuzuordnen:

$ kubectl create service nodeport apache-webserver --tcp=80:80 --node-port=30111

service/apache-webserver erstellt

$

Erstellen Sie die folgende Ingress-Ressource für den Apache-Webserver-Dienst, der den Datenverkehr zur Host-Domain www.example.com steuert, einen http-Präfixpfad zu / bereitstellt und den gesamten an www.example.com gesendeten Datenverkehr an den Apache-Webserver weiterleitet Dienst auf Port 80:ner:

$ nano apache-webserver-ingress.yaml && apache-webserver-ingress.yaml

apiVersion: network.k8s.io/v1

Art: Ingress

Metadaten:

Name: Apache-Weberver-Ingress

spezifikation:

Regeln:

- Gastgeber: www.example.com

http:

Pfade:

- Pfadtyp: Präfix

Weg: /

Backend:

Service:

Name: Apache-Webserver

Hafen:

Anzahl: 80

$ kubectl apply -f apache-webserver-ingress.yaml

ingress.networking.k8s.io/apached-webserver-ingress erstellt

$

Testen Sie die Ingress-Regeln mit curl --resolve www.example.com:30111: http://www.example.com:30111/ :

$ curl --resolve www.example.com:30111: http://www.example.com:30111

Es klappt!

$

Diensterkennung mit CoreDNS

Kubernetes verwendet CoreDNS für die DNS-basierte Diensterkennung. CoreDNS ist flexibel und Änderungen können in der ConfigMap für CoreDNS vorgenommen werden. Jedem Service wird ein DNS-Name in der Syntax zugewiesen: . .svc.cluster.local . Pods wird ein DNS-A-Eintrag in der folgenden Syntax zugewiesen: . .pod.cluster.lokal . Bestätigen wir den DNS-Eintrag eines Dienstes mit einem Nameserver-Lookup mit nslookup aus einem Pod heraus. Erstellen Sie einen ClusterIP-Dienst, um seinen DNS-Eintrag zu testen und seine ClusterIP abzurufen:

$ kubectl create service clusterip my-service --tcp=8080:8080

service/my-service erstellt

$ kubectl Dienst abrufen

NAME TYP CLUSTER-IP EXTERNAL-IP PORT(S) ALTER

Regler ClusterIP 10.96.0.1 443 / TCP 10d

my-service ClusterIP 10.109.165.220 8080/TCP 5m31s

$

Führen Sie einen Pod mit dem Busybox-Image aus und führen Sie ein nslookup auf der IP des Dienstes aus:

$ kubectl run busybox --image=busybox -it -- /bin/sh

Wenn keine Eingabeaufforderung angezeigt wird, drücken Sie die Eingabetaste.

/ # nslookup 10.109.165.220

Server: 10.96.0.10

Adresse: 10.96.0.10:53

220.165.109.10.in-addr.arpa name = my-service.default.svc.cluster.local

/ # Ausfahrt

$

Verwalten von TLS-Zertifikaten für Clusterkomponenten

Alle Clusterkomponenten, die mit dem API-Server kommunizieren müssen, müssen sich mit einem Zertifikat authentifizieren, das vom CA-Clusterzertifikat signiert ist. Jedes CA-Zertifikat muss den Benutzer als Antragstellernamen und eine Gruppe als Organisation enthalten. Das CA-Zertifikat, das alle Komponentenzertifikate eines kubeadm-Clusters signiert, finden Sie unter /etc/kubernetes/pki .Kubeadm clusters verteilt automatisch von der Cluster-CA signierte Zertifikate an alle Komponenten der Steuerungsebene beim Bootstrap. Die Clusterzertifikate werden bis zu 2 Stunden nach dem Bootstrap temporär als Secrets im Cluster gespeichert. Um die Clusterzertifikate erneut hochzuladen, um einen neuen Masterknoten zu erstellen, kann kubeadm die upload-certs-Phase erneut ausführen:

$ sudo kubeadm Initphase upload-certs --upload-certs

[upload-certs] Speichern der Zertifikate im Secret "kubeadm-certs" im "kube-system" Namespace

[upload-certs] Zertifikatschlüssel verwenden:

7d42b0fbecf1f12597591513e6b1e1009fd46bd617f33679c050abe30310b006

$

Erstellen Sie dann mit dem Zertifikatsschlüssel einen Join-Befehl auf dem Master-Knoten, um einen Join-Befehl für zusätzliche Knoten der Steuerungsebene zu generieren:

$ sudo kubeadm token create --print-join-command --certificate-key 7d42b0fbecf1f12597591513e6b1e1009fd46bd617f33679c050abe30310b006

kubeadm Join 192.168.229.134:6443 \

--token yrl04z.14yaclt7m8hljjpw \

--discovery-token-ca-cert-hash sha256:50fecf38c50b760131e7ff3ae6c80d89aa01243e9c6c1d634077eedeb4940929 \

--control-plane \

--Zertifikatsschlüssel 7d42b0fbecf1f12597591513e6b1e1009fd46bd617f33679c050abe30310b006

$

Dieser Join-Befehl weist kubeadm an, dass die neuen Worker-Knoten die Zertifikate herunterladen. Für Worker-Knoten ist der Prozess der gleiche; Die Verwendung von kubeadm Join weist das Kubelet des Zielknotens an, einen TLS-Bootstrap durchzuführen, um automatisch ein neues Zertifikat für den Cluster anzufordern.

Sicher mit Bildern arbeiten

Die Bildsicherheit wird auf unterschiedliche Weise gehandhabt. Eine Möglichkeit besteht darin, den Zugriff auf private Repositorys mithilfe von imagePullSecret zu steuern, das die erforderlichen Anmeldeinformationen für den Zugriff auf ein Repository enthält. Ein Image-Pull-Secret basiert auf Dockers config.json, das nach der Verwendung von docker login erstellt wird. Sie können ein imagePullSecret zwingend erstellen, indem Sie Ihre Anmeldeinformationen angeben an:

$ kubectl create secret docker-registry myregistry \

--docker-server=https://my.image.registry \

--docker-username=my-user --docker-password=my-pw \

--docker-email=myacc@image.registry

$

Container-Images, die aus der privaten Registrierung my.image.registry abgerufen werden müssen, rufen diese Anmeldeinformationen mithilfe des imagePullSecret-Schlüssels in ihrer Spezifikation ab:

apiVersion: v1

Art: Pod

Metadaten:

CreationTimestamp: null

Etiketten:

Ausführen: fluentbitcommandpod

Name: fluentbitcommandpod

spezifikation:

Behälter:

- Befehl:

- /fließend-bit/bin/fließend-bit

- -ich

- meme

- -Ö

- stdout

Bild: myregistry/my-fluent-bit

Name: fluentbitcommandpod

imagePullSecrets:

- Name: myregistry

Auf Container-Images kann mit dem sha256-Hash des Images verwiesen werden. Dadurch wird die Container-Laufzeit angewiesen, jederzeit eine genaue Version des Images zu verwenden. Hier ist ein Beispiel für die Aktualisierung einer Kubernetes-Bereitstellung mit einem bestimmten Image-SHA:

kubectl set image deploy nginx-prod nginx=myregistry/nginx@sha256:2397b05f8a7df1cf48d51314a5e2c249f1e83a4211cd78ceb58e8372bf087f07 --record=true

Sicherheitskontexte

Sicherheitskontexte definieren Berechtigungs- und Zugriffssteuerungseinstellungen für einen Pod oder Container. Ein securityContext-Array in einer Containerspezifikation unter einem Pod ermöglicht eine granulare Kontrolle über den Benutzer oder die Gruppe, mit der ein Container ausgeführt wird, die diesen Benutzern gewährten Berechtigungen und andere Optionen wie Dateisystemzugriff oder die Möglichkeit, als Root ausgeführt zu werden. Um einen securityContext anzugeben, fügen Sie den securityContext-Schlüssel in ein Pod- oder Container-Manifest ein:

apiVersion: v1

Art: Pod

Metadaten:

Name: cka-security-context

spezifikation:

Behälter:

- Name: sec-ctx-demo

Bild: Busybox

Befehl: [ "sh", "-c", "sleep 1h" ]

SicherheitKontext:

allowPrivilegeEskalation: false

SicherheitKontext:

runAsUser: 1000

Sicherheitskontexte ermöglichen die Anpassung der Pod- und Container-Sicherheitsposition und -fähigkeit. Der Pod in der obigen Spezifikation wird beispielsweise als Nicht-Root-Benutzer ausgeführt, und der Container darf keine Rechteausweitung (Mechanismen wie sudo) verwenden.

Sicherer persistenter Schlüsselwertspeicher

Der persistente Schlüsselwertspeicher in Kubernetes ist etcd. Nur der API-Server hat Zugriff auf die in einem Cluster ausgeführte etcd-Instanz. Der Zugriff auf etcd ist auf Prinzipale beschränkt, die ein von der etcd-CA signiertes Zertifikat besitzen. In kubeadm-Clustern befinden sich die etcd-Zertifikate unter /etc/kubernetes/pki/etcd Ein Client muss das CA-Zertifikat sowie einen Client-Schlüssel und ein Zertifikat bereitstellen, um die etcd-Instanz von außerhalb des Kubernetes-Clusters zu kontaktieren. Eine todsichere Methode besteht darin, den Zugriff des API-Servers zu imitieren:

$ ps -ef | Griff "Würfel-Apiserver"

root 3288 3219 1. Februar 25? 00:23:11 apiserver sein

…

--etcd-cafile = /etc/kubernetes/pki/etcd/ca.crt

--etcd-certfile = /etc/kubernetes/pki/apiserver-etcd-client.crt

--etcd-keyfile = /etc/kubernetes/pki/apiserver-etcd-client.key

--etcd-servers=https://127.0.0.1:2379

...

$

Etcd verwendet ein eigenes CA-Zertifikat; Alle Clients, die eine Verbindung zu etcd herstellen müssen, müssen über ein von dieser CA signiertes Zertifikat verfügen, um mit etcd zu kommunizieren. Durch die Bereitstellung dieser Zertifikate können Sie einen externen Client wie etcdctl verwenden, um mit dem etcd-Cluster zu interagieren:

$ sudo etcdctl-Mitgliederliste \

--endpoints 127.0.0.1:2379 \

--cacert /etc/kubernetes/pki/etcd/ca.crt \

--cert /etc/kubernetes/pki/apiserver-etcd-client.crt \

--key /etc/kubernetes/pki/apiserver-etcd-client.key

f093f1e641b93448, gestartet, Ubuntu, https://192.168.229.134:2380, https://192.168.229.134:2379, false

$

Übungsübung

Führen Sie den folgenden Befehl aus: kubectl run --generator run-pod/v1 --image nginx nginx-drill Erstellen Sie einen NodePort-Dienst, mit dem Sie eine curl-Anfrage an den nginx-drill-Pod an Port 80 über die IP-Adresse Ihres Computers senden können.

Übungsübung: Antwort

$ Führen Sie zuerst den Befehl aus, um den Pod zu erstellen:

$ kubectl run nginx-drill --image nginx

pod/nginx-drill erstellt

$

Verwenden Sie dann kubectl Expose mit dem NodePort-Flag --type, um zwingend einen nodePort-Dienst zu erstellen. Stellen Sie sicher, dass Sie den Pod verfügbar machen, da dieser durch den anfänglichen Ausführungsbefehl erstellt wurde:

$ kubectl Expose --type NodePort --port 80 pod nginx-drill

service/nginx-drill ausgesetzt

$

Nachdem Sie den Pod verfügbar gemacht haben, listen Sie die Dienste auf. Sie werden sehen, dass der nginx-drill NodePort Service Port 80 einem Port innerhalb des 30000-Bereichs zuordnet:

$ kubectl get svc

NAME TYP CLUSTER-IP EXTERNAL-IP PORT(S) ALTER

Regler ClusterIP 10.96.0.1 443 / TCP 33d

nginx-drill NodePort 10.101.103.201 80:32402/TCP 10s

$

Versuchen Sie schließlich, eine curl-Anfrage an den nginx-Pod zu senden, indem Sie Ihre Computer-IP-Adresse verwenden:

$ ip als | Kopf

1: siehe: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1

Link/Loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 Scope-Host-Lo

gültig_lft für immer bevorzugt_lft für immer

inet6 ::1/128 Scope-Host

gültig_lft für immer bevorzugt_lft für immer

2: ens33: mtu 1500 qdisc pfifo_fast state UP-Gruppe Standard qlen 1000

Link / Äther 00: 0c: 29: b3: d9: 13 brd ff: ff: ff: ff: ff: ff

inet 192.168.229.134/24 brd 192.168.229.255 Geltungsbereich global ens33

gültig_lft für immer bevorzugt_lft für immer

$ curl 192.168.229.134:32402

Karosserie {

Breite: 35em;

Rand: 0 automatisch;

Schriftfamilie: Tahoma, Verdana, Arial, Sans-Serif;

}

Willkommen bei nginx!

Wenn Sie diese Seite sehen, ist der nginx-Webserver erfolgreich installiert und

Arbeiten. Eine weitere Konfiguration ist erforderlich.

Online-Dokumentation und Support finden Sie unter

nginx.org.

Kommerzieller Support ist verfügbar unter

nginx.com.

Vielen Dank, dass Sie nginx verwenden.

$

Erstellen Sie als weitere Übung einen ClusterIP-Dienst namens other-svc mit kubectl create und verknüpfen Sie ihn mit einem Label-Selektor mit der oben erstellten nginx-drill-Bereitstellung.