3 ms·

For the nginx ingress case: An ingress object creates an nginx/nginx.conf. That nginx server has an IP address which has a round robin IPVS rule. When it get

For the nginx ingress case: An ingress object creates an nginx/nginx.conf. That nginx server has an IP address which has a round robin IPVS rule. When it gets the request it proxy's to a service ip which then round robins to the 10.0.0.0/8 container IP. Ingress -> service -> pod It is all very confusing but once you look behind the curtain it's straight forward if you know Linux networking and web servers. The cloud providers remove the requirement of needing Linux knowledge.

MuffinFlavored 6y ago
> It is all very confusing Is there an easier + simpler alternative?
- base698 6y ago
  Use Heroku, AppEngine, or if in k8s, Knative/Rio. It's confusing because a lot of people being exposed to K8s don't necessarily know how Linux networking and web servers work. So there is a mix of terminology (services, ingress, ipvs, iptables, etc) and context that may not be understood if you didn't come from running/deploying Linux servers.
  - roman_sf 6y ago
    The deal was it all abstracted :) And now developers have to start all over with subnet masks?!
    - AlphaSite 6y ago
      The abstraction was file a ticket and let someone figure it out for you, or script it if it happens often enough.
ownagefool 6y ago
I don't think this is accurate which plays into the parents point, I guess. Looking at the docs, ingress-nginx configures an upstream using endpoints, which are essentially Pod IPs, with skips kubernetes service based round-robin networking altogether. Assuming you use an ingress that does configure services instead, and assuming you're using a service proxy that uses ipvs (i.e. kube-proxy in default settings) then your explanation would have been correct. For the most part, kubernetes networking is as hard as networking with loads of automation. Often, depth in both those skills are pretty exclusive, but if you're using the popular and/or supported CNI not doing things like changing in-flight, your average dev just needs to learn basic k8s debugging such as kubectl get endpoints to check whether his service selectors are setup correctly, and curl them to check whether the pods are actually listening on those ports.

MuffinFlavored 6y ago

> It is all very confusing Is there an easier + simpler alternative?

base698 6y ago
Use Heroku, AppEngine, or if in k8s, Knative/Rio. It's confusing because a lot of people being exposed to K8s don't necessarily know how Linux networking and web servers work. So there is a mix of terminology (services, ingress, ipvs, iptables, etc) and context that may not be understood if you didn't come from running/deploying Linux servers.
- roman_sf 6y ago
  The deal was it all abstracted :) And now developers have to start all over with subnet masks?!
  - AlphaSite 6y ago
    The abstraction was file a ticket and let someone figure it out for you, or script it if it happens often enough.

ownagefool 6y ago

I don't think this is accurate which plays into the parents point, I guess. Looking at the docs, ingress-nginx configures an upstream using endpoints, which are essentially Pod IPs, with skips kubernetes service based round-robin networking altogether. Assuming you use an ingress that does configure services instead, and assuming you're using a service proxy that uses ipvs (i.e. kube-proxy in default settings) then your explanation would have been correct. For the most part, kubernetes networking is as hard as networking with loads of automation. Often, depth in both those skills are pretty exclusive, but if you're using the popular and/or supported CNI not doing things like changing in-flight, your average dev just needs to learn basic k8s debugging such as kubectl get endpoints to check whether his service selectors are setup correctly, and curl them to check whether the pods are actually listening on those ports.