kubedns

　DNS Policy

Kubernetes 目前在 Pod 定義中支援兩個 DNS 策略：Default和ClusterFirst，dnsPolicy預設為ClusterFirst：

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

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

• 架構圖:
  

• 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

• 原理梳理下

  • 　執行的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）。

  • 存在的問題: 建立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裡有環境變數.

後來我查閱了下:

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裡說的比較清楚:

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

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