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

k8s編排之DaemonSet知識(shí)點(diǎn)詳解

 更新時(shí)間:2023年01月17日 10:21:29   作者:半芽灣  
這篇文章主要為大家介紹了k8s編排之DaemonSet知識(shí)點(diǎn)詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪

如何對(duì) StatefulSet 進(jìn)行“滾動(dòng)更新”(rolling update)?

你只要修改 StatefulSet 的 Pod 模板,就會(huì)自動(dòng)觸發(fā)“滾動(dòng)更新”:

kubectl patch statefulset mysql --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"mysql:5.7.23"}]'

在這里,我使用了 kubectl patch 命令。它的意思是,以“補(bǔ)丁”的方式(JSON 格式的)修改一個(gè) API 對(duì)象的指定字段,也就是我在后面指定的“spec/template/spec/containers/0/image”。

這樣,StatefulSet Controller 就會(huì)按照與 Pod 編號(hào)相反的順序,從最后一個(gè) Pod 開始,逐一更新這個(gè) StatefulSet 管理的每個(gè) Pod。而如果更新發(fā)生了錯(cuò)誤,這次“滾動(dòng)更新”就會(huì)停止。此外,StatefulSet 的“滾動(dòng)更新”還允許我們進(jìn)行更精細(xì)的控制,比如金絲雀發(fā)布(Canary Deploy)或者灰度發(fā)布,這意味著應(yīng)用的多個(gè)實(shí)例中被指定的一部分不會(huì)被更新到最新的版本。

這個(gè)字段,正是 StatefulSet 的 spec.updateStrategy.rollingUpdate 的 partition 字段。

比如,現(xiàn)在我將前面這個(gè) StatefulSet 的 partition 字段設(shè)置為 2:

kubectl patch statefulset mysql -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":2}}}}'

其中,kubectl patch 命令后面的參數(shù)(JSON 格式的),就是 partition 字段在 API 對(duì)象里的路徑。所以,上述操作等同于直接使用 kubectl edit 命令,打開這個(gè)對(duì)象,把 partition 字段修改為 2。

這樣,我就指定了當(dāng) Pod 模板發(fā)生變化的時(shí)候,比如 MySQL 鏡像更新到 5.7.23,那么只有序號(hào)大于或者等于 2 的 Pod 會(huì)被更新到這個(gè)版本。并且,如果你刪除或者重啟了序號(hào)小于 2 的 Pod,等它再次啟動(dòng)后,也會(huì)保持原先的 5.7.2 版本,絕不會(huì)被升級(jí)到 5.7.23 版本。

下面重點(diǎn)講解一個(gè)\知識(shí)點(diǎn):DaemonSet

顧名思義,DaemonSet 的主要作用,是讓你在 Kubernetes 集群里,運(yùn)行一個(gè) Daemon Pod。 所以,這個(gè) Pod 有如下三個(gè)特征:

  • 這個(gè) Pod 運(yùn)行在 Kubernetes 集群里的每一個(gè)節(jié)點(diǎn)(Node)上;
  • 每個(gè)節(jié)點(diǎn)上只有一個(gè)這樣的 Pod 實(shí)例;
  • 當(dāng)有新的節(jié)點(diǎn)加入 Kubernetes 集群后,該 Pod 會(huì)自動(dòng)地在新節(jié)點(diǎn)上被創(chuàng)建出來;而當(dāng)舊節(jié)點(diǎn)被刪除后,它上面的 Pod 也相應(yīng)地會(huì)被回收掉。

這個(gè)機(jī)制聽起來很簡單,但 Daemon Pod 的意義確實(shí)是非常重要的

列舉幾個(gè)例子:

  • 各種網(wǎng)絡(luò)插件的 Agent 組件,都必須運(yùn)行在每一個(gè)節(jié)點(diǎn)上,用來處理這個(gè)節(jié)點(diǎn)上的容器網(wǎng)絡(luò);
  • 各種存儲(chǔ)插件的 Agent 組件,也必須運(yùn)行在每一個(gè)節(jié)點(diǎn)上,用來在這個(gè)節(jié)點(diǎn)上掛載遠(yuǎn)程存儲(chǔ)目錄,操作容器的 Volume 目錄;
  • 各種監(jiān)控組件和日志組件,也必須運(yùn)行在每一個(gè)節(jié)點(diǎn)上,負(fù)責(zé)這個(gè)節(jié)點(diǎn)上的監(jiān)控信息和日志搜集。

更重要的是,跟其他編排對(duì)象不一樣,DaemonSet 開始運(yùn)行的時(shí)機(jī),很多時(shí)候比整個(gè) Kubernetes 集群出現(xiàn)的時(shí)機(jī)都要早。

這個(gè)乍一聽起來可能有點(diǎn)兒奇怪。但其實(shí)你來想一下:如果這個(gè) DaemonSet 正是一個(gè)網(wǎng)絡(luò)插件的 Agent 組件呢?

這個(gè)時(shí)候,整個(gè) Kubernetes 集群里還沒有可用的容器網(wǎng)絡(luò),所有 Worker 節(jié)點(diǎn)的狀態(tài)都是 NotReady(NetworkReady=false)。這種情況下,普通的 Pod 肯定不能運(yùn)行在這個(gè)集群上。所以,這也就意味著 DaemonSet 的設(shè)計(jì),必須要有某種“過人之處”才行。

API 對(duì)象的定義

為了弄清楚 DaemonSet 的工作原理,我們還是按照老規(guī)矩,先從它的 API 對(duì)象的定義說起。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      tolerations:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      containers:
      - name: fluentd-elasticsearch
        image: k8s.gcr.io/fluentd-elasticsearch:1.20
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers

這個(gè) DaemonSet,管理的是一個(gè) fluentd-elasticsearch 鏡像的 Pod。這個(gè)鏡像的功能非常實(shí)用:通過 fluentd 將 Docker 容器里的日志轉(zhuǎn)發(fā)到 ElasticSearch 中。

可以看到,DaemonSet 跟 Deployment 其實(shí)非常相似,只不過是沒有 replicas 字段;它也使用 selector 選擇管理所有攜帶了 name=fluentd-elasticsearch 標(biāo)簽的 Pod。

而這些 Pod 的模板,也是用 template 字段定義的。在這個(gè)字段中,我們定義了一個(gè)使用 fluentd-elasticsearch:1.20 鏡像的容器,而且這個(gè)容器掛載了兩個(gè) hostPath 類型的 Volume,分別對(duì)應(yīng)宿主機(jī)的 /var/log 目錄和 /var/lib/docker/containers 目錄。

顯然,fluentd 啟動(dòng)之后,它會(huì)從這兩個(gè)目錄里搜集日志信息,并轉(zhuǎn)發(fā)給 ElasticSearch 保存。這樣,我們通過 ElasticSearch 就可以很方便地檢索這些日志了。

需要注意的是,Docker 容器里應(yīng)用的日志,默認(rèn)會(huì)保存在宿主機(jī)的 /var/lib/docker/containers/{{. 容器 ID}}/{{. 容器 ID}}-json.log 文件里,所以這個(gè)目錄正是 fluentd 的搜集目標(biāo)。

那么,DaemonSet 又是如何保證每個(gè) Node 上有且只有一個(gè)被管理的 Pod 呢?

顯然,這是一個(gè)典型的“控制器模型”能夠處理的問題。

DaemonSet Controller,首先從 Etcd 里獲取所有的 Node 列表,然后遍歷所有的 Node。這時(shí),它就可以很容易地去檢查,當(dāng)前這個(gè) Node 上是不是有一個(gè)攜帶了 name=fluentd-elasticsearch 標(biāo)簽的 Pod 在運(yùn)行。

而檢查的結(jié)果,可能有這么三種情況:

沒有這種 Pod,那么就意味著要在這個(gè) Node 上創(chuàng)建這樣一個(gè) Pod;

有這種 Pod,但是數(shù)量大于 1,那就說明要把多余的 Pod 從這個(gè) Node 上刪除掉;

正好只有一個(gè)這種 Pod,那說明這個(gè)節(jié)點(diǎn)是正常的。

其中,刪除節(jié)點(diǎn)(Node)上多余的 Pod 非常簡單,直接調(diào)用 Kubernetes API 就可以了。

如何在指定的 Node 上創(chuàng)建新 Pod 呢?

如果你已經(jīng)熟悉了 Pod API 對(duì)象的話,那一定可以立刻說出答案:用 nodeSelector,選擇 Node 的名字即可。

不過,在 Kubernetes 項(xiàng)目里,nodeSelector 其實(shí)已經(jīng)是一個(gè)將要被廢棄的字段了。因?yàn)?,現(xiàn)在有了一個(gè)新的、功能更完善的字段可以代替它,即:nodeAffinity。我來舉個(gè)例子:

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

在這個(gè) Pod 里,我聲明了一個(gè) spec.affinity 字段,然后定義了一個(gè) nodeAffinity。其中,spec.affinity 字段,是 Pod 里跟調(diào)度相關(guān)的一個(gè)字段。關(guān)于它的完整內(nèi)容,我會(huì)在講解調(diào)度策略的時(shí)候再詳細(xì)闡述。

nodeAffinity 含義

而在這里,我定義的 nodeAffinity 的含義是:

requiredDuringSchedulingIgnoredDuringExecution:它的意思是說,這個(gè) nodeAffinity 必須在每次調(diào)度的時(shí)候予以考慮。同時(shí),這也意味著你可以設(shè)置在某些情況下不考慮這個(gè) nodeAffinity;

這個(gè) Pod,將來只允許運(yùn)行在“metadata.name”是“node-geektime”的節(jié)點(diǎn)上。

在這里,你應(yīng)該注意到 nodeAffinity 的定義,可以支持更加豐富的語法,比如 operator: In(即:部分匹配;如果你定義 operator: Equal,就是完全匹配),這也正是 nodeAffinity 會(huì)取代 nodeSelector 的原因之一。

所以,我們的 DaemonSet Controller 會(huì)在創(chuàng)建 Pod 的時(shí)候,自動(dòng)在這個(gè) Pod 的 API 對(duì)象里,加上這樣一個(gè) nodeAffinity 定義。其中,需要綁定的節(jié)點(diǎn)名字,正是當(dāng)前正在遍歷的這個(gè) Node。

當(dāng)然,DaemonSet 并不需要修改用戶提交的 YAML 文件里的 Pod 模板,而是在向 Kubernetes 發(fā)起請(qǐng)求之前,直接修改根據(jù)模板生成的 Pod 對(duì)象。這個(gè)思路,也正是我在前面講解 Pod 對(duì)象時(shí)介紹過的。

此外,DaemonSet 還會(huì)給這個(gè) Pod 自動(dòng)加上另外一個(gè)與調(diào)度相關(guān)的字段,叫作 tolerations。這個(gè)字段意味著這個(gè) Pod,會(huì)“容忍”(Toleration)某些 Node 的“污點(diǎn)”(Taint)。

而 DaemonSet 自動(dòng)加上的 tolerations 字段,格式如下所示:

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

這個(gè) Toleration 的含義是:“容忍”所有被標(biāo)記為 unschedulable“污點(diǎn)”的 Node;“容忍”的效果是允許調(diào)度。

而在正常情況下,被標(biāo)記了 unschedulable“污點(diǎn)”的 Node,是不會(huì)有任何 Pod 被調(diào)度上去的(effect: NoSchedule)??墒?,DaemonSet 自動(dòng)地給被管理的 Pod 加上了這個(gè)特殊的 Toleration,就使得這些 Pod 可以忽略這個(gè)限制,繼而保證每個(gè)節(jié)點(diǎn)上都會(huì)被調(diào)度一個(gè) Pod。當(dāng)然,如果這個(gè)節(jié)點(diǎn)有故障的話,這個(gè) Pod 可能會(huì)啟動(dòng)失敗,而 DaemonSet 則會(huì)始終嘗試下去,直到 Pod 啟動(dòng)成功。

這時(shí),你應(yīng)該可以猜到,我在前面介紹到的DaemonSet 的“過人之處”,其實(shí)就是依靠 Toleration 實(shí)現(xiàn)的。

假如當(dāng)前 DaemonSet 管理的,是一個(gè)網(wǎng)絡(luò)插件的 Agent Pod,那么你就必須在這個(gè) DaemonSet 的 YAML 文件里,給它的 Pod 模板加上一個(gè)能夠“容忍”node.kubernetes.io/network-unavailable“污點(diǎn)”的 Toleration。正如下面這個(gè)例子所示:

...
template:
    metadata:
      labels:
        name: network-plugin-agent
    spec:
      tolerations:
      - key: node.kubernetes.io/network-unavailable
        operator: Exists
        effect: NoSchedule

在 Kubernetes 項(xiàng)目中,當(dāng)一個(gè)節(jié)點(diǎn)的網(wǎng)絡(luò)插件尚未安裝時(shí),這個(gè)節(jié)點(diǎn)就會(huì)被自動(dòng)加上名為node.kubernetes.io/network-unavailable的“污點(diǎn)”。

而通過這樣一個(gè) Toleration,調(diào)度器在調(diào)度這個(gè) Pod 的時(shí)候,就會(huì)忽略當(dāng)前節(jié)點(diǎn)上的“污點(diǎn)”,從而成功地將網(wǎng)絡(luò)插件的 Agent 組件調(diào)度到這臺(tái)機(jī)器上啟動(dòng)起來。

這種機(jī)制,正是我們?cè)诓渴?Kubernetes 集群的時(shí)候,能夠先部署 Kubernetes 本身、再部署網(wǎng)絡(luò)插件的根本原因:因?yàn)楫?dāng)時(shí)我們所創(chuàng)建的 Weave 的 YAML,實(shí)際上就是一個(gè) DaemonSet。

至此,通過上面這些內(nèi)容,你應(yīng)該能夠明白,DaemonSet 其實(shí)是一個(gè)非常簡單的控制器。在它的控制循環(huán)中,只需要遍歷所有節(jié)點(diǎn),然后根據(jù)節(jié)點(diǎn)上是否有被管理 Pod 的情況,來決定是否要?jiǎng)?chuàng)建或者刪除一個(gè) Pod。

只不過,在創(chuàng)建每個(gè) Pod 的時(shí)候,DaemonSet 會(huì)自動(dòng)給這個(gè) Pod 加上一個(gè) nodeAffinity,從而保證這個(gè) Pod 只會(huì)在指定節(jié)點(diǎn)上啟動(dòng)。同時(shí),它還會(huì)自動(dòng)給這個(gè) Pod 加上一個(gè) Toleration,從而忽略節(jié)點(diǎn)的 unschedulable“污點(diǎn)”。

當(dāng)然,你也可以在 Pod 模板里加上更多種類的 Toleration,從而利用 DaemonSet 實(shí)現(xiàn)自己的目的。比如,在這個(gè) fluentd-elasticsearch DaemonSet 里,我就給它加上了這樣的 Toleration:

tolerations:
- key: node-role.kubernetes.io/master
  effect: NoSchedule

這是因?yàn)樵谀J(rèn)情況下,Kubernetes 集群不允許用戶在 Master 節(jié)點(diǎn)部署 Pod。因?yàn)?,Master 節(jié)點(diǎn)默認(rèn)攜帶了一個(gè)叫作node-role.kubernetes.io/master的“污點(diǎn)”。所以,為了能在 Master 節(jié)點(diǎn)上部署 DaemonSet 的 Pod,我就必須讓這個(gè) Pod“容忍”這個(gè)“污點(diǎn)”。

以上就是k8s編排之DaemonSet知識(shí)點(diǎn)詳解的詳細(xì)內(nèi)容,更多關(guān)于k8s編排DaemonSet的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!

相關(guān)文章

  • Kubernetes集群模擬刪除k8s重裝詳解

    Kubernetes集群模擬刪除k8s重裝詳解

    這篇文章主要為大家介紹了Kubernetes集群模擬刪除k8s重裝詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪
    2022-11-11
  • 使用sealos快速搭建K8s集群環(huán)境的過程

    使用sealos快速搭建K8s集群環(huán)境的過程

    這篇文章主要介紹了使用sealos快速搭建K8s集群環(huán)境,主要包括sealos安裝方法,虛擬機(jī)設(shè)置方法,本文給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下
    2022-09-09
  • k8s dashboard安裝過程記錄

    k8s dashboard安裝過程記錄

    這篇文章主要介紹了k8s dashboard安裝過程記錄,本案例k8s版本為v1.22.17,所以安裝v2.7.0版本的dashboard,需要的朋友可以參考下
    2024-05-05
  • Rainbond功能架構(gòu)及應(yīng)用管理官方文檔介紹

    Rainbond功能架構(gòu)及應(yīng)用管理官方文檔介紹

    這篇文章主要為大家介紹了Rainbond功能機(jī)構(gòu)及使用官方文檔,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪
    2022-04-04
  • 一文詳解基于k8s部署Session模式Flink集群

    一文詳解基于k8s部署Session模式Flink集群

    這篇文章主要為大家介紹了基于k8s部署Session模式Flink集群詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪
    2023-03-03
  • 云原生技術(shù)kubernetes調(diào)度單位pod的使用詳解

    云原生技術(shù)kubernetes調(diào)度單位pod的使用詳解

    這篇文章主要介紹了云原生技術(shù)kubernetes調(diào)度單位pod的使用詳解,幫助大家更好的理解和學(xué)習(xí)使用K8S,感興趣的朋友可以了解下
    2021-03-03
  • k8s之ingress-nginx詳解和部署方案

    k8s之ingress-nginx詳解和部署方案

    Ingress是一種向k8s集群外部的客戶端公開服務(wù)的方法,下面這篇文章主要給大家介紹了關(guān)于k8s之ingress-nginx詳解和部署方案的相關(guān)資料,文中通過實(shí)例代碼介紹的非常詳細(xì),需要的朋友可以參考下
    2022-07-07
  • Rainbond上部署API?Gateway?Kong及環(huán)境配置教程

    Rainbond上部署API?Gateway?Kong及環(huán)境配置教程

    這篇文章主要為大家介紹了Rainbond上部署API?Gateway?Kong及環(huán)境配置教程,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪
    2022-04-04
  • k8s應(yīng)用監(jiān)控探針詳解

    k8s應(yīng)用監(jiān)控探針詳解

    這篇文章主要為大家介紹了k8s應(yīng)用監(jiān)控探針的使用詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪
    2023-02-02
  • K8S如何利用Prometheus監(jiān)控pod的實(shí)時(shí)數(shù)據(jù)指標(biāo)

    K8S如何利用Prometheus監(jiān)控pod的實(shí)時(shí)數(shù)據(jù)指標(biāo)

    這篇文章主要給大家介紹了關(guān)于K8S如何利用Prometheus監(jiān)控pod的實(shí)時(shí)數(shù)據(jù)指標(biāo)的相關(guān)資料,Prometheus是一個(gè)開源的服務(wù)監(jiān)控系統(tǒng)和時(shí)序數(shù)據(jù)庫,其提供了通用的數(shù)據(jù)模型和快捷數(shù)據(jù)采集、存儲(chǔ)和查詢接口,需要的朋友可以參考下
    2024-01-01

最新評(píng)論