In the fourteenth episode of the Ambassador Livin’ on the Edge podcast, Katie Gamanji, Cloud Platform Engineer at American Express and TOC member of the CNCF, discusses the building blocks of developer experience related to interacting with Kubernetes clusters. She covers the evolution of tooling from the kubectl that we all know and love, to UI-driven tooling like k9s and Octant, and ultimately to ApplicationOps and GitOps.Katie also talks about the evolving ClusterAPI and how this is becoming integrated with the Kubernetes developer experience. She discusses if the tooling is currently good enough to allow engineers to treat Kubernetes clusters as resources themselves, and treat them as “cattle, not pets”.
Be sure to check out the additional episodes of the "Livin' on the Edge" podcast.
Key takeaways from the podcast included:
- Automation and transparency are key to creating an effective continuous delivery pipeline. Siloing based on teams or technical verticals (e.g. networking, security) leads to inefficiencies via the introduction of uncertainty who is responsible, increased handoffs, and delays in verification.
- Creating an application platform that is focused on self-service operation for development teams decreases friction when building, deploying, and releasing applications.
- Platform and ops teams can provide expertise, support, and consultation to dev teams when required, but they should not be on the critical path for daily work.
- Platform teams should recognize that developers are their customers. Platform and operations teams must empathize with and understand the needs of developers in order to build an effective developer experience.
- There are typically three personas involved in building and releasing applications on Kubernetes: application developers, application operators, and infrastructure operators.
- Each persona has differing requirements for interacting with a Kubernetes cluster. As the developer experience of Kubernetes cluster tooling has evolved, a series of categories and techniques have emerged: cluster CLI e.g. kubectl, including plugins and wrappers; and ApplicationOps, such as ClickOps, GitOps, and SheetOps.
- Engineers are increasingly using kubectl "wrapper" tools to view and interact with a Kubernetes cluster. These tools provide a richer user interface than traditional CLI tools.
- K9s provides a useful terminal-driven user interface. Octant provides a useful web-based UI onto a cluster and associated resources. Spect8 provides an interesting view onto the networking components of a k8s cluster.
- GitOps enables engineers to specify the desired state of a cluster, typically via declarative YAML configuration, and use tooling like Flux or ArgoCD to ensure that the cluster state matches this specification. All configuration is stored in version control, and this enables easy rollout and rollback, and also provides an audit trail.
- The Kubernetes founding team, the community, and the CNCF have worked to define useful abstractions and APIs for all of the personas listed above. These are now becoming a standard, and moving forward the innovation will focus on techniques on top of Kubernetes.
- The Cluster API is potentially allowing infrastructure operators to treat clusters as "cattle, not pets". When engineers can think of a cluster as a Kubernetes resource, this opens up new possibilities. For example, clusters can be created and managed via well-established practices like GitOps via ArgoCD or Flux.
- The Cluster API can also allow engineers to easily visualise what's "underneath their clusters", such as VMs, network attached storage etc. This will help with provisioning and upgrading, for example, engineers can easily look via the Kubernetes API to see the progress of each node during a K8s update.
