Pod的擴(kuò)縮容

實(shí)際生產(chǎn)系統(tǒng), 會(huì)遇到某個(gè)服務(wù)需要擴(kuò)容的場(chǎng)景锭汛，也可能會(huì)遇到由于資源緊張或者工作負(fù)載降低而需要減少服務(wù)實(shí)例數(shù)量的場(chǎng)景夏醉。

此時(shí)可以利用Deployment/RC的Scale機(jī)制來(lái)完成這些工作微驶。

Kubernetes對(duì)Pod的擴(kuò)縮容操作提供了手動(dòng)和自動(dòng)兩種模式.

手動(dòng)模式通過(guò)執(zhí)行kubectl scale命令或通過(guò)RESTful API對(duì)一個(gè)Deployment/RC進(jìn)行Pod副本數(shù)量的設(shè)置，即可一鍵完成判耕。

自動(dòng)模式則需要用戶根據(jù)某個(gè)性能指標(biāo)或者自定義業(yè)務(wù)指標(biāo)跛梗，并指定Pod副本數(shù)量的范圍寻馏，系統(tǒng)將自動(dòng)在這個(gè)范圍內(nèi)根據(jù)性能指標(biāo)的變化進(jìn)行調(diào)整。

手動(dòng)擴(kuò)縮容機(jī)制

以Deployment nginx為例：

# nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

[root@k8s-master01 pod]# kubectl get pods
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-56bbb744cc-lb28h   1/1     Running   1          24h
nginx-deployment-56bbb744cc-nwhgk   1/1     Running   1          24h
nginx-deployment-56bbb744cc-z2k5h   1/1     Running   1          24h

# 通過(guò)kubectl scale命令可以將Pod副本數(shù)量從初始的3個(gè)更新為5個(gè)：
[root@k8s-master01 pod]# kubectl scale deployment/nginx-deployment --replicas 5
deployment.apps/nginx-deployment scaled
[root@k8s-master01 pod]# kubectl get pods
NAME                                READY   STATUS              RESTARTS   AGE
nginx-deployment-56bbb744cc-5sr67   0/1     ContainerCreating   0          1s
nginx-deployment-56bbb744cc-lb28h   1/1     Running             1          24h
nginx-deployment-56bbb744cc-nwhgk   1/1     Running             1          24h
nginx-deployment-56bbb744cc-wxn5c   0/1     ContainerCreating   0          1s
nginx-deployment-56bbb744cc-z2k5h   1/1     Running             1          24h

# 將--replicas設(shè)置為比當(dāng)前Pod副本數(shù)量更小的數(shù)字,系統(tǒng)將會(huì)“殺掉”一些運(yùn)行中的Pod茄袖，以實(shí)現(xiàn)應(yīng)用集群縮容：
[root@k8s-master01 pod]# kubectl scale deployment/nginx-deployment --replicas 1
deployment.apps/nginx-deployment scaled
[root@k8s-master01 pod]# kubectl get pods
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-56bbb744cc-z2k5h   1/1     Running   1          24h

自動(dòng)擴(kuò)縮容機(jī)制

Kubernetes從1.1版本開(kāi)始操软，新增了名為Horizontal Pod Autoscaler（HPA）的控制器，用于實(shí)現(xiàn)基于CPU使用率進(jìn)行自動(dòng)Pod擴(kuò)縮容的功能宪祥。

HPA控制器基于Master的kube-controller-manager服務(wù)啟動(dòng)參數(shù)--horizontal-pod-autoscaler-sync-period定義的探測(cè)周期（默認(rèn)值為15s）聂薪，周期性地監(jiān)測(cè)目標(biāo)Pod的資源性能指標(biāo)，并與HPA資源對(duì)象中的擴(kuò)縮容條件進(jìn)行對(duì)比蝗羊，在滿足條件時(shí)對(duì)Pod副本數(shù)量進(jìn)行調(diào)整藏澳。

HPA的工作原理

Kubernetes中的某個(gè)Metrics Server（Heapster或自定義Metrics Server）持續(xù)采集所有Pod副本的指標(biāo)數(shù)據(jù)。

HPA控制器通過(guò)Metrics Server的API（Heapster的API或聚合API）獲取這些數(shù)據(jù)耀找，基于用戶定義的擴(kuò)縮容規(guī)則進(jìn)行計(jì)算翔悠，得到目標(biāo)Pod副本數(shù)量业崖。

當(dāng)目標(biāo)Pod副本數(shù)量與當(dāng)前副本數(shù)量不同時(shí)，HPA控制器就向Pod的副本控制器（Deployment蓄愁、RC或ReplicaSet）發(fā)起scale操作双炕，調(diào)整Pod的副本數(shù)量，完成擴(kuò)縮容操作撮抓。

image.png

指標(biāo)的類型

Master的kube-controller-manager服務(wù)持續(xù)監(jiān)測(cè)目標(biāo)Pod的某種性能指標(biāo)妇斤，以計(jì)算是否需要調(diào)整副本數(shù)量。

目前Kubernetes支持的指標(biāo)類型如下丹拯。

• Pod資源使用率：Pod級(jí)別的性能指標(biāo)站超，通常是一個(gè)比率值，例如CPU使用率乖酬。
• Pod自定義指標(biāo)：Pod級(jí)別的性能指標(biāo)死相，通常是一個(gè)數(shù)值，例如接收的請(qǐng)求數(shù)量咬像。
• Object自定義指標(biāo)或外部自定義指標(biāo)：通常是一個(gè)數(shù)值算撮，需要容器應(yīng)用以某種方式提供，例如通過(guò)HTTP URL“/metrics”提供施掏，或者使用外部服務(wù)提供的指標(biāo)采集URL钮惠。

Kubernetes從1.11版本開(kāi)始茅糜，棄用Ｆ甙拧！蔑赘！ 基于Heapster組件完成Pod的CPU使用率采集的機(jī)制狸驳，全面轉(zhuǎn)向基于Metrics Server完成數(shù)據(jù)采集。

Metrics Server將采集到的Pod性能指標(biāo)數(shù)據(jù)通過(guò)聚合API（Aggregated API）如metrics.k8s.io缩赛、custom.metrics.k8s.io和external.metrics.k8s.io提供給HPA控制器進(jìn)行查詢耙箍。

擴(kuò)縮容算法詳解

Autoscaler控制器從聚合API獲取到Pod性能指標(biāo)數(shù)據(jù)之后，基于下面的算法計(jì)算出目標(biāo)Pod副本數(shù)量酥馍，與當(dāng)前運(yùn)行的Pod副本數(shù)量進(jìn)行對(duì)比辩昆，決定是否需要進(jìn)行擴(kuò)縮容操作：

desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desireMetricValue)]

即當(dāng)前副本數(shù) ×（當(dāng)前指標(biāo)值/期望的指標(biāo)值），將結(jié)果向上取整旨袒。

以CPU請(qǐng)求數(shù)量為例汁针，如果用戶設(shè)置的期望指標(biāo)值為100m，當(dāng)前實(shí)際使用的指標(biāo)值為200m砚尽，則計(jì)算得到期望的Pod副本數(shù)量應(yīng)為兩個(gè)（200/100=2）施无。如果設(shè)置的期望指標(biāo)值為50m，計(jì)算結(jié)果為0.5必孤，則向上取整值為1猾骡，得到目標(biāo)Pod副本數(shù)量應(yīng)為1個(gè)。

當(dāng)計(jì)算結(jié)果與1非常接近時(shí)，可以設(shè)置一個(gè)容忍度讓系統(tǒng)不做擴(kuò)縮容操作兴想。容忍度通過(guò)kube-controller-manager服務(wù)的啟動(dòng)參數(shù)--horizontal-pod-autoscaler-tolerance進(jìn)行設(shè)置幢哨，默認(rèn)值為0.1（即10%），表示基于上述算法得到的結(jié)果在[-10% - +10%]區(qū)間內(nèi)嫂便，即[0.9 - 1.1]嘱么，控制器都不會(huì)進(jìn)行擴(kuò)縮容操作。

也可以將期望指標(biāo)值（desiredMetricValue）設(shè)置為指標(biāo)的平均值類型顽悼，例如targetAverageValue或targetAverageUtilization曼振，此時(shí)當(dāng)前指標(biāo)值（currentMetricValue）的算法為所有Pod副本當(dāng)前指標(biāo)值的總和除以Pod副本數(shù)量得到的平均值。

此外蔚龙，存在幾種Pod異常的情況冰评，如下所述。

• Pod正在被刪除（設(shè)置了刪除時(shí)間戳）：將不會(huì)計(jì)入目標(biāo)Pod副本數(shù)量木羹。
• Pod的當(dāng)前指標(biāo)值無(wú)法獲得：本次探測(cè)不會(huì)將這個(gè)Pod納入目標(biāo)Pod副本數(shù)量甲雅，后續(xù)的探測(cè)會(huì)被重新納入計(jì)算范圍。
• 如果指標(biāo)類型是CPU使用率坑填，則對(duì)于正在啟動(dòng)但是還未達(dá)到Ready狀態(tài)的Pod抛人，也暫時(shí)不會(huì)納入目標(biāo)副本數(shù)量范圍∑旯澹可以通過(guò)kube-controller-manager服務(wù)的啟動(dòng)參數(shù)--horizontal-pod-autoscaler-initial-readiness-delay設(shè)置首次探測(cè)Pod是否Ready的延時(shí)時(shí)間妖枚，默認(rèn)值為30s。另一個(gè)啟動(dòng)參數(shù)--horizontal-pod-autoscaler-cpuinitialization-period設(shè)置首次采集Pod的CPU使用率的延時(shí)時(shí)間苍在。

在計(jì)算“當(dāng)前指標(biāo)值/期望的指標(biāo)值”（currentMetricValue / desiredMetricValue）時(shí)將不會(huì)包括上述這些異常Pod

當(dāng)存在缺失指標(biāo)的Pod時(shí)绝页，系統(tǒng)將更保守地重新計(jì)算平均值。系統(tǒng)會(huì)假設(shè)這些Pod在需要縮容（Scale Down）時(shí)消耗了期望指標(biāo)值的100%寂恬，在需要擴(kuò)容（Scale Up）時(shí)消耗了期望指標(biāo)值的0%续誉，這樣可以抑制潛在的擴(kuò)縮容操作。

此外初肉，如果存在未達(dá)到Ready狀態(tài)的Pod酷鸦，并且系統(tǒng)原本會(huì)在不考慮缺失指標(biāo)或NotReady的Pod情況下進(jìn)行擴(kuò)展，則系統(tǒng)仍然會(huì)保守地假設(shè)這些Pod消耗期望指標(biāo)值的0%牙咏，從而進(jìn)一步抑制擴(kuò)容操作臼隔。

如果在HorizontalPodAutoscaler中設(shè)置了多個(gè)指標(biāo)，系統(tǒng)就會(huì)對(duì)每個(gè)指標(biāo)都執(zhí)行上面的算法眠寿，在全部結(jié)果中以期望副本數(shù)的最大值為最終結(jié)果躬翁。如果這些指標(biāo)中的任意一個(gè)都無(wú)法轉(zhuǎn)換為期望的副本數(shù)（例如無(wú)法獲取指標(biāo)的值），系統(tǒng)就會(huì)跳過(guò)擴(kuò)縮容操作盯拱。

最后盒发，在HPA控制器執(zhí)行擴(kuò)縮容操作之前例嘱，系統(tǒng)會(huì)記錄擴(kuò)縮容建議信息（Scale Recommendation）∧ⅲ控制器會(huì)在操作時(shí)間窗口（時(shí)間范圍可以配置）中考慮所有的建議信息拼卵，并從中選擇得分最高的建議。這個(gè)值可通過(guò)kube-controller-manager服務(wù)的啟動(dòng)參數(shù)--horizontal-pod-autoscaler-downscale-stabilization-window進(jìn)行配置蛮艰，默認(rèn)值為5min腋腮。這個(gè)配置可以讓系統(tǒng)更為平滑地進(jìn)行縮容操作，從而消除短時(shí)間內(nèi)指標(biāo)值快速波動(dòng)產(chǎn)生的影響壤蚜。

HorizontalPodAutoscaler配置詳解

Kubernetes將HorizontalPodAutoscaler資源對(duì)象提供給用戶來(lái)定義擴(kuò)縮容的規(guī)則即寡。

HorizontalPodAutoscaler資源對(duì)象處于Kubernetes的API組“autoscaling”中，目前包括v1和v2兩個(gè)版本

其中autoscaling/v1僅支持基于CPU使用率的自動(dòng)擴(kuò)縮容袜刷，autoscaling/v2則用于支持基于任意指標(biāo)的自動(dòng)擴(kuò)縮容配置聪富，包括基于資源使用率、Pod指標(biāo)著蟹、其他指標(biāo)等類型的指標(biāo)數(shù)據(jù)墩蔓，當(dāng)前版本為autoscaling/v2beta2。

下面對(duì)HorizontalPodAutoscaler的配置和用法進(jìn)行說(shuō)明萧豆。

（1）基于autoscaling/v1版本的HorizontalPodAutoscaler配置奸披，僅可以設(shè)置CPU使用率：

apiVersion: autoscaling/v1 
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
 spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50

主要參數(shù)如下

• scaleTargetRef：目標(biāo)作用對(duì)象，可以是Deployment涮雷、ReplicationController或ReplicaSet阵面。
• targetCPUUtilizationPercentage：期望每個(gè)Pod的CPU使用率都為50%，該使用率基于Pod設(shè)置的CPU Request值進(jìn)行計(jì)算份殿，例如該值為200m膜钓，那么系統(tǒng)將維持Pod的實(shí)際CPU使用值為100m嗽交。
• minReplicas和maxReplicas：Pod副本數(shù)量的最小值和最大值卿嘲，系統(tǒng)將在這個(gè)范圍內(nèi)進(jìn)行自動(dòng)擴(kuò)縮容操作，并維持每個(gè)Pod的CPU使用率為50%夫壁。

為了使用autoscaling/v1版本的HorizontalPodAutoscaler拾枣，需要預(yù)先安裝Heapster組件或Metrics Server，用于采集Pod的CPU使用率盒让。

Heapster從Kubernetes 1.11版本開(kāi)始進(jìn)入棄用階段梅肤，不再對(duì)Heapster進(jìn)行詳細(xì)說(shuō)明。

（2）基于autoscaling/v2beta2的HorizontalPodAutoscaler配置：

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

主要參數(shù)如下邑茄。

• scaleTargetRef：目標(biāo)作用對(duì)象姨蝴，可以是Deployment、ReplicationController或ReplicaSet肺缕。
• minReplicas和maxReplicas：Pod副本數(shù)量的最小值和最大值左医，系統(tǒng)將在這個(gè)范圍內(nèi)進(jìn)行自動(dòng)擴(kuò)縮容操作授帕，并維持每個(gè)Pod的CPU使用率為50%。
• metrics：目標(biāo)指標(biāo)值浮梢。在metrics中通過(guò)參數(shù)type定義指標(biāo)的類型跛十；通過(guò)參數(shù)target定義相應(yīng)的指標(biāo)目標(biāo)值，系統(tǒng)將在指標(biāo)數(shù)據(jù)達(dá)到目標(biāo)值時(shí)（考慮容忍度的區(qū)間秕硝，見(jiàn)前面算法部分的說(shuō)明）觸發(fā)擴(kuò)縮容操作芥映。

可以將metrics中的type（指標(biāo)類型）設(shè)置為以下三種，可以設(shè)置一個(gè)或多個(gè)組合远豺，如下所述奈偏。

（1）Resource：基于資源的指標(biāo)值，可以設(shè)置的資源為CPU和內(nèi)存躯护。

（2）Pods：基于Pod的指標(biāo)霎苗，系統(tǒng)將對(duì)全部Pod副本的指標(biāo)值進(jìn)行平均值計(jì)算。

（3）Object：基于某種資源對(duì)象（如Ingress）的指標(biāo)或應(yīng)用系統(tǒng)的任意自定義指標(biāo)榛做。

Resource類型的指標(biāo)可以設(shè)置CPU和內(nèi)存唁盏。

• 對(duì)于CPU使用率，在target參數(shù)中設(shè)置averageUtilization定義目標(biāo)平均CPU使用率检眯。
• 對(duì)于內(nèi)存資源厘擂，在target參數(shù)中設(shè)置AverageValue定義目標(biāo)平均內(nèi)存使用值。

指標(biāo)數(shù)據(jù)可以通過(guò)API“metrics.k8s.io”進(jìn)行查詢锰瘸，要求預(yù)先啟動(dòng)Metrics Server服務(wù)刽严。

Pods類型和Object類型都屬于自定義指標(biāo)類型，指標(biāo)的數(shù)據(jù)通常需要搭建自定義Metrics Server和監(jiān)控工具進(jìn)行采集和處理避凝。指標(biāo)數(shù)據(jù)可以通過(guò)API“custom.metrics.k8s.io”進(jìn)行查詢舞萄，要求預(yù)先啟動(dòng)自定義Metrics Server服務(wù)。

類型為Pods的指標(biāo)數(shù)據(jù)來(lái)源于Pod對(duì)象本身管削，其target指標(biāo)類型只能使用AverageValue倒脓，示例如下：

metrics:
- type: Pods
  pods:
    metric:
      name: packets-per-second
    target:
      type: AverageValue
      averageValue: 1k

其中，設(shè)置Pod的指標(biāo)名為packets-per-second含思，在目標(biāo)指標(biāo)平均值為1000時(shí)觸發(fā)擴(kuò)縮容操作崎弃。

類型為Object的指標(biāo)數(shù)據(jù)來(lái)源于其他資源對(duì)象或任意自定義指標(biāo)，其target指標(biāo)類型可以使用Value或AverageValue（根據(jù)Pod副本數(shù)計(jì)算平均值）進(jìn)行設(shè)置含潘。下面對(duì)幾種常見(jiàn)的自定義指標(biāo)給出示例和說(shuō)明饲做。

例1，設(shè)置指標(biāo)的名稱為requests-per-second遏弱，其值來(lái)源于Ingress “main-route”盆均，將目標(biāo)值（value）設(shè)置為2000，即在Ingress的每秒請(qǐng)求數(shù)量達(dá)到2000個(gè)時(shí)觸發(fā)擴(kuò)縮容操作：

metrics:
- type: Object
  object:
    metric:
      name: requests-per-second
    describedObject:
      apiVersion: extensions/v1beta1
      kind: Ingress
      name: main-route
    target:
      type: Value
      value: 2k

例2漱逸，設(shè)置指標(biāo)的名稱為http_requests泪姨，并且該資源對(duì)象具有標(biāo)簽“verb=GET”居砖，在指標(biāo)平均值達(dá)到500時(shí)觸發(fā)擴(kuò)縮容操作

metrics:
- type: Object
  object:
    metric:
      name: 'http_requests'
      selector: 'verb=GET'
    target:
      type: AverageValue
      AverageValue: 500

還可以在同一個(gè)HorizontalPodAutoscaler資源對(duì)象中定義多個(gè)類型的指標(biāo)，系統(tǒng)將針對(duì)每種類型的指標(biāo)都計(jì)算Pod副本的目標(biāo)數(shù)量驴娃，以最大值為準(zhǔn)進(jìn)行擴(kuò)縮容操作奏候。例如：

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
  namespace: default
 spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: AverageUtilization
        averageUtilization: 50
  - type: Pods
    pods:
      metric:
        name: packets-per-second
      targetAverageValue: 1k
  - type: Object
    object:
      metric:
        name: requests-per-second
      describedObject:
        apiVersion: extensions/v1beta1
        kind: Ingress
        name: main-route
      target:
        kind: Value
        value: 10k

從1.10版本開(kāi)始，Kubernetes引入了對(duì)外部系統(tǒng)指標(biāo)的支持唇敞。例如蔗草，用戶使用了公有云服務(wù)商提供的消息服務(wù)或外部負(fù)載均衡器，希望基于這些外部服務(wù)的性能指標(biāo)（如消息服務(wù)的隊(duì)列長(zhǎng)度疆柔、負(fù)載均衡器的QPS）對(duì)自己部署在Kubernetes中的服務(wù)進(jìn)行自動(dòng)擴(kuò)縮容操作咒精。這時(shí)，就可以在metrics參數(shù)部分設(shè)置type為External來(lái)設(shè)置自定義指標(biāo)旷档，然后就可以通過(guò)API“external.metrics.k8s.io”查詢指標(biāo)數(shù)據(jù)了模叙。當(dāng)然，這同樣要求自定義Metrics Server服務(wù)已正常工作鞋屈。

例3范咨，設(shè)置指標(biāo)的名稱為queue_messages_ready，具有queue=worker_tasks標(biāo)簽在目標(biāo)指標(biāo)平均值為30時(shí)觸發(fā)自動(dòng)擴(kuò)縮容操作：

- type: External
  external:
    metric:
      name: queue_messages_ready
      selector: "queue=worker_tasks"
    target:
      type: AverageValue
      averageValue: 30

在使用外部服務(wù)的指標(biāo)時(shí)厂庇，要安裝渠啊、部署能夠?qū)拥終ubernetes HPA模型的監(jiān)控系統(tǒng)，并且完全了解監(jiān)控系統(tǒng)采集這些指標(biāo)的機(jī)制权旷，后續(xù)的自動(dòng)擴(kuò)縮容操作才能完成替蛉。

Kubernetes推薦盡量使用type為Object的HPA配置方式，這可以通過(guò)使用Operator模式拄氯，將外部指標(biāo)通過(guò)CRD（自定義資源）定義為API資源對(duì)象來(lái)實(shí)現(xiàn)躲查。

基于自定義指標(biāo)的HPA實(shí)踐

通過(guò)一個(gè)完整的示例，對(duì)如何搭建和使用基于自定義指標(biāo)的HPA體系進(jìn)行說(shuō)明译柏。

基于自定義指標(biāo)進(jìn)行自動(dòng)擴(kuò)縮容時(shí)镣煮，需要預(yù)先部署自定義Metrics Server，目前可以使用基于Prometheus艇纺、Microsoft Azure怎静、Datadog Cluster等系統(tǒng)的Adapter實(shí)現(xiàn)自定義Metrics Server，未來(lái)還將提供基于Google Stackdriver的實(shí)現(xiàn)自定義Metrics Server黔衡。讀者可以參考官網(wǎng) https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custommetrics-api 的說(shuō)明。

基于Prometheus監(jiān)控系統(tǒng)對(duì)HPA的基礎(chǔ)組件部署和HPA配置進(jìn)行詳細(xì)說(shuō)明腌乡。

基于Prometheus的HPA架構(gòu)如圖

image.png

關(guān)鍵組件包括如下:

• Prometheus：定期采集各Pod的性能指標(biāo)數(shù)據(jù)盟劫。
• Custom Metrics Server：自定義Metrics Server，用Prometheus Adapter進(jìn)行具體實(shí)現(xiàn)与纽。它從Prometheus服務(wù)采集性能指標(biāo)數(shù)據(jù)侣签，通過(guò)Kubernetes的Metrics Aggregation層將自定義指標(biāo)API注冊(cè)到Master的API Server中塘装，以/apis/custom.metrics.k8s.io路徑提供指標(biāo)數(shù)據(jù)。
• HPA Controller：Kubernetes的HPA控制器影所，基于用戶定義的HorizontalPodAutoscaler進(jìn)行自動(dòng)擴(kuò)縮容操作蹦肴。

接下來(lái)對(duì)整個(gè)系統(tǒng)的部署過(guò)程進(jìn)行說(shuō)明。

（1）在Master的API Server啟動(dòng)Aggregation層猴娩，通過(guò)設(shè)置kube-apiserver服務(wù)的下列啟動(dòng)參數(shù)進(jìn)行開(kāi)啟阴幌。

• --requestheader-client-ca-file=/etc/kubernetes/ssl_keys/ca.crt：客戶端CA證書(shū)。
• --requestheader-allowed-names=：允許訪問(wèn)的客戶端common names列表卷中，通過(guò)header中由--requestheader-username-headers參數(shù)指定的字段獲取矛双。客戶端common names的名稱需要在client-ca-file中進(jìn)行配置蟆豫，將其設(shè)置為空值時(shí)议忽，表示任意客戶端都可以訪問(wèn)。
• --requestheader-extra-headers-prefix=X-Remote-Extra-：請(qǐng)求頭中需要檢查的前綴名十减。
• --requestheader-group-headers=X-Remote-Group：請(qǐng)求頭中需要檢查的組名栈幸。
• --requestheader-username-headers=X-Remote-User：請(qǐng)求頭中需要檢查的用戶名。
• --proxy-client-cert-file=/etc/kubernetes/ssl_keys/kubelet_client.crt：在請(qǐng)求期間驗(yàn)證Aggregator的客戶端CA證書(shū)帮辟。
• --proxy-client-key-file=/etc/kubernetes/ssl_keys/kubelet_client.key：在請(qǐng)求期間驗(yàn)證Aggregator的客戶端私鑰侦镇。

配置kube-controller-manager服務(wù)中HPA的相關(guān)啟動(dòng)參數(shù)（可選配置）如下。

• --horizontal-pod-autoscaler-sync-period=10s：HPA控制器同步Pod副本數(shù)量的時(shí)間間隔织阅，默認(rèn)值為15s壳繁。
• --horizontal-pod-autoscaler-downscale-stabilization=1m0s：執(zhí)行縮容操作的等待時(shí)長(zhǎng)，默認(rèn)值為5min荔棉。
• --horizontal-pod-autoscaler-initial-readiness-delay=30s：等待Pod達(dá)到Ready狀態(tài)的時(shí)延闹炉，默認(rèn)值為30min。
• --horizontal-pod-autoscaler-tolerance=0.1：擴(kuò)縮容計(jì)算結(jié)果的容忍度润樱，默認(rèn)值為0.1渣触，表示[-10% - +10%]。

（2）部署Prometheus壹若，這里使用Operator模式進(jìn)行部署嗅钻。

首先，使用下面的YAML配置文件部署prometheus-operator：

# 1. prometheus-operator
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    k8s-app: prometheus-operator
  name: prometheus-operator
spec:
  replicas: 1
  selector:
    matchLabels:
      k8s-app: prometheus-operator
  template:
    metadata:
      labels:
        k8s-app: prometheus-operator
    spec:
      containers:
      - image: quay.io/coreos/prometheus-operator:v0.17.0
        imagePullPolicy: IfNotPresent
        name: prometheus-operator
        ports:
        - containerPort: 8080
          name: http
        resources:
          limits:
            cpu: 200m
            memory: 100Mi
          requests:
            cpu: 100m
            memory: 50Mi