亚洲激情专区-91九色丨porny丨老师-久久久久久久女国产乱让韩-国产精品午夜小视频观看

溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

Kubernetes應用服務質量管理的方法是什么

發布時間:2022-11-25 10:04:08 來源:億速云 閱讀:114 作者:iii 欄目:開發技術

本篇內容主要講解“Kubernetes應用服務質量管理的方法是什么”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學習“Kubernetes應用服務質量管理的方法是什么”吧!

    服務質量管理

    在Kubernetes中,Pod是最小的調度單元,所以跟資源和調度相關的屬性都是Pod對象的字段,而其中最重要的就是CPU和內存。

    如下所示:

    ---
    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-demo
    spec:
      containers:
      - name: myweb
        image: wordpress
        imagePullPolicy: IfNotPresent
        resources:
          requests:
            memory: "128Mi"
            cpu: "250m"
          limits:
            memory: "256Mi"
            cpu: "500m"

    其中resources就是資源限制部分。

    注:由于一個Pod里可以定義多個Containers,而每個資源限制都是配置在各自的Container,所以Pod的整體配置資源是所有Containers的總和。

    在Kubernetes中,CPU這樣的資源被稱為"可壓縮資源",所謂可壓縮資源就是當可用資源不足的時候,Pod只會"饑餓",不會退出。而向Memory這樣的資源被稱為"不可壓縮資源",所謂的不可壓縮資源就是當資源不足的時候Pod只會OOM。

    其中CPU的設置單位是CPU的個數,比如CPU=1就表示這個Pod的CPU限額是1個CPU,而到底是1個CPU核心、是1個vCPU還是1個CPU超線程,這要取決于宿主機上CPU實現方式,而Kunernetes只需要保證該Pod能夠使用到1個CPU的使用能力。

    Kubernetes允許將CPU的限額設置位分數,比如上面我們設置的CPU.limits的值為500m,而所謂的500m就是500milliCPU,也就是0.5個CPU,這樣,這個Pod就會被分到一個CPU一半的計算能力。所以我們可以直接把配置寫成cpu=0.5,不過官方推薦500m的寫法,這是Kubernetes內部的CPU計算方式。

    在Kubernetes中,內存資源的單位是bytes,支持使用Ei,Pi,Ti,Gi,Mi,Ki的方式作為bytes的值,其中需要注意Mi和M的區別(1Mi=1024_1024,1M=1000_1000)。

    Kubernetes中Pod的CPU和內存的資源限制,實際上分為requests和limits兩種情況。

    spec.containers[].resources.limits.cpu
    spec.containers[].resources.limits.memory
    spec.containers[].resources.requests.cpu
    spec.containers[].resources.requests.memory

    這兩者的區別如下:

    • 在調度的時候,kube-scheduler會安requests的值進行計算;

    • 在設置CGroups的時候,kubelet會安limits的值來進行設置;

    QoS模型

    Kubernetes中支持三種QoS模型。其分類是基于requests和limits的不同配置。

    Guaranteed

    當Pod里的每一個Containers都設置了requests和limits,并且其值都相等的時候,這種Pod就屬于Guaranteed類別,如下:

    apiVersion: v1
    kind: Pod
    metadata:
      name: qos-demo
      namespace: qos-example
    spec:
      containers:
      - name: qos-demo-ctr
        image: nginx
        resources:
          limits:
            memory: "200Mi"
            cpu: "700m"
          requests:
            memory: "200Mi"
            cpu: "700m"

    注意,當這Pod僅設置limits,沒有設置requests的時候,系統默認為它分配于limits相等的requests值,也就會被劃分為Guaranteed類別。

    Burstable

    而當這個Pod不滿足Guaranteed條件,但至少有一個Contaienrs設置了requests,那么這個Pod就會被劃分為Burstable類別。如下:

    apiVersion: v1
    kind: Pod
    metadata:
      name: qos-demo-2
      namespace: qos-example
    spec:
      containers:
      - name: qos-demo-2-ctr
        image: nginx
        resources:
          limits
            memory: "200Mi"
          requests:
            memory: "100Mi"
    BestEffort

    如果這個Pod既沒有設置requests值,也沒有設置limits的值的時候,那么它的QoS類別就是BestEffort類別。

    apiVersion: v1
    kind: Pod
    metadata:
      name: qos-demo-3
      namespace: qos-example
    spec:
      containers:
      - name: qos-demo-3-ctr
        image: nginx

    而QoS劃分的主要場景就是當宿主機資源緊張的時候,kubelet對資源進行Eviction時需要用到。目前Kubernetes設置的默認Eviction的閾值如下:

    memory.available<100Mi
    nodefs.available<10%
    nodefs.inodesFree<5%
    imagefs.available<15%

    上述條件可以在kubelet中設置:

    kubelet --eviction-hard=imagefs.available<10%,memory.available<500Mi,nodefs.available<5%,nodefs.inodesFree<5% --eviction-soft=imagefs.available<30%,nodefs.available<10% --eviction-soft-grace-period=imagefs.available=2m,nodefs.available=2m --eviction-max-pod-grace-period=600

    Kubernetes中的Eviction分為Soft Eviction和Hard Eviction兩種模式。

    • Soft Eviction允許設置優雅等待時間,如上設置imagefs.available=2m,允許在Imagefs不足閾值達到2分鐘之后才進行Eviction;

    • Hard Eviction在達到閾值就進行Eviction;

    當宿主機的Eviction閾值達到后,就會進入MemoryPressure或者DiskPressure狀態,從而避免新的Pod調度到上面去。而當Eviction發生時,kubelet刪除Pod的先后順序如下:

    • BestEffort 類型的Pod;

    • Burstable類別并且發生"饑餓"的資源使用量已經超出了requests的Pod;

    • Guaranteed類別并且只有當Guaranteed類別的Pod的資源使用量超過了其limits限制,或者宿主機本身處于Memory Pressure狀態時,Guaranteed才會被選中被Eviction;

    cpuset

    cpuset,就是把容器綁定到某個CPU核上,減少CPU的上下文切換。

    • Pod必須是Guaranteed類型;

    • 只需要將Pod的CPU資源的requests和limits設置為同一個相等的數值;

    spec:
      containers:
      - name: nginx
        image: nginx
        resources:
          limits:
            memory: "200Mi"
            cpu: "2"
          requests:
            memory: "200Mi"
            cpu: "2"

    LimitRange

    在正常配置應用Pod的時候,都會把服務質量加上,也就是配置好requests和limits,但是,如果Pod非常多,而且很多Pod只需要相同的限制,我們還是像上面那樣一個一個的加就非常繁瑣了,這時候我們就可以通過LimitRange做一個全局限制。如果在部署Pod的時候指定了requests和Limits,則指定的生效。反之則由全局的給Pod加上默認的限制。

    總結,LimitRange可以實現的功能:

    • 限制namespace中每個pod或container的最小和最大資源用量。

    • 限制namespace中每個PVC的資源請求范圍。

    • 限制namespace中資源請求和限制數量的比例。

    • 配置資源的默認限制。

    常用的場景如下(來自《Kubernetes權威指南》)

    • 集群中的每個節點都有2GB內存,集群管理員不希望任何Pod申請超過2GB的內存:因為在整個集群中都沒有任何節點能滿足超過2GB內存的請求。如果某個Pod的內存配置超過2GB,那么該Pod將永遠都無法被調度到任何節點上執行。為了防止這種情況的發生,集群管理員希望能在系統管理功能中設置禁止Pod申請超過2GB內存。

    • 集群由同一個組織中的兩個團隊共享,分別運行生產環境和開發環境。生產環境最多可以使用8GB內存,而開發環境最多可以使用512MB內存。集群管理員希望通過為這兩個環境創建不同的命名空間,并為每個命名空間設置不同的限制來滿足這個需求。

    • 用戶創建Pod時使用的資源可能會剛好比整個機器資源的上限稍小,而恰好剩下的資源大小非常尷尬:不足以運行其他任務但整個集群加起來又非常浪費。因此,集群管理員希望設置每個Pod都必須至少使用集群平均資源值(CPU和內存)的20%,這樣集群能夠提供更好的資源一致性的調度,從而減少了資源浪費。

    (1)、首先創建一個namespace

    apiVersion: v1
    kind: Namespace
    metadata:
      name: coolops

    (2)、為namespace配置LimitRange

    apiVersion: v1
    kind: LimitRange
    metadata:
      name: mylimit
      namespace: coolops
    spec:
      limits:
      - max:
          cpu: "1"
          memory: 1Gi
        min:
          cpu: 100m
          memory: 10Mi
        maxLimitRequestRatio:
          cpu: 3
          memory: 4
        type: Pod
      - default:
          cpu: 300m
          memory: 200Mi
        defaultRequest:
          cpu: 200m
          memory: 100Mi
        max:
          cpu: "2"
          memory: 1Gi
        min:
          cpu: 100m
          memory: 10Mi
        maxLimitRequestRatio:
          cpu: 5
          memory: 4
        type: Container

    參數說明:

    • max:如果type是Pod,則表示pod中所有容器資源的Limit值和的上限,也就是整個pod資源的最大Limit,如果pod定義中的Limit值大于LimitRange中的值,則pod無法成功創建。如果type是Container,意義類似。

    • min:如果type是Pod,則表示pod中所有容器資源請求總和的下限,也就是所有容器request的資源總和不能小于min中的值,否則pod無法成功創建。如果type是Container,意義類似。

    • maxLimitRequestRatio:如果type是Pod,表示pod中所有容器資源請求的Limit值和request值比值的上限,例如該pod中cpu的Limit值為3,而request為0.5,此時比值為6,創建pod將會失敗。

    • defaultrequest和defaultlimit則是默認值,只有type為Container才有這兩項配置

    注意:

    (1)、如果container設置了maxpod中的容器必須設置limit,如果未設置,則使用defaultlimt的值,如果defaultlimit也沒有設置,則無法成功創建

    (2)、如果設置了containermin,創建容器的時候必須設置request的值,如果沒有設置,則使用defaultrequest,如果沒有defaultrequest,則默認等于容器的limit值,如果limit也沒有,啟動就會報錯

    創建上面配置的LimitRange:

    $ kubectl apply -f limitrange.yaml 
    limitrange/mylimit created
    $ kubectl get limitrange -n coolops
    NAME      CREATED AT
    mylimit   2022-08-02T06:08:43Z
    $ kubectl describe limitranges -n coolops mylimit
    Name:       mylimit
    Namespace:  coolops
    Type        Resource  Min   Max  Default Request  Default Limit  Max Limit/Request Ratio
    ----        --------  ---   ---  ---------------  -------------  -----------------------
    Pod         cpu       100m  1    -                -              3
    Pod         memory    10Mi  1Gi  -                -              4
    Container   cpu       100m  2    200m             300m           5
    Container   memory    10Mi  1Gi  100Mi            200Mi          4

    (3)、創建一個允許范圍之內的requests和limits的pod

    apiVersion: v1
    kind: Pod
    metadata:
      name: pod01
      namespace: coolops
    spec:
      containers:
      - name: pod-01
        image: nginx
        imagePullPolicy: IfNotPresent
        resources:
          requests:
            cpu: 200m
            memory: 30Mi
          limits:
            cpu: 300m
            memory: 50Mi

    我們通過kubectl apply -f pod-01.yaml可以正常創建Pod。

    (4)、創建一個cpu超出允許訪問的Pod

    apiVersion: v1
    kind: Pod
    metadata:
      name: pod02
      namespace: coolops
    spec:
      containers:
      - name: pod-02
        image: nginx
        imagePullPolicy: IfNotPresent
        resources:
          requests:
            cpu: 200m
            memory: 30Mi
          limits:
            cpu: 2
            memory: 50Mi

    然后我們創建會報如下錯誤:

    # kubectl apply -f pod-02.yaml 
    Error from server (Forbidden): error when creating "pod-02.yaml": pods "pod02" is forbidden: [maximum cpu usage per Pod is 1, but limit is 2, cpu max limit to request ratio per Pod is 3, but provided ratio is 10.000000, cpu max limit to request ratio per Container is 5, but provided ratio is 10.000000]

    (5)創建低于允許范圍的Pod

    apiVersion: v1
    kind: Pod
    metadata:
      name: pod03
      namespace: coolops
    spec:
      containers:
      - name: pod-03
        image: nginx
        imagePullPolicy: IfNotPresent
        resources:
          requests:
            cpu: 200m
            memory: 30Mi
          limits:
            cpu: 100m
            memory: 10Mi

    然后會報如下錯誤:

    # kubectl apply -f pod-03.yaml 
    The Pod "pod03" is invalid: 
    * spec.containers[0].resources.requests: Invalid value: "200m": must be less than or equal to cpu limit
    * spec.containers[0].resources.requests: Invalid value: "30Mi": must be less than or equal to memory limit

    (6)、創建一個未定義request或Limits的Pod

    apiVersion: v1
    kind: Pod
    metadata:
      name: pod04
      namespace: coolops
    spec:
      containers:
      - name: pod-04
        image: nginx
        imagePullPolicy: IfNotPresent
        resources:
          requests:
            cpu: 200m
            memory: 200Mi

    然后我們創建完Pod后會發現自動給我們加上了limits。如下:

    # kubectl describe pod -n coolops pod04
    ...
        Limits:
          cpu:     300m
          memory:  200Mi
        Requests:
          cpu:        200m
          memory:     200Mi
    ...

    上面我指定了requests,LimitRange自動給我們加上了defaultLimits,你也可以試一下全都不加或者加一個,道理是一樣的。值得注意的是這里要注意一下我們設置的maxLimitRequestRatio,配置的比列必須小于等于我們設置的值。

    上文有介紹LimitRange還可以限制還可以限制PVC,如下:

    apiVersion: v1
    kind: LimitRange
    metadata:
      name: storagelimits
      namespace: coolops
    spec:
      limits:
      - type: PersistentVolumeClaim
        max:
          storage: 2Gi
        min:
          storage: 1Gi

    創建完后即可查看:

     kubectl describe limitranges -n coolops storagelimits 
    Name:                  storagelimits
    Namespace:             coolops
    Type                   Resource  Min  Max  Default Request  Default Limit  Max Limit/Request Ratio
    ----                   --------  ---  ---  ---------------  -------------  -----------------------
    PersistentVolumeClaim  storage   1Gi  2Gi  -                -              -

    你可以創建PVC進行測試,道理是一樣的。

    服務可用性管理

    高可用

    生產級別應用,為了保證應用的可用性,除了特殊應用(例如批次應用)都會保持高可用,所以在設計應用Pod的時候,就要考慮應用的高可用。

    最簡單的就是多副本,也就是在創建應用的時候,至少需要2個副本,如下指定replicas為3就表示該應用有3個副本:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        app: nginx
      name: nginx-deployment
    spec:
      progressDeadlineSeconds: 600
      replicas: 3
      revisionHistoryLimit: 10
      selector:
        matchLabels:
          app: nginx
      strategy:
        rollingUpdate:
          maxSurge: 25%
          maxUnavailable: 25%
        type: RollingUpdate
      template:
        metadata:
          creationTimestamp: null
          labels:
            app: nginx
        spec:
          containers:
          - image: nginx:1.8
            imagePullPolicy: IfNotPresent
            name: nginx
            resources:
              requests:
                cpu: 0.5
                memory: 500M
              limits:
                cpu: 0.5
                memory: 500M
            ports:
            - containerPort: 80
              name: http
              protocol: TCP

    但是光配置多副本就夠了么?

    如果這三個副本都調度到一臺服務器上,該服務器因某些原因宕機了,那上面的應用是不是就不可用?

    為了解決這個問題,我們需要為同一個應用配置反親和性,也就是不讓同一應用的Pod調度到同一主機上,將上面的應用YAML改造成如下:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        app: nginx
      name: nginx-deployment
    spec:
      progressDeadlineSeconds: 600
      replicas: 3
      revisionHistoryLimit: 10
      selector:
        matchLabels:
          app: nginx
      strategy:
        rollingUpdate:
          maxSurge: 25%
          maxUnavailable: 25%
        type: RollingUpdate
      template:
        metadata:
          creationTimestamp: null
          labels:
            app: nginx
        spec:
          affinity:
            podAntiAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchExpressions:
                  - key: app
                    operator: In
                    values:
                    - nginx
                topologyKey: kubernetes.io/hostname
          containers:
          - image: nginx:1.8
            imagePullPolicy: IfNotPresent
            name: nginx
            resources:
              requests:
                cpu: 0.5
                memory: 500M
              limits:
                cpu: 0.5
                memory: 500M
            ports:
            - containerPort: 80
              name: http
              protocol: TCP

    這樣能保證同應用不會被調度到同節點,基本的高可用已經做到了。

    可用性

    但是光保證應用的高可用,應用本身不可用,也會導致異常。

    我們知道Kubernetes的Deployment的默認更新策略是滾動更新,如何保證新應用更新后是可用的,這就要使用readinessProbe,用來確保應用可用才會停止老的版本,上面的YAML修改成如下:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        app: nginx
      name: nginx-deployment
    spec:
      progressDeadlineSeconds: 600
      replicas: 3
      revisionHistoryLimit: 10
      selector:
        matchLabels:
          app: nginx
      strategy:
        rollingUpdate:
          maxSurge: 25%
          maxUnavailable: 25%
        type: RollingUpdate
      template:
        metadata:
          creationTimestamp: null
          labels:
            app: nginx
        spec:
          affinity:
            podAntiAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchExpressions:
                  - key: app
                    operator: In
                    values:
                    - nginx
                topologyKey: kubernetes.io/hostname
          containers:
          - image: nginx:1.8
            imagePullPolicy: IfNotPresent
            name: nginx
            resources:
              requests:
                cpu: 0.5
                memory: 500M
              limits:
                cpu: 0.5
                memory: 500M
            readinessProbe:
              failureThreshold: 3
              httpGet:
                path: /
                port: http
                scheme: HTTP
              initialDelaySeconds: 10
              periodSeconds: 10
              successThreshold: 1
              timeoutSeconds: 3
            ports:
            - containerPort: 80
              name: http
              protocol: TCP

    這樣至少能保證只有新版本可訪問才接收外部流量。

    但是應用運行過程中異常了呢?這就需要使用livenessProbe來保證應用持續可用,上面的YAML修改成如下:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        app: nginx
      name: nginx-deployment
    spec:
      progressDeadlineSeconds: 600
      replicas: 3
      revisionHistoryLimit: 10
      selector:
        matchLabels:
          app: nginx
      strategy:
        rollingUpdate:
          maxSurge: 25%
          maxUnavailable: 25%
        type: RollingUpdate
      template:
        metadata:
          creationTimestamp: null
          labels:
            app: nginx
        spec:
          affinity:
            podAntiAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchExpressions:
                  - key: app
                    operator: In
                    values:
                    - nginx
                topologyKey: kubernetes.io/hostname
          containers:
          - image: nginx:1.8
            imagePullPolicy: IfNotPresent
            name: nginx
            resources:
              requests:
                cpu: 0.5
                memory: 500M
              limits:
                cpu: 0.5
                memory: 500M
            readinessProbe:
              failureThreshold: 3
              httpGet:
                path: /
                port: http
                scheme: HTTP
              initialDelaySeconds: 10
              periodSeconds: 10
              successThreshold: 1
              timeoutSeconds: 3
            livenessProbe:
              failureThreshold: 3
              httpGet:
                path: /
                port: http
                scheme: HTTP
              initialDelaySeconds: 20
              periodSeconds: 10
              successThreshold: 1
              timeoutSeconds: 3
            ports:
            - containerPort: 80
              name: http
              protocol: TCP

    上面的readinessProbe和livenessProbe都是應用在運行過程中如何保證其可用,那應用在退出的時候如何保證其安全退出?

    所謂安全退出,也就是能正常處理退出邏輯,能夠正常處理退出信號,也就是所謂的優雅退出。

    優雅退出有兩種常見的解決方法:

    • 應用本身可以處理SIGTERM信號。

    • 設置一個preStop hook,在hook中指定怎么優雅停止容器

    這里拋開應用本身可以處理SIGTERM信號不談,默認其能夠處理,我們要做的就是協助其能優雅退出。在Kubernetes中,使用preStop hook來協助處理,我們可以將上面的YAML修改成如下:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        app: nginx
      name: nginx-deployment
    spec:
      progressDeadlineSeconds: 600
      replicas: 3
      revisionHistoryLimit: 10
      selector:
        matchLabels:
          app: nginx
      strategy:
        rollingUpdate:
          maxSurge: 25%
          maxUnavailable: 25%
        type: RollingUpdate
      template:
        metadata:
          creationTimestamp: null
          labels:
            app: nginx
        spec:
          affinity:
            podAntiAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchExpressions:
                  - key: app
                    operator: In
                    values:
                    - nginx
                topologyKey: kubernetes.io/hostname
          containers:
          - image: nginx:1.8
            imagePullPolicy: IfNotPresent
            name: nginx
            lifecycle:
              preStop:
                exec:
                  command:
                  - /bin/sh
                  - -c
                  - sleep 15
            resources:
              requests:
                cpu: 0.5
                memory: 500M
              limits:
                cpu: 0.5
                memory: 500M
            readinessProbe:
              failureThreshold: 3
              httpGet:
                path: /
                port: http
                scheme: HTTP
              initialDelaySeconds: 10
              periodSeconds: 10
              successThreshold: 1
              timeoutSeconds: 3
            livenessProbe:
              failureThreshold: 3
              httpGet:
                path: /
                port: http
                scheme: HTTP
              initialDelaySeconds: 20
              periodSeconds: 10
              successThreshold: 1
              timeoutSeconds: 3
            ports:
            - containerPort: 80
              name: http
              protocol: TCP

    當然,這里只是一個樣例,實際的配置還需要根據企業情況做跳轉,比如企業使用了注冊中心如zk或者nacos,我們就需要把服務從注冊中心下掉。

    PDB

    上面的那些配置基本可以讓應用順利的在Kubernetes里跑了,但是不可避免有維護節點的需求,比如升級內核,重啟服務器等。

    而且也不是所有的應用都可以多副本,當我們使用kubectl drain的時候,為了避免某個或者某些應用直接銷毀而不可用,Kubernetes引入了PodDisruptionBudget(PDB)控制器,用來控制集群中Pod的運行個數。

    在PDB中,主要通過兩個參數來控制Pod的數量:

    • minAvailable:表示最小可用Pod數,表示在Pod集群中處于運行狀態的最小Pod數或者是運行狀態的Pod數和總數的百分比;

    • maxUnavailable:表示最大不可用Pod數,表示Pod集群中處于不可用狀態的最大Pod數或者不可用狀態Pod數和總數的百分比;

    注意:minAvailable和maxUnavailable是互斥了,也就是說兩者同一時刻只能出現一種。

    kubectl drain命令已經支持了PodDisruptionBudget控制器,在進行kubectl drain操作時會根據PodDisruptionBudget控制器判斷應用POD集群數量,進而保證在業務不中斷或業務SLA不降級的情況下進行應用POD銷毀。在進行kubectl drain或者Pod主動逃離的時候,Kubernetes會通過以下幾種情況來進行判斷:

    • minAvailable設置成了數值5:應用POD集群中最少要有5個健康可用的POD,那么就可以進行操作。

    • minAvailable設置成了百分數30%:應用POD集群中最少要有30%的健康可用POD,那么就可以進行操作。

    • maxUnavailable設置成了數值5:應用POD集群中最多只能有5個不可用POD,才能進行操作。

    • maxUnavailable設置成了百分數30%:應用POD集群中最多只能有30%個不可用POD,才能進行操作。

    在極端的情況下,比如將maxUnavailable設置成0,或者設置成100%,那么就表示不能進行kubectl drain操作。同理將minAvailable設置成100%,或者設置成應用POD集群最大副本數,也表示不能進行kubectl drain操作。

    注意:使用PodDisruptionBudget控制器并不能保證任何情況下都對業務POD集群進行約束,PodDisruptionBudget控制器只能保證POD主動逃離的情況下業務不中斷或者業務SLA不降級,例如在執行kubectldrain命令時。

    (1)、定義minAvailable

    apiVersion: policy/v1
    kind: PodDisruptionBudget
    metadata:
      name: pdb-demo
    spec:
      minAvailable: 2
      selector:
        matchLabels:
          app: nginx

    (2)、定義maxUnavailable

    apiVersion: policy/v1
    kind: PodDisruptionBudget
    metadata:
      name: pdb-demo
    spec:
      maxUnavailable: 1
      selector:
        matchLabels:
          app: nginx

    可以看到PDB是通過label selectors和應用Pod建立關聯,而后在主動驅逐Pod的時候,會保證app: nginx的Pod最大不可用數為1,假如本身是3副本,至少會保證2副本正常運行。

    到此,相信大家對“Kubernetes應用服務質量管理的方法是什么”有了更深的了解,不妨來實際操作一番吧!這里是億速云網站,更多相關內容可以進入相關頻道進行查詢,關注我們,繼續學習!

    向AI問一下細節

    免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。

    AI

    永靖县| 云林县| 渭源县| 宜兴市| 辉南县| 奇台县| 特克斯县| 松桃| 从化市| 象州县| 乐平市| 文成县| 永善县| 井陉县| 娄烦县| 翁牛特旗| 什邡市| 长阳| 天峨县| 庄浪县| 新野县| 唐河县| 读书| 青龙| 都兰县| 民权县| 繁昌县| 观塘区| 将乐县| 应用必备| 伊春市| 齐齐哈尔市| 临颍县| 潼南县| 杨浦区| 当阳市| 平谷区| 松滋市| 敦煌市| 灵山县| 辽宁省|