oh, and i know i could have destroyed them in the right order, but i wanted to update something on the cluster and messed them up in an inrecoverable state as well.

Hi, How would you go about adding flux into the cluster? It requires a cli to be run as indicated here.

Can anyone give my an idea how to debug this error message. I'm trying to deploy

kube-prometheus-stack

from

<https://prometheus-community.github.io/helm-charts>

. I get the same error for a few of the resources

error: 2 errors occurred:
        * the Kubernetes API server reported that "kube-system/kube-prometheus-stack-kube-controller-manager" failed to fully initialize or become live: 'kube-prometheus-stack-kube-controller-manager' timed out waiting to be Ready
        * Service does not target any Pods. Selected Pods may not be ready, or field '.spec.selector' may not match labels on any Pods

Using AWS EKS and Typescript. Is there any way to enumerate a list of IAM users from an existing IAM group? I can use the 

aws.iam.Group.get

 method to get the group, but I'm not sure how to actually access the existing group membership. The ultimate goal is to pull in a list of users to apply specific RBAC permissions to. Is there a better way?

Trying to get the hang of the relationships between k8s and kx - I don't see how kx can set the context for the cluster in the kubeconfig things should be applied to, is the intention that I set up k8s.Provider first to lock down the context and then pass that as a provider: argument to kx?

Hello. Have anyone experienced any issues with deleting kubernetes namespaces? When I remove a namespace that has been provisioned by pulumi it ends up in a "terminating" state, like described here: https://stackoverflow.com/questions/52369247/namespace-stuck-as-terminating-how-do-i-remove-it#:~:text=This%20is%20caused%20by%20resources,controller%20is%20unable%20to%20remove.&text=You%20can%20edit%20namespace%20on,enter%20or%20save%2Fapply%20changes.

Does anyone have advice on silencing helm warnings? Every time I run I get 1000 warnings about CRD fields that will be deprecated in 3 versions and all the unsupported hook stuff.

General question not really related to pulumi but I have to build images periodically at runtime to be deployed via k8s in Azure This has to be optimized for speed I could a) spin up virtual machine(s) and run the build there (costly, slow to start up, hard to maintain, hard to scale) b) build (using buildah?) in a container possibly using KEDA or just a scaleset or similar Has anyone else faced this problem, any thoughts? Sorry for OT, I can remove this if needed :)

If you're using ACR you can use its build tasks? 😉

And just for good measure - this is also exposed via pulumi 😉 https://www.pulumi.com/docs/reference/pkg/azure-native/containerregistry/buildtask/

And lastly - if you're wanting to build those images as well - and you're running pulumi regardless - why not try https://www.pulumi.com/docs/reference/pkg/docker/

Is there any way to force the Kubernetes provider to overwrite instead of ‘create’ if I have no prior state?

Running this in CI and I’m currently not tracking state

Only option.I have at the minute is to delete the old resources prior (Which is fine as it’s a staging env)

Probably going to add some state management in GCS later

is there a way to kick of a k8s.batch.v1.Job only wait for lets say 2 min and then mark the job as succesfull eventhough it is still processing ? if that’s not possible, is there away to extend the time pulumi waits for just this job to complete?

is there a way to force a restart of all pods in a namespace with pulumi ?

No there's not. You'd need to do something like

kubectl -n <namespace> rollout restart deployment <name>

if they're connected to a deployment or stateset you could in principle scale it down to 0 and then back up again.. but that's a bit wonky. I might be using that in combination with automation for tasks related to scaling up persistent volume claims

Running into this issue with a new EKS deployment:

kubernetes:apps/v1:Deployment (web):
    error: 2 errors occurred:
    	* the Kubernetes API server reported that "my-application/web-v845050y" failed to fully initialize or become live: 'web-v845050y' timed out waiting to be Ready
    	* Attempted to roll forward to new ReplicaSet, but minimum number of Pods did not become live

If I watch the cluster I can see all of the pods (2) in the RS stand up and become Ready, and the ReplicaSet/Deployment reports them all as up + Ready/Up-to-Date inside of 2 minutes. This is happening for every Deployment I have configured on this cluster. Tried latest

@pulumi/kubernetes

Node module, I’m on latest Pulumi CLI binary, on EKS 1.19. I tried blowing everything up and redeploying. Nothing of note when describing the Deployment or ReplicaSet. It’s like the Pulumi client is just ignoring the state of the ReplicaSet. Any assistance would be appreciated, there’s very little out there on the Googles other than what I’ve already tried.

Hey peeps... I am tryping to upgrade an AKS cluster and add a VMSS (node pool) to the cluster. When I do the pulumi up, I'm getting this scary "I'm going to replace your resource group" message/warning.

As far as I know, replacing a rg would be a delete/create operation in Azure, and deleting an RG deletes everything inside of it. This particular RG contains all of our lower environment control planes. I've tried to do a non-

import

and an

import

of the resource group and and the cli always shows as wanting to replace it. The

details

(when trying to

import

)doesn't seem to indicate why it wants to replace it.

=>azure:core/resourceGroup:ResourceGroup: (import-replacement) 🔒
        [urn=urn:pulumi:dpts-shared::KubernetesCluster::azure:core/resourceGroup:ResourceGroup::rg-kubernetes]
        [provider=urn:pulumi:dpts-shared::KubernetesCluster::pulumi:providers:azure::default_3_52_1::04da6b54-80e4-46f7-96ec-b56ff0331ba9]      
        name: "rg-kubernetes"
    +-azure:core/resourceGroup:ResourceGroup: (replace) 🔒
        [id=/subscriptions/ad73ec2e-0337-4de5-983c-3944fcb68be8/resourceGroups/rg-kubernetes]
        [urn=urn:pulumi:dpts-shared::KubernetesCluster::azure:core/resourceGroup:ResourceGroup::rg-kubernetes]
        [provider: urn:pulumi:dpts-shared::KubernetesCluster::pulumi:providers:azure::default_3_6_1::09b02d81-f05d-4347-a5d2-831be11283e0 => urn:pulumi:dpts-shared::KubernetesCluster::pulumi:providers:azure::default_3_52_1::output<string>]
        id      : "/subscriptions/ad73ec2e-0337-4de5-983c-3944fcb68be8/resourceGroups/rg-kubernetes"
        location: "centralus"
        name    : "rg-kubernetes"

Do you have any insights as to how I can get my pulumi app to not touch this resource-group? I've added the

protect

statement to it and I've also added a

lock

in the Azure Portal. I do NOT want to accidentally delete all of our control planes and subsequently delete all of the clusters.

This is the details output when I do not try to import the existing ResourceGroup:

If i wanted to ignore changes to the image of a container in a deployment, which is a part of a config group, what would i have to do? I've read this article: https://www.pulumi.com/docs/intro/concepts/resources/#ignorechanges. I am unsure what shape the "root" is in the scenario where i am passing multiple yaml files in a config group. Would the root be an array? 🤔

pulumi up:

error: resource default/azure-secret was not successfully created by the Kubernetes API server : secrets "azure-secret" already exists

but:

$ KUBECONFIG=./kube.yaml k get secret azure-secret -n default   
Error from server (NotFound): secrets "azure-secret" not found

any leads for debugging this? kube.yaml is from:

p stack output kubeconfig --show-secrets > kube.yaml

with an azure-native ManagedCluster and pulumi_kubernetes, how do I: 1. create a namespace conditionally (check if it exists, create if if doesn't) 2. create a secret scoped to the namespace

Anyone ever experience a refresh on a helm chart causing pulumi to think

apiVersion

on an ingress is different than what it actually is. Basically in reality my ingress is

extensions/v1beta1

but when I refresh pulumi changes state to

<http://networking.k8s.io/v1|networking.k8s.io/v1>

and then when I preview it shows it wanting to change it to

extensions/v1beta1

which it already is... I'm also seeing this

Ingress has at least one rule that does not target any Service. Field '.spec.rules[].http.paths[].backend.serviceName' may not match any active Service

which is also around this helmchart and ingress. I found an issue form 2020 around this. Basically then it was simply a misconfigured helmchart. However, I have confirmed that my labels are correct and my label selectors all line up.

How can I tell Pulumi to overwrite all resources that are already there?

--replace

requires that you specify each resource, but there are quite a lot, I just want it to clobber everything.

I would like to automate our deployments, but want our abstractions to take into account the changes between versions of Kubernetes, e.g. APIs being promoted which leads to other resource versions, different annotations etc. What is the best way to find out against which version of Kubernetes we are working? So far I looked in the Kubernetes

Provider

class but that doesn’t expose the info. Is there a standard way of getting this using the

pulumi-kubernetes

provider?