ClusterIP, Ingress, NodePort, Load Balancer - bobbae/gcp GitHub Wiki
Kubernetes service
Kubernetes service is an abstract way to expose an application running on a set of Pods as a Network service.
With Kubernetes you don't need to modify your application to use an unfamiliar service discovery mechanism. Kubernetes gives Pods their own IP addresses and a single DNS name for a set of Pods, and can load-balance across them.
https://kubernetes.io/docs/concepts/services-networking/service/
A service can be exposed via NodePort, LoadBalancer or ClusterIP.
A NodePort is an open port on every node of your cluster. Kubernetes transparently routes incoming traffic on the NodePort to your service, even if your application is running on a different node.
Using a LoadBalancer service type automatically deploys an external load balancer. This external load balancer is associated with a specific IP address and routes external traffic to a Kubernetes service in your cluster.
https://cloud.google.com/kubernetes-engine/docs/concepts/service
When to use NodePort vs. LoadBalancer can be confusing.
GKE
GKE is a Secured and fully managed Kubernetes service with revolutionary autopilot mode of operation.
Service Types
Services can be exposed in different ways
ClusterIP
A ClusterIP service is the default Kubernetes service. It gives you a service inside your cluster that other apps inside your cluster can access. There is no external access. It exposes the Service on a cluster-internal IP. Choosing this value makes the Service only reachable from within the cluster. This is the default ServiceType.
The ClusterIP in kubernetes is a service type which has its origins in the iptables CLUSTERIP.
https://book.huihoo.com/iptables-tutorial/x8906.htm
Kube-proxy
There are several types of proxies in Kubernetes, and among them is the node proxier, or kube-proxy, which reflects services defined in Kubernetes API on each node and performs simple TCP/UDP/SCTP stream forwarding across a set of backends.
iptables
In iptables proxy mode, kube-proxy watches the Kubernetes control plane for the addition and removal of Service and Endpoint objects. For each Service, it installs iptables rules, which capture traffic to the Service's clusterIP and port, and redirect that traffic to one of the Service's backend sets. For each Endpoint object, it installs iptables rules which select a backend Pod.
By default, kube-proxy in iptables mode chooses a backend at random.
https://kubernetes.io/docs/concepts/services-networking/service/#proxy-mode-iptables
ipvs
In ipvs mode, kube-proxy watches Kubernetes Services and Endpoints, calls netlink interface to create IPVS rules accordingly and synchronizes IPVS rules with Kubernetes Services and Endpoints periodically. This control loop ensures that IPVS status matches the desired state. When accessing a Service, IPVS directs traffic to one of the backend Pods.
https://kubernetes.io/docs/concepts/services-networking/service/#proxy-mode-iptables
NodePort
A NodePort service is the most primitive way to get external traffic directly to your service. NodePort, as the name implies, opens a specific port on all the Nodes (the VMs), and any traffic that is sent to this port is forwarded to the service.
NodePort exposes the Service on each Node's IP at a static port (the NodePort). A ClusterIP Service, to which the NodePort Service routes, is automatically created. You'll be able to contact the NodePort Service, from outside the cluster, by requesting NodeIP:NodePort.
https://hackernoon.com/introducing-nodeport-service-in-kubernetes-ear0360s
LoadBalancer
A LoadBalancer service is the standard way to expose a service to the internet. On GKE, this will spin up a Network Load Balancer that will give you a single IP address that will forward all traffic to your service.
MetalLB
MetalLB is a load-balancer implementation for bare metal Kubernetes clusters, using standard routing protocols.
External Name
Services of type ExternalName map a Service to a DNS name, not to a typical selector such as my-service or cassandra. You specify these Services with the spec.externalName parameter.
Ingress
Ingress is not a Service type, but it acts as the entry point for your cluster. It lets you consolidate your routing rules into a single resource as it can expose multiple services under the same IP address.
https://kubernetes.io/docs/concepts/services-networking/ingress/
ECMP
ECMP stands for “equal-cost multi-path”; it’s a routing strategy where packets are forwarded to one of any “best paths” in a network. How the best paths are determined depends on a lot of factors, but typically, the best path is likely the shortest path (the path with the least amount of hops). The most common example of using anycast is with global DNS services where we want one IP (think 1.1.1.1 or 8.8.8.8) to be routed to the closest site that is running a globally distributed DNS service. BGP is one of many routing protocols that allows us to implement ECMP routing.
If you’ve already configured your network to handle ECMP routing, then all that’s left to implement anycast is to advertise your anycast IP over multiple BGP peers. With Kubernetes, we can advertise service IPs to accomplish anycast routing for any of our services.
https://www.asykim.com/blog/kubernetes-traffic-engineering-with-bgp