A Kubernetes “Service” is an abstraction which defines a logical set of Pods and a policy by which to access them. In general,
- Pods targeted by a Service are found by a Label Selector.
- For Kubernetes-native applications, the Endpoints API will be updated whenever the set of Pods in a Service changes. For non-native applications, there is a virtual-IP-based bridge to Services which redirects to the backend Pods.
- Service will be assigned an IP address (“cluster IP”), which is used by the service proxies.
- Service can map an incoming port to any targetPort. (By default the targetPort will be set to the same value as the port field and it can defined as a string.)
- The actual port number assigned to that name can be different in each backend Pod. For example, you can change the port number that pods expose in the next version of your backend software, without breaking clients.
- Service support TCP, UDP and SCTP for protocols. The default is TCP.
- Service can be defined with or without a selector.
- Service supports multiple port definitions.
Type of service
There are 4 types of service,
- ClusterIP – Exposes the service on a cluster-internal IP. Service is only reachable from within the cluster. This is the default Type.
- NodePort – Exposes the service on each Node’s IP at a static port. A ClusterIP service, to which the NodePort service will route, is automatically created. You’ll be able to contact the NodePort service, from outside the cluster, by using “
: ”. - LoadBalancer – Exposes the service externally using a cloud provider’s load balancer. NodePort and ClusterIP services, to which the external load balancer will route, are automatically created.
- ExternalName – Maps the service to the contents of the externalName field (e.g. foo.bar.example.com), by returning a CNAME record with its value.
Discovering Service
There are two ways to discover service in kubernetes. By ENV variable or DNS.
ENV Var – When a Pod is run on a Node, the kubelet adds a set of environment variables for each active Service.
DNS – The DNS server is a cluster add-on that watches the Kubernetes API for new Services and creates a set of DNS records for each. If DNS has been enabled throughout the cluster then all Pods should be able to do name resolution of Services automatically. This is the recommended option.
Headless services
Headless services
Sometimes you don’t need or want load-balancing and a single service IP. In this case, you can create “headless” services by specifying “None” for the cluster IP (.spec.clusterIP).
With selectors – For headless services that define selectors, the endpoints controller creates Endpoints records in the API, and modifies the DNS configuration to return A records (addresses) that point directly to the Pods backing the Service.
Without selectors – For headless services that do not define selectors, the endpoints controller does not create Endpoints records. However, the DNS system looks for and configures either:
CNAME records for ExternalName-type services.
A records for any Endpoints that share a name with the service, for all other types.
pod & port
services find pods by lables. service decoupled the deployments, it dose not care about pods.
port –> service/pod/container
targetPort –> remote port
demo
1, create a deployment kind for application
kubectl run hello-world –replicas=2 –labels=”run=load-balancer-example” –image=gcr.io/google-samples/node-hello:1.0 –port=8080
2, create a service for application with type ClusterIP
kubectl expose deployment hello-world --type=ClusterIP --name=example-service
3,forward the port in service to a local port
kubectl port-forward service/example-service 8080:8080