Service Discovery

Module

Service discovery is one of the core functionalities of any container-based environment to automatically discover each object and manage their domain name resolution.

Overview

At the end of this module, you will :

  • Learn what is the Service Discovery

  • Learn how to resolve a Pod and a Service by his DNS name

  • Understand how to use it in your development

This module needs a DNS plugin to be deployed on the cluster. The default DNS plugin used in this module is CoreDNS. Ensure this module is up and running before continuing.

Prerequisites

Create the directory data/servicediscovery in your home folder to manage the YAML file needed in this module.

mkdir ~/data/servicediscovery

Create

Kubernetes DNS system is designed to manage the domain name of each Pods and Services in a Kubernetes cluster. Kube-DNS and CoreDNS (CoreDNS is a newer add-on that became a default DNS server as of Kubernetes v1.12) are two established DNS solutions for defining DNS naming rules and resolving pod and service DNS to their corresponding cluster IPs.

With DNS, Kubernetes services can be referenced by name that will correspond to any number of backend pods managed by the service. The naming scheme for DNS also follows a predictable pattern, making the addresses of various services more memorable.

Services can also be referenced not only via a Fully Qualified Domain Name (FQDN) but also via only the name of the service itself.

Both add-ons schedule a DNS pod or pods and a service with a static IP on the cluster and both are named kube-dns.

Kubernetes DNS add-ons currently support forward lookups (A records), port lookups (SRV records), reverse IP address lookups (PTR records), and some other options.

Their is no create command to directly ask the API resource to create a DNS record in command line. The DNS record are tightly coupled with the life cycle of Pods and Services. The DNS records are created at the creation of a resource and deleted at the deletion of the object.

Service DNS records

Kubernetes Services support A records, CNAME, and SRV records.

A Record

A Record is the most basic type of a DNS record used to point a domain or subdomain to a certain IP address. The record consists of the domain name, the IP address to resolve it, and TTL in seconds. TTL stands for Time To Live, and is a sort of expiration date put on a DNS record. A TTL tells the DNS server how long it should keep a given record in its cache.

The default DNS A record assigned to a Service is formed based on this principles : your-svc.your-namespace.svc.cluster.local. This name resolves to a set of IPs of the pods selected by the Service. The DNS will not resolve this set to a specific IP automatically so the clients should take care of load balancing or round-robin selection from the set.

CNAME

CNAME records are used to point a domain or subdomain to another hostname. To achieve this, CNAMEs use the existing A record as their value. In Kubernetes, CNAME records can be used for cross-cluster service discovery with federated services.

SRV Records

SRV records facilitate service discovery by describing the protocol/s and address of certain services.

An SRV record usually defines a symbolic name and the transport protocol (e.g., TCP) used as part of the domain name and defines the priority, weight, port, and target for a given service (see the example below).

_sip._tcp.example.com.   3600 IN    SRV 10       70     5060 srvrecord.example.com.
_sip._tcp.example.com.   3600 IN    SRV 10       20     5060 srvrecord2.example.com.

In Kubernetes, SRV Records are created for named ports. The SRV record takes the form of _my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster.local. For a regular service, this resolves to the port number and the domain name : my-svc.my-namespace.svc.cluster.local.

Exercise n°1

On Minikube, CoreDNS is enable by default.

Create an Nginx HTTP server Deployment that listen on port 80.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sd-deployment
  labels:
    app: webserver
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webserver
  template:
    metadata:
      labels:
        app: webserver
    spec:
      containers:
      - image: nginx
        name: nginx
        ports:
          - name: http
            containerPort: 80

Create the Service to expose the previous Deployment internally on port 4000.

kind: Service
apiVersion: v1
metadata:
  name: sd-service
spec:
  selector:
    app: webserver
  ports:
  - protocol: TCP
    port: 8080
    targetPort: http

Create the resources based on the previous yaml files definition.

kubectl apply  -f data/servicediscovery/

Ensure the Pods are created before continuing otherwise, the client will log errors.

Create a client Pod that will request the service by its name.

kubectl run sd-client --image=appropriate/curl --restart=Never -- /bin/sh -c "curl -s sd-service:8080"

Get the logs of the client Pod to get the DNS resolution information.

kubectl logs sd-client

Pods DNS records

Kubernetes Pods support A records and environment variable configuration.

A Record

The default DNS A record assigned to a Pods is pod-ip-address.my-namespace.pod.cluster.local.

For example, a pod with IP 172.12.3.4 in the namespace default with a DNS name of cluster.local would have an entry of the form 172-12-3-4.default.pod.cluster.local.

Hostname and subdomain of a Pod can be overwritten with optional parameters defined in the spec field of the object declaration.

For example, a pod with its hostname set to custom-host , and subdomain set to custom-subdomain, in namespace my-namespace, will have the fully qualified domain name (FQDN) custom-host.custom-subdomain.my-namespace.svc.cluster.local.

Environment variable

When a Pod is run on a Node, the kubelet adds a set of environment variables for each active Service. It supports both Docker links compatible variables and simpler {SVCNAME}_SERVICE_HOST and {SVCNAME}_SERVICE_PORT variables, where the Service name is upper-cased and dashes are converted to underscores.

Any Service that a Pod wants to access must be created before the Pod itself, or else the environment variables will not be populated.

Exercise n°1

Create a new Pod and get the environment variable.

kubectl run busybox --image=busybox --restart=Never env

Get the logs and parse it to ensure the SD_SERVICE, created previously, has been automatically configured.

kubectl logs busybox | grep SD_SERVICE

Delete

The delete command delete resources by filenames, stdin, resources and names, or by resources and label selector.

The DNS record are tightly coupled with the life cycle of Pods and Services. The DNS records are created at the creation of a resource and deleted at the deletion of the object.

Note that the delete command does NOT do resource version checks, so if someone submits an update to a resource right when you submit a delete, their update will be lost along with the rest of the resource.

Exercise n°1

Delete the service and the deployment created previously in the default namespace.

# Delete the service discovery resources
kubectl delete -f ~/data/servicediscovery/

# Delete the busybox pod
kubectl delete po busybox

# Delete the sd-client pod
kubectl delete po sd-client

External documentation

Those documentations can help you to go further in this topic :

PreviousServicesNextConfigMaps

Last updated