## Introduction A Service in Kubernetes is an abstraction that provides a network interface to access a set of Pods. These Pods can either be a component of an application or the whole application itself. The Service can expose the set of Pods: * Internally within the cluster to enable inter-communication between nodes and Pods. * Externally to accept incoming traffic from outside the cluster. Different components of an application may need to communicate with each other. These components live on Pods that have an internal IP address assigned to them. In Kubernetes, Pods are not a permanent entity. Pods may fail and get replaced by new ones with different IP addresses. To keep the application functioning, the components of an application that rely on these Pods have to be updated with their new IP addresses. Manually updating the IP address in these components is not practical. Instead, you can use a network entity with a fixed IP address, such as a Service that acts as a proxy for non-permanent Pods. Furthermore, the application that serves requests to external clients, like an Nginx web server, has to be exposed as a single endpoint, even if the cluster has multiple instances of that application. ## Prerequisites To test out the Kubernetes manifest files of this article, you will need: * A Kubernetes cluster. You can use [Vultr Kubernetes Engine](https://docs.vultr.com/vultr-kubernetes-engine/) to deploy a Kubernetes cluster. * A **kubectl** client on your local workstation that is configured to work with your Kubernetes cluster. ## Understanding a Kubernetes Service The following is the manifest file that creates a Kubernetes Service Object: apiVersion: v1 kind: Pod metadata: name: nginx labels: app: web-server spec: containers: - name: nginx image: nginx:stable ports: - containerPort: 80 name: pod-port --- apiVersion: v1 kind: Service metadata: name: first-service spec: selector: app: web-server ports: - name: service-port protocol: TCP port: 80 targetPort: pod-port This manifest file creates two resources: * A Pod named `nginx`. * A Service named `first-service`. The `.spec.selector` field specifies a list of `labels` to look for in a Pod. Pods that have all the labels of the Service become its `endpoint` and are added to the `Endpoints` object of the service. The `Endpoints` object represents the set of Pods that a Service is exposing. The Service forwards the incoming request to any one of its endpoints. Kubernetes automatically adds any new pod as an endpoint that has all the matching labels with the service. The `.spec.ports` field defines the network port of the Service, Service protocol, and other necessary network-related information. It contains the following sub-fields: * `name`: This defines the name of the port through which the Service accepts the incoming network requests. * `protocol`: This defines the network protocol of the Service. The default protocol is `TCP`. The other two supported protocols are `SCTP` and `UDP`. * `port`: This specifies the port number through which the Service accepts the incoming network requests. * `targetPort`: This specifies the port of the endpoints to which the Service forwards the incoming network traffic. You can specify the port number of the endpoint or its port name. In the example above, the value of this field matches the Pod's `.spec.ports.name` field. By default, the `targetPort` and the `port` field have the same value. > **Note:** The `---` inside the above manifest files between the definition of the Pod and the Service allows you to group many definitions in a single file. To POST this manifest file to the Kubernetes API, use: $ kubectl apply -f first-service.yaml Expected output: pod/nginx created service/first-service created Once a Service is created, it is assigned an IP address. To check the IP address of a service, use: $ kubectl get services Expected output: NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE first-service ClusterIP 10.107.13.79 80/TCP 52m kubernetes ClusterIP 10.96.0.1 443/TCP 101d This lists all the Services in your cluster. Under the `CLUSTER-IP` field, you can see the assigned IP address of a Service. ## Types of Kubernetes Services A Service can expose its endpoints to other internal components of the cluster, or it can expose them to traffic from outside the cluster. This section discusses how you can do that and more using the different Service types. The Service manifest has a `.spec.type` field. The value of this field determines how the Service works. The `type` property can have one of the following values: 1. ClusterIP 2. NodePort 3. LoadBalancer 4. ExternalName ### ClusterIP This is the default value of the `.spec.type` field. The Service is assigned an internal IP address of the cluster. The Service is only reachable from within the cluster. The two example Service definitions that are mentioned above in this article are of type `ClusterIP` by default. ### NodePort A `NodePort` type Service is an extension of `ClusterIP` type, meaning that the Service is still assigned an internal IP address that exposes the endpoints internally within the cluster. The additional feature of `NodePort` type Service is that the nodes that host the endpoint Pods are assigned a random port from `--service-node-port-range`. The default range is from 30000 through 32767. > **Note:** You can specify a custom port number in the `.spec.ports.nodePort` field to the `NodePort` Service from this range. However, it is recommended to let Kubernetes assign the `nodePort` value. This can prevent a possible collision with Services that pre-exist. These nodes are directly accessible through their public IP address. Working of NodePort Service: * The assigned port number is opened on all the nodes. * This port number is then proxied to the Service. * Any request made to the IP address of the node and its port is then proxied by the Service to the `targetPort` of the node's Pod. * For example, a node hosts an endpoint Pod of a Service. Its IP address is `192.168.1.101` and the `NodePort` Service assigned port `30200` to this Node. The `targetPort` of the endpoint Pod of this Service is `80`. Then, any external request that is made at `192.168.1.101:30200` is directed to the Pod's port `80` which resided on the node with the same IP address. Example: apiVersion: v1 kind: Service metadata: name: nodeport-service spec: type: NodePort selector: app: webapp ports: - port: 8080 targetPort: 80 nodePort: 30007 This Service accepts internal traffic at port 8080 and forwards the traffic to the endpoints at port 80. The optional `.spec.ports.nodePort` field specifies the port number of the Node at which it accepts the external traffic. > **Note:** NodePort Service is not very secure as it exposes the Nodes directly through their IP addresses. ### LoadBalancer Using type `LoadBalancer` creates a load balancer in the infrastructure that hosts the cluster. For example, deploying a `LoadBalancer` type Service in Vultr creates a [Vultr Load Balancer](https://docs.vultr.com/vultr-load-balancers) that distributes the traffic to different endpoints. The distribution mechanism depends on the cloud service provider. The control plane of the Kubernetes cluster has a component called `cloud-controller-manager`. This component connects the cluster to the cloud service provider's API and implements its specific mechanism of creating and handling objects. It includes a `service controller` that is responsible to implement components like a load balancer. Working of `LoadBalancer` Service: 1. Kubernetes creates a Service that is similar to a `NodePort` type Service, meaning that the Service has an internal cluster IP address that is accessible locally and each node in the cluster is assigned a `nodePort` value. 2. The `service controller` component configures the load balancer to send traffic to individual nodes on their assigned `nodePort`. 3. A `LoadBalancer` type Service can be accessed externally using the Kubernetes Ingress object. You can assign an external IP address to the Service in its `.status.loadBalancer.ingress` field. Example: apiVersion: v1 kind: Service metadata: name: load-balancer-service spec: selector: app: web-app ports: - protocol: TCP port: 80 targetPort: 9350 type: LoadBalancer status: loadBalancer: ingress: - ip: 192.0.2.127 Refer to the [Vultr Load Balancer with VKE](https://docs.vultr.com/how-to-use-a-vultr-load-balancer-with-vke/) article for more information. ### ExternalName This type of Service uses a DNS name to redirect the incoming traffic. The traditional `.spec.selector` field is not used to select the endpoints. Instead, the Service uses an external endpoint that is specified using a DNS name in the `.spec.externalName` field. This Service type is generally used to abstract a component that is not present inside the cluster. Example: apiVersion: v1 kind: Service metadata: name: external-service spec: type: ExternalName externalName: endpoint.database.site.com ## Basic Operations The operations described in this section are performed on a Service named `test-service` for demonstration purposes. You can replace it with any Service object's name. 1. **List all Service objects** $ kubectl get services Expected output: NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE external-service ExternalName endpoint.database.site.com 26h kubernetes ClusterIP 10.96.0.1 443/TCP 103d load-balancer-service LoadBalancer 10.106.55.89 80:32075/TCP 6h21m nodeport-service NodePort 10.97.164.108 8080:30007/TCP 23h test-service LoadBalancer 10.105.111.220 80:31297/TCP 2m29s 2. **Describe a Service object** $ kubectl describe service test-service Expected output: Name: test-service Namespace: default Labels: Annotations: Selector: app=web-app Type: LoadBalancer IP Family Policy: SingleStack IP Families: IPv4 IP: 10.105.111.220 IPs: 10.105.111.220 Port: 80/TCP TargetPort: 9350/TCP NodePort: 31297/TCP Endpoints: Session Affinity: None External Traffic Policy: Cluster Events: 3. **Delete a Service object** $ kubectl delete service test-service Expected output: service "test-service" deleted ## Expose Multiple Ports A Service can accept traffic on multiple ports. You can define multiple port definitions under the `.spec.ports` field. apiVersion: v1 kind: Service metadata: name: multi-port-service spec: selector: app: nginx ports: - name: http-port protocol: TCP port: 80 targetPort: 9376 - name: https-port protocol: TCP port: 443 targetPort: 9377 > **Note:** You have to define the `name` property for every port if your Service has multiple port definitions. ## Set a Custom IP Address Kubernetes allows you to set a custom IP Address for your Service. You can specify the IP address in the `.spec.clusterIP` field. The value should: * Lie within the `service-cluster-ip-range` * Be a valid IPv4 or IPv6 address. Not following these rules will cause the API server to throw an error. To check the default `service-cluster-ip-range`, use: $ kubectl cluster-info dump | grep -m 1 service-cluster-ip-range | sed -e 's/^[ \t]*//' Sample output: "--service-cluster-ip-range=10.96.0.0/12", You may want to use a custom IP address in certain situations like: * You have a preconfigured client that relies on a specific IP address and reconfiguring it may turn out to be a tedious task. * You have the IP address set as a DNS entry somewhere and you wish to reuse it. ## Service Discovery It is the process of discovering the network location of a Service. It can be done using the environment variables and cluster DNS. ### Environment Variables Kubernetes adds a set of environment variables to the Pod. These variables contain information about each active Service which helps the Pod to communicate with the Service. This way, you do not have to hard-code the IP address of the Service in each Pod. The disadvantage of using this method is that the Pod will not be updated with the data about Services that are created after the Pod. Using DNS for Service discovery eliminates this issue. ### DNS In Kubernetes, Service and Pod objects get DNS records. A DNS server like [CoreDNS](https://kubernetes.io/docs/tasks/administer-cluster/coredns/) creates a set of DNS records for a new Service and Pod object. To use DNS service in a cluster, you have to set it up. To set up a DNS service, check out the [Kubernetes documentation](https://kubernetes.io/docs/tasks/access-application-cluster/configure-dns-cluster/). Pods can use DNS records to Discover Services. ## Session Stickiness In Kubernetes, you can route the network traffic from a specific client to a fixed Pod during the entirety of its session. To set this up, you have to set the `.spec.sessionAffinity` field of the Service. Refer to the [Session Stickiness](https://kubernetes.io/docs/concepts/services-networking/service/#session-stickiness) section for more information. ## Conclusion Kubernetes Service is a vital component of Kubernetes clusters, enabling efficient communication and load balancing between pods. With different types of services and service discovery options, it allows access to services within and outside the cluster, making it a powerful tool for building scalable and reliable applications.

Articles Tagged: Service Discovery