成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

一文弄懂pod Evicted的狀態究竟是何人所為

作者：姜總
運維 系統運維
今天發現好多pod的狀態都是Evicted，然后我沒有監控的權限，本來想看看grafana上監控圖是否出現了特殊情況，無奈沒權限看。

[[421065]]

背景

今天發現好多pod的狀態都是Evicted，然后我沒有監控的權限，本來想看看grafana上監控圖是否出現了特殊情況，無奈沒權限看。

因為我發現pod出現大量的Evicted狀態的時候，查看pod所在的node節點，距離當時發生Evicted的時間已經是7小時之久了。因此可能會存在一種原因：發生了Evicted的時候的確磁盤已經超過默認的kubelet的資源預留參數了。但是問題發生后，觸發了閾值，已經回收了磁盤空間，導致我看的時候磁盤空間已經恢復。

在每個 Kubernetes Node節點 上，kubelet 默認根目錄是 /var/lib/kubelet 和 日志目錄 /var/log 保存在節點的系統分區上，這個分區同時也會被Pod的 EmptyDir 類型的 volume、容器日志、鏡像層、容器的可寫層所占用。ephemeral-storage 便是對系統分區進行管理。

大量的Evicted狀態的pod

  1. $ kubectl get po -A -o wide | grep -v "Running" 
  2. NAMESPACE              NAME                                                              READY   STATUS             RESTARTS   AGE     IP              NODE                           NOMINATED NODE   READINESS GATES 
  3. nsop                   account-service-pre-master-6db67f5cc-5nrgf                        0/1     Evicted            0          103m    <none>          node2.pre.ayunw.cn           <none>           <none> 
  4. nsop                   account-service-pre-master-6db67f5cc-7zbrf                        0/1     Evicted            0          103m    <none>          node2.pre.ayunw.cn           <none>           <none> 
  5. nsop                   account-service-pre-master-6db67f5cc-h78hv                        0/1     Evicted            0          103m    <none>          node2.pre.ayunw.cn           <none>           <none> 
  6. nsop                   account-service-pre-master-6db67f5cc-jj4xx                        0/1     Evicted            0          103m    <none>          node2.pre.ayunw.cn           <none>           <none> 
  7. nsop                   account-service-pre-master-6db67f5cc-jz4cs                        0/1     Evicted            0          103m    <none>          node2.pre.ayunw.cn           <none>           <none> 
  8. nsop                   account-service-pre-master-6db67f5cc-km2cz                        0/1     Evicted            0          103m    <none>          node2.pre.ayunw.cn           <none>           <none> 

當我們的集群中有太多被驅逐的 pod 時，這會導致網絡負載。因為每個 pod 即使被驅逐是連接到網絡的，并且在云 Kubernetes 集群的情況下，也會阻塞一個 IP 地址，這可能導致如果您的集群有固定的 IP 地址池，也會耗盡 IP 地址。此外，當我們有太多處于 Evicted 狀態的 Pod 時，通過運行kubectl get pod命令來監控 Pod 會變得很困難，因為會存在非常多的 Evicted Pod。當然你可以通過grep等手段過濾掉Evicted狀態的pod。

查看Evicted的pod的任意一個node

describe任意一個pod查看，發現Warning提示DiskPressure，表示磁盤存在壓力了。

  1. $ kubectl describe po account-service-pre-master-6db67f5cc-5nrgf -n nsop 
  2. ... 
  3. QoS Class:       Burstable 
  4. Node-Selectors:  <none> 
  5. Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s 
  6.                  node.kubernetes.io/unreachable:NoExecute op=Exists for 300s 
  7.                  topology.kubernetes.io/env=pre:NoSchedule 
  8.                  topology.kubernetes.io/region=bce-gz:NoSchedule 
  9.                  topology.kubernetes.io/type=appserver:NoSchedule 
  10.                  topology.kubernetes.io/zone:NoSchedule op=Exists 
  11. Events: 
  12.   Type     Reason     Age   From                               Message 
  13.   ----     ------     ----  ----                               ------- 
  14.   Normal   Scheduled  100m  default-scheduler                  Successfully assigned nsop/account-service-pre-master-6db67f5cc-5nrgf to node2.pre.ayunw.cn 
  15.   Warning  Evicted    100m  kubelet, node2.pre.ayunw.cn        The node had condition: [DiskPressure]. 

登錄node2.pre.ayunw.cn查看

  1. [root@node2-pre-ayunw.cn ~]# df -Th | egrep -v "overlay2|kubernetes|docker" 
  2. Filesystem     Type      Size  Used Avail Use% Mounted on 
  3. devtmpfs       devtmpfs   32G     0   32G   0% /dev 
  4. tmpfs          tmpfs      32G     0   32G   0% /dev/shm 
  5. tmpfs          tmpfs      32G  5.9M   32G   1% /run 
  6. tmpfs          tmpfs      32G     0   32G   0% /sys/fs/cgroup 
  7. /dev/vda1      ext4       50G  7.9G   39G  17% / 
  8. /dev/vdb1      xfs       200G  138G   63G  69% /data 
  9. tmpfs          tmpfs     6.3G     0  6.3G   0% /run/user/0 

發現還有69%的磁盤空間，似乎也沒有什么問題啊，應該磁盤空間也還很充足的。

iostat命令查看磁盤IO

  1. [root@node2-pre-ayunw.cn ~]# iostat -xk 1 3 
  2. Linux 5.10.8-1.el8.elrepo.x86_64 (node2-pre-ayunw.cn)  08/31/2021  _x86_64_ (32 CPU) 
  3.  
  4. avg-cpu:  %user   %nice %system %iowait  %steal   %idle 
  5.            1.86    0.00    1.77    0.03    0.00   96.34 
  6.  
  7. Device            r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util 
  8. vda              0.02    2.77      0.40     22.43     0.00     2.14   4.57  43.58    1.51    0.75   0.00    24.11     8.09   0.38   0.11 
  9. vdb              0.08  126.81      3.31    519.35     0.00     0.54   0.31   0.43    3.20    0.56   0.07    40.29     4.10   0.47   6.01 
  10.  
  11. avg-cpu:  %user   %nice %system %iowait  %steal   %idle 
  12.            3.09    0.00    3.34    0.03    0.00   93.54 
  13.  
  14. Device            r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util 
  15. vda              0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00 
  16. vdb              0.00   51.00      0.00    168.50     0.00     0.00   0.00   0.00    0.00    0.45   0.02     0.00     3.30   0.55   2.80 
  17.  
  18. avg-cpu:  %user   %nice %system %iowait  %steal   %idle 
  19.            2.74    0.00    2.81    0.00    0.00   94.45 
  20.  
  21. Device            r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util 
  22. vda              0.00    3.00      0.00     40.00     0.00     7.00   0.00  70.00    0.00    0.67   0.00     0.00    13.33   1.00   0.30 
  23. vdb              0.00   62.00      0.00    619.50     0.00     7.00   0.00  10.14    0.00    0.58   0.04     0.00     9.99   0.50   3.10 

目前似乎也看不到有什么IO壓力 。但是由于我手上沒有監控權限，估計也是直接就沒有對pod做監控。然后describe的時候看到問題發生也是7個小時之前的事情了，所以的話這邊猜測可能是當時已經觸發了kubelet的eviction-hard，然后磁盤已經有部分空間被回收了，而且壓力可能也已經下去了。

查看node上的日志

查看節點上kubelet日志和message日志，并沒有任何Evicted的日志被發現。

  1. $ tail -500 kubelet.log  | grep "Evicted" 
  2. $ tail -500 /var/log/messages  | grep "Evicted" 

那當前情況下就只能臨時先處理掉這個Evicted狀態的pod了

  1. $ kubectl get po -n nsop  --field-selector 'status.phase!=Running' -o json| kubectl delete -f - 

因為是磁盤空間的問題，所以想到去檢查一下是否有持續增長的目錄。最后排查發現，所有出現Evicted狀態的pod所處的節點似乎都有一個共性：那就是都啟用了skywalking，并且以emptyDir的形式寫日志到本地臨時存儲中。

目前公司將默認的docker目錄和kubelet目錄都改到了/data目錄下，上pod所在的node，到/data/目錄下通過du -sh ./* | grep G命令去查看了一下有好多/data/kubernetes/kubelet/pods/xxx/volumes/kubernetes.io~empty-dir/vol-apm-empty/logs的目錄下存在skywalking-api.log的日志，而且都是輪轉的日志，默認沒有設置日志保留時間。

skywalking-agent的配置文件中默認開啟了以下幾個參數：

  1. $ egrep -v "^$|^#" agent.config 
  2. agent.service_name=${SW_AGENT_NAME:Your_ApplicationName} 
  3. collector.backend_service=${SW_AGENT_COLLECTOR_BACKEND_SERVICES:127.0.0.1:11800} 
  4. logging.file_name=${SW_LOGGING_FILE_NAME:skywalking-api.log} 
  5. logging.level=${SW_LOGGING_LEVEL:INFO} 
  6. plugin.mount=${SW_MOUNT_FOLDERS:plugins,activations} 

skywalking-agent在emptyDir下的日志

  1. [root@node2-pre-ayunw.cn vol-apm-empty]# cd logs/ 
  2. [root@node2-pre-ayunw.cn logs]# ll 
  3. total 4327672 
  4. -rw-r--r-- 1 root root 260328481 Aug 31 09:43 skywalking-api.log 
  5. -rw-r--r-- 1 root root 314573222 Aug 12 02:56 skywalking-api.log.2021_08_12_02_56_35 
  6. -rw-r--r-- 1 root root 314573394 Aug 13 15:01 skywalking-api.log.2021_08_13_15_01_56 
  7. -rw-r--r-- 1 root root 314574277 Aug 15 03:12 skywalking-api.log.2021_08_15_03_12_26 
  8. -rw-r--r-- 1 root root 314574161 Aug 16 15:21 skywalking-api.log.2021_08_16_15_21_13 
  9. -rw-r--r-- 1 root root 314574334 Aug 18 03:31 skywalking-api.log.2021_08_18_03_31_18 
  10. -rw-r--r-- 1 root root 314572887 Aug 19 15:40 skywalking-api.log.2021_08_19_15_40_22 
  11. -rw-r--r-- 1 root root 314574238 Aug 21 03:44 skywalking-api.log.2021_08_21_03_44_28 
  12. -rw-r--r-- 1 root root 314574144 Aug 22 15:49 skywalking-api.log.2021_08_22_15_49_08 
  13. -rw-r--r-- 1 root root 314573963 Aug 24 03:51 skywalking-api.log.2021_08_24_03_51_28 
  14. -rw-r--r-- 1 root root 314572991 Aug 25 15:54 skywalking-api.log.2021_08_25_15_54_21 
  15. -rw-r--r-- 1 root root 314573321 Aug 27 03:57 skywalking-api.log.2021_08_27_03_57_11 
  16. -rw-r--r-- 1 root root 314572890 Aug 28 16:01 skywalking-api.log.2021_08_28_16_01_26 
  17. -rw-r--r-- 1 root root 314573311 Aug 30 04:05 skywalking-api.log.2021_08_30_04_05_34 

我的docker根目錄被更改過，不是默認的/var/lib/docker，而是/data/docker。我的k8s的kubelet目錄也是被更改過的，在/data/kubernetes/kubelet。

臨時解決日志爆滿的兩種方法

  • 在K8s-master節點查看Evicted的pod調度在哪個節點，然后到/data/kubernetes/kubelet/pods目錄下去通過du -sh 命令找到目錄占用量大的pod，然后將截圖指出的輪轉后(就是帶上時間2021_08_17這一類)的日志文件刪除
  • 直接重新刪除pod，其實只要是pod重啟后，EmptyDir目錄就會被刪除掉。

操作步驟

  1. $ cd /data/kubernetes/kubelet/pods 
  2.  
  3. $ du -sh ./* | grep G 
  4. 1.3G ./02c9511d-0787-49f1-8c59-0db239baee79 
  5. 1.3G ./079f3ca0-810d-468d-9136-75f3d3235b2d 
  6. 4.8G ./07fc67f7-d46d-4d0c-8f6c-401e14705ae1 
  7. 3.0G ./091594a0-b5ac-45c2-8ad9-7dcfc91c9e55 
  8. 1.8G ./130a1b35-b447-43e1-8802-eb74aefa566c 
  9. 1.2G ./1b257c27-cbaf-49f8-bca3-ceadc467aad6 
  10. 2.8G ./2ec50216-f81e-4e83-922d-14316762dee2 
  11. 7.0G ./321baae6-1efe-4535-8a20-0fdfa6cc3117 
  12. 8.0G ./46680114-11f7-47af-9ee2-347f56592924 
  13. ... 

我這里找到了占用7.0G大小的pod，根據目錄名稱找到pod名字，然后觸發了這個pod的cicd,也就相當于更新了這個pod的deployment.yaml，然后apply -f重新生成了一遍這個pod

  1. $ docker ps -a | grep "321baae6-1efe-4535-8a20-0fdfa6cc3117" 
  2. a69b2635ba98        registry.ayunw.cn/tsp/msmessagecenter                     "/startApp.sh"           5 weeks ago          Up 5 weeks                                          k8s_msmessagecenter-perf-dev-v1-0-0_msmessagecenter-perf-dev-v1-0-0-7f746b84bf-wb4g5_tsp_321baae6-1efe-4535-8a20-0fdfa6cc3117_0 
  3. c8f2cc0a2737        874552b27b34                                                        "sh -c 'set -ex;mkdi…"   5 weeks ago          Exited (0) 5 weeks ago                              k8s_init-skywalking-agent_msmessagecenter-perf-dev-v1-0-0-7f746b84bf-wb4g5_tsp_321baae6-1efe-4535-8a20-0fdfa6cc3117_0 
  4. c415f52e7489        registry.ayunw.cn/library/k8s.gcr.io/pause:3.2            "/pause"                 5 weeks ago          Up 5 weeks                                          k8s_POD_msmessagecenter-perf-dev-v1-0-0-7f746b84bf-wb4g5_tsp_321baae6-1efe-4535-8a20-0fdfa6cc3117_0 

等pod被完全刪除后查看這個目錄已經消失

  1. $ du -sh ./* | grep G 
  2. 1.3G ./02c9511d-0787-49f1-8c59-0db239baee79 
  3. 1.3G ./079f3ca0-810d-468d-9136-75f3d3235b2d 
  4. 4.8G ./07fc67f7-d46d-4d0c-8f6c-401e14705ae1 
  5. 3.0G ./091594a0-b5ac-45c2-8ad9-7dcfc91c9e55 
  6. 1.8G ./130a1b35-b447-43e1-8802-eb74aefa566c 
  7. 1.2G ./1b257c27-cbaf-49f8-bca3-ceadc467aad6 
  8. 2.8G ./2ec50216-f81e-4e83-922d-14316762dee2 
  9. 8.0G ./46680114-11f7-47af-9ee2-347f56592924 
  10. ... 

永久解決日志保留個數方法

  • 直接在Dockerfile打鏡像的時候更改參數或者提前寫好配置文件然后構建鏡像的時候COPY進去

我這里直接改好agent.config參數然后Dockerfile中COPY進去了

  1. $ cat Dockerfile 
  2. FROM registry.ayunw.cn/library/alpine:3.12.0 
  3. ENV LANG=C.UTF-8 \ 
  4.     SKYWLKING_AGENT_VERSION=8.6.0 
  5. RUN set -eux && mkdir -p /opt/skywalking/agent \ 
  6.     && apk add wget \ 
  7.     && wget https://downloads.apache.org/skywalking/${SKYWLKING_AGENT_VERSION}/apache-skywalking-apm-es7-${SKYWLKING_AGENT_VERSION}.tar.gz -P /tmp/ \ 
  8.     && cd /tmp && tar zxf apache-skywalking-apm-es7-${SKYWLKING_AGENT_VERSION}.tar.gz \ 
  9.     && mv /tmp/apache-skywalking-apm-bin-es7/agent/* /opt/skywalking/agent \ 
  10.     && rm -f /opt/skywalking/agent/optional-plugins/apm-spring-annotation-plugin-8.6.0.jar /opt/skywalking/agent/plugins/thrift-plugin-8.6.0.jar \ 
  11.     && mv /opt/skywalking/agent/plugins/thrift-plugin-8.6.0.jar /tmp/thrift-plugin-8.6.0.jar \ 
  12.     && cp -r /opt/skywalking/agent/optional-plugins/* /opt/skywalking/agent/plugins/ \ 
  13.     && unset export \ 
  14.     && rm -rf /tmp/* /opt/skywalking/agent/config/agent.config 
  15.  
  16. COPY agent.config /opt/skywalking/agent/config/ 
  17.  
  18. WORKDIR / 
  1. $ egrep -v "^$|^#" agent.config 
  2. agent.service_name=${SW_AGENT_NAME:Your_ApplicationName} 
  3. collector.backend_service=${SW_AGENT_COLLECTOR_BACKEND_SERVICES:127.0.0.1:11800} 
  4. logging.file_name=${SW_LOGGING_FILE_NAME:skywalking-api.log} 
  5. logging.level=${SW_LOGGING_LEVEL:INFO} 
  6. plugin.mount=${SW_MOUNT_FOLDERS:plugins,activations} 
  7. # 以下參數是我更改后的，表示日志保留個數為3個 
  8. logging.max_history_files=${SW_LOGGING_MAX_HISTORY_FILES:3} 

其實agent.config文件中是有logging.max_history_files=${SW_LOGGING_MAX_HISTORY_FILES:-1}這一行的，但是默認被注釋掉了。我這里將它打開，然后將-1改成了3。這行配置是JAVA中的寫法，意思是默認是-1表示"最大歷史日志文件保留個數"，而-1則表示不設置最大歷史日志文件保留，也就是一直輪轉，不會做日志清理。參數意思可以參考skywalking官網。

然后重新構建這個skywalking-agent鏡像，在deployment中引用即可。

  1. $ cat deployment.yaml 
  2. apiVersion: apps/v1 
  3. kind: Deployment 
  4. ... 
  5.       dnsPolicy: ClusterFirst 
  6.       terminationGracePeriodSeconds: 10 
  7.       serviceAccountName: default 
  8.       imagePullSecrets: 
  9.         - name: registry-auth-ayunw-cn 
  10.       initContainers: 
  11.         - name: init-skywalking-agent 
  12.           image: "registry.ayunw.cn/library/skywalking-agent:33-ac402d20" 
  13.           command: 
  14.             - 'sh' 
  15.             - '-c' 
  16.             - 'set -ex;mkdir -p /skywalking/agent;cp -r /opt/skywalking/agent/* /skywalking/agent;' 
  17.           volumeMounts: 
  18.             - name: vol-apm-empty 
  19.               mountPath: /skywalking/agent 
  20.       containers: 
  21.         - name: demo-hello-pre-master 
  22.           image: "registry.ayunw.cn/paas/demo-hello:537-c87b6177" 
  23.           ... 
  24.           volumeMounts: 
  25.             - name: vol-apm-empty 
  26.               mountPath: /skywalking/agent 
  27.       volumes: 
  28.         - name: vol-apm-empty 
  29.           emptyDir: {} 

其實這里的磁盤DiskPressure目前只能大概排查到skywalking導致，但沒有監控的情況下并不能百分百確認就是skywalking引起，因此如果需要更精準的定位這個問題，還需要通過監控等手段去排查。如果各位有更好的解決Evicted狀態的pod這種問題的方法，也歡迎后臺回復，一起交流。

本文轉載自微信公眾號「運維開發故事」

【編輯推薦】

 

責任編輯：姜華 來源： 運維開發故事
pod EvictedKubernetes
相關推薦

2018-08-15 09:26:56

2016-11-01 15:16:52

QQ狀態即時通訊

2019-04-26 13:55:02

Istio微服務架構

2019-06-04 14:15:08

JavaScript V8前端

2019-07-22 15:29:53

JavaScriptGitHub語言

2011-02-16 16:13:40

Debian

2020-12-22 21:24:45

在線狀態服務端狀態狀態同步

2011-02-28 09:51:43

內省

2018-07-05 16:15:26

緩存數據cache miss

2010-08-24 09:19:59

2020-06-11 09:18:34

動靜分離架構架構設計開發

2011-08-04 13:24:28

IT運維

2021-02-19 20:38:01

互聯網衛星系統

2012-05-28 22:49:50

PureView

2022-06-13 09:51:35

UWB超寬帶無線載波通信技術

2023-12-26 01:24:45

Jedis連接池參數

2019-05-27 15:30:44

Node.jsJavaScript前端

2015-09-29 09:47:14

2018-09-10 13:47:21

數據科學統計學決策

2016-06-17 12:31:10

Spark SQL數據處理Spark
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板： 9porny九色视频自拍 | 亚洲国产一区二区在线 | 综合网在线| 日韩三级免费观看 | 久久r久久 | 成人av高清在线观看 | 国产欧美日韩在线一区 | 欧美精品成人一区二区三区四区 | 蜜桃视频一区二区三区 | 久久久久久久夜 | 国产精品久久久久久久久久妞妞 | 精品欧美乱码久久久久久1区2区 | 国产福利91精品 | 亚洲高清在线播放 | 精品在线一区 | 狠狠干狠狠插 | 欧美综合国产精品久久丁香 | 91久久 | 国产精品成人一区二区三区 | 不卡一二三区 | 成人h动漫亚洲一区二区 | 欧美一区二区三区在线播放 | 成人在线精品 | 天天爽夜夜爽精品视频婷婷 | 国产成人福利视频在线观看 | wwww.xxxx免费| 国产片网站| 大象视频一区二区 | 国产高清视频一区二区 | 亚洲国产激情 | 日韩视频一区二区三区 | 精品成人av| 国产在线一区二区三区 | 凹凸日日摸日日碰夜夜 | 日韩一区二区三区精品 | 99亚洲精品| 四虎影院在线观看免费视频 | 在线亚洲欧美 | 日韩在线免费 | 久久久噜噜噜久久中文字幕色伊伊 | 中文字幕亚洲视频 |