I ignored Kubernetes for 12 years

Overview

The speaker avoided Kubernetes for about 12 years, then rapidly learned it through multiple live streams to understand the modern ecosystem and get a working cluster.

---

Goal / approach

• They compressed roughly 8–9 Twitch live streams (each 2–3 hours) into a “distilled” guide.
• The guide is aimed at mid-level/senior engineers who are new to Kubernetes and want to avoid common pitfalls.
• Their learning goal was practical: reach a working cluster quickly, rather than fully mastering low-level internals first.

---

Early impressions and why they delayed learning

• Kubernetes is commonly framed as a “container orchestrator” (historically associated with Docker), though the speaker hadn’t learned Docker around 2014.
• They believed Kubernetes adoption often came with painful experiences, making it seem overly complex relative to its value.
• They also referenced common jokes/memes about Kubernetes being too hard/overkill (e.g., “resume-driven development” for getting Kubernetes introduced).

---

Learning journey (key tools and what went wrong)

1) Official docs + Learning Kubernetes the Hard Way

• They started with the official Kubernetes documentation.
• They were directed to Kelsey Hightower’s guide, Learning Kubernetes the Hard Way.
• That approach required multiple machines (e.g., control plane, workers, jump box).
• Since they lacked hardware, they used AWS EC2 and manually built PKI using shell/SSH steps.
• They became frustrated with the process turning into a “blob of shell scripts,” arguing friction should be lower by now—while acknowledging the guide’s intent is to expose low-level concepts.

2) Bootstrap with kubeadm

• Rather than staying fully manual, they switched to kubeadm to bootstrap nodes.
• This helped them move toward infrastructure as code.

3) Infrastructure as code: CloudFormation → Pulumi

• They used CloudFormation to create EC2 nodes and bootstrap Kubernetes via user data.
• After the cluster came up, they tried to make the setup reproducible using:
  • Helm
  • Deploying a game server (Valheim)
• They hit troubleshooting issues, including:
  • Pods crashing due to insufficient understanding of debugging/logging tooling
  • Confusion with taints and tolerations
• They concluded their “scrappy” bootstrapping approach suffered from bootstrapping/state problems.
• They pivoted from CloudFormation to Pulumi:
  • Pulumi is praised as “type-checked infrastructure”
  • Using the Go SDK means invalid infrastructure fails compilation

Root cause: bootstrapping order (AWS CCM)

• Their real deployment problems were traced to bootstrapping order:
  • AWS CCM (Cloud Controller Manager) needed to be set up before other controllers/pods (they mention Argo CD).
  • Without CCM, Argo CD attempted to create AWS-dependent resources too early.

4) GitOps with Argo CD

After fixing the ordering (CCM first), things became smoother:

• Add to a Git repository
• Argo CD pulls and reconciles
• Pods appear quickly—on the order of seconds

This became a major theme for “how to operate Kubernetes”: GitOps continuous reconciliation.

---

Platform/developer experience tooling considered (but not adopted)

They explored “platformized deployments” to reduce developer cognitive load, mentioning:

• KubeVela
• Backstage
• Crossplane
• Open Application Model (OAM)

Why they liked the idea (OAM / KubeVela)

• Developers shouldn’t need to understand every Kubernetes primitive:
  • pods, deployments, statefulsets, services, etc.
• Instead:
  • teams define standardized component/types (e.g., web service, worker service)
  • developers submit minimal YAML that expands into full Kubernetes configuration

Why they didn’t continue

• It ultimately felt subjective and environment-dependent.

---

Two pathways for Kubernetes adoption

1) “90%”: Managed Kubernetes + GitOps

• Use a managed service such as:
  • EKS, GKE, or Azure Kubernetes Service
• Pair it with GitOps, then “call it a day.”

2) “10%”: Run your own Kubernetes

Reasons include:

• avoiding vendor lock-in
• needing multi-cloud
• wanting to offer managed Kubernetes yourself

To make “run your own” less painful, they found success combining:

• Talos Linux for cluster OS/setup
• Terraform or Pulumi for provisioning/bootstrap
• Argo CD for GitOps management

---

What they still need to learn to be proficient

They list gaps and future learning areas.

Core Kubernetes concepts

They understand basic building blocks (pods/services) but still need clarity on:

• ConfigMaps and Secrets (including choosing a secret provider)
• Namespaces and Service Accounts
• Differences between:
  • pods vs deployments vs stateful sets
• Ingresses, Services, and NodePorts

GitOps + Kubernetes extensions

• CRDs
• How Argo CD continuously reconciles cluster state

Helm and alternatives

• Deeper reading of Helm charts (best practices and standard patterns)
• Kustomize (noted as built into kubectl)

Operational concerns

• Cluster/node autoscaling:
  • cluster autoscaler
  • Karpenter for scaling worker nodes based on capacity/pod needs

Networking and CNI

• Cilium (as a key networking area to learn)

Observability

• Logging/metrics tooling such as:
  • Prometheus
  • Grafana
  • tools like Victoria (Victor)

Building an operator

• Writing their own Kubernetes operator from scratch (harder, later-stage learning)

---

Main speakers / sources

• Speaker: the video’s author/narrator (unnamed in the subtitles)
• Referenced sources/tools:
  • Kelsey Hightower — Learning Kubernetes the Hard Way
  • Kubernetes ecosystem tools:
    • kubeadm, Helm, kubectl, Argo CD, Pulumi
    • CloudFormation, AWS CCM (Cloud Controller Manager)
    • Talos Linux, Terraform
    • KubeVela, Backstage, Crossplane
    • Open Application Model (OAM)
    • Karpenter, Cilium
    • Prometheus, Grafana