Every Kubernetes minor release is a mix of the same three things: features graduating from alpha to beta to stable, deprecated APIs finally getting removed, and a batch of scheduler and kubelet improvements nobody notices until they fix a problem you had. 1.30 fits that pattern — nothing in it is a rewrite, but a few of the graduations are worth updating your manifests and RBAC around.
Native sidecar containers reach GA
The most immediately useful change is native sidecar container support graduating to stable. Before this, a "sidecar" was just a convention — a second container in the pod that happened to run alongside your main container, with no special lifecycle guarantees, which caused real problems for logging agents, service mesh proxies, and anything that needed to start before the main container and stay alive until after it exited. The fix is an init container with restartPolicy: Always, which tells the kubelet to treat it as a genuine sidecar: it starts before regular init containers finish blocking, keeps running for the pod's lifetime, and — critically for Jobs — doesn't stop the pod from being marked complete when the main container exits.
apiVersion: v1
kind: Pod
metadata:
name: app-with-sidecar
spec:
initContainers:
- name: log-shipper
image: fluent-bit:2.2
restartPolicy: Always # this makes it a native sidecar
# runs for the pod's whole lifetime, starts before app container
containers:
- name: app
image: myapp:1.4
This matters most for service meshes (Envoy/Istio sidecars no longer racing the main container on startup) and for batch Jobs that ship logs or metrics via a sidecar — the Job can now actually complete instead of hanging on a sidecar that never exits.
ValidatingAdmissionPolicy goes GA
ValidatingAdmissionPolicy lets you write admission control rules in CEL (Common Expression Language) directly as a Kubernetes resource, instead of standing up a webhook server to reject or allow requests. For a large class of policy checks — required labels, disallowed image registries, replica count floors — this removes an entire webhook deployment, its TLS certificates, and its availability requirements from the admission path. It's not a full replacement for OPA/Gatekeeper or Kyverno in every case, but for straightforward rules it's now a stable, in-tree option with one less moving part to keep available.
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
name: require-approved-registry
spec:
failurePolicy: Fail
matchConstraints:
resourceRules:
- apiGroups: [""]
apiVersions: ["v1"]
resources: ["pods"]
operations: ["CREATE"]
validations:
- expression: >
object.spec.containers.all(c,
c.image.startsWith('registry.internal/'))
message: "images must come from the internal registry"
Because ValidatingAdmissionPolicy runs as a compiled CEL expression inside the API server itself, there's no separate webhook pod that can go unavailable and start failing admission requests open or closed. That operational simplification is the main reason to prefer it over a webhook for policies simple enough to express in CEL.
Structured authorization configuration moves toward GA
The API server's authorization chain — which authorizers run, in what order, and how they combine — has historically been configured through a mix of command-line flags with limited expressiveness. The AuthorizationConfiguration structured config file replaces that with a proper config resource supporting multiple authorizer webhooks with explicit chaining and fail-open/fail-closed behavior per authorizer, which matters for clusters layering multiple authorization systems (say, RBAC plus an external policy service) and needing precise control over what happens when one of them is unreachable.
Dynamic Resource Allocation: still alpha, but moving
Dynamic Resource Allocation (DRA) is Kubernetes' answer to requesting specialized hardware — GPUs, FPGAs, anything beyond the simple integer-count model that resources.limits was designed for — through a claims-based API closer to how PersistentVolumeClaims work for storage. It's still alpha in 1.30, with continued refinement to the resource claim and resource class APIs, but it's the direction Kubernetes is heading for AI/ML and specialized-hardware scheduling, and it's worth tracking even before it's something you'd run in production.
Pod scheduling readiness, and the usual kubelet churn
Pod scheduling readiness gates continued maturing in this release, letting external controllers hold a pod out of the scheduler's consideration until a precondition is met — useful for gang-scheduling and custom autoscaling logic that needs to delay scheduling decisions. Beyond the headline items, 1.30 carries the usual load of scheduler plugin refinements, kubelet metrics additions, and deprecated API cleanup that every minor release ships — the kind of change that doesn't get a blog post of its own but shows up in the changelog and occasionally in a `kubectl` deprecation warning you'll want to act on before the next upgrade.
Wrapping up
The two changes worth acting on immediately are native sidecar support, if you run service mesh proxies or logging sidecars in Jobs, and ValidatingAdmissionPolicy, if you're maintaining webhook servers for policy checks simple enough to express in CEL. Structured authorization and DRA are worth watching but don't demand changes yet — DRA in particular is still alpha and will keep shifting before it's something to depend on in production.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.