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 Link Directive

• Service Discovery Within and Across Namespaces

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 , 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.

When you create a new workload in v2.x (not migrated, more on that ), 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.

Individual pods running in the Kubernetes cluster also get a DNS record assigned, which uses dot notation as well: . 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 .

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.

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 files our migration example services are linked together.

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.