The Kubernetes Decision Path: A Practical Framework for Your Cloud-Native Stack

Kubernetes has become the operating system of the cloud. But with great power comes extreme complexity. The CNCF landscape is a dizzying array of logos, and for many teams, the first and most critical question isn't "how do we run Kubernetes?" but rather "should we even be using it?"

Inspired by the excellent Kubernetes Decision Path framework by Sid Palas (DevOps Directive), this guide provides a structured approach to mapping out your cloud-native journey. Whether you're a CTO deciding on the next three years of infrastructure or a Platform Engineer picking a CNI, this framework will help you navigate the noise.

---

Step 1: The "Should We?" Test

Before you install a single agent, you must pass the threshold of complexity. Kubernetes is not a "default" choice; it is a choice for scale.

Ask yourself:

1. Do you operate many different applications? (If you have two apps, K8s is overkill).
2. Are they already containerized? (Or is your team willing to learn Docker?).
3. Have you ruled out Platform as a Service (PaaS)? (Tools like Google Cloud Run, AWS Fargate, or Vercel can handle 90% of use cases with 10% of the operational burden).

---

Step 2: Hosting — Managed vs. Self-Hosted

If you’ve decided that you definitely need Kubernetes, the next fork in the road is about control vs. convenience.

The Case for Managed Clusters (EKS, GKE, AKS)

For 95% of organizations, Managed Kubernetes is the only correct answer.

• Pros: The cloud provider manages the "Control Plane" (the brain of K8s). They handle upgrades, certificates, and scaling the API server.
• Recommendation: Stick with your current cloud provider. If you're on AWS, use EKS. On Google Cloud, GKE is arguably the best managed experience in the market.

The Case for Self-Hosted (Kops, Kubespray, Talos)

You should only self-host if:

• You have extreme compliance/regulatory needs that force you on-prem.
• You need "Bleeding Edge" upstream features the day they are released.
• You have a team of senior SREs who want to debug the control plane at 3 AM.

---

Step 3: Infrastructure as Code (IaC)

How do you build the VPC, the clusters, and the load balancers?

• Terraform: The industry standard. Huge provider support and a massive hiring pool.
• Pulumi: Excellent if your team prefers TypeScript/Go/Python over HCL.
• Crossplane: The "Kubernetes-native" way. It turns your K8s cluster into a control plane for your entire cloud.

---

Step 4: The Networking Layer (CNI)

Once your cluster is up, how do your pods talk to each other?

• Cloud Provider Default: Usually the safest bet for stability.
• Cilium: The rising star. It uses eBPF for high-performance networking, deep observability, and advanced security. If you're building a modern platform in 2026, look at Cilium.
• Calico: Battle-tested and great for complex network policies across multi-cloud or hybrid environments.

---

Step 5: Traffic & Ingress

How do you get users from the public internet into your services?

• Inbound Proxy (Nginx, Kong, HAProxy): The standard. Nginx Ingress is the most common, while Kong offers great API gateway features.
• Traefik: Modern, auto-configuring, and works natively with Kubernetes metadata.
• LoadBalancer Services: If your needs are simple, just use the cloud provider's native Load Balancer. It’s less to manage.

---

Step 6: Continous Delivery — GitOps vs. Push

This is where the "Operations" part of DevOps happens.

• GitOps (Pull-based with ArgoCD or Flux): This is the modern gold standard. The cluster "pulls" the desired state from Git. If someone manually changes a setting in the cluster, GitOps will automatically revert it. Recommendation: Use ArgoCD.
• Push-based (from CI): Your GitHub Actions or GitLab CI pipeline runs a helm upgrade command. It’s simpler to set up initially but harder to secure (requires cluster credentials in your CI) and lacks auto-reconciliation.

---

Step 7: Packaging & Developer Experience

How do your developers actually deploy things?

• Helm: The "Yum/Apt" of Kubernetes. Essential for managing complex applications.
• Kustomize: Better for simple overlays and avoiding the complexity of Helm templates.
• Developer Tooling (Tilt/Skaffold): These tools let devs code locally and see their changes reflected in a K8s namespace instantly. This is critical for team velocity.

---

Step 8: The "Day 2" Concerns

Once the apps are running, you need to survive.

1. Observability: You need a stack like Prometheus and Grafana for metrics. Don't fly blind.
2. Secrets Management: Don't bake passwords into environment variables. Use Hashicorp Vault or your Cloud Provider's Secret Store synced via External Secrets Operator.
3. Backups: Use Velero. In the event of a disaster, you need to be able to restore your cluster state, not just your app data.
4. Security: Implement Snyk for image scanning and Falco for runtime threat detection.

---

Summary: A Recommended Baseline for 2026

If you are a mid-market company building a new platform today, here is the "Safe, Modern Stack" I recommend:

• Hosting: Google GKE (Managed).
• IaC: Terraform.
• Networking: Cilium.
• Traffic: Traefik or GKE Gateway API.
• CI/CD: GitHub Actions (CI) + ArgoCD (GitOps CD).
• Packaging: Helm.
• Observability: Prometheus + Grafana.
• Secrets: AWS/Google Secret Manager + External Secrets Operator.

Kubernetes is a journey, not a destination. You don't have to implement all 22 nodes of the decision path on day one. Start with a managed cluster and a simple CI/CD setup, then layer on security and observability as your traffic grows.

---

Further Reading

• Choosing the Right CI/CD Pipeline
• Prometheus vs. Datadog: The Cost Aspect
• Secrets Management: Vault vs. External Secrets Operator

Need help mapping your specific decision path? Let's talk.

Frequently Asked Questions

How do I know if we should use Kubernetes at all?

Run the 'should we?' test honestly: multiple services with real scaling/scheduling needs, a team able to own the platform, and workloads that don't fit simpler runtimes. If a managed PaaS or container service covers you, take it — Kubernetes adopted without those triggers becomes pure overhead.

Should we run managed or self-hosted Kubernetes?

Managed (EKS, GKE, AKS), with rare exceptions like strict on-prem or edge requirements. The control plane is undifferentiated heavy lifting; your team's energy belongs in the layers above it — networking, delivery, and developer experience.

In what order should we choose the rest of the stack?

Follow the dependency chain: hosting → IaC → CNI → ingress/traffic → delivery (GitOps) → packaging/DX → day-2 (observability, backups, upgrades). Each step constrains the next, and deciding them in this order prevents the classic trap of picking tools before the requirements that should drive them.