Kubernetes指南
Linux性能优化实战eBPF 核心技术与实战SDN指南个人博客
EN
EN
  • Overview
  • Introduction
    • Kubernetes Introduction
    • Kubernetes Concepts
    • Kubernetes 101
    • Kubernetes 201
    • Kubernetes Cluster
  • Concepts
    • Concepts
    • Architecture
    • Design Principles
    • Components
      • etcd
      • kube-apiserver
      • kube-scheduler
      • kube-controller-manager
      • kubelet
      • kube-proxy
      • kube-dns
      • Federation
      • kubeadm
      • hyperkube
      • kubectl
    • Objects
      • Autoscaling
      • ConfigMap
      • CronJob
      • CustomResourceDefinition
      • DaemonSet
      • Deployment
      • Ingress
      • Job
      • LocalVolume
      • Namespace
      • NetworkPolicy
      • Node
      • PersistentVolume
      • Pod
      • PodPreset
      • ReplicaSet
      • Resource Quota
      • Secret
      • SecurityContext
      • Service
      • ServiceAccount
      • StatefulSet
      • Volume
  • Setup
    • Setup Guidance
    • kubectl Install
    • Single Machine
    • Feature Gates
    • Best Practice
    • Version Support
    • Setup Cluster
      • kubeadm
      • kops
      • Kubespray
      • Azure
      • Windows
      • LinuxKit
      • kubeasz
    • Setup Addons
      • Addon-manager
      • DNS
      • Dashboard
      • Monitoring
      • Logging
      • Metrics
      • GPU
      • Cluster Autoscaler
      • ip-masq-agent
  • Extension
    • API Extension
      • Aggregation
      • CustomResourceDefinition
    • Access Control
      • Authentication
      • RBAC Authz
      • Admission
    • Scheduler Extension
    • Network Plugin
      • CNI
      • Flannel
      • Calico
      • Weave
      • Cilium
      • OVN
      • Contiv
      • SR-IOV
      • Romana
      • OpenContrail
      • Kuryr
    • Container Runtime
      • CRI-tools
      • Frakti
    • Storage Driver
      • CSI
      • FlexVolume
      • glusterfs
    • Network Policy
    • Ingress Controller
      • Ingress + Letsencrypt
      • minikube Ingress
      • Traefik Ingress
      • Keepalived-VIP
    • Cloud Provider
    • Device Plugin
  • Cloud Native Apps
    • Apps Management
      • Patterns
      • Rolling Update
      • Helm
      • Operator
      • Service Mesh
      • Linkerd
      • Linkerd2
    • Istio
      • Deploy
      • Traffic Management
      • Security
      • Policy
      • Metrics
      • Troubleshooting
      • Community
    • Devops
      • Draft
      • Jenkins X
      • Spinnaker
      • Kompose
      • Skaffold
      • Argo
      • Flux GitOps
  • Practices
    • Overview
    • Resource Management
    • Cluster HA
    • Workload HA
    • Debugging
    • Portmap
    • Portforward
    • User Management
    • GPU
    • HugePage
    • Security
    • Audit
    • Backup
    • Cert Rotation
    • Large Cluster
    • Big Data
      • Spark
      • Tensorflow
    • Serverless
  • Troubleshooting
    • Overview
    • Cluster Troubleshooting
    • Pod Troubleshooting
    • Network Troubleshooting
    • PV Troubleshooting
      • AzureDisk
      • AzureFile
    • Windows Troubleshooting
    • Cloud Platform Troubleshooting
      • Azure
    • Troubleshooting Tools
  • Community
    • Development Guide
    • Unit Test and Integration Test
    • Community Contribution
  • Appendix
    • Ecosystem
    • Learning Resources
    • Domestic Mirrors
    • How to Contribute
    • Reference Documents
由 GitBook 提供支持
在本页
  • CoreDNS: Efficiency at its best
  • DNS formats supported
  • Configuring Private DNS Servers and Upstream DNS Servers
  • kube-dns: At the heart of Kubernetes
  • Starting a kube-dns example
  • kube-dns: Behind the scenes
  • An introduction to the source code
  • Frequently Asked Questions
  • References
  1. Concepts
  2. Components

kube-dns

上一页kube-proxy下一页Federation

最后更新于1年前

The DNS service is one of the essentials in the Kubernetes world, and it's facilitated through kube-dns or CoreDNS as crucial extensions of the Kubernetes cluster.

CoreDNS: Efficiency at its best

Starting from version v1.11, has been available to furnish the vital DNS services, and it took the mantle as the default DNS service from v1.13. CoreDNS checks off all the boxes when it comes to efficiency and less resource usage. Thus, the shift from using kube-dns to CoreDNS in delivering DNS services to the cluster is highly recommended.

Upgrading from kube-dns to CoreDNS: Here's how you can do it:

$ git clone https://github.com/coredns/deployment
$ cd deployment/kubernetes
$ ./deploy.sh | kubectl apply -f -
$ kubectl delete --namespace=kube-system deployment kube-dns

For a fresh deployment, you can follow the CoreDNS extension configuration method .

DNS formats supported

  • Service

    • A record: Generates my-svc.my-namespace.svc.cluster.local. IP resolving takes two forms

      • For a standard service, it resolves to Cluster IP

      • For a headless service, it resolves to a list of specified Pod IPs

    • SRV record: Generates _my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster.local

  • Pod

    • A record: pod-ip-address.my-namespace.pod.cluster.local

    • Specified hostname and subdomain: hostname.custom-subdomain.default.svc.cluster.local. Check out an example shown below:

apiVersion: v1
kind: Pod
metadata:
  name: busybox2
  labels:
    name: busybox
spec:
  hostname: busybox-2
  subdomain: default-subdomain
  containers:
  - image: busybox
    command:
      - sleep
      - "3600"
    name: busybox

Configuring Private DNS Servers and Upstream DNS Servers

Beginning with Kubernetes 1.6, customization of stub domains and upstream name servers got easier by providing a ConfigMap for kube-dns. The configuration below introduces a standalone private root DNS server and two upstream DNS 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”]

Upon using the above configuration, query requests will first be sent to the DNS cache layer of kube-dns (Dnsmasq server). The Dnsmasq server checks the suffix of the request first. Requests with a cluster suffix (such as: ”.cluster.local”) will be sent to kube-dns, names with a stub domain suffix (like: ”.acme.local”) will be dispatched to the configured private DNS server [“1.2.3.4”]. Finally, requests that do not satisfy any of these suffixes will be sent to the upstream DNS [“8.8.8.8”, “8.8.4.4”].

kube-dns: At the heart of Kubernetes

Starting a kube-dns example

kubectl apply -f https://github.com/feiskyer/kubernetes-handbook/raw/master/manifests/kubedns/kube-dns.yaml

This will initiate a Pod containing three containers in Kubernetes, running three DNS-related services:

# kube-dns container
kube-dns --domain=cluster.local. --dns-port=10053 --config-dir=/kube-dns-config --v=2

# dnsmasq container
dnsmasq-nanny -v=2 -logtostderr -configDir=/etc/k8s/dns/dnsmasq-nanny -restartDnsmasq=true -- -k --cache-size=1000 --log-facility=- --server=127.0.0.1#10053

# sidecar container
sidecar --v=2 --logtostderr --probe=kubedns,127.0.0.1:10053,kubernetes.default.svc.cluster.local.,5,A --probe=dnsmasq,127.0.0.1:53,kubernetes.default.svc.cluster.local.,5,A
kubectl apply -f https://github.com/feiskyer/kubernetes-handbook/raw/master/manifests/kubedns/coredns.yaml

kube-dns: Behind the scenes

As shown below, kube-dns consists of three main components:

  • kube-dns: The heart of the DNS service, mainly composed of KubeDNS and SkyDNS

    • KubeDNS listens to the changes in Service and Endpoint and updates related information in SkyDNS

    • SkyDNS is responsible for DNS resolution, listening on ports 10053 (tcp/udp) and 10055 for metrics

    • kube-dns also listens on port 8081 for health checks

  • dnsmasq-nanny: Manages dnsmasq and restarts it when the configuration changes

    • The upstream of dnsmasq is SkyDNS, meaning the internal DNS resolution of the cluster is handled by SkyDNS

  • sidecar: Looks after health checks and provides DNS metrics (listening on port 10054)

An introduction to the source code

Frequently Asked Questions

Issues with DNS Resolution in Ubuntu 18.04

Ubuntu 18.04 has been configured to activate systemd-resolved by default. This writes nameserver 127.0.0.53 into the system's /etc/resolv.conf. As this is a local address, it can cause CoreDNS or kube-dns to fail when resolving external addresses.

To fix this issue, replace the resolv.conf file generated by systemd-resolved:

sudo rm /etc/resolv.conf
sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

Or, manually specify the path to the resolv.conf for the DNS service:

--resolv-conf=/run/systemd/resolve/resolv.conf

References

Generally, the DNS service is deployed as an expansion. This can be done by adding the to the /etc/kubernetes/addons directory of the Master node. Of course, manual deployment is also an option:

Kubernetes v1.10 also supports the Beta version of CoreDNS, which outperforms kube-dns. Deployment can be done via extension by adding to the /etc/kubernetes/addons directory on the Master node. Of course, manual deployment is another option:

The kube-dns code has been separated from Kubernetes and can now be found at .

The code for kube-dns, dnsmasq-nanny, and sidecar starts from cmd/<cmd-name>/main.go respectively and calls pkg/dns, pkg/dnsmasq, and pkg/sidecar to perform respective functions. The core DNS resolution directly refers to the code in github.com/skynetservices/skydns/server, the specific implementation can be seen at .

CoreDNS
right here
kube-dns.yaml
coredns.yaml
https://github.com/kubernetes/dns
skynetservices/skydns
Introduction to dns-pod-service
coredns/coredns