Containers and Kubernetes management

Automated Kubernetes cluster deployment and management using Terraform and Helm charts for a microservices architecture, with applications containerized through optimized multi-stage Docker builds.

Hand-built clusters drift apart, and the knowledge of how they were made leaves with whoever made them. The goal of this kind of work is that a new cluster is a routine, repeatable operation.

What a repeatable cluster setup has to provide.

• –A new cluster from code, with no manual steps
• –Separate lifecycles for infrastructure and for applications
• –Small images with a non-root user and no build tools

Terraform owns the cluster and node groups. Helm owns what runs on them. Keeping those separate means an application release can never plan a change to the cluster.

Why these tools fit together.

• –Multi-stage builds leave compilers and caches out of the final image, reducing both size and attack surface.
• –Helm provides versioned, rollback-capable releases.
• –Terraform provides the reviewable plan for the layer beneath.

Build in layers: network, then cluster, then add-ons, then workloads. Each layer is verified before the next depends on it, and a cluster should be destroyed and rebuilt once to prove that the code is complete.

Images are tagged with the commit SHA and never with latest. A helm upgrade with --atomic reverts automatically if the release does not become healthy.

Private API endpoint where possible, namespaces with network policies, Pod Security Standards, and workload identity in place of node-level credentials.

Disruption budgets keep node upgrades from taking a service down. Topology spread keeps replicas in different zones. Accurate requests are what make the scheduler and autoscalers work at all.

Common failure modes, and the standard answer to each.

• –Pods Pending with free-looking capacity: requests are what count, not usage. The Scheduler lab demonstrates this.
• –Version upgrades breaking add-ons: check API deprecations first and upgrade a non-production cluster first.
• –Image size creep: review what each layer adds, and keep a minimal base.

No verified figures are published for this project. The numbers that would prove it worked: time to create a cluster, image size, and failed upgrades per quarter.