thinking that the best option would be to create a component resource which is scoped (i.e. named per cluster) and have all the other stuff hang on that.

easier to set the parent as that definetely tracks 😉

aaand of course it doesn't. sigh.

is there a way to interrupt an update (manual timeout early?) often, I realize my mistake while I'm `pulumi up`'ing, but alas, I can't cleanly terminate what's going on as usually that invalidates the stack's state and creates dirtier problems...

there is customTimeouts on the CustomResourceOptions of the kubernetes provider..

https://www.pulumi.com/docs/reference/pkg/nodejs/pulumi/pulumi/#CustomResourceOptions which is opts of https://www.pulumi.com/docs/reference/pkg/kubernetes/provider/

how this might be modifiable at runtime though is a different question..

it's a bit frustrating that k8s helm always takes the pulumi resource name as its name input, all I can do is set a "prefix" and not override that. That means I have to do some string replacement on the variables I can use for component naming so they don't collide in the stack and are able to be created - but the names get horrible when the chart doesn't have a "fullNameOverride" value

I'm trying to add a

taint

to my

eks.ManagedNodeGroup

I see it under

Supporting Types

here . but I am not sure how to access it. am I missing something silly?

I have a kubernetes secret managed by Pulumi (as part of a larger stack). I want to stop managing the secret via Pulumi, is there a way to do that without having Pulumi nuke the secret?

I added Grafana's helm chart using pulumi, and while it works great, every

pulumi up

detects changes in a secret and in an annotation (checksum/secret). How do you use

ignoreChanges

with helm chart's sub resources?

Hi everyone. I'm currently debating the merits of managing K8s deployments in Pulumi vs. Helm. I already provision the K8s infrastructure (cluster, etc), but have not yet embraces making K8s API calls (to deploy, etc) from within Pulumi. Am I right in assuming that Pulumi can be a full replacement for Helm -- for example, it can compute the diffs in desired/deployed K8s resources and make the necessary changes (such as deleting a Service if you've deleted it's definition in the Pulumi code). I do like the idea of colocating infra provisioning with app deployment, but I do worry about the ability for a corruption in state file due to some bad/unlucky infra provisioning preventing progress in making application deployment changes inside K8s. Does anyone have thoughts on how to weigh the pros and cons here?

ive created a custom ComponentResource of which a child resource is a helm chart (ingress-nginx specifically). when using this ComponentResource in a stack, it does not appear that changes to helm config result in changes to changes to resources created by the helm chart. does anyone have thoughts on this?

I’m creating an apps/v1:Deployment. Something is wrong in my spec I think, but Pulumi is masking my entire spec as a Secret making it hard to debug? Is there something causing this? I don’t think I’m even using a secret as an input to the Spec? eg,

+ kubernetes:apps/v1:Deployment: (create)
        [urn=urn:pulumi:sandbox-usw2a::app-60-app::kubernetes:apps/v1:Deployment::be-innkeeper-deployment]
        [provider=urn:pulumi:sandbox-usw2a::app-60-app::pulumi:providers:kubernetes::k8s::15e3e6ce-24ca-419c-a449-3238c4372aa6]
        apiVersion: "apps/v1"
        kind      : "Deployment"
        metadata  : {
            labels   : {
                <http://app.kubernetes.io/managed-by|app.kubernetes.io/managed-by>: "pulumi"
            }
            name     : "be-innkeeper"
            namespace: "default"
        }
        spec      : "[secret]"

anyone here know how to read in a K8s entity that isn't managed by Pulumi? I need to annotate an EKS provided service account programatically

but the only methods I see are

corev1.GetServiceAccount

which requires a Pulumi ID

Hey Guys Good Morning, I am deploying a helm chart with pulumi and every service name got an extra hash value at the end. How can i disable this auto naming with pulumi ?

Is there a way to find Helm created resource other than this?

wordpress.getResourceProperty("v1/Service", "wpdev-wordpress", "status");

This approach doesn't work when some charts like kube-prometheus truncates the long resource names. For example chart creates two different service names based on pulumi resource name.

new k8s.helm.v3.Chart(
      `kube-prometheus-example`,
      ...
)

new k8s.helm.v3.Chart(
      `kube-prometheus-example1`,
      ...
)

generates following Services..

kube-prometheus-example-kube-alertmanager
kube-prometheus-example1-kub-alertmanager

In such cases I cannot lookup the service its created..

I'm trying to install the kube prometheus stack via its helm chart: https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack ... I've seen a few people mention it in the slack channels. What transformations are you using to get it to work with pulumi?

I am trying to install kube-prometheus-stack via its helm chart. It creates a couple of crds and I want to create some resources using those crds as well. What’s happening is, the creation of these resources using those crds fails (error - resource of type doesn’t exist) because it somehow executes before the kube-prometheus-stack has finished installing. The kube-prometheus-stack creation and the resources are all in different files. I tried adding

dependsOn

to the custom resources but that does not help. Is there any example where I see dependent k8s resources being created from different files. Also, I am using typescript. Any help is highly appreciated.

Hi, today I updated the "values" part of a helm chart (v3) I deployed with pulumi, but pulumi didn't notice any change, therefore reported "everything unchanged". Is this a known limitation or should I dig deeper to (maybe) reveal an issue?

Pulumi works well with modern “immutable infrastructure” architectures, where bootstrapping and patching are unnecessary. In such cases, configuration management is not needed in the usual sense.

hi! how does immutable infra works with persistent storage in k8s? please see this example: i have deployed a statefulset application on k8s, whose pods and persistent volume live on a node(machine). now i am going to do some system update to that machine(node). for “immutable infrastructure”, it will destroy the old one, which will definitely leave my app in error state. i believe ppl who designed "immutable infra" already figured a elegant solution for the above. can someone share your thoughts here? thanks!

You'd need to create a new node pool and do a blue/green type of upgrade. This isn't something an Infrastructure-as-code solution will do for you

I'm assuming most of us are using Server Side Apply at this point. How do I configure the manager name of fields managed by pulumi?

just curious, for ppl who use pulumi rke provider, if you update some config/parameter of a existing cluster, the cluster will get updated in place right? it won't be destroyed and recreated

I am attempting to use the pulumi_tls module to populate a k8s secret how do I Base64 encode the output of the tls module for use in secrets?

Hello folks, I have a quick question about how to install Grafana using its Helm chart. What I'm trying to do is to install Grafana with a datasource, but it fails to read the configuration when using Pulumi's

k8s.helm.v3.Chart

values

parameter. I suspect it happens because one of the keys is

datasources.yaml

which contains a

.

and may be expanded to something the helm chart does not understand. This YAML works when installing the chart not using Pulumi:

datasources:
  datasources.yaml:
    apiVersion: 1
    datasources:
      - name: "Cinnamon Prometheus"
        type: prometheus
        access: proxy
        url: <http://prometheus-server.default.svc.cluster.local>
        editable: true

But it fails when using Pulumi (typescript api):

new k8s.helm.v3.Chart(
  "grafana",
  {
    chart: "grafana",
    fetchOpts: {
      repo: "<https://grafana.github.io/helm-charts>",
    },
    values: {
      datasources: {
        "datasources.yaml": {
          apiVersion: 1,
          datasources: {
            name: "Cinnamon Prometheus",
            type: "prometheus",
            access: "proxy",
            url: "<http://prometheus-server.default.svc.cluster.local>",
            editable: true,
          },
        },
      },
    },
  },
  { provider: clusterProvider },
);

How would one scale the PV/PVC of a statefulset deployed via helm/pulumi? Changing the storage value in the statefulset is ignored (not even a replace which is probably a good idea :))

is kubernetesx still maintained? Some fairly simple things (e.g. a pvc.mount() in both an init container and main container) give naming collisions.