This message was deleted.

Same here. It prob happens because the lb that gets created from the service isnt visible for pulumi. So it tears down the eks cluster, because it doenst seem to be any reason to uninstall everything first. But that leaves the lb, so that the vpc isnt empty … and yeah. Messed up state. What we did is that we separated it so that we only setup aws infra with pulumi, and roll out ingress controller etc with helm afterwards, then custom script to destroy that uninstalls the ingress controller first. I would love to set it up so that we precreate the lb ourselves and tie the ingress controller to that lb with service type nodeport instead of type loadbalancer.

But shouldn't the LBC on deletion via Kubernetes wait until the LB was deleted, remove the finalizer from the Ingress and THEN shut down? I wonder if it has something to do with a SIGKILL beeing initiated by Kubernetes/Docker because the shutdown of LBC takes to long after a SIGTERM. And maybe the LBC couldn't completed a graceful termination.

Thanks for the ping back @bored-barista-23480!

You're welcome. 😉

@bored-barista-23480 I started to look into it and Im not sure how to implement it. Would you mind showing some code? Is it the

new k8s.helm.v3.Chart

that has dependsOn the cluster somehow? If so, how do I say ready? Is it something like this?

const cluster = new eks.Cluster(clusterName, {...});

new k8s.helm.v3.Chart('ingress-nginx', {
    version: '4.0.17',
    chart: 'ingress-nginx',
    fetchOpts: {
        repo: '<https://kubernetes.github.io/ingress-nginx>',
    },
}, {
    dependsOn: [cluster],
});