In diesem Artikel erfahren Sie alles über Kubernetes-Ressourcen.
Dieser Dienst befindet sich derzeit im Early Access. Kontaktieren Sie uns, um Zugang zu beantragen.
Deployment
Ein Deployment in Kubernetes ist eine Ressource, die eine Reihe identischer Pods verwaltet und sicherstellt, dass die gewünschte Anzahl von Replikaten ausgeführt wird, und die Aktualisierungen, Rollbacks und Skalierungen ermöglicht.
Beispiel: Bereitstellen einer Webanwendung mit drei Replikaten und automatisches Ausrollen von Updates, wenn das Container-Image aktualisiert wird.
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app-deployment
spec:
replicas: 3
selector:
matchLabels:
app: web-app
template:
metadata:
labels:
app: web-app
spec:
containers:
- name: web-app
image: web-app:1.0
ports:
- containerPort: 80
Pods
Ein Pod in Kubernetes stellt das kleinste und einfachste Kubernetes-Objekt dar, es ist eine einzelne Instanz einer laufenden Anwendung.
Beispiel: Ausführen eines einzelnen Webservers in einem Pod.
apiVersion: v1
kind: Pod
metadata:
name: my-web-pod
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
Container
Ein Container ist eine Software und ihre Abhängigkeiten, die in einer virtuellen Umgebung verpackt sind und ausgeführt werden können. Container werden innerhalb eines Pods in Kubernetes verwaltet, siehe Teile des obigen Beispiels:
Beispiel: Dies ist das neueste nginx-Image, das innerhalb eines Pods ausgeführt wird.
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
Ressourcenanforderungen und -grenzen
Ressourcenanforderungen und -limits definieren die Mindest- und Höchstmengen an CPU und Speicher, die ein Container verbrauchen kann. Ressourcenlimits verhindern, dass Knoten überlastet werden, während Ressourcenanforderungen sicherstellen, dass ein Container nur auf einem Knoten mit ausreichenden Ressourcen eingeplant wird.
Keep in mind that containers will not start if no nodes with the requested resources are available.
ReplicaSets
ReplicaSets stellt sicher, dass eine bestimmte Anzahl von Pod-Replikaten zu jeder Zeit ausgeführt wird.
Beispiel: Erstellen eines ReplicaSets, das 5 Replikate einer Webanwendung ausführt.
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: webapp-replicaset
spec:
replicas: 5
selector:
matchLabels:
app: web-app
template:
metadata:
labels:
app: web-app
spec:
containers:
- name: web-app
image: web-app:1.0
Horizonal Pod Autoscaling
Die horizontale Pod-Autoskalierung ermöglicht die Skalierung von Pods auf der Grundlage der Ressourcennutzung, z. B. der CPU- oder Speichernutzung.
Beispiel: Konfigurieren der automatischen Skalierung für eine Webanwendung auf der Grundlage der CPU-Auslastung.
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: webapp-hpa
spec:
maxReplicas: 10
metrics:
- resource:
name: cpu
target:
averageUtilization: 50
type: Utilization
type: Resource
minReplicas: 2
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: web-app-deployment
Persistent Volume
Ein persistentes Volume ist eine von einem Administrator bereitgestellte Speicherressource, die von Pods zum Persistieren von Daten verwendet werden kann. In den meisten Fällen wird das Volume automatisch von einem CSI-Treiber bereitgestellt, so dass eine manuelle Volume-Erstellung nicht erforderlich ist.
Beispiel: Definieren eines PV, das von einem Pod beansprucht werden kann.
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-storage
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/mnt/data"
PersistentVolumeClaim
Ein PersistentVolumeClaim ist eine Speicheranforderung, die an ein PersistentVolume gebunden ist. Er wird in erster Linie für die dynamische Bereitstellung von Speichervolumen verwendet.
Beispiel: Anforderung eines 50GB-Volumes für einen Datenbank-Pod.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: database-pv-claim
spec:
storageClassName: xelon-persistent-storage
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 50Gi
StorageClass
StorageClasses definieren verschiedene Arten von Speicher, die dynamisch bereitgestellt werden können.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: xelon-persistent-storage
provisioner: csi.xelon.ch
reclaimPolicy: Delete
volumeBindingMode: Immediate
Networking
Dieser Abschnitt behandelt die grundlegende Kommunikation zwischen Kubernetes-Komponenten, einschliesslich Pods, Diensten und externen Entitäten.
Dienste
Es gibt verschiedene Arten von Diensten, die jeweils eigene Merkmale aufweisen. Alle Diensttypen haben jedoch gemeinsame Merkmale, darunter eine stabile IP-Adresse und einen DNS-Namen für eine ausgewählte Gruppe von Pods.
ClusterIP
ClusterIP ist der gängigste und standardmässige Diensttyp. Er stellt einen Dienst innerhalb des Clusters zur Verfügung und bietet eine IP-Adresse, auf die nur von innerhalb des Clusters zugegriffen werden kann.
apiVersion: v1
kind: Service
metadata:
name: web-app-svc-ci
spec:
selector:
app: web-app
ports:
- protocol: TCP
port: 80
targetPort: 80
NodePort
Der NodePort stellt Ihren Dienst auf jedem Knoten an einem Port über 30000 zur Verfügung. Er ist nützlich, wenn Sie Dienste direkt in Ihrem Knotennetzwerk bereitstellen möchten. Dieser Diensttyp wird in der Regel verwendet, wenn eine Firewall mit Lastausgleichsfunktionen vor Ihrem Cluster steht.
apiVersion: v1
kind: Service
metadata:
name: web-app-svc-np
spec:
selector:
app: web-app
ports:
- port: 80
targetPort: 80
protocol: TCP
type: NodePort
LoadBalancer
Der Diensttyp LoadBalancer ist ein „automatischer“ NodePort. Wenn Sie einen Dienst dieses Typs erstellen, fordert er automatisch einen NodePort an und richtet Weiterleitungsregeln für den LoadBalancer ein. Diese Anfragen werden von der Komponente Cloud-controller-manager bearbeitet. Sie wird häufig verwendet, um Dienste dem World Wide Web zur Verfügung zu stellen.
apiVersion: v1
kind: Service
metadata:
name: web-app-svc-lb
spec:
selector:
app: web-app
ports:
- port: 8000
targetPort: 80
protocol: TCP
type: LoadBalancer
L7 Service Control
Layer 7 Service Control ermöglicht die Verwaltung des Datenverkehrsroutings auf der Anwendungsebene und ermöglicht Funktionen wie URL-basiertes Routing.
Ingress Controller
Der Ingress Controller ist ein veralteter Ansatz (obwohl er immer noch weit verbreitet ist), um den Datenverkehr zu Ihrer Anwendung zu leiten. Der Ingress Controller selbst ist ein Webserver, der mit Hilfe der Ingress-Ressource dynamisch konfiguriert wird.
Beispiel:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: webapp-ingress
spec:
ingressClassName: cilium
rules:
- host: fqdn.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: web-app-svc-ci
port:
number: 80
- path: /api
pathType: Prefix
backend:
service:
name: web-app-backend-svc-ci
port:
number: 80
GatewayAPI
Die GatewayAPI ist der Nachfolger der Ingress-Ressource. Sie bietet einen stärker standardisierten Ansatz für die Verwaltung von Funktionen wie TLS, gRPC und Sonderfunktionen, die zuvor über Anmerkungen gehandhabt wurden. Letztlich erstellen beide Lösungen eine Konfigurationsdatei für einen Reverse Proxy.
Beispiel Gateway:
apiVersion: networking.k8s.io/v1alpha1
kind: Gateway
metadata:
name: webapp-gateway
spec:
gatewayClassName: cilium
listeners:
- protocol: HTTP
port: 80
routes:
kind: HTTPRoute
namespaces:
from: Selector
selector:
matchLabels:
app: web-app
Beispiel HTTPRoute:
apiVersion: networking.k8s.io/v1alpha1
kind: HTTPRoute
metadata:
name: webapp-route
spec:
parentRefs:
- name: webapp-gateway
rules:
- matches:
- path:
type: Prefix
value: /
forwardTo:
- serviceName: web-app-svc-ci
port: 80
- matches:
- path:
type: Prefix
value: /api
forwardTo:
- serviceName: web-app-backend-svc-ci
port: 80
Certificate Manager
Certificate Manager automatisiert die Ausstellung und Erneuerung von TLS-Zertifikaten und implementiert die Funktionalität von Certbot (Let's Encrypt) in Kubernetes. Für weitere Informationen besuchen Sie die offizielle Website: cert-manager
Kubernetes DNS
Kubernetes DNS, häufig von CoreDNS implementiert, bietet eine automatische DNS-Auflösung innerhalb des Clusters für alle Pods und Dienste. Es ist von unschätzbarem Wert für den Aufbau skalierbarer Anwendungen, da es den DNS-Lastausgleich und die Zuweisungen übernimmt. In den meisten Fällen müssen Sie innerhalb des Kubernetes-Clusters keine IP-Adressen verwenden, da DNS-Namen immer für die Adressierung verfügbar sind.
Beispiele:
Kommunikation mit demselben Namensraum:
Wenn sich ein Backend und eine Datenbank im selben Namespace befinden, können Sie die Datenbank direkt über den Dienstnamen der Datenbank erreichen.
mysql -h <servicename> -u admin -p
# Exmaple with dns records
mysql -h database -u admin -p
Kommunikation zwischen Namespaces:
Wenn Sie ein Backend und eine Datenbank in zwei getrennten Namensräumen haben, können Sie die Datenbank über ihren relativen Domänennamen erreichen, der aus besteht:
mysql -h <servicename>.<namespace> -u admin -p
# Exmaple with dns records
mysql -h database.prod -u admin -p
Kommunikation mit voll qualifizierten Domänennamen:
Wenn Sie mehrere Cluster mit weitergeleiteten DNS-Zonen haben, können Sie diese über ihre FQDNs erreichen. Wenn Sie es vorziehen, generell FQDNs zu verwenden, können Sie alternativ auch mit den vollständigen Domänennamen auf die Dienste zugreifen. Auf diese Weise können Sie Dienste in verschiedenen Clustern und Netzwerken mit einer standardisierten Namenskonvention ansprechen
mysql mysql -h <servicename>.<namespace>.svc.<cluster-domain> -u admin -p
# Exmaple with dns records
mysql -h database.prod.svc.cluster.local -u admin -p
Namespaces
In Kubernetes ist ein Namespace eine logische Partitionierung von Ressourcen innerhalb eines Clusters. Er hilft bei der Organisation und Isolierung von Ressourcen wie Pods, Diensten und Bereitstellungen und erleichtert so deren Verwaltung und Kontrolle.
Standardmässig trennen Namespaces keine Netzwerke, d. h. Container in verschiedenen Namespaces können weiterhin miteinander kommunizieren.