Service discovery is one of the core functionalities of any container-based environment. Once you have packaged and launched your application, the next step is making it discoverable to other containers in your environment or the external world. This document will describe how to use the service discovery support provided by Rancher v2.x so that you can find them by name.

This document will also show you how to link the workloads and services that you migrated into Rancher v2.x. When you parsed your services from v1.6 using migration-tools CLI, it output two files for each service: one deployment manifest and one service manifest. You’ll have to link these two files together before the deployment works correctly in v2.x.

Resolve the output.txt Link Directive

In This Document

• Service Discovery: Rancher v1.6 vs. v2.x
• Service Discovery Within and Across Namespaces
• Container Discovery
• Service Name Alias Creation

Service Discovery: Rancher v1.6 vs. v2.x

For Rancher v2.x, we’ve replaced the Rancher DNS microservice used in v1.6 with native Kubernetes DNS support, which provides equivalent service discovery for Kubernetes workloads and pods. Former Cattle users can replicate all the service discovery features from Rancher v1.6 in v2.x. There’s no loss of functionality.

Kubernetes schedules a DNS pod and service in the cluster, which is similar to the Rancher v1.6 DNS microservice. Kubernetes then configures its kubelets to route all DNS lookups to this DNS service, which is skyDNS, a flavor of the default Kube-DNS implementation.

The following table displays each service discovery feature available in the two Rancher releases.

Service Discovery Within and Across Namespaces

When you create a new workload in v2.x (not migrated, more on that below), Rancher automatically creates a service with an identical name, and then links the service and workload together. If you don’t explicitly expose a port, the default port of 42 is used. This practice makes the workload discoverable within and across namespaces by its name.

Container Discovery

Individual pods running in the Kubernetes cluster also get a DNS record assigned, which uses dot notation as well: <POD_IP_ADDRESS>.<NAMESPACE_NAME>.pod.cluster.local. For example, a pod with an IP of 10.42.2.7 in the namespace default with a DNS name of cluster.local would have an entry of 10-42-2-7.default.pod.cluster.local.

Pods can also be resolved using the hostname and subdomain fields if set in the pod spec. Details about this resolution is covered in the Kubernetes docs.

Linking Migrated Workloads and Services

When you migrate v1.6 services to v2.x, Rancher does not automatically create a Kubernetes service record for each migrated deployment. Instead, you’ll have to link the deployment and service together manually, using any of the methods listed below.

In the image below, the web-deployment.yml and web-service.yml files created after parsing our migration example services are linked together.

Linked Workload and Kubernetes Service

Service Name Alias Creation

Just as you can create an alias for Rancher v1.6 services, you can do the same for Rancher v2.x workloads. Similarly, you can also create DNS records pointing to services running externally, using either their hostname or IP address. These DNS records are Kubernetes service objects.

Using the v2.x UI, use the context menu to navigate to the Project view. Then click Resources > Workloads > Service Discovery. (In versions before v2.3.0, click the Workloads > Service Discovery tab.) All existing DNS records created for your workloads are listed under each namespace.

Click Add Record to create new DNS records. Then view the various options supported to link to external services or to create aliases for another workload, DNS record, or set of pods.

Add Service Discovery Record

The following table indicates which alias options are implemented natively by Kubernetes and which options are implemented by Rancher leveraging Kubernetes.

Next: Load Balancing