https://pulumi.com logo
Title
p

prehistoric-laptop-47240

11/29/2022, 12:04 PM
Anyone is using the ingress (for kubernetes) package ? I'm wondering why I meet the current issue : When I need to build an image for a service, my ingress gets a "connexion refused" error, and fails to create. I need to do a second
pulumi up
when everything else is ready to have it working. I'm using it exactly like in the examples. Any idea ? :s. All I saw is that if i'm pulling an image and not building it, everythings seems to work fine...
m

many-telephone-49025

11/29/2022, 12:06 PM
p

prehistoric-laptop-47240

11/29/2022, 12:13 PM
Hi ! Exactly ^^. I'm using the typescript wrapper but that's it.
m

many-telephone-49025

11/29/2022, 12:31 PM
Do you have by any chance an example repo?
Otherwise I need to reconstruct an example to understand the issue
p

prehistoric-laptop-47240

11/29/2022, 1:18 PM
Hmm, I can create a repo to isolate the issue if you want, but everything is a work in progress and there might be stuff which doesn't have anything to do with the issue ^^'
m

many-telephone-49025

11/29/2022, 1:19 PM
I can create one too. So as far as I understood, you deploy the ingress controller and then your services/deployment of your own app
and during this up you get the error message?
p

prehistoric-laptop-47240

11/29/2022, 1:25 PM
Tbh, I'm new to everything around kubernetes, and I'm learning so I can get better at it ^^'. I'm fine developping around with docker-compose, but I want to understand the whole process of modern development under micro services context, so I'm trying to learn kubernetes basics trough Pulumi (as a dev.... :')). So to summarize , I have a folder called "services" with 2 services (one backend for auth with fastify, one frontend which is a vue 3 project). I have a folder named infrastructure with Pulumi and some helpers in TS to easily and automatically integrates any created services. The process is this : • I create a namespace • I create the Ingress controller • I have an automation process looking for each loadable services, dynamically loads them and : ◦ Build a local image (no push) ◦ Build the service (Cluster IP) ◦ Build the deployment • When everything is done, build the Ingress and inject configuration exposed by a loadable service. So far, only my auth service is declared "loadable", which means than the frontend is out of the equation.
Doing things like this, yes, I get an error message saying "connection refused". Then on the next pulumi up command, it runs fine. It sounds like it doesn't know when it can start, or maybe there is a timeout leading to a connection which fails. I don't know how to debug this :s
My env is the latest version of Pulumi, node 16, Kubernetes in a WSL 2 ubuntu distro, injected thanks to Docker Desktop k8s intergration (using default stack docker-desktop)
The exemples works "almost" fine (sometimes I have to reset the cluster through docker desktop as it fails randomly). The only difference I can find is that I have local image building in the process, where the exemples uses an already existing image which is pulled
Here is the complete output when I'm running
pulumi up
for the first time
I hope this brings enough context, and thank you again for your kind support
m

many-telephone-49025

11/29/2022, 1:40 PM
yes!
p

prehistoric-laptop-47240

11/29/2022, 2:44 PM
Tell me if you need a dedicated repo, I'm fine with making a minimal project for it. It's already super kind of you to help me, and I don't want to eat your time like it's nothing 🙂
m

many-telephone-49025

11/29/2022, 4:45 PM
Hi @prehistoric-laptop-47240 it worked for me. Please have a look into https://github.com/dirien/pulumi-ingress-test Maybe I use a different code! Btw: I use Civo as Cluster.
p

prehistoric-laptop-47240

11/30/2022, 8:17 AM
Oh wow, thank you so much for your time and effort. I read how you created this project, and I have to admit, I don't see any conceptual difference... I'm wondering if it could be something about env, such as docker-desktop k8s integration... hmm...
And also, I don't push my image to any repository ^^'. This might change something
Weird stuff happening next : I cleaned my images, to rebuild / pull everything and now I get (still from Helm) :
rendered manifests contain a resource that already exists. Unable to continue with install: IngressClass "nginx" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-name" must equal "myctrl-helm-9b125594": current value is "myctrl-helm-b24ad579"; annotation validation error: key "meta.helm.sh/release-namespace" must equal "medcms-fd1b7965": current value is "medcms-8267ab2a"
m

many-telephone-49025

11/30/2022, 8:51 AM
Try to delete it by hand
are you runing on docker-desktop?
p

prehistoric-laptop-47240

11/30/2022, 9:54 AM
Yes
m

many-telephone-49025

11/30/2022, 11:13 AM
I tried it on a cloud provider. On my docker-desktop I can' get the status to ready, as it is not updating the status of the ingress with the loadbalancer ip
I have to give it a try again or use rancher desktop or kind/minkube
p

prehistoric-laptop-47240

11/30/2022, 12:20 PM
I'm afraid I'm doing a beginner mistake... I was extracting the name for the ingress service name from a created service metadata name instead of giving it the same string I gave to generate the name. Maybe it's different ?
m

many-telephone-49025

11/30/2022, 12:23 PM
oh, yes. Either you fix the names so there is no hash at the end. Or you use the output of the service as input for the ingress service definition
could be the reason why the webhook is failing
p

prehistoric-laptop-47240

11/30/2022, 12:23 PM
I gave to the ingress, my service.metadata.name output<string>
I'm trying to give the string I used in the name of the service instead
Just in case they can be different
m

many-telephone-49025

11/30/2022, 12:26 PM
could you try the default namespace too?
just to rule this out too. In my tests I used the default NS for my deployment
p

prehistoric-laptop-47240

11/30/2022, 12:35 PM
Oh, actually, it does work without namespace x)
Or not, nvm, it's random
m

many-telephone-49025

11/30/2022, 12:42 PM
so as far as I understood, you deploy the controlle into the default ns any your deployment into a specific ns
p

prehistoric-laptop-47240

11/30/2022, 12:54 PM
I'm having a namespace shared and used the ingress and all its services
I tried without any namespace as you suggested, but it still generates the error from earlier
Using a string for the service name, instead of the service.metadata.name seems to solve the issue :s
I'm not sure I understand when I should use a string or a metadata... To share my namespace name, I created a namespace from a resource, and used namespace: namespace.metadata.name To me, it makes sense, as It's a generated name. So I was thinking that I would have to do the same to safely share names from any kind of resource :s
m

many-telephone-49025

11/30/2022, 1:04 PM
ok I got smth similar
let me check 🙂
p

prehistoric-laptop-47240

11/30/2022, 1:05 PM
Actually, weird fact : I logged the inner string inside the Output type, and the actual name I give as a string, and they are equal, even when it doesn't work
what the xD
m

many-telephone-49025

11/30/2022, 1:10 PM
So now it works!
You need to wait with the ingress creation that the controller is fully deployed
so i put a
pulumi.DependsOn([]pulumi.Resource{namespace, ingressController})
in the creation of the ingress resource
so it will wait until both other resources are deployed and ready
p

prehistoric-laptop-47240

11/30/2022, 1:18 PM
😮 that could explain the randomness of the issue. Trying right now
Hmm, that smells great 😄.
So far so good, thank you a million times !
Oh, sometimes I have : kubernetes:networking.k8s.io/v1:Ingress medcms-ingress *creating failed
context deadline exceeded
Hmm, after a cluster reset, it's working fine again 😛
m

many-telephone-49025

11/30/2022, 4:09 PM
ok. maybe some glitched resources