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

This article shares with you the content of the sample analysis of Kubernetes DNS. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

Environment $sudo lsb_release-aNo LSB modules are available.Distributor ID: UbuntuDescription: Ubuntu 16.04.2 LTSRelease: 16.04Codename: xenial$ kubectl versionClient Version: version.Info {Major: "1", Minor: "5", GitVersion: "v1.5.4", GitCommit: "7243c69eb523aa4377bce883e7c0dd76b84709a1", GitTreeState: "clean", BuildDate: "2017-03-07T23:53:09Z", GoVersion: "go1.7.4", Compiler: "gc" Platform: "linux/amd64"} Server Version: version.Info {Major: "1", Minor: "5", GitVersion: "v1.5.4", GitCommit: "7243c69eb523aa4377bce883e7c0dd76b84709a1", GitTreeState: "clean", BuildDate: "2017-03-07T23:34:32Z", GoVersion: "go1.7.4", Compiler: "gc", Platform: "linux/amd64"} introduction

Since Kubernetes 1.3, DNS has become a built-in self-starting service by using the plug-in management system cluster add-on.

Kubernetes DNS dispatches a DNS Pod and Service on the Kubernetes cluster and configures kubelet to tell each container to use DNS Service's Ip to resolve the DNS name.

What is a DNS name

Each Service defined in the cluster (including DNS Service itself) is assigned a DNS name. By default, Pod's DNS search list contains Pod's own namespace and the cluster's default domain. Let's use an example to explain the following.

Suppose you have a Service named foo in the namespace bar. Pod running in the bar namespace can find the service through the DNS lookup foo keyword, while Pod running in the namespace quux can find the service by the keyword foo.bar.

Supported DNS mode

The following sections describe in detail the supported record (record) types and layout.

Services

Normal (non-headless) Service is assigned a DNS record with a name format of my-svc.my-namespace.svc.cluster.local, through which the cluster IP of the service can be resolved.

The Service of Headless (no clustered IP) is also assigned a DNS record with the name format my-svc.my-namespace.svc.cluster.local. Unlike a normal Service, it parses the IP list of the Pod selected by Service.

SRV records

SRV records is used to serve named ports, which are part of headless or normal Service. For each named port, the format of SRV record is: _ my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster.local. For a normal service, this parses the port number and CNAMEmy-svc.my-namespace.svc.cluster.local. For headless services, this parses multiple results, one for each pod on the service backend, and one for the CNAME containing the port number and pod in the format auto-generated-name.my-svc.my-namespace.svc.cluster.local.

Backward compatibility

Previous versions of kube-dns used a name in the format my-svc.my-namespace.cluster.local (the svc layer is added later). But this format is no longer supported.

Pods

Pod is assigned a DNS record with the name format pod-ip-address.my-namespace.pod.cluster.local.

For example, a pod whose IP address is 1.2.3.4 and its namespace default,DNS name is cluster.local, then its record is: 1-2-3-4.default.pod.cluster.local.

When pod is created, its hostname is set in Pod's metadata.name (you should be aware of this when writing yaml).

In v1.2, users can specify a Pod annotation, pod.beta.kubernetes.io/hostname, to specify the hostname of the Pod. This Pod comment, once specified, will take precedence over the name of Pod and become the hostname of pod. For example, if a Pod is annotated with pod.beta.kubernetes.io/hostname: my-pod-name, then the hostname of the Pod will be set to my-pod-name.

A beta feature has also been introduced in v1.2 where the user specifies the Pod annotation, pod.beta.kubernetes.io/subdomain, to specify the subdomain of the Pod. For example, if a Pod has its hostname annotation set to "foo", its subdomain annotation to "bar", and its namespace to "my-namespace", its final FQDN is "foo.bar.my-namespace.svc.cluster.local".

In v1.3, PodSpec has hostname and subdomain fields that specify the hostname and subdomain of Pod. It takes precedence over the pod.beta.kubernetes.io/hostname and pod.beta.kubernetes.io/subdomain mentioned above.

Example:

ApiVersion: v1kind: Servicemetadata: name: default-subdomainspec: selector: name: busybox clusterIP: None ports:-name: foo # Actually, no port is needed. Port: 1234 targetPort: 1234---apiVersion: v1kind: Podmetadata: name: busybox1 labels: busyboxspec: hostname: busybox-1 subdomain: default-subdomain containers:-image: busybox command:-sleep-"3600" name: busybox---apiVersion: v1kind: Podmetadata: name: busybox2 labels: name: busyboxspec: hostname: busybox-2 subdomain: default-subdomain containers:-image: busybox command:-sleep-"3600" name: busybox

If multiple pod in a headless service are in the same namespace and the subdomain name is the same, the KubeDNS of the cluster will still return a complete and qualified hostname for each Pod. Given a Pod whose hostname is set to busybox-1,subdomain to default-subdomain, and the headless Service in the same namespace is named default-subdomain, then pod's own FQDN is "busybox-1.default-subdomain.my-namespace.svc.cluster.local".

In Kubernetes v1.2, the Endpoint object also uses the annotated endpoints.beta.kubernetes.io/hostnames-map. Its value is the map [string (IP)] [endpoints.HostRecord] in json format, such as'{"10.245.1.6": {HostName: "my-webserver"}}'. If Endpoint is used for headless service, a record is created for it in the format... svc. In json format, for example, if Endpoint is used for a headless service named "bar" and the ip of one of the Endpoint is "10.245.1.6", a record named "my-webserver.bar.my-namespace.svc.cluster.local" will be created, and a query on the record will result in "10.245.1.6". This Endpoint annotation generally does not need to be specified by the end user, but can be used by the internal service controller to implement the above features.

In v1.3, the Endpoint object can specify hostname and IP for any Endpoint. The hostname field overrides the value of the endpoints.beta.kubernetes.io/hostnames-map annotation.

In v1.3, the following annotations are deprecated: pod.beta.kubernetes.io/hostname,pod.beta.kubernetes.io/subdomain, endpoints.beta.kubernetes.io/hostnames-map.

How to test whether DNS works to create a simple Pod, using the test environment

Create a file called busybox.yaml, using the following:

ApiVersion: v1kind: Podmetadata: name: busybox namespace: defaultspec: containers:-image: busybox command:-sleep-"3600" imagePullPolicy: IfNotPresent name: busybox restartPolicy: Always

Use this file to create a pod:

Kubectl create-f busybox.yaml waits for pod to enter running state

Get pod status:

$kubectl get pods busybox

You will see:

NAME READY STATUS RESTARTS AGEbusybox 1 move 1 Running 0 7m confirm that DNS is working

Once pod is in the running state, you can use exec nslookup to query the status:

$kubectl exec-ti busybox-nslookup kubernetes.default

You should see a similar result:

Server: 10.0.0.10Address 1: 10.0.0.10Name: kubernetes.defaultAddress 1: 10.0.0.1

If the above results occur, it means that DNS is working properly.

Troubleshooting

If nslookup fails, check the following options:

Check the local DNS configuration

Check the resolv.conf file for pod.

$kubectl exec busybox cat / etc/resolv.conf

Verify that the search path and name sever are set to look similar to the following (note that the search path may vary from cloud provider to cloud provider):

Search default.svc.cluster.local svc.cluster.local cluster.local google.internal c.gce_project_id.internalnameserver 10.0.0.10options ndots:5 rapid diagnosis

The following error indicates that there is a problem with kube-dns add-on or related services:

$kubectl exec-ti busybox-- nslookup kubernetes.defaultServer: 10.0.0.10Address 1: 10.0.0.10nslookup: can't resolve 'kubernetes.default'

Or

$kubectl exec-ti busybox-- nslookup kubernetes.defaultServer: 10.0.0.10Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.localnslookup: can't resolve 'kubernetes.default' check whether DNS pod is running

Use the kubectl get pods command to confirm that DNS pod is running.

$kubectl get pods-- namespace=kube-system-l k8s-app=kube-dns

The results should be as follows:

NAME READY STATUS RESTARTS AGE...kube-dns-v19-ezo1y 3/3 Running 0 1h...

If there is no relevant pod running, or if the pod status is failed/completed, then your environment does not deploy DNS add-on by default, you need to deploy it manually.

Check for errors in DNS pod

Use the kubectl log command to view the logs of the DNS daemon.

$kubectl logs-- namespace=kube-system $(kubectl get pods-- namespace=kube-system-l k8s-app=kube-dns-o name)-c kubedns$ kubectl logs-- namespace=kube-system $(kubectl get pods-- namespace=kube-system-l k8s-app=kube-dns-o name)-c dnsmasq$ kubectl logs-- namespace=kube-system $(kubectl get pods-- namespace=kube-system-l k8s-app=kube-dns-o name)-c healthz

If there are any suspicious logs, the letter Wemerol F at the beginning of each line indicates warning, error, and fault, respectively. Please search for entries in these error logs, or report unexpected errors through the kubernetes issues page.

Whether the DNS service is started

Use the kubectl get service command to see if the DNS service has been started.

$kubectl get svc-namespace=kube-system

You will see:

NAME CLUSTER-IP EXTERNAL-IP PORT (S) AGE...kube-dns 10.0.0.10 53 Universe UDP 53 TCP 1h.

The service will be created by default, or if you manually create the service but the service does not appear in the above command, please check the debugging services page page for more information.

Is DNS Endpoint exposed?

You can use the kubectl get endpoints command to confirm that DNS Endpoint is exposed.

$kubectl get ep kube-dns-namespace=kube-system

You should see the following results:

NAME ENDPOINTS AGEkube-dns 10.180.3.17:53,10.180.3.17:53 1h

If you don't see Endpoint, check out the debugging services page page.

To see more Kubernetes DNS examples, check the cluster-dns examples in the Kubernetes Github repository.

How to work

The running Kubernetes DNS pod contains three containers-- kubedns, dnsmasq, and a health check container called healthz. The kubedns process monitors changes to Service and Endpoint on Kubernetes master and maintains the lookup structure in memory to serve DNS requests. The dnsmasq container adds DNS caching to improve performance. The healthz container provides a single point of health check Endpoint to check the health of dnsmasq and kubedns.

DNS pod is exposed as a service, which has a static IP. Once created, kubelet uses the-- cluster-dns=10.0.0.10 identity to pass the DNS configuration information to each container.

The DNS name also requires a domain. The local domain is configurable. In kubelet, use the-- cluster-domain= parameter.

The DNS service of the Kubernetes cluster (based on the SkyDNS library) supports forward lookup (A recoreds), service lookup (SRV records) and reverse IP address lookup (PTR recoreds).

Inherit DNS from node

When running pod, kubelet anticipates the DNS service of the cluster and searches for the path in the local DNS settings of the node. If node can resolve DNS names, so can pod.

If you want to use a different DNS in pod, you can use the-resolv-conf parameter of kubelet. This setting means that pod does not inherit DNS from node. Setting this value to a different file path means that the file will be used to configure DNS instead of / etc/resolv.conf.

Known problem

By default, the Kubernetes installation does not use the cluster's DNS configuration to set the Kubernetes node's resolv.conf file, because the process depends on the distribution's configuration.

Linux's libc has a limit of 3 DNS nameserver and 6 DNS search records, and Kubernetes consumes one nameserver and 3 search records. This means that if a local configuration already uses 3 nameserver or more than 3 search records, these configurations may be lost. There is an interim solution where node can run dnsmasq, which provides more nameserver options, but not more search options. You can also use kubelet's-- resolv-conf option.

If you are using Alpine 3.3 or earlier, DNS may not work properly, which is a known problem.

Thank you for reading! This is the end of this article on "sample Analysis of Kubernetes DNS". I hope the above content can be of some help to you, so that you can learn more knowledge. 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.