Versionen und Standardwerte

Kubernetes

Der Cluster läuft auf Kubernetes 1.34. Alles aus der API dieser Version steht dir zur Verfügung, im Rahmen dessen, was dein Namespace anlegen darf, siehe Berechtigungen und Richtlinien.

API-Versionen, die du schreibst

Das hier sind die Versionen, die du schreiben solltest. Manche älteren Versionen derselben Kinds werden noch ausgeliefert und still umgewandelt. Ein veraltetes Manifest geht also unter Umständen durch und verhält sich dann anders, als seine Dokumentation beschreibt. Nimm die Werte unten.

Was du anlegst	apiVersion
Deployments, StatefulSets	apps/v1
Jobs, CronJobs	batch/v1
Services, ConfigMaps, Secrets, PVCs	v1
Horizontal Pod Autoscaler	autoscaling/v2
Vertical Pod Autoscaler	autoscaling.k8s.io/v1
Pod Disruption Budgets	policy/v1
HTTPRoutes, GRPCRoutes	gateway.networking.k8s.io/v1
ClientSettingsPolicies	gateway.nginx.org/v1alpha1
PostgreSQL-Cluster und -Backups	postgresql.cnpg.io/v1
MariaDB und zugehörige Ressourcen	k8s.mariadb.com/v1alpha1
Dragonfly	dragonflydb.io/v1alpha1
KEDA ScaledObjects und ScaledJobs	keda.sh/v1alpha1

Die Gateway API liegt in v1.6.1, Standard-Channel vor. Funktionen aus dem Experimental-Channel sind nicht installiert. Was upstream als experimentell dokumentiert ist, wird hier also nicht erkannt.

Was dein Namespace für dich einsetzt

Drei Dinge werden auf deine Workloads angewendet, ob du sie angibst oder nicht, und alle drei überraschen regelmäßig.

Requests und Limits, wenn du keine angibst

Ein Container ohne resources bekommt das hier:

	CPU	Speicher
Request	50m	64Mi
Limit	200m	256Mi

Abgerechnet wird der Request in jedem Fall. Resources wegzulassen macht einen Pod also nicht kostenlos, es heißt nur, dass jemand anderes seine Größe gewählt hat. Das Limit ist außerdem niedrig genug, dass eine echte Anwendung gedrosselt oder beendet wird. Setz eigene Werte, siehe Abrechnung und Kontingente.

Eine Sandbox-Runtime

Deine Pods laufen sandboxed. Das wird automatisch gesetzt und lässt sich nicht abschalten. Für deine eigenen Workloads gibt es dabei nichts anders zu machen.

Sichtbar wird es an genau einer Stelle: Verwaltete PostgreSQL-Pods sind davon ausgenommen, und weil eine Shell nur in sandboxed Pods erlaubt ist, kommst du dort nicht per kubectl exec hinein. Siehe Datenbanken.

Eine Scheduling-Priorität

Pods bekommen die PriorityClass des Namespace. Eine andere zu setzen wird abgelehnt.

Pod Security

Namespaces erzwingen den Pod-Security-Standard baseline und warnen gegen restricted.

Praktisch heißt das: Ein Manifest ohne securityContext geht durch, gibt aber Warnungen aus:

Warning: would violate PodSecurity "restricted:latest":
allowPrivilegeEscalation != false, unrestricted capabilities,
runAsNonRoot != true, seccompProfile

Das sind Warnungen, keine Ablehnungen. Die vier Felder zu setzen bringt sie zum Schweigen und ist ohnehin sinnvoll:

securityContext:
  allowPrivilegeEscalation: false
  runAsNonRoot: true
  seccompProfile:
    type: RuntimeDefault
  capabilities:
    drop: ["ALL"]

runAsNonRoot: true braucht ein Image, das als Nicht-Root läuft. Wenn deins das nicht tut, lass die Zeile weg und behalte die anderen drei.

Wie es weitergeht

• Berechtigungen und Richtlinien, was du anlegen darfst
• Erstes Deployment für ein Manifest, in dem all das richtig steht