Hi all, I have to update a secret, but `pulumi up`

does not show any changes. If I delete the secret using kubectl it does not get recreated the next time I do `pulumi up``

Only chance I had so far is to destroy the cluster and recreate it (which is bad). I see that destroy has the flag -t, but it seems that the resource name I am using is wrong. Is there a better way to work with this?

can anyone help -> https://pulumi-community.slack.com/archives/C84L4E3N1/p1596723191488400?

Hi, AWS EKS with Fargate requires that a patch is applied to CoreDNS' deployment. Is there a way to apply the patch using a Kubernetes provider? Is there an equivalent workaround? Thanks

On a related question, I need to get the YAML from a deployment, but I don't see any get* in the Kubernetes provider for Pulumi. Any ideas?

Documentation doesn't match the code or the examples: https://www.pulumi.com/docs/reference/pkg/kubernetes/yaml/configfile/ For example file_id is mandatory and here there isn't even a file_id

I'm trying to get information on a service in Kubernetes using Python, to no avail:

kubernetes.core.v1.Service.get("service", "kube-dns",
                               opts=pulumi.ResourceOptions(provider=kubernetes_provider))

This results in

Preview failed: resource 'kube-dns' does not exist

But:

$ kubectl --kubeconfig /tmp/kubeconfig get svc -n kube-system kube-dns
NAME       TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)         AGE
kube-dns   ClusterIP   10.100.0.10   <none>        53/UDP,53/TCP   3d22h

And yes, my kubernetes_provider is using the

kube-system

namespace

I didn't create

kube-dns

myself, it comes with EKS. I really don't understand how data sources work with Kubernetes, do they even exist?

Hey, I don't know if is my mistake or a bug. But when I am creating a presistent volume Claim using pulumi , the command pulumi up get stuck in the creation of the presistentvolume claim. I double check with kubectl and the PVC is in state pending but that it is because I don't have pod for that PVC. I think the PVC config is correct because i am converting yaml manifests to pulumi code

Q: Hey can some one clarify what is the impact of using k8s.yaml.ConfigGroup instead of using the pulumi API to declare the K8s resources?

is there any plans to support

helm hooks

? if helm chart has it, there is no way to install it

I'm trying to set up an EKS cluster and, in order to have it working with Fargate, I need to update the definition of kube-dns, which comes by default with EKS. The easy way is to get the dns.yml file from AWS and then just to a

kubectl apply

. I'm trying to use

yaml.ConfigGroup

to apply those resources, but Pulumi seems to be unable to update existing resources:

(...)
  kubernetes:core:ServiceAccount (kube-system/coredns):
    error: resource kube-system/coredns was not successfully created by the Kubernetes API server : serviceaccounts "coredns" already exists
(...)

Any ideas on how to bypass this? Importing those resources would be a tremendous amount of work (6 documents in that YAML file), also seems to be impossible (https://github.com/pulumi/pulumi-kubernetes/issues/1238) and it means doing manual changes and having multiple runs of Pulumi, which is a big no-no for automation.

message has been deleted

URN seems to be too tightly coupled to helm generated resource names. ie. If I'm trying to install the same chart on two clusters - two distinct kubernetes providers - I get URN duplicates unless I start specifying `resourcePrefix`'s for the charts. However If I go that route I end up with names that are are often too long and break the 53 char rule to be passed to the helm

--name-template

arg which Pulumi is using under the hood AND unecessarily convoluted names for resources within the cluster.

Anyone got any recommendations for using Pulumi with multiple kubernetes clusters and staying sane with resource naming?

Ok... found https://github.com/pulumi/pulumi-kubernetes/issues/1225 reminder to folks like me who forget to look in github issues first.... look in github issues first!

@abundant-airplane-93796 Are you using one stack to create two clusters?

yes

In our env, we have decided to have a single cluster per stack approach. We do have multiple clusters per Azure subscription, but we still do a 1 cluster per stack approach.

right now I have two clusters per stack as I need windows nodes in one cluster, but want to use some incompatible gke features in another. however, even if it weren't for that split, at some point I'll probably want to take this multi-regional and have clusters across several regions in a stack, that are identical to each other. doing a stack per cluster seems like overkill - though I will admit I can see some benefits

either way though, I feel like the URN's for helm resources should be tied to the cluster so that pulumi can support multi-cluster in a stack without these kinds of issues if folks wanna use it

We treat a stack as mostly a configuration boundary, such that everything in the stack gets configured the same. We wanted to be able to update/reconfigure clusters independently, so that contributed to our stack per cluster approach.

With our CI/CD pipelines, it is fairly trivial to update multiple stacks concurrently if we want.

I currently have 2 stacks per environment one sets up core stuff like the gke network/nat etc, and also the creation of the clusters and then the other configures what runs on those clusters. I can potentially see breaking the second stack into per-cluster stacks. going to give it more thought

For our environments, we have: • Network application that has 2 stacks, lowers (dev/test envs) and production. That ensures vnets/subnets are built to look exactly the same, but use different IP ranges per environment. This application would run VERY infrequently. Only when we wanted to add subnets probably. This application is the considered "the base" that everything else will build on • Kubernetes application - this has 6 stacks. lowers-shared, cluster per lowers environment (dev/test/preprod), production-shared, and production. The application ensures that all clusters are structured the same, but vary based on stack configuration values. This application also installs default kubernetes resources that all clusters should have. (nginx + ingress controllers, fluentd, etc) • LoB Applications application(s) - each LoB app that we create (microservices) are responsible for their own deployment (via a pulumi app) into the core infrastructure. All of the exported consts from the kubernetes stacks are available via stack references, so an application has a stack per target environment that shares the same name as the kubernetes cluster that it is destined to run in. Yes, this is a lot of stacks, but it allows us to evolve the pulumi applications, and test them in a specific environment, and also to test various configuration changes in specific environments, and then we migrate those changes up through all environments, testing as we go.

Why would one use the pulumi-kubernetes-operator instead of running

pulumi up

as part of a CI pipeline?

Hi I am running aws eks using pulumi and deployed an helm chart to the cluster. This setup is running in production for the past few months. Today i ran

pulumi refresh

and update the stack but now every time i try to run

pulumi up

i see that according to preview pulumi is about to delete all helm chart resources. How can i understand the reason for this ? i definitely don't wont to delete those resources from the cluster

How can I retrieve the value of an annotation on a kubernetes resource? ie. I have a service with the following annotations:

metadata:
  annotations:
    <http://beta.cloud.google.com/backend-config|beta.cloud.google.com/backend-config>: '{"default": "istio-ingressgateway"}'
    <http://cloud.google.com/app-protocols|cloud.google.com/app-protocols>: '{"https":"HTTP2"}'
    <http://cloud.google.com/neg|cloud.google.com/neg>: '{"ingress": true}'
    <http://cloud.google.com/neg-status|cloud.google.com/neg-status>: '{"network_endpoint_groups":{"443":"k8s1-5487ae62-istio-system-istio-ingressgateway-443-811432aa"},"zones":["us-east1-d"]}'

I'd like to extract the value of the

<http://cloud.google.com/neg-status|cloud.google.com/neg-status>

annotation in such a way that I can use it to retrieve a gcp network endpoint group like:

const neg = gcp.compute.getNetworkEndpointGroup({
  name: "k8s1-5487ae62-istio-system-istio-ingressgateway-443-811432aa",
  zone: "us-east1-d"
})

I'm usually ok working with outputs, but pulling something that's in json in a property of a property has got me beat right now

Is it possible me to manage, deploy stuff to existing Kubernetes (AKS) cluster ?

Not created with Pulumi