CCHQ ARTICLE GUIDE / CONTAINERS & KUBERNETES
Practical learning, clear decisions, real-world context
An easy-to-navigate field guide with key takeaways, applied checks, FAQs, and official references. Approximately 7 minutes of reading.
Containers and Kubernetes are related but different technologies. A container packages an application with its required runtime and dependencies so it can run consistently across environments.
Kubernetes is an orchestration system that schedules and manages containerized workloads across a cluster. Docker is commonly used to build and run container images, while Amazon ECS and EKS are AWS services for operating containers under different models.
Understanding these layers matters because many beginners learn one command and then mistake a successful container start for a production-ready deployment.
This guide explains the container lifecycle, cluster components, networking, persistent data, security, observability, and the decision to use Kubernetes at all.
The goal is to help cloud engineers choose a deployment model based on application needs rather than technical fashion.
At a glance
The main topics you’ll work through:
- Containers versus virtual machines
- Build and manage container images
- What Kubernetes manages
- Networking, ingress, and service discovery
In this guide
01 / KEY CONCEPT
Containers versus virtual machines
KEY TAKEAWAY
A virtual machine provides a guest operating system and virtualized hardware resources.
A container generally shares the host kernel and isolates processes using operating-system primitives. This distinction affects startup behavior, density, portability, and isolation expectations.
A container image packages filesystem layers and metadata required to start the application, but it does not normally include a complete guest kernel.
The runtime starts a process from the image and applies resource limits, filesystem mounts, and network configuration.
Containers are portable within practical boundaries, not universally identical across every environment. CPU architecture, kernel capabilities, file permissions, external services, and runtime settings can still cause failures.
A containerized application also needs a plan for upgrades, secrets, health checks, logging, and state persistence. Think of an image as an immutable release artifact and of a running container as an instance of that artifact.
Keeping those concepts separate makes rollback and vulnerability remediation easier.
02 / PRACTICAL APPLICATION
Build and manage container images
KEY TAKEAWAY
A typical workflow begins with a Dockerfile that specifies a base image, application files, dependencies, the process command, and runtime defaults.
Keep the image small enough to maintain efficiently, but choose a supported base rather than minimizing size at the expense of security updates. Build images in a controlled pipeline, scan known vulnerabilities, and pin dependencies to approved versions.
Multi-stage builds can reduce which build tools and temporary files appear in the final runtime image.
Do not embed credentials, tokens, or private configuration in an image layer. Files deleted in a later build stage may still exist in earlier layers if the build was structured incorrectly.
Give the application an unprivileged execution identity when feasible and avoid unnecessary Linux capabilities. Push the signed or approved artifact to a registry and deploy by a predictable version or digest.
A mutable latest tag alone makes it difficult to prove which version ran during an incident or to reproduce a failed rollout.
03 / KEY CONCEPT
What Kubernetes manages
KEY TAKEAWAY
Kubernetes provides an API for declaring workload objects and desired state.
A Pod is the smallest deployable grouping and may contain one or more tightly coupled containers. A Deployment manages replica sets and rolling updates for appropriate stateless workloads.
A Service provides a stable way to address matching Pods despite changes in individual Pod IPs.
Controllers continually reconcile desired configuration with observed cluster state; a successful API submission does not necessarily mean the application is healthy.
Kubernetes control-plane components handle API processing, scheduling decisions, and cluster state coordination. Worker nodes run Pods through the runtime and supporting agents.
In managed services such as EKS, some control-plane responsibilities are handled by the cloud provider, but workloads, IAM integration, cluster policies, add-ons, node arrangements, networking, and patch planning can remain your responsibility.
Learn the actual division of work for your chosen deployment model instead of assuming the word managed means fully hands-off.
04 / PRACTICAL APPLICATION
Networking, ingress, and service discovery
KEY TAKEAWAY
Pods often receive their own IP addresses and can communicate through the cluster’s network implementation.
Services abstract sets of Pods and make discovery more stable. Ingress or Gateway API implementations may provide HTTP routing and TLS termination, but the exact controller and load balancing resources depend on the cluster and cloud environment.
Exposing a Service publicly can add an unexpected reachable entry point and cost. Plan traffic paths before installing controllers or creating public-facing load balancers.
NetworkPolicies can restrict allowed Pod traffic when the CNI and network implementation actually support and enforce them. A policy object alone is not proof of enforcement. Use DNS, readiness probes, and test traffic to troubleshoot routing.
An application that works through a local port-forward might still fail from a public client because of ingress routing, TLS, security groups, target health, or DNS.
Separate application-level authentication from network access; a reachable service should not automatically trust the caller.
05 / KEY CONCEPT
Storage and stateful workloads
KEY TAKEAWAY
Containers are often replaced, rescheduled, or destroyed as part of ordinary operation.
Files written only to a container’s ephemeral filesystem should not be treated as durable application data. Kubernetes supports persistent volumes and claims to express storage needs, with behavior influenced by the available storage classes and drivers.
AWS managed storage integrations introduce their own placement, access, and billing choices. StatefulSets can help manage workloads that require stable identifiers or ordered operations, but they do not make databases self-maintaining.
For a first project, prefer a stateless API backed by a managed database or object storage rather than attempting to run a production database inside a beginner cluster.
Decide who manages backups, credential rotation, encryption, schema upgrades, and restore tests. If you use persistent storage, inspect volume reclaim policy, availability-zone placement, snapshots, and retention.
A database container surviving a restart is not the same as a recoverable data architecture. Document the application data path and its expected failure behavior.
06 / PRACTICAL APPLICATION
Choose ECS, EKS, or another platform
KEY TAKEAWAY
Amazon ECS provides AWS-native container orchestration and integrates closely with AWS identity, networking, and monitoring.
Amazon EKS provides managed Kubernetes control-plane capabilities for teams that need Kubernetes APIs and ecosystem patterns. AWS Fargate is a compute option used by certain ECS and EKS workloads; it is not a replacement for the orchestration layer.
A fully managed app platform may be simpler still for a small web service. Compare the level of control, required expertise, service compatibility, available team tooling, and operational burden.
Kubernetes is not automatically required for microservices. A small team can deploy several services using an orchestrator without maintaining complex cluster components.
On the other hand, Kubernetes can be valuable when common cluster APIs, admission controls, ecosystem tooling, or existing platform standards are key requirements. Compare total cost, not just container CPU and memory.
Control planes, nodes, load balancers, persistent volumes, NAT gateways, logging, and data transfer can dominate expenses in an otherwise tiny application.
07 / KEY CONCEPT
Security responsibilities across the stack
KEY TAKEAWAY
Security begins before deployment.
Scan base images, review dependencies, use scoped registry access, and keep secrets out of image layers. At runtime, avoid privileged containers, minimize capabilities, apply resource limits, and restrict administrative execution where practical.
Use application-specific identities and narrow cloud permissions. In Kubernetes, RBAC controls access to the API, while NetworkPolicies concern traffic between workloads; they solve different problems and should be reviewed separately.
Pay attention to the supply chain. A compromised build dependency, workflow action, or container registry can deliver untrusted code even when the Kubernetes manifests look correct. Control who can publish images and who can change workload declarations.
Monitor cluster audit events and application logs without collecting unnecessary secrets. Plan how a vulnerable image is identified, replaced, and rolled back.
Treat cluster administrator access as sensitive even when the environment contains only test workloads.
08 / PRACTICAL APPLICATION
Practical deployment and validation plan
KEY TAKEAWAY
Begin with a simple HTTP application that reports a health endpoint.
Build the image locally, test it without secrets, and push it to an approved registry. Choose a deployment platform, define resource requests or task sizing, and provide the application a scoped identity. Configure service discovery or routing only if required.
Add health checks and logs before the first release. Then deploy one replica and inspect readiness, actual image version, network reachability, and runtime permissions.
Change the image version to exercise an update, observe whether unhealthy instances are replaced, and check that users can still reach the service where appropriate. Induce a controlled failure in a lab and read the relevant events and logs.
Record the clean-up sequence for compute, images, load balancers, volumes, and network components. Keep notes on the operational questions you could not answer at first; they provide a focused path for learning more about the platform.
Before you finish: practical checklist
Turn the main lessons into a short review of your own environment:
- Keep the image small enough to maintain efficiently, but choose a supported base rather than minimizing size at the expense of security updates.
- Build images in a controlled pipeline, scan known vulnerabilities, and pin dependencies to approved versions.
- Plan traffic paths before installing controllers or creating public-facing load balancers.
- Use DNS, readiness probes, and test traffic to troubleshoot routing.
- Document the application data path and its expected failure behavior.
Frequently asked questions
Is Docker the same as Kubernetes?
No. Docker tools commonly build and run containers; Kubernetes coordinates workloads across a cluster. You can learn containers without operating Kubernetes.
Does Kubernetes automatically make an application highly available?
No. Replica counts, multi-zone design, data dependencies, health checks, and recovery operations determine availability. A cluster may still have single points of failure in the workload.
Should a beginner start with EKS?
Not necessarily. Learn image, network, and identity basics first. ECS, a local Kubernetes cluster, or a managed app platform may be a better initial exercise depending on the learning goal.
References and next steps
Kubernetes security concepts · Kubernetes NetworkPolicies · Amazon ECS getting started · Amazon ECS Fargate guide
Visit Containers & Kubernetes for platform and security follow-ups.
A strong first project deploys a simple service with a reproducible image, clear access rules, useful logs, and a verified teardown—not a cluster containing every possible add-on.
