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

Resolve Link Directive

In This Document

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 FeatureRancher v1.6Rancher v2.xDescription
service discovery within and across stack (i.e., clusters)All services in the stack are resolvable by <service_name> and by <service_name>.<stack_name> across stacks.
container discoveryAll containers are resolvable globally by their name.
service alias name creationAdding an alias name to services and linking to other services using aliases.
discovery of external servicesPointing to services deployed outside of Rancher using the external IP(s) or a domain name.

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

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

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.

OptionKubernetes-implemented?Rancher-implemented?
Pointing to an external hostname
Pointing to a set of pods that match a selector
Pointing to an external IP address
Pointing to another workload
Create alias for another DNS record

Next: Load Balancing