Not every application belongs in a container, and not every workload should be orchestrated with Kubernetes. Before you invest in container-native development, it is worth distinguishing between what you can run in containers and what you should. That distinction becomes especially important when you are building a brand-new application versus migrating an existing monolith.
This article focuses on the greenfield scenario: building applications designed from the ground up to run in containers and be operated with Kubernetes. Practitioners sometimes call this cloud-native development. It is often the most practical starting point for teams new to containers, because purpose-built apps expose fewer migration surprises and let you learn orchestration concepts on clean ground.
“Containers [and orchestration] are a technical vehicle for building, deploying, and running cloud-native applications. I typically recommend to those starting their journey with containers to use a new, simple greenfield application as their test case.”
Rani Osnat, VP of Strategy, Aqua Security
1. Think and Build Modern
Building for containers is not just a packaging decision — it is an architectural one. Modern application patterns such as microservices and the Twelve-Factor App methodology fit naturally with how Kubernetes schedules, scales, and heals workloads.
Miles Ward, CTO at SADA, recommends treating this as a genuine opportunity: “If you’re building an app, build it in a modern way!” He is quick to add nuance, though. Microservices are not a hard requirement for running on Kubernetes. “A monolithic approach can also work, provided it can scale horizontally either as a single horizontal deployment or as multiple deployments with different endpoints to the same codebase.”
Similarly, the Twelve-Factor methodology is a useful starting point but not an absolute rulebook. Apply its principles where they genuinely improve your design — environment-based configuration, stateless processes, and declarative setup are almost always worth adopting.
For greenfield projects, the microservices path offers the clearest alignment with Kubernetes capabilities. Rani Osnat recommends architecting so that “individual containers can be refreshed without breaking the application” and so that “container images represent units that can be released independently, allowing for an efficient CI/CD implementation.”
Concrete ways to apply modern thinking from day one:
- Define container images as logical, independently scalable units. Components such as databases, logging agents, monitoring sidecars, load balancers, and session stores typically belong in their own containers or container groups (Osnat).
- Integrate with Kubernetes APIs. “Kubernetes has powerful API extension mechanisms,” says Vaibhav Kamra, VP of Engineering and co-founder at Kasten. “By integrating with those, you can immediately take advantage of existing tools in the ecosystem like command-line utilities and authentication.”
- Choose container-friendly runtimes and frameworks. Most modern languages now respect container resource boundaries (CPU and memory limits) correctly. Ravi Lachhman, DevOps advocate at Harness, notes that earlier JVM versions famously ignored cgroup limits, leading to out-of-memory kills — a problem that has largely been addressed in recent releases.
2. Make CI/CD and Automation Non-Negotiable
Kubernetes automates container scheduling, self-healing, and scaling. Your development and deployment pipeline should match that level of automation, or the operational overhead of managing many containers will quickly become unmanageable.
“Build applications and services with automation as minimum table stakes. With the proliferation of services and components, this can become an unmanageable issue.”
Chander Damodaran, Chief Architect, Brillio
A well-structured CI/CD pipeline enforces consistency across every build and deployment. It bakes in testing, security scanning, linting, and change-management gates so that human error is caught early and rollbacks are fast.
Lachhman frames this around resilience: “Using any new platform requires a lot of trial and error. Having a robust continuous delivery pipeline in place can ensure that confidence-building standards like testing, security, and change management strategies are followed to ensure your applications are running effectively.” Automation does not prevent mistakes — it makes recovery from them faster and more predictable.
Practical pipeline checkpoints to build in from the start:
- Automated unit and integration tests triggered on every commit
- Container image build and vulnerability scanning on every merge
- Automated promotion between environments (dev → staging → production) with configurable approval gates
- Rollback or canary-deployment strategies driven by health checks, not manual intervention
3. Keep Container Images as Small as Possible
Image size affects pull time, startup latency, storage costs, and — critically — security posture. Every package installed in a container image is a potential attack surface. Keeping images lean reduces both blast radius and operational friction.
“Only include what you absolutely need. Often images contain packages which are not needed to run the contained application. Make sure to remove all other packages — including shell utilities — that are not required by the application. This not only makes the images smaller but reduces the attack surface for security issues.”
Ken Mugrage, Principal Technologist, Office of the CTO, ThoughtWorks
Nilesh Deo, Director of Product Marketing at CloudBolt, connects image size directly to application performance: “Create a smaller container and base image. The smaller the image, the faster it can load, and as a result, the application will be faster.”
Techniques for keeping images lean:
- Use multi-stage builds. Compile or build artifacts in a full SDK image, then copy only the output binary or application files into a minimal runtime image (for example,
alpineor a distroless base). - Start from minimal base images. Prefer purpose-built minimal images over general-purpose OS images when your runtime supports them.
- Remove build tools, package managers, and shell utilities from the final runtime image unless the application explicitly requires them.
- Audit installed packages regularly — dependencies added during development often linger in production images.
- Scan images for known CVEs as part of your CI/CD pipeline, and treat new critical vulnerabilities as build-breaking conditions.
4. Design for Statelessness and Horizontal Scalability
Kubernetes excels at scaling stateless workloads horizontally. Applications that store session state, local files, or in-process caches in a way that is tightly coupled to a single pod instance will fight the scheduler rather than benefit from it.
Design application containers to be disposable and interchangeable. Any pod instance should be able to handle any request without knowledge of what other pod instances have processed. Externalise state to dedicated services: use a database for persistent data, a distributed cache (such as Redis) for session state, and object storage for files. This is one of the core tenets of the Twelve-Factor App methodology and maps directly to how Kubernetes Deployments manage replica sets.
When you genuinely need stateful workloads — databases, message queues, distributed storage — Kubernetes provides StatefulSets, Persistent Volumes, and a growing ecosystem of Operators designed to manage stateful applications safely. Use these abstractions deliberately rather than trying to force stateful behaviour onto a Deployment.
5. Implement Proper Health Checks and Graceful Shutdown
Kubernetes relies on application-level signals to make scheduling decisions. Without them, the scheduler cannot distinguish a healthy pod from one that is deadlocked, initialising, or overloaded. Implementing health checks correctly is one of the highest-leverage things you can do to make your application behave well in a cluster.
Kubernetes offers three probe types:
- Liveness probes — tell Kubernetes when to restart a container that is running but not functioning (for example, deadlocked).
- Readiness probes — tell Kubernetes when a container is ready to receive traffic. A pod that fails its readiness probe is removed from Service endpoints without being restarted.
- Startup probes — give slow-starting containers time to initialise before liveness checks begin, preventing premature restarts.
Equally important is graceful shutdown. When Kubernetes terminates a pod, it sends a SIGTERM signal. Your application should catch this signal, stop accepting new requests, finish in-flight requests, and then exit cleanly. Set terminationGracePeriodSeconds in your pod spec to give your application enough time to drain. Failing to handle SIGTERM properly leads to dropped requests during rolling updates and node drains.
6. Externalise Configuration and Secrets
Configuration that is baked into container images couples your build artefacts to a specific environment. That means separate builds for development, staging, and production — or, worse, secrets embedded in image layers. Neither outcome is acceptable in a production Kubernetes environment.
The solution is to externalise all environment-specific configuration. Kubernetes provides two native mechanisms:
- ConfigMaps — for non-sensitive configuration data such as feature flags, connection strings (without credentials), or tuning parameters. ConfigMaps can be mounted as files or injected as environment variables.
- Secrets — for sensitive values such as passwords, API keys, and TLS certificates. Kubernetes Secrets are base64-encoded by default; for production workloads, integrate with an external secrets manager (such as HashiCorp Vault, AWS Secrets Manager, or GCP Secret Manager) and use a Secrets Store CSI driver or an Operator to inject them at runtime.
Treating configuration as external to the image means a single container image can be promoted unchanged from development through to production, with only the injected configuration differing between environments. This is a foundational principle of the Twelve-Factor methodology and a practical prerequisite for reliable CI/CD pipelines.
7. Plan for Observability from Day One
In a microservices-based containerised system, debugging a problem by logging into a server and inspecting files is no longer practical. Pods are ephemeral and may have already been rescheduled by the time an incident is investigated. You need centralised, structured observability built into the application from the beginning — not bolted on later.
The three pillars of observability in a Kubernetes environment:
- Logs — Write structured logs (JSON is preferable) to
stdoutandstderr. Kubernetes captures these streams, and cluster-level log aggregators (Fluentd, Fluent Bit, Loki) can forward them to a centralised store. Avoid writing logs to files inside the container. - Metrics — Expose application metrics in a format that your metrics system can scrape. Prometheus is the de facto standard in the Kubernetes ecosystem. Instrument your application to expose request rates, error rates, latency histograms, and resource utilisation via a
/metricsendpoint. - Distributed tracing — In a microservices architecture, a single user request may traverse many services. Implement distributed tracing using an OpenTelemetry-compatible library so you can follow a request end-to-end and identify latency bottlenecks across service boundaries.
Investing in observability early pays compound dividends. It shortens incident resolution time, makes capacity planning more accurate, and gives your CI/CD pipeline the feedback signals needed to validate canary deployments and progressive rollouts.
Putting It All Together
Building applications for containers and Kubernetes is as much a design discipline as it is a tooling choice. The practices above — modern architecture, pipeline automation, lean images, stateless design, robust health signalling, externalised configuration, and built-in observability — are mutually reinforcing. Adopting them together from the start of a greenfield project is far easier than retrofitting them into an application that was never designed with container orchestration in mind.
If your team is just beginning its Kubernetes journey, start small: pick a genuinely new, low-risk service, apply these principles deliberately, and use it as the learning vehicle for your platform practices before rolling them out to more critical workloads.