Kubernetes Service External access mode: Nodeport and LoadBalancer

The lifespan of kubernetes pods is limited and they are not resurrected, so although each pod has its own IP address, these IP addresses are unreliable and disappear as the pod dies.

This poses a problem, if some of the pod's collections (called backends) are other pods of the cluster (called frontends), how do these frontends find and always know which backends are in such a collection?

This requires the introduction of a service, a kubernetes service is an abstraction that defines a logical set of pods and a strategy for accessing them. The set of target pods for a service is usually determined by the label selector.

Imagine, for example, that a three copy of the back end of a processing picture is running. These replicas can be substituted, and the front end does not care which backend they are using. Although the pod that actually makes up the back-end collection may change, the front-end client does not need to know about the change, nor does it need to have a list to record the backend services. Service abstraction allows you to achieve this decoupling.

For those kubernetes native applications, Kubernetes provides a simple endpoints API that is updated when the Pod collection in the service changes. For non-kubernetes native applications, Kubernetes provides the service with a virtual IP-based bridging method that redirects it to the pods of the backend.

Define a service

The service in Kubernetes is a rest object, which is similar to a pod. As with all rest objects, the definition of a service to Apiserver Post can create a new instance. For example, suppose you have a set of pods, each pod has 9376 ports open and there is a label for "App=myapp".

{    "Kind":"Service",    "apiversion":"v1",    "metadata": {        "name":"My-service"    },    "Spec": {        "selector": {            "app":"MyApp"        },        "Ports": [            {                "Protocol":"TCP",                "Port": the,                "Targetport":9376            }        ]    }}

This definition creates a new service object named "My-service", which points to all 9376 ports above the pod labeled "App=myapp". The service is also assigned an IP address (sometimes referred to as the "Cluster IP"), which is used by the proxy of the services (see below). The service selector will continuously filter the Pod and post the result to the endpoints object with the same name as "My-service".

Note that a service can map a port from one source to any targetport. By default, Targetport is set to the same value as the Port field. Perhaps more interesting is that Targetport can be a string that references a port name defined in a back-end pod. The port number that is actually assigned to the name may be different in each pod. This provides a lot of flexibility for deploying and updating your service. For example, you can change an open port in the next version of your backend without causing the customer to fail.

The Kubernetes service supports both TCP and UDP protocols. The default is TCP.

Types of publishing Services-service

Kubernetes's servicetypes allows you to specify which service you want. The default and base is Clusterip, which opens a service that can be connected within the cluster. Nodeport and LoadBalancer are two types that open services to external networks.

The legal value of the ServiceType field is:

L Clusterip: Use only one IP address within the cluster-this is the default. Choosing this value means that you only want the service to be accessible within the cluster.

L Nodeport: on the basis of the internal IP of the cluster, the service is opened on the port of each node of the cluster. You can access this service at any <nodeip>:nodeport address.

L LoadBalancer: In addition to using a clustered internal IP address and opening a service on Nodeport, the cloud provider applies for a load balancer that will allow traffic to be forwarded to this on each node to <nodeip> Nodeport in the form of open service.

On the basis of using a clustered internal IP address and opening a service on Nodeport, you can also request a load balancer from the cloud provider to forward traffic to a service that has been developed in the form of Nodeport.

Note that although nodeport can be TCP or UDP, LoadBalancer also supports TCP for Kubernetes 1.0来.

Nodeport type

If you set the Type field to "Nodeport", Kubernetes's master assigns a port from the range configured by the startup parameter (by default: 30000-32767). Each node then proxies the port (the same port on each node) to your service. This port will be written to your service's Spec.ports[*].nodeport field.

If you want a specific port number, you can specify a value in the Nodeport field to ensure that the system can assign you this port, otherwise the API request will fail (for example, you need to handle possible port conflicts yourself). The value you specify must be within the range of the node port configuration.

This gives developers the freedom to set their own load balancer, configure cloud environments that are not fully supported by kubernetes, or even directly open one or more nodes of IP.

This service can be accessed at the same time as <nodeip>:spec.ports[*].nodeport and Spec.clusterip:spec.ports[*].port.

LoadBalancer type

On top of those cloud providers that support external load balancers, setting the Type field to "LoadBalancer" sets a load balancer for your service. The actual creation of the load balancer is performed asynchronously, and the equalizer is displayed in the Status.loadbalancer field of the service. For example:

{    "Kind":"Service",    "apiversion":"v1",    "metadata": {        "name":"My-service"    },    "Spec": {        "selector": {            "app":"MyApp"        },        "Ports": [            {                "Protocol":"TCP",                "Port": the,                "Targetport":9376,                "Nodeport":30061            }        ],        "Clusterip":"10.0.171.239",        "Loadbalancerip":"78.11.24.19",        "type":"LoadBalancer"    },    "Status": {        "LoadBalancer": {            "Ingress": [                {                    "IP":"146.148.47.155"                }            ]        }    }

Traffic from the external load balancer will be led to the back-end pod, but the specifics of how this is implemented depends on the cloud provider. Some cloud providers allow the designation of Loadbalancerip. In this scenario, the load balancer is created with the user-specified loadbalancerip. If the field Loadbalancerip is not specified, the load balancer is assigned a transient IP. If Loadbalancerip is specified, but the cloud provider does not support this feature, this field is ignored.

Kubernetes Service External access mode: Nodeport and LoadBalancer