Kubernetes without YAML

Kubernetes Deployment Challenges

• The speaker begins by asking the audience to share their thoughts on the resources needed for deploying applications to Kubernetes in production.
• The audience responds with a variety of resources, including deployments, services, service meshes, networking policies, load balancers, observability stacks, and Argo Rollouts.
• The speaker emphasizes the complexity of deploying to Kubernetes in production, highlighting the vast landscape of resources and tools.
• The text discusses the challenges of deploying applications to Kubernetes in a production environment.
• It highlights the complexity of managing various Kubernetes resources like deployments, services, config maps, secrets, and more.
• The author emphasizes that deploying monolithic applications to Kubernetes might not be the most efficient approach due to the operational complexity.
• The text suggests that deploying microservices to Kubernetes requires repetitive tasks and copying and pasting YAML files, leading to a need for better tooling.
• The author mentions Helm as a tool that helps manage this complexity but acknowledges its own challenges.
• The text concludes by outlining the desired features of tooling for Kubernetes deployments, including reusability, sharability, opinionated configurations, and composability.

Current Deployment Methods

• The speaker then asks the audience about their current deployment methods, revealing that most use YAML, Helm, and Terraform.
• The speaker mentions other tools like Kustomize, Jsonnet, Pulumi, Carvel, Kube, CDK8s, Capitan, and Kpt, but notes that they are less commonly used.

YAML Limitations

• The speaker highlights the limitations of YAML for managing Kubernetes resources, particularly the lack of robust documentation and testing tools. They also point out the challenges of using YAML anchors for code reuse, as they only work within a single YAML document.
• The speaker emphasizes the importance of documentation when working with Kubernetes resources, particularly custom resource definitions (CRDs). They recommend using the kubectl explain command to understand the spec of a resource without having to delve into the code.
• The speaker finds kubectl explain and VS Code extensions for Kubernetes to be inadequate for providing documentation and testing, as they rely on communication with the cluster, which can be slow and problematic.
• The speaker discusses the challenges of using YAML for Kubernetes deployments and emphasizes the need for a better developer experience.
• They highlight the importance of leveraging existing developer skills and intuition to simplify the deployment process.

Helm Challenges

• The speaker introduces kubectl customize as a tool for addressing some of the challenges of working with YAML, but acknowledges that it doesn't solve all the problems. They then discuss Helm as a tool for sharing and deploying Kubernetes resources, but express concerns about its use of the Go template language, which they find difficult to work with due to its reliance on whitespace and context variables.
• The speaker criticizes Helm charts for being too general-purpose and having too many configuration options, leading to complex YAML files that are difficult to work with.
• While Helm is still recommended for deploying third-party software, it may not be the best long-term solution for deploying your own software.

Open Policy Agent (OPA)

• The speaker expresses concerns about the usability of Rego, the language used for Open Policy Agent, finding it difficult to understand and maintain.
• The speaker welcomes the addition of Common Expression Language (CEL) to Kubernetes, as it provides a simpler and more developer-friendly way to write validated admission policies.

CDK8s and CDKates

• The speaker introduces CDK8s as a potential solution for improving the developer experience, emphasizing its ability to work with familiar programming languages.
• The video discusses the challenges of using YAML for Kubernetes deployments and explores alternatives like CDKates.
• CDKates is a CDK implementation that allows deploying to Kubernetes using various languages like Go, JavaScript, TypeScript, Python, and Java.
• CDKates leverages the gsii project to generate SDKs for different programming languages, enabling developers to use familiar tools and IDEs for Kubernetes deployments.
• CDKates offers benefits like language server protocol support, debugging capabilities, and integration with Helm 2.
• CDKates provides constructs and charts for managing dependencies and generating YAML files for Kubernetes deployments.
• The video demonstrates a live coding example using CDKates TypeScript to define Kubernetes resources and generate YAML files.
• The example showcases how to import the Kubernetes API using CDKates and generate SDKs for specific Kubernetes versions.
• CDKates allows developers to define Kubernetes resources using code, eliminating the need for manual YAML editing.
• The video highlights the advantages of using CDKates for simplifying Kubernetes deployments and improving developer productivity.

CDK (Cloud Development Kit)

• The video demonstrates how to create a Kubernetes deployment using CDK (Cloud Development Kit) without writing YAML.
• CDK provides a way to define Kubernetes resources using code, specifically TypeScript in this case.
• The example uses a cdk.app.App object to create a cdk.aws.eks.Deployment object, which represents a Kubernetes deployment.
• The Deployment object is configured with metadata, spec, and container information.
• CDK offers features like tab completion, error detection, and code refactoring, enhancing the developer experience.
• The example demonstrates how to create a function to encapsulate the deployment creation logic, making it reusable.
• CDK introduces the concept of "scope" or "context," which allows for organizing and managing resources.
• The scope provides a way to apply common configurations or augmentations to multiple resources.
• The example shows how to define labels and other properties within the deployment definition.
• By using CDK, Kubernetes deployments become more manageable and maintainable, leveraging existing software development practices and tools.

CDK8s Features

• The video demonstrates how to refactor YAML code into a function, which allows for snapshot-based testing.
• This refactoring enables the use of a fluent API, where developers can chain methods to create and configure Kubernetes resources.
• The video highlights the CDK8s library, which provides a developer-friendly way to interact with Kubernetes resources, including custom resource definitions (CRDs).
• CDK8s offers a streamlined approach to working with CRDs, eliminating the need for manual SDK generation.
• The video showcases how to import a CRD from a GitHub repository and use it within a CDK8s application.
• The example demonstrates the use of the CTManager CRD to create a self-signed certificate issuer.
• CDK8s provides a developer-friendly way to manage Kubernetes resources, allowing for the creation of internal pattern libraries and the encapsulation of deployment patterns in classes or functions.
• CDK8s enables policy enforcement and testing through aspect-oriented programming, ensuring security contexts and resource access control.
• CDK8s integrates with existing tools like Helm, Terraform CDK, and Git repositories, allowing for seamless deployment and resource provisioning.
• CDK8s can consume Helm charts, providing a way to manage Helm deployments within the CDK8s framework.
• CDK8s can be used to manage complex deployments involving multiple microservices and shared resources like databases, enabling dependency management and resource creation based on need.

Kube and Timon

• The speaker criticizes Terraform's approach to Kubernetes deployments, stating that it lacks the developer experience needed for working with CRDs and that its support for custom resources is limited.
• They introduce Kube, a project from Google that aims to eliminate YAML and JSON from Kubernetes deployments, and highlight its features, including its ability to generate arbitrary formats and recursively parse YAML and JSON into structured data.
• The speaker mentions Timon, a project by Stefan Pran, the maintainer of the Flux project, which leverages Kube to enable GitOps workflows for Kubernetes deployments.

Pulumi

• The speaker also mentions Pulumi as a tool for Kubernetes deployments, but cautions against its use due to its reliance on a Terraform resource model, which can lead to challenges with custom resource definitions (CRDs).

Speaker Introduction

• The speaker concludes by introducing himself as David, a Kubernetes educator and consultant, and mentions his YouTube channel, Rock Hood Academy.
• He also mentions his show "Clustered," where he challenges people to break Kubernetes clusters and then fixes them live on stream.

Platform Team Responsibilities

• The speaker argues that Kubernetes is not a platform that should be given to developers without guardrails and structure.
• They suggest that platform teams should provide pre-built building blocks and constructs for developers to use, rather than requiring them to write complex YAML configurations.
• This approach allows developers to focus on writing code and deploying it to production easily, while platform teams handle the infrastructure and security aspects.
• The speaker emphasizes the importance of providing opinionated ways to deploy applications, including policies, testing, and security measures, to ensure consistency and best practices.
• They advocate for using SDKs like the one mentioned in the video, which abstract away complex Kubernetes configurations and provide developers with a simpler interface.