Shulou(Shulou.com)06/01 Report--

This article introduces how to use service discovery in Rancher 2.0. the content is very detailed, which can be used for reference by interested friends. I hope it will be helpful to you.

Service Discovery in Rancher 1.6

Rancher 1.6 provides service discovery in a Cattle environment. Rancher's own DNS microservice provides internal DNS functionality.

Rancher's internal DNS provides the following main functions:

Intra-stack and cross-stack service discovery

All services in the stack can be passed through and. Parsing across stacks.

Container discovery

All containers are resolved globally by their names.

Create a service alias

Add aliases to the service and use aliases to link to other services.

Discover external services

Point to services that are deployed outside of Rancher using an external IP or domain name.

Service Discovery in Rancher 2.0

Rancher 2.0 uses native Kubernetes DNS support to provide equivalent service discovery for Kubernetes workloads and pod. Cattle users will be able to replicate all service discovery capabilities in Rancher 2.0 without losing any functionality.

Similar to the Rancher 1.6 DNS microservice, Kubernetes dispatches DNS pod and services within the cluster and configures kubelet to route all DNS lookups to this DNS service. The Kubernetes cluster of Rancher 2.0 deploys skyDNS as a Kubernetes DNS service, which is a style of the default Kube-DNS implementation.

Service parsing

The Rancher 1.6 service maps to some type of Kubernetes workload, where you can learn about a short summary of popular types of workloads:

Https://rancher.com/docs/rancher/v2.x/en/k8s-in-rancher/workloads/#workloads

The Kubernetes workload is the object of the deployment rules specified for the pod initiated by the workload. The workload object itself cannot be resolved to other objects in the Kubernetes cluster through DNS. To find and access the workload, you need to create a Kubernetes service for the workload. Here are some details of the Kubernetes service:

Https://kubernetes.io/docs/concepts/services-networking/service/

Any service created in Kubernetes will get the DNS name. The format of the DNS A record created for the service is... svc.cluster.local. The DNS name of the service resolves to the cluster IP of the service. The cluster IP is the internal IP assigned to the service and can be parsed within the cluster.

Within the Kubernetes namespace, services can be parsed directly, while services outside the namespace can be used. Parse directly. This is similar to service discovery within and across stacks in Rancher 1.6.

Therefore, to find and access the application workload, you need to create a service that gets DNS records.

Rancher simplifies this process by automatically creating services and workloads using the service ports and service types that you select in UI, while deploying workloads and service names that have the same name as the workload. If the port is not exposed, port 42 is used. This approach allows workloads to be discovered by names within and across namespaces.

For example, as shown below, I deployed several workloads of type Deployment in both namespaces using Rancher 2.0 UI.

I can see the corresponding DNS records that Rancher automatically creates for the workload under the Cluster > Project > Service Discovery tab.

As shown below, workloads are accessible to any other workload within and across namespaces.

Pod parsing

Each pod running in the Kubernetes cluster will also be assigned a DNS record in the format of.. pod.cluster.local. For example, if the IP of a pod is 10.42.2.7, it is in the namespace default, and the DNS name is cluster.local, then its entry is 10-42-2-7.default.pod.cluster.local.

If you set it in the pod specification, you can also use the hostname and subdomain fields to resolve the Pod. For more information, please refer to the Kubernetes documentation:

Https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/

Create aliases for workloads and external services

Just as you can create aliases for Rancher 1.6 services, you can use Rancher 2.0 to do the same for Kubernetes workloads. Similarly, you can use the hostname or IP address in Rancher 2.0 to create an DNS record that points to an external running service. These DNS records are Kubernetes service objects.

Using 2.0 UI, navigate to the Cluster > Project view, and then select the Service Discovery tab. Here, all existing DNS records created for your workload are listed under each namespace.

Click Add Record to create a new DNS record and view the various options supported by linking to an external service, or create an alias for another workload / DNS record / pod group.

It is important to note that among these options for creating DNS records, Kubernetes itself supports the following options:

Point to an external hostname

Point to a set of pod that matches the selector

The rest of the functions are implemented by Rancher using Kubernetes:

Point to an external IP address

Create an alias for another DNS record

Point to another workload

From Docker Compose to Kubernetes YAML

Now let's see what we need to do if we want to migrate the application from 1.6 to 2.0 using Compose files instead of deploying it through 2.0 UI.

As mentioned above, when we deploy the workload using Rancher 2.0 UI, Rancher internally creates the necessary Kubernetes ClusterIP services for service discovery. However, if you are deploying a workload through a Rancher CLI or Kubectl client, how should you ensure that you complete the same service discovery behavior?

Service discovery within and across namespaces through Compose

Let's start with the following docker-compose.yml file, which shows the two services in the stack (foo and bar). In the Cattle stack, the two services can access each other using their service names.

So what happens if we migrate these two services to the namespace in Rancher 2.0?

We can use the Kompose tool to convert this docker-compose.yml file from Rancher 1.6 to Kubernetes YAML, and then use Rancher CLI to deploy the application in the Kubernetes cluster.

This transformation now generates *-deployment.yaml files, and deploying them with Rancher CLI creates the corresponding workload within the namespace.

Can these workloads access each other within the namespace? We can use Rancher 2.0 UI to execute the shell of the workload foo, and then see if another workload of ping, bar, is valid.

No! The reason is that we only created workload objects of type Deployment. In order for these workloads to be discoverable, each of them needs a service pointing to their ClusterIP type, which will be assigned a DNS record. The Kubernetes YAML for this type of service should be as follows.

Note that ports is a required field. Therefore, we need to provide it with some port numbers, as shown in 42.

After deploying this service through CLI, the service foo can successfully ping to the service bar!

Therefore, if you use Compose-to-Kubernetes-YAML routing to migrate 1.6 services to Rancher 2.0, make sure that you also deploy the appropriate ClusterIP services for the workload. The same solution applies to cross-namespace references to workloads.

Links / external links to Compose

If you are a Cattle user, you must know that in Rancher 1.6, you can create service links / aliases to other services and use that alias in your application to discover the target service of the link.

For example, the following application, where the Web service links to the database service using the alias mongo.

Using Kompose, convert this Compose file to Kubernetes YAML to generate the appropriate deployment and service YAML specification. If your service in docker-compose.yml exposes the port, Kompose generates the Kubernetes ClusterIP service YAML specification by default.

Deploying these tools using Rancher CLI generates the necessary workloads.

However, the service link mongo is missing here because the Kompose transformation does not support links in the docker-compose.yml file. As a result, the workload web has an error and its pod continues to restart and cannot resolve the mongo link to the database service.

How do we fix broken DNS links? The solution is to create another ClusterIP service specification and set its name to the alias of the link in docker-compose.

Deploying this service creates the necessary DNS records and a linked mongo to make the web workload available.

The following figure shows that the pod started by the web workload has entered the Running state.

Transition from SkyDNS to CoreDNS in the future

Starting with Rancher v2.0.7, Rancher deployed skyDNS supported by Kubernetes version 1.10.x. In Kubernetes 1.11 and later, CoreDNS can be installed as a DNS provider. We are also evaluating CoreDNS, which will be used as a replacement for skyDNS in future versions of Rancher.

So much for sharing about how to use service discovery in Rancher 2.0. I hope the above content can be of some help and learn more. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.