How to Structure Your Kubernetes Project

In partnership with

TechOps Examples

Hey — It's Govardhana MK 👋

Along with a use case deep dive, we identify the remote job opportunities, top news, tools, and articles in the TechOps industry.

👋 Before we begin... a big thank you to today's sponsor FYXER AI

Fyxer AI: Automate Emails, Meetings, and Team Tasks in Seconds

Fyxer AI automates daily email and meeting tasks:

  • Email Organization: It organizes your inbox so you see important emails first.

  • Automated Email Drafting: Crafts replies that sound like you—convincing, concise, and flawlessly written in any language.

  • Meeting Notes: Keeps you focused by taking notes, summarizing meetings, and drafting follow-ups.

Fyxer AI adapts to teams and sets up in just 30 seconds with Gmail or Outlook.

IN TODAY'S EDITION

🧠 Use Case

  • How to Structure Your Kubernetes Project

🚀 Top News

👀 Remote Jobs

  • Sardine is hiring a Staff SRE

    Remote Location: USA, Canada

📚️ Resources

🛠️ TOOL OF THE DAY

Terrateam -  An open-source GitOps CI/CD platform for automating infrastructure workflows.

  • It integrates with GitHub to orchestrate Terraform, OpenTofu, CDKTF, and Terragrunt operations via pull requests.

🧠 USE CASE

How to Structure Your Kubernetes Project

Application designs, infra architectures, and project structures are subjective decisions, and everyone has their own way, and even systems demand certain specifics – agreed!

Having said that, I strongly believe any design decision shouldn't be about NOW, rather about scalability, longevity, and future-proofing.

The DRY (Don't Repeat Yourself) Principle is one such crucial aspect that plays a significant role in this.

Every engineer should read the crisp version of The Pragmatic Programmer by David Thomas and Andrew Hunt - This helps to enhance your understanding to design scalable and less redundant systems.

Coming to the context…

In line with the DRY principle, here’s a directory structure you can adopt to organize your Kubernetes project for clarity, scalability, and operational efficiency.

base/:

Contains shared Kubernetes manifests that apply across all environments.

Example: deployment.yaml defines the core application deployment (image, ports, labels) used in every environment.

overlays/:

Environment-specific configurations using Kustomize overlays.

Subdirectories like dev/, prod/, and staging/ override base/ configurations as needed.

helm/:

Optional directory for Helm charts to template Kubernetes manifests.

Includes values.yaml (shared settings) and environment-specific values (e.g., dev-values.yaml).

Useful for teams preferring Helm over Kustomize.

To the parent directory, you can even add:

apps/ - to host multiple application specific files.

scripts/ - to host automation scripts like deploying, rolling back, and cleaning up resources

How to Deploy to a Specific Environment

Using Kustomize:

For deploying resources to a specific environment, you can apply the relevant overlay directory:

kubectl apply -k overlays/dev/

Using Helm:

Specify the appropriate values file:

helm install techops-app ./helm -f ./helm/values/dev-values.yaml

Verifying the Deployment:

After deployment, ensure the resources are correctly applied:

kubectl get all -n <namespace>
kubectl describe deployment <techops-app> -n <namespace>

Things To Consider

📌 Deploy environment specific resources in their own namespaces to avoid conflicts.

📌 Adopt GitOps tools like ArgoCD or Flux for automated deployments.

📌 Encrypt secrets using tools like Sealed Secrets; avoid plain YAML files.

📌 Maintain balance between shared and environment-specific configurations; avoid redundant directories.

Check out these guides to level up :

Organize and manage environment-specific Kubernetes configs using overlays.

Templating and deploying Kubernetes resources with Helm.

You may even like:

Looking to promote your company, product, service, or event to 25,000+ TechOps Professionals? Let's work together.