找出占用Kubernetes节点磁盘的Pod

发表于2023-10-24|更新于2024-10-31|容器

|浏览量:

有部分开发不规范导致日志写入容器, 在 k8s 环境下导致节点磁盘空间占用过高, 解决方案有:

通过监控告警来提前预防
挂载磁盘, 容器日志写入磁盘
使用自动清理脚本

kubectl 查询每个 pod 占用磁盘空间

kubectl get --raw /api/v1/nodes/10.20.20.12/proxy/stats/summary | jq '.pods[] | "PodName:  \(.podRef.name)", "usedBytes:   \(.containers[].rootfs.usedBytes)", "======================================================"'

输出结果如图:

Docker 相关操作

查看容器磁盘占用

# 节点上查看磁盘使用情况,并安装从大到小排序,可以看到各个容器的占用磁盘空间。
docker ps -a --format "table {{.Size}}\t{{.Names}}" | sort -hr

# 查看磁盘总体使用情况
docker system df

文章作者: 张理坤

文章链接: https://zahui.fan/posts/lo47lj11/

版权声明: 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源杂烩饭！

相关推荐

Java程序被停止前自动dump内存快照

线上业务偶尔会出现重启现象，为了排查这个问题，决定在 OOM 的时候自动进行 dump 内存快照用于分析针对 JVM OOM 的情况OOM 全称 “Out Of Memory”，表示内存耗尽。当 JVM 因为没有足够的内存来为对象分配空间，并且垃圾回收器也已经没有空间可回收时，就会抛出这个错误，解决 OOM 问题的一个思路: 假设发生 OOM 了，必然说明系统中某个区域的对象太多了，塞满了那个区域，而且一定是无法回收掉那些对象，最终才会导致内存溢出的，首先就得知道到底是什么对象太多了导致 OOM ，就必须得有一份 JVM 发生 OOM 时的 dump 内存快照有了 dump 内存快照，就可以用 MAT 之类的工具，或者在线工具来分析：https://memory.console.heapdump.cn/JVM 在发生 OOM 的时候并不是直接挂掉的，而是在 OOM 之前会尽量去 GC 腾出来一些内存空间，如果 GC 后还是没有空间，放不下对象，才会触发内存溢出的。JVM 给我们提供了一些参数可以在发生 OOM 的时候进行自动 dump 内存快照。：...

Kubernetes之master高可用方案

之前一直用使用的负载方案是搭建一台负载均衡器，可以是 haproxy 或 nginx 或 lvs，来将多个 master 节点的 6443 端口做个负载均衡，但是考虑到负载均衡也需要高可用，所以会引入类似 keepalived 的方案来解决问题。偶然看到了 kubeasz 这个开源项目，宣称解决了 master 高可用问题，部署了一遍发现并没有额外搭建负载均衡器，研究了一下，发现了另一种思路。使用额外的负载均衡来做高可用这种就是比较容易想到的一种方案，比如 3 个 master 节点，前面有一台负载均衡（nginx、haproxy、lvs）等，但是负载均衡本身就是一个单点故障，所以一般来说还需要另一台负载均衡，通过 keepalived 来实现 VIP 的切换使用Keepalived来实现Nginx高可用使用Nginx做负载均衡使用HAproxy做负载均衡使用LVS做负载均衡vim nginx.conf 在文件最后添加 123stream { include stream.conf;} 然后 vim...

Kubernetes同一个namespace共用镜像secret

配置一个全局的镜像拉取密钥，后续拉镜像就不用每个 deployment 单独配置了。在每个 namespace 下都有一个默认的 service account, 假设命名空间是 test 使用 kubectl get sa -n test 查看查看 serviceaccount 信息 1kubectl describe sa -n test Image pull secrets 是此 namespace 下拉取镜像的秘钥 1.创建 secret 1kubectl create secret -p docker-registry registrykey --namespace=test --docker-username=<harbor_user> --docker-password=<harbor_password> --docker-server=<harbor_url> 2.配置进 service account 1kubectl patch serviceaccount default -p...

Kubernetes的3中探针readinessProbe、livenessProbe和startupProbe

探针K8S 提供了 3 种探针 startupProbe 启动检查（1.16 版本新增）livenessProbe 存活检查readinessProbe 就绪检查 startupProbekubernetes 1.16 版本新增功能，用于判断容器内应用程序是否已经启动，如果配置了 startuprobe，就会先禁用其他的探测，直到它成功为止，成功后将不再进行探测。 1234567891011startupProbe: # 健康检查方式：[readinessProbe,livenessProbe,StartupProbe] failureThreshold: 3 # 检测失败3次表示未就绪 httpGet: # 请求方式 path: /health # 请求路径 port: 8080 # 请求端口 scheme: HTTP # 请求协议 ...

k8s解除service端口限制

我自己写了一个 svc 的 yaml 文件，部署的时候报错，不在默认的范围内，默认范围是: 30000-32767 kubectl apply -f nginx-src.yaml 报错: 1The Service "nginx" is invalid: spec.ports[0].nodePort: Invalid value: 80: provided port is not in the valid range. The range of valid ports is 30000-32767 如果是 kubeadm 部署修改配置文件 vim /etc/kubernetes/manifests/kube-apiserver.yaml 在启动参数里面添加如下一行 1- --service-node-port-range=1-65535 重启 kube-apiserver 1kubectl delete pod -n kube-system kube-apiserver-xxx

Kubernetes回滚应用之kubectl rollout

kubernetes 每次更新资源会记录资源的历史版本，方便我们进行回滚操作。真的 k8s 解决了很多运维的痛点问题, 想起来以前没有用 k8s 的时候,用 jenkins 和 ansible 来做的发布和回滚… 查看历史版本12345678kubectl rollout history deployment nfs-client-provisionerdeployment.apps/nfs-client-provisionerREVISION CHANGE-CAUSE1 <none>2 <none>4 <none>5 <none> 这里列出的就是版本，为什么没有 3，因为从版本 4 回滚到了版本 3，则版本 3 就变成了版本 5 查看指定版本详情1kubectl rollout history deployment nfs-client-provisioner --revision=4 回滚到指定版本1kubectl rollout undo...

评论

数据加载中