Anyone know if it's safe to use https://www.pulumi.com/docs/reference/pkg/kubernetes/autoscaling/

v2beta2 here ?

I see in the documentation for

kustomize

support that transformations "happen in memory, and are not persisted to disk." Is this still true if the

RenderYamlToDirectory

property is set on the Kubernetes provider?

Anyone have an example of how to add non-existing keys and "sub-values" using a transformation? For example, let's say I have this YAML:

apiVersion: <http://kustomize.config.k8s.io/v1beta1|kustomize.config.k8s.io/v1beta1>
kind: Kustomization
resources:
  - ../../base

and I'd like to add this to that YAML:

patchesJson6902:
  - path: name.json
    target:
      group: <http://infrastructure.cluster.x-k8s.io|infrastructure.cluster.x-k8s.io>
      kind: AWSCluster
      name: base
      version: v1alpha3

Is this possible using a transformation?

anyone could be able to help with auto scaling? i have a deployment that has one replica and it's targeted with an autoscaler that i set to resource cpu metrics.. after running the whole stack in GCP everything is up only the scaler shows the following status:

message: 'the HPA was unable to compute the replica count: missing request for cpu'

What's the preferred future proof way (as much as anything can be) to deploy apps on to a kubs cluster (eks) ?

using helm right now, is that going to be around going forward ?

Hey guys does Pulumi work with microk8s? I use this to run k8s in a hyper-v linux vm.

@gorgeous-egg-16927 What's a good way to handle pre-existing resources that I don't want to import to be pulumi managed but that I want to delete to clear the way for pulumi managed resources? Specifically, looking at https://docs.aws.amazon.com/eks/latest/userguide/windows-support.html, which is kind of a mess:

vpc-resource-controller-role

cluster role,

vpc-resource-controller-role-binding

cluster role binding, and

vpc-resource-controller

service account already exist after standing up a new eks cluster, while the

vpc-resource-controller

deployment does not exist, but the cluster role is different from the guide's download link and is missing config map access (so needs modification anyway), ... so I want to delete the lot iff they exist (and not managed by pulumi) and create new ones with consistent

vpc-resource-controller

names throughout, which would leave duplicates for cluster role and cluster role binding and clashes with the service account if I can't delete the pre-existing ones first. 🤔

Also, what's a good way to do the webhook-create-signed-cert.sh dance to automate creating a secret for the

vpc-admission-webhook

?

hi, i’ve tried to install ingress-controller using this code and it failed: it turns out, admission create job didn’t start. I’ve tried to install it with helm CLI and it went fine, — “admission create” job appeared and completed

const nginxController = new k8s.helm.v3.Chart(`core1-${stack}`, {
  version: "3.3.0",
  chart: "ingress-nginx",
  fetchOpts: {
    repo: "<https://kubernetes.github.io/ingress-nginx>"
  },
  values: {
    controller: {
      admissionWebhooks: {
        enabled: true,
        patch: {
          enabled: true
        }
      },

      service: {
        annotations: {
          "<http://external-dns.alpha.kubernetes.io/hostname|external-dns.alpha.kubernetes.io/hostname>": "<http://mydomain.net|mydomain.net>"
        },
        externalTrafficPolicy: 'Local',
      },

      config: {
        "use-forwarded-headers": 'true'
      }
    }
  }
}, { provider: cluster.provider });

Is there any way of how to debug what was rendered and sent to k8s?

I assume Job wasn’t, because it didn’t appear in stack preview

are there any plans to start doing three way diff for kubernetes objects?

ok, so I’ve cloned those charts and played around with it locally — if I remove

"<http://helm.sh/hook|helm.sh/hook>": pre-install,pre-upgrade

from metadata/annotations in Job template than Pulumi creates the Job. It looks like those hooks are not supported porperly: I got this problem while doing clean install

created an issue: https://github.com/pulumi/pulumi-kubernetes/issues/1335

I’m adding two TS

exports

to my Pulumi project from a k8s

Service

resource but only a single output is created:

exports.temporalFrontendEndpoint = temporal_frontendService.spec.externalName;
exports.temporalFrontEndName = temporal_frontendService.metadata.name;

results in:

--outputs:--        
  + temporalFrontEndName: "temporal-frontend-vw2qfr65"

Any idea why the

externalName

is not created as an output?

Hi everyone, I'm facing some problems with my stack state, and I'm unable to fix.

I described it here, any lights? https://github.com/pulumi/pulumi-kubernetes/issues/1013#issuecomment-701544909

TLDR; DigitalOcean rotates the kubeconfig, and everytime it does that, pulumi is unable to connect to the cluster due to server asking for credentials. I tried doing a refresh with

--target

into the

digitalocean.KubernetesCluster

, which brought a new kubeconfig content, but for some reason it doesn't seem to be used by the provider at all. Still getting

configured Kubernetes cluster is unreachable: unable to load schema information from the API server: the server has asked for the client to provide credentials

Does Pulimi understand states outside of its s3 bucket? Like, say docker images? Hmm, if the only thing I change in my Pulimi is the replica count for a k8 deployment would Pulimi do a full redeployment by making a new image in AWS ECR even though the codebase has not changed?

I think it’ll depend on how your Pulumi code is written.

I don’t think Pulumi implicitly knows if the codebase has changed or not compared to what is on ECR.

We manage the ECR deployment separate from the image tags deployed in our cluster. So we have a CICD process that will trigger a new container being tagged, created, and deployed to ECR based on our rules. Then in our Pulumi config we have an image version that is consumed by the Pulumi code and we manually manage that to control what version of the container is deployed where.

@loud-battery-37784 Honestly I’d chalk it up to a bug. If a

pulumi up

runs and the only thing that has changed is the replica count in

index.ts

(written using Pulumi APIs) then it shouldn’t really build the docker image again. But what bothers me is how unclear it is right now.

If i'm trying to pull an image from a private self hosted gitlab registry (under custom dns), to deploy on a kubs cluster

should i first deploy my private token using this

and then reference the image re yaml for k8s

ts
export const image = repo.buildAndPushImage("./app");

Running this twice where

./app

hasn’t changed since last time, should be no-op the second time and re-used the image already pushed since last time. I’d consider it a bug, not sure if I should post an issue, though.