Versions and defaults
Kubernetes
The cluster runs Kubernetes 1.34. Anything in that version's API is available to you, subject to what your namespace is allowed to create, see Permissions and policies.
API versions to write
These are the versions to write. Some older versions of the same kinds are still served and get converted silently, so an out-of-date manifest may apply and then behave in ways its documentation does not describe. Prefer the values below.
| What you are creating | apiVersion |
|---|---|
| Deployments, StatefulSets | apps/v1 |
| Jobs, CronJobs | batch/v1 |
| Services, ConfigMaps, Secrets, PVCs | v1 |
| Horizontal pod autoscalers | autoscaling/v2 |
| Vertical pod autoscalers | autoscaling.k8s.io/v1 |
| Pod disruption budgets | policy/v1 |
| HTTPRoutes, GRPCRoutes | gateway.networking.k8s.io/v1 |
| Client settings policies | gateway.nginx.org/v1alpha1 |
| PostgreSQL clusters and backups | postgresql.cnpg.io/v1 |
| MariaDB and its resources | k8s.mariadb.com/v1alpha1 |
| Dragonfly | dragonflydb.io/v1alpha1 |
| KEDA scaled objects and jobs | keda.sh/v1alpha1 |
Gateway API is at v1.6.1, standard channel. Experimental-channel features are not installed, so anything documented upstream as experimental will not be recognised here.
What your namespace fills in for you
Three things are applied to your workloads whether or not you ask, and all three surprise people.
Requests and limits, if you declare none
A container that sets no resources gets these:
| CPU | Memory | |
|---|---|---|
| Request | 50m | 64Mi |
| Limit | 200m | 256Mi |
You are billed for the request either way, so omitting resources does not make a pod free, it means someone else chose its size. The limit is also low enough that a real application will be throttled or killed by it. Set your own, see Billing and quotas.
A sandboxed runtime
Your pods run sandboxed. It is applied automatically and cannot be turned off. For your own workloads there is nothing to do differently.
It becomes visible in exactly one place: managed PostgreSQL pods are exempt from it, and because a shell is only permitted into sandboxed pods, you cannot kubectl exec into one. See Databases.
A scheduling priority
Pods get the namespace's priority class. Setting a different one is rejected.
Pod security
Namespaces enforce the baseline pod security standard and warn against restricted.
The practical effect is that a manifest without a securityContext still applies, but prints warnings:
Warning: would violate PodSecurity "restricted:latest":
allowPrivilegeEscalation != false, unrestricted capabilities,
runAsNonRoot != true, seccompProfileThose are warnings, not rejections. Setting the four fields silences them and is worth doing anyway:
securityContext:
allowPrivilegeEscalation: false
runAsNonRoot: true
seccompProfile:
type: RuntimeDefault
capabilities:
drop: ["ALL"]runAsNonRoot: true requires an image that runs as a non-root user. If yours does not, leave that line out and keep the other three.
What's next
- Permissions and policies for what you may create
- Your first deployment for a manifest that has all of this right