[k8s]kube-dns架構圖解

kubedns

　DNS Policy

http://blog.fleeto.us/translation/configuring-private-dns-zones-and-upstream-nameservers-kubernetes

Kubernetes 目前在 Pod 定義中支持兩個 DNS 策略：Default和ClusterFirst，dnsPolicy缺省爲ClusterFirst：

若是dnsPolicy設置爲Default，那麼域名解析配置會從 Pod 所在節點繼承而來。注意，本文所述功能在dnsPolicy設置爲Default時無效。
若是dnsPolicy設置爲ClusterFirst，DNS 查詢會被髮送到 kube-dns 服務。kube-dns 服務負責相應以集羣域名爲後綴（例如.cluster.local）的查詢。其餘的域名查詢（例如 www.kubernetes.io ）會被轉發給來自節點定義的上級域名服務器。

https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#dns-policy

By default, DNS policy for a pod is ‘ClusterFirst’. So pods running with hostNetwork cannot resolve DNS names. To have DNS options set along with hostNetwork, you should specify DNS policy explicitly to ‘ClusterFirstWithHostNet’. Update the busybox.yaml as following:

apiVersion: v1
kind: Pod
metadata:
  name: busybox
  namespace: default
spec:
  containers:
  - image: busybox
    command:
      - sleep
      - "3600"
    imagePullPolicy: IfNotPresent
    name: busybox
  restartPolicy: Always
  hostNetwork: true
  dnsPolicy: ClusterFirstWithHostNet

組件架構看這個就夠了
http://cizixs.com/2017/04/11/kubernetes-intro-kube-dns

設置細節看這個就夠了
http://blog.fleeto.us/translation/configuring-private-dns-zones-and-upstream-nameservers-kubernetes

busybox你的忠實實驗伴侶
命令看這裏: https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#dns-policy

• 架構圖:
  

應該是這樣
老版本

新版本

參考:
http://cizixs.com/2017/04/11/kubernetes-intro-kube-dns

• kubedns架構有3個容器組成:

gcr.io/google_containers/k8s-dns-dnsmasq-nanny-amd64:1.14.1
gcr.io/google_containers/k8s-dns-kube-dns-amd64:1.14.1
gcr.io/google_containers/k8s-dns-sidecar-amd64:1.14.1

• 原理梳理下
  • 故障排除: http://blog.csdn.net/styshoo/article/details/69941606

　運行的Kubernetes DNS pod包含3個容器——kubedns、dnsmasq和一個叫作healthz的健康檢查容器。kubedns進程監視Kubernetes master上Service和Endpoint的改變，並在內存中維護lookup 結構用於服務DNS請求。dnsmasq容器增長DNS緩存，從而提高性能。healthz容器提供一個單點的健康檢查Endpoint，檢查dnsmasq和kubedns的健康程度。
　　DNS pod以服務的形式暴露出來，它擁有一個靜態IP。一旦被建立，kubelet就使用--cluster-dns=10.0.0.10標識，將DNS配置信息傳遞給每一個容器。
　　DNS名稱也須要域。本地域是能夠配置的，在kubelet中，使用--cluster-domain= 參數。
　　Kubernetes集羣的DNS服務（基於SkyDNS庫）支持forward lookup（A recoreds），service lookup（SRV records）和反向IP地址查找（PTR recoreds）。

• 先後版本對比: http://www.javashuo.com/article/p-vlllyjcr-dm.html
• 存在的問題: 建立k8的dns的時候沒看到dns的yml裏配置有api的地址,不知道kube-dns組件是如何去找api的,可是經過kubectl exec -it -n kube-system kube-dns-1446441763-14hdh -c kubedns env 能夠看到KUBERNETES_SERVICE_HOST一些環境變量KUBERNETES_SERVICE_HOST=10.233.0.1 ,可是環境變量是怎麼注入進去的呢? 這個是個問題,沒看到yml裏有環境變量.

後來我查閱了下:

• 是docker link的一些機制.
  https://docs.docker.com/compose/link-env-deprecated/

Compose uses Docker links to expose services’ containers to one another. Each linked container injects a set of environment variables, each of which begins with the uppercase name of the container.
To see what environment variables are available to a service, rundocker-compose run SERVICE env.

name_PORT
Full URL, e.g. DB_PORT=tcp://172.17.0.5:5432

name_PORT_num_protocol
Full URL, e.g. DB_PORT_5432_TCP=tcp://172.17.0.5:5432

name_PORT_num_protocol_ADDR
Container’s IP address, e.g. DB_PORT_5432_TCP_ADDR=172.17.0.5

name_PORT_num_protocol_PORT
Exposed port number, e.g. DB_PORT_5432_TCP_PORT=5432

name_PORT_num_protocol_PROTO
Protocol (tcp or udp), e.g. DB_PORT_5432_TCP_PROTO=tcp

name_NAME
Fully qualified container name, e.g. DB_1_NAME=/myapp_web_1/myapp_db_1

k8s裏說的比較清楚:

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

Environment variables
When a Pod is run on a Node, the kubelet adds a set of environment variables for each active Service. It supports both Docker links compatible variables (see makeLinkVariables) and simpler {SVCNAME}_SERVICE_HOST and {SVCNAME}_SERVICE_PORT variables, where the Service name is upper-cased and dashes are converted to underscores.
For example, the Service "redis-master" which exposes TCP port 6379 and has been allocated cluster IP address 10.0.0.11 produces the following environment variables:

REDIS_MASTER_SERVICE_HOST=10.0.0.11
REDIS_MASTER_SERVICE_PORT=6379
REDIS_MASTER_PORT=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP_PROTO=tcp
REDIS_MASTER_PORT_6379_TCP_PORT=6379
REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11

• 測了下,一個ns裏有多個svc時候,新建一個pod,會註冊全部svc到這個pod.
  

• 執行kubenernetes看執行過程

kubectl -v 9 get pods

• 強制刪除2個參數還不錯
  https://kubernetes.io/docs/tasks/run-application/force-delete-stateful-set-pod/

Force Deletion
Force deletions do not wait for confirmation from the kubelet that the Pod has been terminated. Irrespective of whether a force deletion is successful in killing a Pod, it will immediately free up the name from the apiserver. This would let the StatefulSet controller create a replacement Pod with that same identity; this can lead to the duplication of a still-running Pod, and if said Pod can still communicate with the other members of the StatefulSet, will violate the at most one semantics that StatefulSet is designed to guarantee.
When you force delete a StatefulSet pod, you are asserting that the Pod in question will never again make contact with other Pods in the StatefulSet and its name can be safely freed up for a replacement to be created.
If you want to delete a Pod forcibly using kubectl version >= 1.5, do the following:

kubectl delete pods <pod> --grace-period=0 --force

If you’re using any version of kubectl <= 1.4, you should omit the --force option and use:

kubectl delete pods <pod> --grace-period=0

Always perform force deletion of StatefulSet Pods carefully and with complete knowledge of the risks involved. What’s next