Ingress works on layer 7 (http/https only) and Ingress can provide load balancing, SSL termination and name-based virtual hosting (host based or URL based HTTP routing).
So, unlike the NodePort service type, not all cloud providers support the LoadBalancer service type. Also note that the exact implementation of a LoadBalancer is dependent on the cloud provider. Note that this is on Layer 4 (Ingress is on Layer 7). Internally, it uses NodePort to bounce across to the machine that the service is running on. In this Django post, we'll use Load Balancer service type ( deploy/django/service.yaml):
The NodePort can be used as a building block for higher-level ingress models (e.g., load balancers) and it is handy for development purposes, however, NodePorts are not designed to be directly used for production. In other words, when a user sets the Service type field to NodePort, the Kubernetes master allocates a static port from a range, and each Node will proxy that port (the same port number on every Node) into our Service. Then the Service is accessible by using the IP address of any node along with the nodePort value. When we create a Service of type NodePort, Kubernetes gives us a nodePort value. So, if we hit a node that the service is not running, it will bounce across to our nodes. Kubernetes arrange things with the NodePort and it's on every node in our cluster (Kubernetes cluster, by default, supports NodePort). We've been using the NodePort type for all the services that require public access. In Kubernetes, there are three general approaches (service types) to expose our application. Picture source: Kinvolk Tech Talks: Introduction to Kubernetes Networking with Bryan Boreham. Kubernetes Ingress 101: NodePort, Load Balancers, and Ingress Controllers.
0 kommentar(er)
