@mhaller wrote:
Thanks for posting this. Although, I had heard deprecation was coming, it is good to see it stated clearly here.
I’ve started to use
cloudflared
in our cluster for internal web applications. Initially I was using the sidecar approach but later decided on configuringcloudflared
in its own deployment and running it in its own pods. This means instead oflocalhost
, the tunnel is using a service address for my application as the--url
.There are some advantages to this in my view. I can scale the the tunnel and app independently. For example, there are cases where I am exposing just one path of a production application, and I see no need to have as many tunnels as I have production pods. Because we are tunneling internal applications (or internal paths of production web applications, say like
/admin
), I don’t have the same availability requirements as I do with the production workloads.I also had some concerns about the grace of restarts with the sidecar model. My testing wasn’t complete, but it seems like there could be shutdown issues unless one used a
preStop
hook. (Imagine the application container stops before the tunnel, and before the next LB health check.)For us, a
cloudflared
deployment per app gets a good balance of runtime independence and localized configuration, which I think the ingress controller was bringing as well though using a more complex api. If you already had sidecar injection machinery, and maybe different usecases for Argo, the sidecar model would likely work well.Definitely welcome the published Docker image - it would be helpful to use something official.