入門Kubernetes-DaemonSet對象(守護進程)

前言：

　在集羣部署中，因爲節點數量不定，那麼若是咱們須要對每一個節點中都運行一個守護進程、日誌收集進程等狀況時，在k8s中如何實現呢？

　經過了解DaemonSet 資源能夠實現上述狀況。

1、Kubernetes 中資源對象

　在k8s中有不少資源對象，如下列舉的內容都是 k8s 中相關對象的對象，這些對象均可以在 yaml 文件中做爲一種 API 類型來配置。

類別	名稱
工做負載型資源對象	Pod、Replicaset、ReplicationController、Deployments、StatefulSets、DaemonSet、Job、CronJob
服務發現及負載均衡	Service、Ingress
配置與存儲	Volume、Persistent Volume、CSl 、 configMap、Secret
集羣資源	Namespace、Node、Role、ClusterRole、RoleBinding、ClusterRoleBinding
元數據資源	HPA、PodTemplate、LimitRang

　前面已經對：Pod、Replicaset、Deployments、Service有了必定了解，接下來繼續對DaemonSet對象進行學習

2、什麼是DaemonSet ？

　DaemonSet：用於確保所有（或者某些）節點上運行一個 Pod 的副本。 當有節點加入集羣時， 也會爲他們新增一個 Pod 。 當有節點從集羣移除時，這些 Pod 也會被回收。刪除 DaemonSet 將會刪除它建立的全部 Pod。

　DaemonSet 的一些典型用法：

• 在每一個節點上運行集羣守護進程
• 在每一個節點上運行日誌收集守護進程
• 在每一個節點上運行監控守護進程

　一種簡單的用法是爲每種類型的守護進程在全部的節點上都啓動一個 DaemonSet。 一個稍微複雜的用法是爲同一種守護進程部署多個 DaemonSet；每一個具備不一樣的標誌， 而且對不一樣硬件類型具備不一樣的內存、CPU 要求。

　總結：DaemonSet 保證每一個一個節點上都運行一個定義的Pod副本。 

3、DaemonSet Spec 的定義

　a）必填字段：

　　與其餘k8s資源定義同樣：DaemonSet 須要 apiVersion、kind 和 metadata字段。

　　DaemonSet 對象的名稱必須是一個合法的 DNS 子域名

　　　DNS子域名：　　　　

• • 不能超過253個字符
  • 只能包含小寫字母、數字，以及'-' 和 '.'
  • 須以字母數字開頭
  • 須以字母數字結尾

　b）Pod模板定義：　　

　　.spec 中惟一必需的字段是 .spec.template。

　　.spec.template 是一個 Pod 模板。 除了它是嵌套的，於是不具備 apiVersion 或 kind 字段以外，它與 Pod 具備相同的 schema。

　　除了 Pod 必需字段外，在 DaemonSet 中的 Pod 模板必須指定合理的標籤（查看 Pod 選擇算符）。

　　在 DaemonSet 中的 Pod 模板必須具備一個值爲 Always 的 RestartPolicy。 當該值未指定時，默認是 Always。

　　Pod 選擇算符 

.spec.selector 字段表示 Pod 選擇算符，它與 Job 的 .spec.selector 的做用是相同的。

從 Kubernetes 1.8 開始，您必須指定與 .spec.template 的標籤匹配的 Pod 選擇算符。 用戶不指定 Pod 選擇算符時，該字段再也不有默認值。 選擇算符的默認值生成結果與 kubectl apply 不兼容。 此外，一旦建立了 DaemonSet，它的 .spec.selector 就不能修改。 修改 Pod 選擇算符可能致使 Pod 意外懸浮，而且這對用戶來講是費解的。

spec.selector 是一個對象，以下兩個字段組成：

• • matchLabels - 與 ReplicationController 的 .spec.selector 的做用相同。
  • matchExpressions - 容許構建更加複雜的選擇器，能夠經過指定 key、value 列表以及將 key 和 value 列表關聯起來的 operator。

當上述兩個字段都指定時，結果會按邏輯與（AND）操做處理。

若是指定了 .spec.selector，必須與 .spec.template.metadata.labels 相匹配。 若是與後者不匹配，則 DeamonSet 會被 API 拒絕。

　c）僅在某些節點上運行 Pod

　　若是指定了 .spec.template.spec.nodeSelector，DaemonSet 控制器將在可以與 Node 選擇算符 匹配的節點上建立 Pod。

　　若是根本就沒有指定，則 DaemonSet 控制器將在全部節點上建立 Pod。

　d）通訊方式

 　　DaemonSet 中的 Pod 進行通訊的幾種可能模式以下：

• • 推送（Push）：配置 DaemonSet 中的 Pod，將更新發送到另外一個服務，例如統計數據庫。 這些服務沒有客戶端。

  • NodeIP 和已知端口：DaemonSet 中的 Pod 可使用 hostPort，從而能夠經過節點 IP 訪問到 Pod。客戶端能經過某種方法獲取節點 IP 列表，而且基於此也能夠獲取到相應的端口。

  • DNS：建立具備相同 Pod 選擇算符的 無頭服務， 經過使用 endpoints 資源或從 DNS 中檢索到多個 A 記錄來發現 DaemonSet。

  • Service：建立具備相同 Pod 選擇算符的服務，並使用該服務隨機訪問到某個節點上的 守護進程（沒有辦法訪問到特定節點）。

4、DaemonSet 調度策略/更新策略

　a）調度策略

 　　一般狀況下，經過DaemonSet建立的的Pod應該調度到那個節點是經過Kubernetes調度策略決定的，然而，當這個Pod被建立的時候，運行在那個節點上其實已經被提早決定了，因此它會忽略調度器。所以：

• • DaemonSet控制器並不在意Node的unschedulable字段；
  • 即便調度器沒有啓動，DaemonSet控制器均可以建立Pod；

　　可是能夠經過如下方法來讓Pod運行到指定的Node上：

• • nodeSelector：只調度到匹配指定label的Node上；
  • nodeAffinity：功能更豐富的Node選擇器，好比支持集合操做；
  • podAffinity：調度到知足條件的Pod所在的Node上；

　b）DaemonSet 有兩種更新策略：

• OnDelete: 使用 OnDelete 更新策略時，在更新 DaemonSet 模板後，只有當你手動刪除老的 DaemonSet pods 以後，新的 DaemonSet Pod 纔會被自動建立。跟 Kubernetes 1.6 之前的版本相似。
• RollingUpdate: 默認的更新策略。使用 RollingUpdate 更新策略時，在更新 DaemonSet 模板後， 老的 DaemonSet pods 將被終止，而且將以受控方式自動建立新的 DaemonSet pods。 更新期間，最多隻能有 DaemonSet 的一個 Pod 運行於每一個節點上

5、DaemonSet 示例

　a）建立一個收集日誌的DaemonSet，使用filebeat收集日誌，經過filebeat收集日誌傳給redis。

# 建立Redis環境
apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: redis
      role: cachedb
  template:
    metadata:
      labels:
        app: redis
        role: cachedb
    spec:
      containers:
      - name: redis
        image: redis:5.0.5-alpine
        ports:
        - name: redis
          containerPort: 6379
---
# 建立服務
apiVersion: v1
kind: Service
metadata:
  name: redis
  namespace: default
spec:
  type: ClusterIP
  selector:
    app: redis
    role: cachedb
  ports:
  - port: 6379    
---
# 建立守護進程集合：filebeat-收集日誌
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: filebeat-ds
  namespace: default
spec:
  selector:
    matchLabels:
      app: filebeat
      role: logstorage
  template:
    metadata:
      labels:
        app: filebeat
        role: logstorage
    spec:
      containers:
      - name: filebeat
        image: ikubernetes/filebeat:5.6.5-alpine
        env:
        - name: REDIS_HOST
          value: redis.default.svc.cluster.local 

　b）執行命令：

//應用yaml
kubectl apply -f redis-filebeat.yaml

　c）查看運行狀況

# 1. 查看Pod建立狀況
kubectl get pods
NAME                                 READY   STATUS    RESTARTS   AGE
filebeat-ds-669qx                    1/1     Running   0          56m
filebeat-ds-grthz                    1/1     Running   0          53m
redis-84d7cdf88b-v4n8q               1/1     Running   0          46m

# 2. 查看服務狀態
 kubectl get svc
NAME          TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
redis         ClusterIP   10.100.160.198   <none>        6379/TCP       63m

# 3. 進入filebeat中，添加日誌記錄
kubectl exec -it filebeat-ds-grthz -- /bin/bash
cd /var/log/containers/
echo "測試日誌" > a.log

# 4. 進入redis中查看
kubectl exec -it redis-84d7cdf88b-v4n8q -- /bin/sh
/data # redis-cli -h redis.default.svc.cluster.local -p 6379
redis.default.svc.cluster.local:6379> KEYS *
1) "filebeat"

總結：

　本篇簡單的學習了用於建立守護進程的DaemonSet資源對象，接下來就還將繼續對StatefulSets資源進行學習。　

參考：

　daemonset