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

one。 Custom dns

1. Introduction; 2. How to get the dns name; 3. Supported DNS mode; 4. Custom dns;1. Introduction

Kubernetes DNS dispatches DNS Pod and services on the cluster and configures kubelet to tell each container to use the IP of the DNS service to resolve the DNS name.

two。 How to get the DNS name

Each Service defined in the cluster (including the DNS server itself) is assigned a DNS name. By default, a client-side Pod's DNS search list will contain the Pod's own Namespace and cluster default domain. This can be well illustrated by the following example:

Suppose a Service foo is defined in the Namespace bar of the Kubernetes cluster. A Pod running in Namespace bar can be found simply by querying foo through DNS. A Pod running in Namespace quux can find the Service through the DNS query foo.bar.

The supported record types and supported layouts are detailed in the following sections. The layout, name or query command of the code part are regarded as implementation details and are subject to change without prior notice. Check out Kubernetes's DNS-based service discovery for the latest specification.

3. Supported DNS mode

The following paragraphs detail the supported record types and layouts. If any other layout, name, or query happens to be available, you need to study their implementation details in case you modify them later.

ServiceA record

The "normal" Service (except Headless Service) is assigned a DNS A record in the form of the name my-svc.my-namespace.svc.cluster-domain.example. This resolves to the Cluster IP of the Service.

The "Headless" Service (without Cluster IP) will also be assigned a DNS A record in the form of the name my-svc.my-namespace.svc.cluster-domain.example. Unlike a normal Service, it resolves to the IP of a set of Pod selected by the Service. You want the client to be able to use this set of IP, otherwise use the standard round-robin policy to choose from this set of IP.

SRV record

Named ports require the creation of SRV records, which are part of a normal Service or Headless Services. For each named port, the SRV record has the form _ my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example. For normal Service, this is resolved to the port number and CNAME:my-svc.my-namespace.svc.cluster-domain.example. For Headless Service, this is parsed into multiple results, one for each backend Pod for the Service, including the port number and CNAME of the Pod in the form auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example.

Hostname and subdomain fields of PodsPod

Currently, when a Pod is created, its hostname is the metadata.name value of the Pod.

In v1.2, users can configure Pod annotation to set the hostname of Pod through pod.beta.kubernetes.io/hostname. If annotation is configured for Pod, the name of Pod is preferred as the hostname. For example, given a Pod, it has annotation pod.beta.kubernetes.io/hostname: my-pod-name, and the hostname of the Pod is set to "my-pod-name".

In v1.3, PodSpec has a hostname field that can be used to specify the hostname of the Pod. The value of this field takes precedence over annotation pod.beta.kubernetes.io/hostname. The beta feature was introduced in v1.2, which allows users to specify annotation for Pod, where pod.beta.kubernetes.io/subdomain specifies the subdomain name of Pod. The final domain name will be ".svc." For example, the hostname annotation of Pod is set to "foo", the subdomain annotation is set to "bar", and the corresponding FQDN in Namespace "my-namespace" is "foo.bar.my-namespace.svc.cluster.local".

In v1.3, PodSpec has a subdomain field that can be used to specify the subdomain name of Pod. The value of this field takes precedence over the value of annotation pod.beta.kubernetes.io/subdomain.

DNS setting of 4.Pod

Pod's DNS configuration gives users more control over Pod's DNS settings.

The dnsConfig field is optional and can be used with any dnsPolicy setting. However, when the dnsPolicy of Pod is set to "None", the dnsConfig field must be specified.

Users can specify the following properties in the dnsConfig field:

Nameservers: the list of IP addresses of the DNS server that will be used for Pod. You can specify up to 3 IP addresses. When the dnsPolicy of Pod is set to "None", the list must contain at least one IP address, otherwise this property is optional. The listed servers are merged into the base name server generated from the specified DNS policy, and duplicate addresses are removed.

Searches: a list of DNS search domains used to find hostnames in Pod. This property is optional. When specified, the list provided will be merged into the basic search domain name generated according to the selected DNS policy. Duplicate domain names will be deleted. Kubernetes allows up to 6 search domains.

Options: an optional list of objects, where each object may have a name attribute (required) and a value attribute (optional). The contents of this property are merged into the options generated from the specified DNS policy. Duplicate entries will be deleted.

The following is an example of Pod with custom DNS settings

(1). Dns yaml configuration details

(2)。 Run dns ymal

(3)。 Test parsing dns

(4)。 After creating the above Pod, the container test gets the following in its / etc/resolv.conf file:

two。 Configure private dns through kube-dns

1. Ready to start 2. Configure stub domain and upstream DNS server 3. Understand the name resolution 4.ConfigMap option in Kubernetes configure private DNS and upstream domain name server in Kubernetes ready to start

You must have a Kubernetes cluster, and your Kubernetes cluster must have a kubectl command line tool. If you don't already have a cluster, you can build your own cluster through Minikube, or you can build it using any of the following Kubernetes tools:

Katacoda

Play with Kubernetes

For version information, enter kubectl version.

Kubernetes 1.6 and above.

The cluster must be configured to use the kube-dns plug-in.

Configure stub domain and upstream DNS server

The steps to deploy kube-dns are as follows

(1)。 Get: kube-dns yaml

Wget https://raw.githubusercontent.com/feiskyer/kubernetes-handbook/master/manifests/kubedns/kube-dns.yaml

(2)。 Set kube-dns.yaml clusterIP cluster ip address (reference: ip address is not used in kubernetes network disconnection)

Kubectl get service-all-namespaces

(3)。 Note that the kube-dns image needs to be obtained

By providing ConfigMap for kube-dns (kube-system:kube-dns), the cluster administrator can specify custom stub domains and upstream domain name servers.

For example, the following ConfigMap establishes a DNS configuration with a separate stub domain and two upstream domain name servers:

ApiVersion: v1 kind: ConfigMap metadata: name: kube-dns namespace: kube-system data: stubDomains: | {"acme.local": ["1.2.3.4"]} upstreamNameservers: | ["8.8.8.8", "8.8.4.4"]

As described above, DNS requests with the suffix ".acme.local" are forwarded to DNS 1.2.3.4. The Google public DNS server provides services for upstream queries. The following table describes how queries with specific domain names map to their target DNS servers:

Domain name response query server kubernetes.default.svc.cluster.localkube-dnsfoo.acme.local Custom DNS (1.2.3.4) widget.com upstream DNS (8.8.8.8,8.8.4.4, one of them)

Check the ConfigMap options for more details about the format of the configuration options.

Understand name resolution in Kubernetes

You can set the DNS policy for each Pod. Currently Kubernetes supports two Pod-specific DNS policies: "Default" and "ClusterFirst". These policies can be specified through the dnsPolicy flag. Note: "Default" is not the default DNS policy. If dnsPolicy is not explicitly specified, "ClusterFirst" will be used.

"Default" DNS strategy

If dnsPolicy is set to "Default", the name resolution configuration inherits from the node on which Pod is running. Custom upstream domain name servers and stub domains cannot be used with this policy.

"ClusterFirst" DNS strategy

If dnsPolicy is set to "ClusterFirst", name resolution is handled differently, * depending on whether the stub domain and upstream DNS server are configured *.

No custom configuration: any requests that do not match the configured cluster domain name suffix, such as "www.kubernetes.io", will be forwarded to the upstream domain name server inherited from the node.

Custom configuration: if the stub domain and upstream DNS server are configured (similar to what was configured in the previous example), the DNS query will route the request based on the following process:

The query is first sent to the DNS cache layer in kube-dns.

From the cache layer, check the suffix of the request and forward it to the corresponding DNS according to the following:

* name with cluster suffix * (for example, ".cluster.local"): the request is sent to kube-dns.

* name with stub domain suffix * (for example, ".acme.local"): the request is sent to the configured custom DNS parser (for example, listening at 1.2.3.4).

* failed to match the suffixed name * (e.g. "widget.com"): the request is forwarded to the upstream DNS (for example: Google public DNS server, 8.8.8.8 and 8.8.4.4).

ConfigMap option

The ConfigMap options for kube-dns kube-system:kube-dns are as follows:

The field format describes stubDomains (optional) the JSON map that uses the DNS suffix as the key (for example, "acme.local"), as well as the value consisting of the JSON array of DNS IP. The target domain name server may be a Kubernetes Service. For example, you can run your own copy of dnsmasq to expose the DNS name to ClusterDNS namespace. UpstreamNameservers (optional) JSON array of DNS IP. Note: if specified, the specified value replaces the domain name server that is obtained by default from the node's / etc/resolv.conf. Limit: up to three upstream domain name servers can be specified. Additional example: stub domain

In this example, the user has a Consul DNS service discovery system that they want to integrate with kube-dns. The Consul domain name server address is 10.150.0.1, and all Consul names have the suffix ".cons.local". To configure Kubernetes, the cluster administrator simply creates a ConfigMap object, as shown below:

ApiVersion: v1kind: ConfigMap metadata: name: kube-dns namespace: kube-system data: stubDomains: | {"consul.local": ["10.150.0.1"]}

Note that the cluster administrator does not want to overwrite the upstream domain name server of the node, so they do not specify the optional upstreamNameservers field.

Example: upstream domain name server

In this example, cluster administrators do not want to explicitly force all non-clustered DNS queries into their own domain name server 172.16.0.1. And this is easy to achieve: they just need to create a ConfigMap,upstreamNameservers field to specify the desired domain name server:

ApiVersion: v1 kind: ConfigMap metadata: name: kube-dns namespace: kube-system data: upstreamNameservers: | ["172.16.0.1"]

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.