欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

理解k8s控制器DaemonSet創(chuàng)建及使用場景

 更新時間:2022年09月06日 08:49:07   作者:路由器沒有路  
這篇文章主要為大家介紹了k8s控制器DaemonSet創(chuàng)建及使用場景詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪

DaemonSet 簡介

DaemonSet 的主要作用,是在 Kubernetes 集群里,運行一個 Daemon Pod。 DaemonSet 只管理 Pod 對象,然后通過 nodeAffinity 和 Toleration 這兩個調度器參數的功能,保證了每個節(jié)點上有且只有一個 Pod。

DaemonSet 是一種面向特定應用場景的 Pod 控制器,盡管它也可以管理 Pod 的多個副本,但它主要用于保證一個 Node 上只運行一個 Pod 的場景:

DaemonSet 使用場景

每個節(jié)點上只有一個這樣的 Daemon Pod 實例,然后當有新的節(jié)點加入 Kubernetes 集群后,該 Pod 會自動地在新節(jié)點上被創(chuàng)建出來。當舊節(jié)點被刪除后,它上面的 Pod 也會相應地被回收掉。

Daemon Pod 的意義確實是非常重要的。比如的作用:

  • 網絡插件的 Agent 組件,都必須運行在每一個節(jié)點上,用來處理這個節(jié)點上的容器網絡。
  • 存儲插件的 Agent 組件,也必須運行在每一個節(jié)點上,用來在這個節(jié)點上掛載遠程存儲目錄,操作容器的 Volume 目錄,比如:glusterd、ceph。
  • 監(jiān)控組件和日志組件,也必須運行在每一個節(jié)點上,負責這個節(jié)點上的監(jiān)控信息和日志搜集,比如:fluentd、logstash、Prometheus 等。

DaemonSet 創(chuàng)建

k8s 環(huán)境搭建參考網上教程,這里就不再贅述了。

先來個簡單的例子快速體驗 DaemonSet 控制器是如何應用的。

一個簡單的 DaemonSet 配置如下:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nginx-daemonset
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.17.0

初步看,這份配置跟 Deployment 基本類似,唯一一個顯著的差異是 DaemonSet 不需要指定副本數,因為它的副本數取決于工作節(jié)點數。

DaemonSet 配置中 spec.selector 和 spec.template 作用我們已在介紹 Deployment 時介紹過,在此不再贅述。

該份配置將創(chuàng)建一個 DaemonSet 對象,然后 DaemonSet 控制器會根據該對象信息分別在每個節(jié)點上創(chuàng)建一個 Pod 副本。

接下來使用kubectl create命令將該配置提次給 kube-apiserver,如下所示:

[root@k8s-master]# kubectl create -f daemonset.yaml
daemonset.apps/nginx-daemonset created

查看 DaemonSet

首先查看剛剛創(chuàng)建的 DaemonSet 對象:

[root@k8s-master]# kubectl get daemonset
NAME  DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
nginx-daemonset     3     3     3     3     3      <none>          1m3s

命令行輸出中各字段含義如下:

  • NAME: DaemonSet 對象名稱,同配置中的 metadata.name;
  • DESIRED:需求副本個數,由于沒有刻意篩選節(jié)點,所以副本個數等同于節(jié)點個數(默認);
  • CURRENT:當前已創(chuàng)建的副本個數;
  • READY:處于 Ready 狀態(tài)的副本個數;
  • UP-TO-DATE:已按最新 Pod 模版創(chuàng)建的 Pod 個數;
  • AVAILABLE:可用的副本個數;
  • NODE SELECTOR:節(jié)點選擇器,本例中我們沒有選擇,值為空;
  • AGE:創(chuàng)建至今經歷的時間。

上面的字段中,除了 NODE SELECTOR 以外,我們已在前面的章節(jié)中介紹過。其實 Node Selector 并不是 DaemonSet 對象特有的配置,它是 Pod 模版中用于為 Pod 匹配節(jié)點的配置,DaemonSet 控制器使用該 Node Selector 來篩選需要創(chuàng)建副本的節(jié)點,如果沒有指定,則默認選擇全部節(jié)點。

接著,查看 DaemonSet 控制器所創(chuàng)建的 Pod 副本信息:

[root@k8s-master]# kubectl get pods -o wide
NAME                    READY   STATUS    RESTARTS   AGE     IP           NODE           NOMINATED NODE   READINESS GATES
nginx-daemonset-66dbc   1/1     Running   0          5m13s   10.135.3.2   k8s-master   <none>           <none>
nginx-daemonset-akpdg   1/1     Running   0          5m13s   10.135.1.2   k8s-node1   <none>           <none>
nginx-daemonset-l3wnd   1/1     Running   0          5m13s   10.135.2.2   k8s-node2    <none>           <none>

可以看到,在每個節(jié)點上均創(chuàng)建了一個副本,是符合預期的。

更新 DaemonSet

下面我們適當的調整下 Pod 部署策略,只希望 Pod 運行在名為 k8s-node 的節(jié)點上,這樣我們只需要配置 DaemonSet 對象的 spec.template.spec.nodeSelector 來選擇節(jié)點即可。

在 k8s-node 的節(jié)點中存在一個標識節(jié)點的 label:

kubernetes.io/hostname: k8s-node1

使用 kubectl edit 命令修改配置的 spec.template.spec.nodeSelector 參數如下:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  ...
spec:
  ...
  template:
    ...
    spec:
      ...
      nodeSelector:
        kubernetes.io/hostname: k8s-node1

然后再次觀察 DaemonSet 對象和 Pod 副本:

[root@k8s-master]# kubectl get daemonsets
NAME              DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                        AGE
nginx-daemonset   1         1         1       1            1           kubernetes.io/hostname=k8s-node1   37m
[root@k8s-master]# kubectl get pods -o wide
NAME                    READY   STATUS    RESTARTS   AGE   IP           NODE          NOMINATED NODE   READINESS GATES
nginx-daemonset-66gk2   1/1     Running   0          10s   10.135.2.3   k8s-node1   <none>           <none>

可以發(fā)現(xiàn) DaemonSet 狀態(tài)中,NODE SELECTOR 正確地展示了上面的修改,而且需求的 Pod 副本數也變成了 1 個,符合預期。

原來運行的 3 個 Pod 副本減少到 1 個,而且只在我們配置選定的節(jié)點(k8s-node1)上運行。

刪除 DaemonSet

像其他 Pod 控制器一樣,當刪除 DaemonSet 對象時,其所管理的 Pod 默認也會被刪除,操作如下所示:

[root@k8s-master ~]# kubectl delete daemonsets nginx-daemonset
daemonset.apps "nginx-daemonset" deleted
[root@k8s-master ~]# kubectl get pods
No resources found in default namespace.

其它使用場景

容忍性 Toleration 使用

DaemonSet 還會給這個 Pod 自動加上另外一個與調度相關的字段,叫作 tolerations。這個字段意味著這個 Pod,會“容忍”(Toleration)某些 Node 的“污點”(Taint)。

Toleration 使用 yaml 配置如下:

apiVersion: v1
kind: Pod
metadata:
  name: with-toleration
spec:
  tolerations:
  - key: node.kubernetes.io/unschedulable
    operator: Exists
    effect: NoSchedule

在正常情況下,被標記了 unschedulable“污點”的 Node,是不會有任何 Pod 被調度上去的(effect: NoSchedule)。

可是,DaemonSet 自動地給被管理的 Pod 加上了這個特殊的 Toleration,就使得這些 Pod 可以忽略這個限制,繼而保證每個節(jié)點上都會被調度一個 Pod。

當然,如果這個節(jié)點有故障的話,這個 Pod 可能會啟動失敗,而 DaemonSet 則會始終嘗試下去,直到 Pod 啟動成功。

主要作用:

通過這樣一個 Toleration,調度器在調度這個 Pod 的時候,就會忽略當前節(jié)點上的“污點”,從而成功地將一些組件調度到這臺機器上啟動起來。

這種機制,正是我們在部署 Kubernetes 集群的時候,能夠先部署 Kubernetes 本身、再部署網絡插件的根本原因:因為當時我們所創(chuàng)建的 Weave 的 YAML,實際上就是一個 DaemonSet。

節(jié)點親和性 nodeAffinity 使用

正常情況下 DaemonSet Controller 會在創(chuàng)建 Pod 的時候,自動在這個 Pod 的 API 對象里,加上這樣一個 nodeAffinity 定義。

在這個 Pod 里,聲明了一個 spec.affinity 字段,然后定義了一個 nodeAffinity。其中,spec.affinity 字段,是 Pod 里跟調度相關的一個字段。

nodeAffinity 使用 yaml 配置如下:

apiVersion: v1
kind: Pod
metadata:
  name: demo-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: metadata.name
            operator: In
            values:
            - demo-node

以上關鍵參數含義:

  • requiredDuringSchedulingIgnoredDuringExecution 這個代表 nodeAffinity 必須在每次調度的時候予以考慮,同時,這也意味著可以設置在某些情況下不考慮這個 nodeAffinity;
  • 這個 Pod,將來只允許運行在“metadata.name”是“demo-node”的節(jié)點上。

總結

DaemonSet 其實就是依靠 nodeAffinity 和 Toleration 實現(xiàn)的。這是一種不需要增加設計結構,而直接使用標簽等方式完成的 Daemon 進程。這樣的結構非常符合 Kubernetes 的控制器模式,正所謂一切皆對象。

以上就是k8s控制器DaemonSet理解的詳細內容,更多關于k8s控制器DaemonSet的資料請關注腳本之家其它相關文章!

相關文章

  • 在AWS-EC2中安裝Minikube集群的詳細過程

    在AWS-EC2中安裝Minikube集群的詳細過程

    這篇文章主要介紹了在AWS-EC2中安裝Minikube集群,本文通過圖文并茂的形式給大家介紹的非常詳細,對大家的學習或工作具有一定的參考借鑒價值,需要的朋友可以參考下
    2022-06-06
  • Kubernetes中創(chuàng)建命名空間實現(xiàn)方法

    Kubernetes中創(chuàng)建命名空間實現(xiàn)方法

    這篇文章主要為大家介紹了Kubernetes中創(chuàng)建命名空間實現(xiàn)方法詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪
    2022-11-11
  • Google?Kubernetes?Engine?集群實戰(zhàn)詳解

    Google?Kubernetes?Engine?集群實戰(zhàn)詳解

    這篇文章主要為大家介紹了Google?Kubernetes?Engine?集群實戰(zhàn)詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪
    2022-08-08
  • Kubernetes中使用PersistentVolume掛載云盤方式

    Kubernetes中使用PersistentVolume掛載云盤方式

    這篇文章主要介紹了Kubernetes中使用PersistentVolume掛載云盤方式,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教
    2024-02-02
  • k8s入門實戰(zhàn)deployment使用詳解

    k8s入門實戰(zhàn)deployment使用詳解

    這篇文章主要為大家介紹了k8s入門實戰(zhàn)deployment使用詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪
    2023-03-03
  • Hadoop 2.x與3.x 22點比較,Hadoop 3.x比2.x的改進

    Hadoop 2.x與3.x 22點比較,Hadoop 3.x比2.x的改進

    本文介紹了Hadoop3版本中添加的新功能,Hadoop 2和Hadoop 3的區(qū)別,在這篇文章中,我們將討論Hadoop 2.x與Hadoop 3.x之間的比較。感興趣的朋友跟隨小編一起看一下
    2018-09-09
  • 如何在kubernetes中創(chuàng)建Pod

    如何在kubernetes中創(chuàng)建Pod

    這篇文章主要介紹了如何在kubernetes中創(chuàng)建Pod,幫助大家更好的理解和學習使用kubernetes,感興趣的朋友可以了解下
    2021-04-04
  • kubernetes之statefulset搭建MySQL集群

    kubernetes之statefulset搭建MySQL集群

    這篇文章主要為大家介紹了kubernetes之statefulset搭建MySQL集群示例詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪
    2023-04-04
  • k8s常用命令大全(最新推薦)

    k8s常用命令大全(最新推薦)

    這篇文章主要介紹了k8s常用命令大全,本文給大家介紹的非常詳細,對大家的學習或工作具有一定的參考借鑒價值,需要的朋友可以參考下
    2023-03-03
  • Rainbond云原生快捷部署生產可用的Gitlab步驟詳解

    Rainbond云原生快捷部署生產可用的Gitlab步驟詳解

    這篇文章主要為大家介紹了Rainbond云原生快捷部署生產可用的Gitlab步驟詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪
    2022-04-04

最新評論