Posted on Friday, Aug 11, 2023🤓 Scott Rigby If you’ve ever worked with Kubernetes (K8s), you know that beyond imperatively using the kubectl command-line interface, there are multiple tools and formats available for declaring the desired state of your clusters and applications - Helm, Kustomize, Carvel, Acorn, Timoni, Pulumi – each with pros and cons. Today I’ve decided to try Pulumi’s K8s integration to see how it stacks up. Pulumi has the distinct benefit of allowing me to create and manage K8s clusters and the applications that run on them using a single tool. What is Pulumi, though? 🏗️ Pulumi is an infrastructure as code (IaC) tool that lets you create, deploy, and manage cloud resources and apps using familiar programming languages like Python, JavaScript, Go, and more. Unlike traditional IaC tools primarily using declarative configuration files, Pulumi lets you define your infrastructure using code, providing the benefits of code reuse, version control, and programming language features. Pulumi supports managing K8s and other cloud resources on any cloud: AWS, Azure, Google Cloud, and many others. Ok, show me the code 👀

Terminologyglossary items from https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.mdContinuous Declarative Description Desired State Drift Reconciliation Software System State Store Feedback Principlesfrom https://github.com/open-gitops/documents/blob/v1.0.0/PRINCIPLES.md

I don’t know that this can or even should be standardized. I think repo organization Is subject to Conway’s law, especially with GitOps because your source repo is now an integral part of your overall system. - manage up - manage down However, I do think we can provide some good questions to ask, good rules of thumb, and common patterns that match common use cases for those just getting started or looking to iterate on their current approach. Proposed rules of thumb (axioms, not best practices per se): There should be no standard for GitOps repo structure GitOps tooling should be flexible enough to allow for iterating on repo structure

Summary GitOps is a set of principles for operating and managing software systems. The aggregate of all configuration data for a system form its Desired State which is defined as data sufficient to recreate the system so that instances of the system are behaviourally indistinguishable. When using GitOps, the Desired State of a system or subsystem is defined declaratively as versioned, immutable data, and the running system's configuration is continuously derived from this data. GitOps principles were derived from modern software operations but are rooted in pre-existing and widely adopted best practices. These principles are: The principle of declarative desired state