[[408253]]

隨著Kubernetes的不斷發(fā)展，技術(shù)不斷成熟，越來越多的公司選擇把自家的應(yīng)用部署到Kubernetes中。但是把應(yīng)用部署到Kubernetes中就完事了嗎?顯然不是，應(yīng)用容器化只是萬里長征的第一步，如何讓應(yīng)用安心、穩(wěn)定的運(yùn)行才是后續(xù)的所有工作。

這里主要從以下幾個(gè)方面來進(jìn)行整理，對于大部分公司足夠使用。

Node

Node可以是物理主機(jī)，也可以是云主機(jī)，它是Kubernetes的載體。在很多時(shí)候我們并不太關(guān)心Node怎么樣了，除非其異常。但是作為運(yùn)維人員，我們最不希望的就是異常，對于Node也是一樣。

Node節(jié)點(diǎn)并不需要做太多太復(fù)雜的操作，主要如下：

>內(nèi)核升級

對于大部分企業(yè)，CentOS系統(tǒng)還是首選，默認(rèn)情況下，7系列系統(tǒng)默認(rèn)版本是3.10，該版本的內(nèi)核在Kubernetes社區(qū)有很多已知的Bug，所以對節(jié)點(diǎn)來說，升級內(nèi)核是必須的，或者企業(yè)可以選擇Ubuntu作為底層操作系統(tǒng)。

升級內(nèi)核的步驟如下(簡單的升級方式)：

wget https://elrepo.org/linux/kernel/el7/x86_64/RPMS/kernel-lt-5.4.86-1.el7.elrepo.x86_64.rpm 
rpm -ivh kernel-lt-5.4.86-1.el7.elrepo.x86_64.rpm 
cat /boot/grub2/grub.cfg | grep menuentry 
grub2-set-default 'CentOS Linux (5.4.86-1.el7.elrepo.x86_64) 7 (Core)' 
grub2-editenv list 
grub2-mkconfig -o /boot/grub2/grub.cfg 
reboot 

>軟件更新

對于大部分人來說，更新軟件在很多情況下是不做的，因?yàn)楹ε录嫒輪栴}。不過在實(shí)際生產(chǎn)中，對于已知有高危漏洞的軟件，我們還需要對其進(jìn)行更新，這個(gè)可以針對處理。

>優(yōu)化Docker配置文件

對于Docker的配置文件，主要優(yōu)化的就是日志驅(qū)動(dòng)、保留日志大小以及鏡像加速等，其他的配置根據(jù)情況而定，如下：

cat > /etc/docker/daemon.json  << EOF 
{ 
    "exec-opts": ["native.cgroupdriver=systemd"], 
    "log-driver": "json-file", 
    "log-opts": { 
        "max-size": "100m", 
        "max-file": "10" 
    }, 
    "bip": "169.254.123.1/24", 
    "oom-score-adjust": -1000, 
    "registry-mirrors": ["https://pqbap4ya.mirror.aliyuncs.com"], 
    "storage-driver": "overlay2", 
    "storage-opts":["overlay2.override_kernel_check=true"], 
    "live-restore": true 
} 
EOF 

>優(yōu)化kubelet參數(shù)

對于K8S來講，kubelet是每個(gè)Node的組長，負(fù)責(zé)Node的"飲食起居"，這里對它的參數(shù)配置主要如下：

cat > /etc/systemd/system/kubelet.service <<EOF 
[Unit] 
Description=kubelet: The Kubernetes Node Agent 
Documentation=https://kubernetes.io/docs/ 
 
 
[Service] 
ExecStartPre=/usr/bin/mkdir -p /sys/fs/cgroup/pids/system.slice/kubelet.service 
ExecStartPre=/usr/bin/mkdir -p /sys/fs/cgroup/cpu/system.slice/kubelet.service 
ExecStartPre=/usr/bin/mkdir -p /sys/fs/cgroup/cpuacct/system.slice/kubelet.service 
ExecStartPre=/usr/bin/mkdir -p /sys/fs/cgroup/cpuset/system.slice/kubelet.service 
ExecStartPre=/usr/bin/mkdir -p /sys/fs/cgroup/memory/system.slice/kubelet.service 
ExecStartPre=/usr/bin/mkdir -p /sys/fs/cgroup/systemd/system.slice/kubelet.service 
ExecStart=/usr/bin/kubelet \ 
--enforce-node-allocatable=pods,kube-reserved \ 
--kube-reserved-cgroup=/system.slice/kubelet.service \ 
--kube-reserved=cpu=200m,memory=250Mi \ 
--eviction-hard=memory.available<5%,nodefs.available<10%,imagefs.available<10% \ 
--eviction-soft=memory.available<10%,nodefs.available<15%,imagefs.available<15% \ 
--eviction-soft-grace-period=memory.available=2m,nodefs.available=2m,imagefs.available=2m \ 
--eviction-max-pod-grace-period=30 \ 
--eviction-minimum-reclaim=memory.available=0Mi,nodefs.available=500Mi,imagefs.available=500Mi 
Restart=always 
StartLimitInterval=0 
RestartSec=10 
 
 
[Install] 
WantedBy=multi-user.target 
EOF 

其功能主要是為每個(gè)Node增加資源預(yù)留，可以在一定程度上防止Node宕機(jī)。

>日志配置管理

這里的日志配置管理針對的是系統(tǒng)日志，非自研應(yīng)用日志。默認(rèn)情況下，系統(tǒng)日志都不需要我們特殊配置，我這里提出來，主要是保障日志的可追溯。當(dāng)系統(tǒng)因?yàn)槟撤N原因被入侵，系統(tǒng)系統(tǒng)被刪除的情況下，還有日志提供給我們分析。

所以在條件允許的情況下，對Node節(jié)點(diǎn)的系統(tǒng)日志進(jìn)行遠(yuǎn)程備份是有必要的，可以采用rsyslog進(jìn)行配置管理，日志可以保存到遠(yuǎn)端的日志中心或者oss上。

>安全配置

安全配置這里涉及的不多，主要是針對已知的一些安全問題進(jìn)行加固。主要有以下五種(當(dāng)然還有更多，看自己的情況)：

• ssh密碼過期策略
• 密碼復(fù)雜度策略
• ssh登錄次數(shù)限制
• 系統(tǒng)超時(shí)配置
• 歷史記錄配置

Pod

Pod是K8S的最小調(diào)度單元，是應(yīng)用的載體，它的穩(wěn)定直接關(guān)乎應(yīng)用本身，在部署應(yīng)用的時(shí)候，主要考慮一下幾個(gè)方面。

>資源限制

Pod使用的是主機(jī)的資源，合理的資源限制可以有效避免資源超賣或者資源搶占問題。在配置資源限制的時(shí)候，要根據(jù)實(shí)際的應(yīng)用情況來決定Pod的QoS，不同的QoS配置情況不一樣。

如果應(yīng)用的級別比較高，建議配置Guaranteed級別配置，如下：

resources: 
  limits: 
    memory: "200Mi" 
    cpu: "700m" 
  requests: 
    memory: "200Mi" 
    cpu: "700m" 

如果應(yīng)用級別一般，建議配置Burstable級別，如下：

resources: 
  limits: 
    memory: "200Mi" 
    cpu: "500m" 
  requests: 
    memory: "100Mi" 
    cpu: "100m" 

強(qiáng)烈不建議使用BestEffort類型的Pod。

>調(diào)度策略

調(diào)度策略也是根據(jù)情況來定，如果你的應(yīng)用需要指定調(diào)度到某些節(jié)點(diǎn)，可以使用親和性調(diào)度，如下：

affinity: 
  nodeAffinity: 
    preferredDuringSchedulingIgnoredDuringExecution: 
      - preference: {} 
        weight: 100 
    requiredDuringSchedulingIgnoredDuringExecution: 
      nodeSelectorTerms: 
        - matchExpressions: 
            - key: env 
              operator: In 
              values: 
                - uat 

如果一個(gè)節(jié)點(diǎn)只允許某一個(gè)應(yīng)用調(diào)度，這時(shí)候就需要用到污點(diǎn)調(diào)度了，也就是先給節(jié)點(diǎn)打污點(diǎn)，然后需要調(diào)度到該節(jié)點(diǎn)的Pod需要容忍污點(diǎn)。最穩(wěn)妥的方式是標(biāo)簽+污點(diǎn)相結(jié)合。如下：

tolerations: 
- key: "key1"          #能容忍的污點(diǎn)key 
  operator: "Equal"    #Equal等于表示key=value ， Exists不等于，表示當(dāng)值不等于下面value正常 
  value: "value1"      #值 
  effect: "NoExecute"  #effect策略 
  tolerationSeconds: 3600  #原始的pod多久驅(qū)逐，注意只有effect: "NoExecute"才能設(shè)置，不然報(bào)錯(cuò) 

當(dāng)然，除了Pod和Node的關(guān)聯(lián)，還有Pod和Pod之間的關(guān)聯(lián)，一般情況下，為了達(dá)到真正的高可用，我們不建議同一個(gè)應(yīng)用的Pod都可以調(diào)度到同一個(gè)節(jié)點(diǎn)，所以我們需要給Pod做反親和性調(diào)度，如下：

affinity: 
  podAntiAffinity: 
    requiredDuringSchedulingIgnoredDuringExecution: 
    - labelSelector: 
        matchExpressions: 
        - key: app 
          operator: In 
          values: 
          - store 
      topologyKey: "kubernetes.io/hostname" 

如果某個(gè)應(yīng)用親和其他應(yīng)用，則可以使用親和性，這樣可以在一定程度上降低網(wǎng)絡(luò)延遲，如下：

affinity: 
  podAffinity: 
    requiredDuringSchedulingIgnoredDuringExecution: 
    - labelSelector: 
        matchExpressions: 
        - key: security 
          operator: In 
          values: 
          - S1 
      topologyKey: failure-domain.beta.kubernetes.io/zone 

>優(yōu)雅升級

Pod默認(rèn)是采用的滾動(dòng)更新策略，我們關(guān)注點(diǎn)主要在新的Pod起來后，老的Pod如何能優(yōu)雅的處理流量，對外界是無感的。

最簡單的方式是"睡幾秒"，這種方式并不能保證百分百的優(yōu)雅處理流量，方式如下：

lifecycle: 
  preStop: 
    exec: 
      command: 
      - /bin/sh 
      - -c 
      - sleep 15 

如果有注冊中心，可以在退出的時(shí)候先把原服務(wù)從注冊中心下線再退出，比如這里使用的nacos作為注冊中心，如下：

lifecycle: 
  preStop: 
    exec: 
      command: 
        - /bin/sh 
        - -c 
        - "curl -X DELETE your_nacos_ip:8848/nacos/v1/ns/instance?serviceName=nacos.test.1&ip=${POD_IP}&port=8880&clusterName=DEFAULT" && sleep 15 

>探針配置

探針重要嗎?重要!它是kubelet判斷Pod是否健康的重要依據(jù)。

Pod的主要探針有：

• livenessProbe
• readinessProbe
• startupProbe

其中startupProbe是v1.16版本后才新增的探針，其主要針對啟動(dòng)時(shí)間較長的應(yīng)用，在多數(shù)情況下只需要配置livenessProbe和readinessProbe即可。

通常情況下，一個(gè)Pod就代表一個(gè)應(yīng)用，所以在配置探針的時(shí)候最好能直接反應(yīng)應(yīng)用是否正常，很多框架都帶有健康檢測功能，我們在配置探針的時(shí)候可以考慮使用這些健康檢測功能，如果框架沒有，也可以考慮讓開發(fā)人員統(tǒng)一開發(fā)一個(gè)健康檢測接口，這樣便于標(biāo)準(zhǔn)化健康檢測。如下：

readinessProbe: 
  failureThreshold: 3 
  httpGet: 
    path: /health 
    port: http 
    scheme: HTTP 
  initialDelaySeconds: 40 
  periodSeconds: 10 
  successThreshold: 1 
  timeoutSeconds: 3 
livenessProbe: 
  failureThreshold: 3 
  httpGet: 
    path: /health 
    port: http 
    scheme: HTTP 
  initialDelaySeconds: 60 
  periodSeconds: 10 
  successThreshold: 1 
  timeoutSeconds: 2 

如果需要配置startupProbe，則可以如下配置：

startupProbe: 
  httpGet: 
    path: /health 
    prot: 80 
  failureThreshold: 10 
  initialDelay：10 
  periodSeconds: 10 

>保護(hù)策略

這里的保護(hù)策略主要是指在我們主動(dòng)銷毀Pod的時(shí)候，通過保護(hù)策略來控制Pod的運(yùn)行個(gè)數(shù)。

在K8S中通過PodDisruptionBudget(PDB)來實(shí)現(xiàn)這個(gè)功能，對于一些重要應(yīng)用，我們需要為其配置PDB，如下：

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

在PDB中，主要通過兩個(gè)參數(shù)來控制Pod的數(shù)量：

• minAvailable：表示最小可用Pod數(shù)，表示在Pod集群中處于運(yùn)行狀態(tài)的最小Pod數(shù)或者是運(yùn)行狀態(tài)的Pod數(shù)和總數(shù)的百分比;
• maxUnavailable：表示最大不可用Pod數(shù)，表示Pod集群中處于不可用狀態(tài)的最大Pod數(shù)或者不可用狀態(tài)Pod數(shù)和總數(shù)的百分比;

注意：minAvailable和maxUnavailable是互斥了，也就是說兩者同一時(shí)刻只能出現(xiàn)一種。

日志

日志會貫穿應(yīng)用的整個(gè)生命周期，在排查問題或者分析數(shù)據(jù)的時(shí)候，日志都不可缺少。對于日志，這里主要從以下方面進(jìn)行分析。

>日志標(biāo)準(zhǔn)

日志一般分為業(yè)務(wù)日志和異常日志，對于日志，我們不希望其太復(fù)雜，也不希望其太簡單，更多的是希望通過日志達(dá)到如下目標(biāo)：

1. 對程序運(yùn)行情況的記錄和監(jiān)控;
2. 在必要時(shí)可詳細(xì)了解程序內(nèi)部的運(yùn)行狀態(tài);
3. 對系統(tǒng)性能的影響盡量小;

那日志標(biāo)準(zhǔn)如何定義呢?我這里簡單整理以下幾點(diǎn)：

• 合理使用日志分級
• 統(tǒng)一輸出格式
• 代碼編碼規(guī)范
• 日志輸出路徑統(tǒng)一
• 日志輸出命名規(guī)范統(tǒng)一

這樣規(guī)定的主要目的是便于收集和查看日志。

>收集

針對不同的日志輸出有不同的日志收集方案，主要有以下二種：

• 在Node上部署Logging Agent進(jìn)行收集
• 在Pod中以Sidecar形式進(jìn)行收集

在Node上部署Logging Agent進(jìn)行收集

這種日志收集方案主要針對已經(jīng)標(biāo)準(zhǔn)輸出的日志，架構(gòu)如下：

對于非標(biāo)準(zhǔn)輸出的日志就沒辦法進(jìn)行收集。

在Pod中以Sidecar形式進(jìn)行收集

這種收集方案主要針對非標(biāo)準(zhǔn)輸出的日志，可以在Pod中以sidecar的方式運(yùn)行日志收集客戶端，將日志收集到日志中心，架構(gòu)如下：

不過這種方式比較浪費(fèi)資源，所以最理想的情況就是把應(yīng)用日志都標(biāo)準(zhǔn)輸出，這樣收集起來比較簡單。

>分析

在業(yè)務(wù)正常的情況下，我們其實(shí)很少去查看日志內(nèi)容，只有在出問題的時(shí)候才會借助日志分析問題(大部分情況下都是這樣)，那為什么我這里要把分析提出來呢?

日志其實(shí)承載了很多信息，如果能對日志進(jìn)行有效分析，可以幫助我們識別、排查很多問題，比如阿里云的日志中心，在日志分析方面做的就很不錯(cuò)。

>告警

日志告警，可以讓我們快速知道問題，也縮小了故障排查范圍。不過要做日志告警就必須做好日志“關(guān)鍵字”管理，也就是要確定某一個(gè)關(guān)鍵字能夠準(zhǔn)確的代表一個(gè)問題，最好不出現(xiàn)泛指的現(xiàn)象，這樣做的好處就是能夠讓告警更加準(zhǔn)備，而不是出現(xiàn)一些告警風(fēng)暴或者無效告警，久而久之就麻木了。

監(jiān)控

集群、應(yīng)用等的生命周期里離不開監(jiān)控系統(tǒng)，有效的監(jiān)控系統(tǒng)可以為我們提供更高的可觀測性，方便我們線性的分析問題，排查問題以及定位問題，再配上有效的告警通知，也方便我們能快速的知道問題。

對于監(jiān)控，主要從以下幾個(gè)方面進(jìn)行介紹。

>集群監(jiān)控

對于K8S集群以及跑在K8S應(yīng)用來說，普遍使用Prometheus來進(jìn)行監(jiān)控。整個(gè)集群的穩(wěn)定性關(guān)乎著應(yīng)用的穩(wěn)定性，所以對集群的監(jiān)控至關(guān)重要，下面簡單列舉了一些監(jiān)控項(xiàng)，在實(shí)際的工作中酌情處理。

>應(yīng)用監(jiān)控

在很多企業(yè)中，并沒有接入應(yīng)用監(jiān)控，主要還是沒有在應(yīng)用中集成監(jiān)控指標(biāo)，導(dǎo)致無法監(jiān)控，所以在應(yīng)用開發(fā)的時(shí)候就強(qiáng)烈建議開發(fā)將應(yīng)用監(jiān)控加上，將指標(biāo)按prometheus標(biāo)準(zhǔn)格式暴露出來。

除了開發(fā)人員主動(dòng)暴露指標(biāo)外，我們也可以通過javaagent方式配置一些exporter，用來抓取一些指標(biāo)，比如jvm監(jiān)控指標(biāo)。

在應(yīng)用級別做監(jiān)控，可以將監(jiān)控粒度更細(xì)化，這樣可以更容易發(fā)現(xiàn)問題。我這里簡單整理了一些應(yīng)用監(jiān)控項(xiàng)，如下：

這些監(jiān)控項(xiàng)都有對于的exporter來完成，比如redis中間件有redis-exporter，api監(jiān)控有blcakbox-exporter等。

>事件監(jiān)控

在Kubernetes中，事件分為兩種，一種是Warning事件，表示產(chǎn)生這個(gè)事件的狀態(tài)轉(zhuǎn)換是在非預(yù)期的狀態(tài)之間產(chǎn)生的;另外一種是Normal事件，表示期望到達(dá)的狀態(tài)，和目前達(dá)到的狀態(tài)是一致的。

事件大多數(shù)情況下表示正在發(fā)生或者已經(jīng)發(fā)生的事，在實(shí)際工作中很容易就忽略這類信息，所以我們有必要借助事件監(jiān)控來規(guī)避這類問題。

在K8S中，常用的事件監(jiān)控是kube-eventer，它可以收集pod/node/kubelet等資源對象的event，還可以收集自定義資源對象的event，然后將這類信息發(fā)送到相關(guān)人員。

通過事件，我們主要關(guān)注的監(jiān)控項(xiàng)如下：

>鏈路監(jiān)控

正常情況下，K8S中的應(yīng)用是單獨(dú)的個(gè)體存在，彼此之間沒有顯性的聯(lián)系，這時(shí)候就需要一種手段，將應(yīng)用間的關(guān)系表現(xiàn)出來，方便我們跟蹤分析整個(gè)鏈路的問題。

目前比較流行的鏈路監(jiān)控工具有很多，我這邊主要是使用skywalking進(jìn)行鏈路監(jiān)控，其主要agent端比較豐富，也提供了很高的自擴(kuò)展能力，有興趣的朋友可以了解一下。

通過鏈路監(jiān)控，主要達(dá)到以下目的。

>告警通知

很多人會忽略告警通知，覺得告警就行。但是在做告警通知的時(shí)候還是需要仔細(xì)去考慮的。

如下簡單整理一下關(guān)注點(diǎn)。

個(gè)人覺得難點(diǎn)在于哪些指標(biāo)需要告警。我們在選取指標(biāo)的時(shí)候一定要遵循以下規(guī)則：

• 告警的指標(biāo)具有唯一性
• 告警的指標(biāo)能正確反應(yīng)問題
• 所暴露的問題是需要介入解決的

綜合這些規(guī)則考慮，才方便我們選取需要的指標(biāo)。

第二就是緊急程度分類，這個(gè)主要是根據(jù)這個(gè)告警指標(biāo)所暴露出來的問題是不是需要我們及時(shí)去解決，還有影響范圍來綜合衡量。

故障升級主要是針對需要解決的問題沒有解決而做的一種策略，提高故障等級，也相當(dāng)于提高了緊急程度了。通知渠道分類主要是方便我們區(qū)分不同的告警，還有如果能快速接收到告警信息。

寫在最后

上面寫的都是一些基礎(chǔ)的操作，對于YAML工程師來說，算是必備的技能儲備，這一套放到大部分公司都是適用的。

本文轉(zhuǎn)載自微信公眾號「 運(yùn)維開發(fā)故事」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系 運(yùn)維開發(fā)故事公眾號。