K8S Pod 磁盘治理方案#
背景:关于开发程序在Pod内自定义目录打满磁盘,直接影响到线上环境稳定性,增加运维同志处理磁盘告警的负担。特推出以下方案
灾难案例: 一个服务在在pod内疯狂打日志,输出一小时内输出155G+日志量,直接造成了线上服务因磁盘压力被驱逐
解决方案:#
为每个pod设置默认的可以使用的最大临时卷磁盘大小 limits ephemeral-storage
方案可行性验证:#
目前针对公司环境来说,采取了hostPath 和localPV的方式进行了数据持久化处理,因此对这两种场景进行验证测试
hostPath验证测试#
对容器进行如下配置
volumeMounts:
- name: mydata
mountPath: /opt #容器内挂载目录
resources:
requests:
cpu: 10m
memory: 10Mi
limits:
cpu: 20m
memory: 30Mi
ephemeral-storage: 20Mi
volumes:
- name: mydata
hostPath:
path: /home/work/nginx/logs #主机挂载目录 提前创建好目录
验证测试:
1.进入容器在容器挂载目录/opt 内用 dd if=/dev/zero of=file bs=1M count=20000 测试写一个20G大小的文件
结果:可写入响应大小的文件
2.进入容器在非容器挂载目录/home内用 dd if=/dev/zero of=file bs=1M count=20000 测试写一个20G大小的文件
结果: 超出20Mi 容器立刻被驱逐重启
LocalPV验证测试#
创建一个localPV
apiVersion: v1
kind: PersistentVolume
metadata:
finalizers:
- kubernetes.io/pv-protection
labels:
app: disktest
name: disktest
spec:
accessModes:
- ReadWriteOnce
capacity:
storage: 30Gi
local:
path: /home/.k8s-local-volumes/disktest #提前创建目录
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- 要存储数据的节点 ip #改为自身节点IP
persistentVolumeReclaimPolicy: Retain
storageClassName: local-storage
volumeMode: Filesystem
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mypvc
spec:
storageClassName: local-storage
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 3Gi
创建一个Pod并挂载本地LocalPV
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx
spec:
replicas: 1
selector:
matchLabels:
run: my-nginx
template:
metadata:
labels:
run: my-nginx
spec:
containers:
- name: my-nginx
image: 'nginx:1.18.0'
ports:
- containerPort: 80
volumeMounts:
- name: myhostpath
mountPath: /opt
- name: mypvc
mountPath: /data
resources:
requests:
cpu: 10m
memory: 10Mi
limits:
cpu: 20m
memory: 30Mi
ephemeral-storage: 20Mi
volumes:
- name: myhostpath
hostPath:
path: /home/work/nginx/logs
- name: mypvc
persistentVolumeClaim:
claimName: mypvc
验证测试过程与上面的类似【待验证】
- 先在持久化数据目录写大于20Mi数据测试 => 正常写入
- 非持久化数据目录写大于20Mi数据测试 => Pod被驱逐
整体测试结果截图
优点#
可有效控制开发人员打印日志不规范的问题,养成好的习惯,做到有用数据持久化,无用数据减少输出或不输出
缺点#
如果限制阈值太小,服务会频繁被驱逐。导致服务可能频繁中断或不可用,