Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Voyager – Kubernetes Ingress Controller Releases v12.0.0-RC.2

github.com

Post reply on HN
Print view View original

1–10 of 14 posts

Re: Voyager – Kubernetes Ingress Controller Releases v12.0.0-RC.2

#2

Post by llarsson »

This is the first I hear about this project. Is anyone using it and able to say something about how it works for them and, in particular, if it works well for bare metal clusters?

I don't see myself using something like this on a public cloud when I could just use an Ingress Controller offered by the cloud provider unless there are very good reasons for it. Which there might be! Which is what I ask for. :)

Re: Voyager – Kubernetes Ingress Controller Releases v12.0.0-RC.2

#3

Post by dvcrn »

llarsson wrote: post #2

This is the first I hear about this project. Is anyone using it and able to say something about how it works for them and, in particular, if it works well for bare metal clusters? I don't see myself using something like this on a public cloud when I could just use an Ingress Controller offered by the cloud provider unless there are very good reasons for it. Which there might be! Which is what I ask for. :)

Digitalocean for example doesn’t offer a ingress controller for their clusters so I’m currently using the nginx one. Wonder how this compares

Re: Voyager – Kubernetes Ingress Controller Releases v12.0.0-RC.2

#6

Post by rdli »

Ingress controllers are quite confusing. Here's the general summary:

- General best practice for Kubernetes clusters is to have a proxy that routes external traffic to internal services

- This is because Kubernetes provides its own internal network space so each of your internal services aren't directly exposed externally (although you can do this if you like)

- Kubernetes has a spec for how this is done, the "ingress" spec

- An ingress controller implements the ingress spec

- The ingress spec is pretty limited in functionality (basic routing, no support for timeouts, as an example)

So if you just need to do basic routing, any ingress controller is going to do the same thing, more or less.

If you want to do more than that (which is very likely), then you'll want to compare the ingress controllers beyond basic ingress. That's where NGINX vs Envoy Proxy vs Traefik etc come into play as your core data plane proxy, and then how much stuff comes on top of it.

Hope that helps.

(Disclosure: I work on Ambassador, one of the Envoy-based ingress controllers)

Edited: formatting

Re: Voyager – Kubernetes Ingress Controller Releases v12.0.0-RC.2

#7

Post by rdli »

lcam84 wrote: post #4

I tried to install an kubernetes ingress but it turned out to be too difficult and so I used the standard service from my cloud. Do you know any good articles about how this macanism works?

Maybe https://blog.getambassador.io/kubernetes-ingress-nodeport-lo...

Re: Voyager – Kubernetes Ingress Controller Releases v12.0.0-RC.2

#8

Post by stuff4ben »

rdli wrote: post #6

Ingress controllers are quite confusing. Here's the general summary: - General best practice for Kubernetes clusters is to have a proxy that routes external traffic to internal services - This is because Kubernetes provides its own internal network space so each of your internal services aren't directly exposed externally (although you can do this if you like) - Kubernetes has a spec for how this is done, the "ingres…

I was about to suggest using something like Ambassador in response to your comment and then saw at the end you are the Ambassador guy. Loved Ambassador as it made the hell of using Ingress go away for me at the time. I'm focused on OpenStack nowadays, but wanted to give you all a shout-out!

Re: Voyager – Kubernetes Ingress Controller Releases v12.0.0-RC.2

#9

Post by rdli »

stuff4ben wrote: post #8
rdli wrote: post #6

Ingress controllers are quite confusing. Here's the general summary: - General best practice for Kubernetes clusters is to have a proxy that routes external traffic to internal services - This is because Kubernetes provides its own internal network space so each of your internal services aren't directly exposed externally (although you can do this if you like) - Kubernetes has a spec for how this is done, the "ingres…

I was about to suggest using something like Ambassador in response to your comment and then saw at the end you are the Ambassador guy. Loved Ambassador as it made the hell of using Ingress go away for me at the time. I'm focused on OpenStack nowadays, but wanted to give you all a shout-out!

Thanks! Always nice to hear :).

Re: Voyager – Kubernetes Ingress Controller Releases v12.0.0-RC.2

#10

Post by snuxoll »

dvcrn wrote: post #3
llarsson wrote: post #2

This is the first I hear about this project. Is anyone using it and able to say something about how it works for them and, in particular, if it works well for bare metal clusters? I don't see myself using something like this on a public cloud when I could just use an Ingress Controller offered by the cloud provider unless there are very good reasons for it. Which there might be! Which is what I ask for. :)

Digitalocean for example doesn’t offer a ingress controller for their clusters so I’m currently using the nginx one. Wonder how this compares

It spins up a separate HAProxy service for every Ingress resource, which means a separate DO Load Balancer for each.

This simplifies the implementation, but it also means every Ingress object you create costs $10/mo.

I’ll stick with nginx-ingress for now, personally.

Post reply on HN