The operator is a bit mind-bending, haha. It’s like using a declarative description of a stack, which itself is driven by a declarative description of the infrastructure (i.e., the Pulumi program). It gets even weirder when you think about declaring the CRD resources using Pulumi. It’s just turtles all the way down.

There are a few ways to think about it: • As just another kind of CI/CD - something that replaces Jenkins or Azure DevOps or CircleCI as a way to continuously deliver changes to your Pulumi stacks into various environments. The benefit being it lives inside the Kubernetes cluster - an environment you have a lot of control over in term os permissions, operations, etc. • As a cloud-native GitOps solution in the mold of Flux or Argo, primarily for managing continuous delivery of Kubernetes workloads (but also potentially cloud infrastructure) • As a richer variant of projects like CrossPlane or the AWS Service Operator which provide a fixed set of CRDs for managing specific cloud resources from the Kubernetes API. With the Pulumi Kubernetes Operator, you can manage any cloud infrastructure you want to describe with a Pulumi program via your Kubernetes cluster. Put together, the pattern that we've seen from several of the early interest in the Operator is a platform team building cloud infrastructure building blocks (Pulumi projects), and then exposing those to other service teams to instantiate as needed (where those other teams use Kubernetes YAML as their interface, not necessarily writing Pulumi code). This isn't the only relevant pattern (the operator really opens up a lot of new automation scenarios!), but it is one we've seen several times that I'm particularly excited about.

Very nice! 👍

kube2pulumi is awesome

@broad-dog-22463 Really excited to see kube2pulumi! This has been something I've been waiting for for a long time! I think I've found a yaml fragment that it doesn't seem to handle.

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health {
          lameduck 5s
        }
        ready
        kubernetes CLUSTER_DOMAIN REVERSE_CIDRS {
          fallthrough in-addr.arpa ip6.arpa
        }
        prometheus :9153
        forward . UPSTREAMNAMESERVER {
          max_concurrent 1000
        }
        cache 30
        loop
        reload
        loadbalance
    }STUBDOMAINS

This is from the coredns repo https://github.com/coredns/deployment/blob/master/kubernetes/coredns.yaml.sed Line# 42

Thanks @ancient-megabyte-79588 ! We’ll take a look at those - but if you want to open an issue as well the project is at https://github.com/pulumi/kube2pulumi.

@white-balloon-205 My test was using the live Pulumi Web App.. I don't know if that is relevant. I will create a github issue in the repo though for sure.

Yeah - the website just uses the same

kube2pulumi

tool under the hood - so issues in that repo makes sense. We should actually include a link in the site to the repo for reporting issues. Thanks again!