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…
> Envoy-based ingress controllers
Does that have anything in common with the Istio Envoy proxies? You can use them for ingress as well...
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?
Not sure what you mean by installing ingress; Kubernetes should now support ingress out of the box using [1], based on OpenShift routes I believe.
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…
> Envoy-based ingress controllers Does that have anything in common with the Istio Envoy proxies? You can use them for ingress as well...
Istio does have an ingress gateway. Again, if you’re doing basic routing it’s more-or-less the same as any other ingress (that’s what a standard is for). That being said — Istio is focused more on traffic inside the data center (“east-west”) vs getting data into the data center (“north-south”). And these really are distinct problems, e.g., you don’t need to worry about stuff like PROXY protocol, redirect-to-HTTPS, openID Connect, etc inside the data center. But you definitely need to worry about this at the edge.
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!
Likewise, Ambassador solved a ton of problems with ingress that I just didn't want to think about.