4 ms·

> The notion that you need an 'ingress' pod AND an external load-balancer, just to be able to respond to internet traffic - and not even all internet traffic (o

> The notion that you need an 'ingress' pod AND an external load-balancer, just to be able to respond to internet traffic - and not even all internet traffic (only HTTPS) - is truly staggering. If you are on a cloud provider, the load balancer abstraction is handled for you by AWS load balancer or Google Compute load balancer so really a non-factor. I own and run a DevOps consulting company[1], and clients of course want to deploy their software on-prem which becomes significantly harder and more time consuming. Personally, I use MetalLB[2] by the folks at Google which creates a LoadBalancer abstraction and then use Traefik[3] in front of all deployments (containers). Traefik handles creating the SSL certificates using Let's Encrypt either via http or DNS challenge. The benefit here is only a single LoadBalancer is created pointing to Traefik, and then Traefik terminates https and routes to all the deployments (containers). [1] https://elasticbyte.net https://elasticbyte.net [2] https://metallb.universe.tf/ https://metallb.universe.tf/ [3] https://containo.us/traefik/ https://containo.us/traefik/

ForHackernews 6y ago
> so really a non-factor. As long as money is a non-factor, sure. If the idea is "just pay the cloudy tax" then I'd rather be on something like Heroku that actually makes my life easier, not harder.
- nodesocket 6y ago
  Ok, then just use a single cloud load balancer which points to Traefik running inside Kubernetes. Then you can run as many deployments / containers behind it as you wish.
  - ForHackernews 6y ago
    Yeah, that's what I said: you need a load balancer, and traefik (or one of a dozen other ingress things that do basically the same thing - have fun choosing) just to be able to respond to HTTPS requests.
    - pddp11 6y ago
      I've added some discussion/clarification of these issues in the post and addressed the issues in more detail in another comment: https://news.ycombinator.com/item?id=24224189 https://news.ycombinator.com/item?id=24224189 .
- treeman79 6y ago
  Shocks me when people don’t know how east heroku is. Okay I get it doesn’t work for all use cases. But it is such a gold standard for simplicity. I moved an entire company from a falling infrastructure to heroku in a month. No downtime. Multiple environments and pipelines. Now a company is a year into Kubernetes with no end in sight. Developers can barely function

ForHackernews 6y ago

> so really a non-factor. As long as money is a non-factor, sure. If the idea is "just pay the cloudy tax" then I'd rather be on something like Heroku that actually makes my life easier, not harder.

nodesocket 6y ago
Ok, then just use a single cloud load balancer which points to Traefik running inside Kubernetes. Then you can run as many deployments / containers behind it as you wish.
- ForHackernews 6y ago
  Yeah, that's what I said: you need a load balancer, and traefik (or one of a dozen other ingress things that do basically the same thing - have fun choosing) just to be able to respond to HTTPS requests.
  - pddp11 6y ago
    I've added some discussion/clarification of these issues in the post and addressed the issues in more detail in another comment: https://news.ycombinator.com/item?id=24224189 https://news.ycombinator.com/item?id=24224189 .
treeman79 6y ago
Shocks me when people don’t know how east heroku is. Okay I get it doesn’t work for all use cases. But it is such a gold standard for simplicity. I moved an entire company from a falling infrastructure to heroku in a month. No downtime. Multiple environments and pipelines. Now a company is a year into Kubernetes with no end in sight. Developers can barely function