Most Kubernetes content is written for the people who run clusters. But far more developers simply deploy onto a cluster someone else operates and for them, ninety percent of Kubernetes is noise. You do not need to understand etcd internals to ship a reliable service. You need to get a handful of things right: resource requests, health probes, configuration, and how traffic reaches your app. This guide focuses on exactly that slice for the modern Kubernetes of the 1.36 era what an app developer actually has to know, and the durable concepts behind the version numbers.
The developer-facing essentials
- Resource requests and limits the setting most apps get wrong
- Liveness, readiness, and startup probes done correctly
- Configuration and secrets without baking them into images
- The Gateway API as the modern way traffic reaches your service
- Why "what changed in 1.36" matters less than getting the basics right
Info
You do not need to be an operator
If a platform team runs your cluster, your job is to package your app as a good Kubernetes citizen: declare what it needs, tell the cluster when it is healthy, externalise its config, and define how it receives traffic. Master those and you will deploy reliably without ever touching the control plane.
Warning
Treat version-specific details as "verify, then use"
Kubernetes moves fast and features graduate across releases. This guide emphasises the durable concepts every app developer needs; for the exact status of any feature in 1.36, check the official Kubernetes release notes and your cluster's version, since availability depends on both.
1. Resource requests and limits
This is the single most impactful thing app developers control, and the most commonly botched. A request is what your container is guaranteed (the scheduler uses it to place your pod); a limit is the ceiling it cannot exceed. Set requests too low and your app gets starved and evicted under pressure; too high and you waste cluster capacity and money. Get CPU and memory requests roughly right based on real usage, and be especially careful with memory limits.
resources:
requests: # guaranteed; drives scheduling
cpu: "250m"
memory: "256Mi"
limits: # ceiling; exceeding memory = OOMKilled
cpu: "1000m"
memory: "512Mi"Danger
Memory limits are a hard wall
Exceed your CPU limit and you just get throttled annoying but survivable. Exceed your memory limit and the kernel kills your container (OOMKilled), instantly. Base memory limits on observed real usage with headroom, and treat sudden OOMKills as a sign your limit is too low or your app is leaking.
2. Health probes
Kubernetes keeps your app available only if you tell it what "healthy" means. Three probes do distinct jobs, and confusing them causes outages.
Readiness probe
Answers "can this pod receive traffic right now?" If it fails, Kubernetes stops routing requests to the pod but leaves it running. Essential for not sending traffic to a pod still warming up or briefly overloaded.
Liveness probe
Answers "is this pod broken and in need of a restart?" If it fails, Kubernetes kills and restarts the container. Use it to recover from deadlocks but be conservative, because an aggressive liveness probe causes restart loops.
Startup probe
Answers "has this slow-starting app finished booting?" It holds off the other probes until startup completes, so apps with long initialisation are not killed before they are ready.
readinessProbe:
httpGet: { path: /healthz/ready, port: 8080 }
periodSeconds: 5
livenessProbe:
httpGet: { path: /healthz/live, port: 8080 }
periodSeconds: 10
failureThreshold: 3 # be tolerant — avoid restart stormsPro tip
Make your readiness probe meaningful: it should check that dependencies your app truly needs (like the database) are reachable, so a pod that cannot serve real requests is pulled from rotation. But keep your liveness probe dumb and cheap if it checks the database too, a brief DB hiccup will restart every pod at once and turn a small problem into an outage.
3. Configuration and secrets
Never bake configuration or credentials into your container image. The same image should run in every environment, with its behaviour supplied from outside. Kubernetes provides ConfigMaps for non-sensitive configuration and Secrets for sensitive values, both injected into your pod as environment variables or mounted files. This keeps images portable and keeps credentials out of your registry.
envFrom:
- configMapRef: { name: app-config } # non-sensitive settings
- secretRef: { name: app-secrets } # credentials, tokens, keysWarning
Kubernetes Secrets need real protection
By default, Secrets are only base64-encoded, not encrypted in a way that protects them from anyone with cluster access. Ensure your platform encrypts secrets at rest and tightly controls access, and for sensitive systems consider an external secrets manager. "It is a Secret object" is not the same as "it is secure."
4. How traffic reaches your app: the Gateway API
For years, Ingress was how external traffic got routed to services, but it was limited and pushed vendors into incompatible annotations. The Gateway API is the modern, more expressive successor a standardised, role-aware way to define routing (host and path rules, traffic splitting, and more) that is becoming the recommended approach for new setups. As an app developer you typically define routes that attach to a gateway the platform team provides.
✓ Pros
- More expressive routing than classic Ingress (splitting, headers, etc.)
- A standard model instead of vendor-specific Ingress annotations
- Clear separation between platform-owned gateways and app-owned routes
- The recommended direction for modern Kubernetes networking
✕ Cons
- Newer, so some clusters and tools still center on Ingress
- More concepts to learn than basic Ingress
- Your cluster needs a Gateway API implementation installed
- Migration from Ingress takes planning on existing setups
What actually changed in 1.36?
Honestly: for most app developers, far less than the release-notes length suggests. Kubernetes releases are dominated by control-plane, security, and operator-facing work graduating features to stable, deprecating old APIs, sharpening the scheduler. The developer-facing surface (how you request resources, define probes, inject config, and route traffic) is remarkably stable release to release. The right move on any upgrade is to scan the notes for deprecated APIs your manifests use, confirm nothing you depend on changed status, and otherwise keep doing the basics well.
resources, probes, config, and routing — master these and you deploy reliably
The app developer checklist
✓ Pros
- Realistic CPU and memory requests based on observed usage
- Memory limits with headroom; expect OOMKills if too tight
- Distinct readiness, liveness, and (if needed) startup probes
- Config and secrets injected from outside the image
- Routes defined via the Gateway API onto a platform gateway
✕ Cons
- No baking config or credentials into images
- No liveness probe that checks external dependencies
- No missing resource requests (the scheduler is then guessing)
- No treating base64 Secrets as actually secure
! Common mistakes to avoid
-
✕Omitting resource requests, so the scheduler guesses.
✓Set realistic CPU and memory requests based on observed usage; set memory limits with headroom.
-
✕A liveness probe that checks external dependencies.
✓Keep liveness cheap and self-contained; a DB hiccup must not restart every pod at once.
-
✕Baking config or credentials into the image.
✓Inject configuration via ConfigMaps and secrets via Secrets from outside the image.
-
✕Treating base64 Kubernetes Secrets as secure.
✓Ensure secrets are encrypted at rest with tight access control, or use an external secrets manager.
? Frequently asked questions
Do I need to be a Kubernetes expert to deploy on it? +
No. If a platform team runs the cluster, you mainly need to get four things right: resource requests/limits, health probes, externalised config/secrets, and routing.
What is the difference between liveness, readiness, and startup probes? +
Readiness controls whether a pod receives traffic; liveness decides whether to restart a broken pod; startup holds off the others until a slow-booting app has finished initialising.
Why does my container keep getting OOMKilled? +
It exceeded its memory limit — the kernel kills it instantly (unlike CPU limits, which only throttle). Base memory limits on real observed usage with headroom, and check for leaks.
What is the Gateway API and should I use it? +
It is the modern, more expressive successor to Ingress and the recommended approach for new routing. As an app developer you usually define routes that attach to a gateway the platform team provides.
What actually changed for developers in 1.36? +
Less than the release notes suggest — most work is control-plane and operator-facing. Scan for deprecated APIs your manifests use, confirm nothing you depend on changed status, and keep doing the basics well.
Success
Be a good cluster citizen
You do not have to master Kubernetes to deploy well on it. Declare what your app needs, tell the cluster honestly when it is healthy, keep config and secrets outside your image, and define clean routing. Do those four things consistently and your services will be reliable on 1.36 and on whatever version comes next, because the fundamentals barely change.
Comments
0No comments yet. Be the first to share your thoughts.