优雅停止（Graceful Shutdown）与 502/504 报错
优雅退出，业务侧需要做的任务是处理SIGTERM信号 如果 Pod 正在处理大量请求（比如 1000 QPS+）时，因为节点故障或「竞价节点」被回收等原因被重新调度，可能会观察到在容器被 terminate 的一段时间内出现少量 502/504。 为了搞清楚这个问题，需要先理解清楚 terminate 一个 Pod 的流程： 123451、Pod 被删除，状态置为 Terminating。kube-proxy 更新转发规则，将 Pod 从 service 的 endpoint 列表中摘除掉，新的流量不再转发到该 Pod。2、如果 Pod 配置了 preStop Hook ，将会执行。3、kubelet 对 Pod 中各个 container 发送 SIGTERM 信号以通知容器进程开始优雅停止。4、等待容器进程完全停止，如果在 terminationGracePeriodSeconds 内 (默认 30s) 还未完全停止，就发送 SIGKILL 信号强制杀死进程。5、所有容器进程终止，清理 Pod 资源。 注意：1和2 两个工作是异步发生的，所以在未设置 preSt...
关于 DNS 解析的一些认识
Kubernetes 中的 DNS在 Kubernetes 中，服务发现有几种方式：①：基于环境变量的方式②：基于内部域名的方式 基本上，使用环境变量的方式很少，主要还是使用内部域名这种服务发现的方式。 其中，基于内部域名的方式，涉及到 Kubernetes 内部域名的解析，而 kubedns，是 Kubernetes 官方的 DNS 解析组件。从 1.11 版本开始，kubeadm 已经使用第三方的 CoreDNS 替换官方的 kubedns 作为 Kubernetes 集群的内部域名解析组件，我们的重点，是 CoreDNS，但是在开始 CoreDNS 之前，需要先了解下 kubedns Kubernetes 中的域名是如何解析的在 Kubernetes 中，比如服务 a 访问服务 b，对于同一个 Namespace下，可以直接在 pod 中，通过 curl b 来访问。对于跨 Namespace 的情况，服务名后边对应 Namespace即可。比如 curl b.default。那么，使用者这里边会有几个问题： ①：服务名是什么？②：为什么同一个 Namespace 下，直...
Kubernetes 内存限制深度解析：cgroup 与 OOM Killer 实战
概述Kubernetes 通过 Linux cgroup（Control Groups）机制实现容器的资源隔离和限制。本文通过实验深入探索容器内存限制的工作原理，以及在何种情况下容器会被 OOM Killer 杀死。 核心内容： 🔍 cgroup 内存限制机制 ⚡ OOM Killer 工作原理 🧪 压力测试与故障模拟 📊 oom_score 计算方法 技术背景： cgroup 是容器资源控制的基础 具有层级结构，可继承父级属性 Kubernetes 基于 cgroup 实现 Pod 的资源限制 原文来源： https://cloud.tencent.com/developer/article/1495508 扩展阅读： 深入理解 Kubernetes 资源限制：内存 cgroup 基础知识什么是 cgroup定义： cgroup（Control Groups）是 Linux 内核提供的一种机制，用于限制、记录和隔离进程组使用的物理资源（CPU、内存、I/O 等）。 核心特性： 📊 资源限制：限制进程组使用的资源上限 📈 优先级控制：控制进程组的 C...
关于 K8s 的资源分配与限制
相关概念引自kubesphere - requests与limits 简介为了实现 K8s 集群中资源的有效调度和充分利用， K8s 采用requests和limits两种限制类型来对资源进行容器粒度的分配。每一个容器都可以独立地设定相应的requests和limits。这 2 个参数是通过每个容器 containerSpec 的 resources 字段进行设置的。一般来说，在调度的时候requests比较重要，在运行时limits比较重要。 一些本地临时存储的配置 **注: ** 当容器申请内存超过limits时会被oomkill，并根据重启策略进行重启。而cpu超过limit则是限流，但不会被kill 由于CPU资源是可压缩的，进程无论如何也不可能突破上限，因此设置起来比较容易。对于Memory这种不可压缩资源来说，它的Limit设置就是一个问题了，如果设置得小了，当进程在业务繁忙期试图请求超过Limit限制的Memory时，此进程就会被Kubernetes杀掉 1234567891011121314# requests: 可以使用requests来设置各容器需...
Kubernetes 资源监控脚本：定时检测并企业微信告警
概述本文介绍一个轻量级的 Kubernetes 资源监控脚本，定期检测节点和 Pod 的 CPU、内存使用情况，超过阈值时通过企业微信 Webhook 发送告警通知。 核心功能： 🔍 节点资源监控（CPU/内存） 📦 Pod 资源监控（CPU/内存） 📢 企业微信告警推送 ⚙️ 阈值可配置 🔄 定时任务执行 适用场景： 轻量级资源监控 快速告警通知 开发测试环境 补充监控方案 脚本完整代码1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101111121131141151161171181191201211221231241251261271281291301...
定时自动重启 Pod 服务
方法1：滚动重启从 1.15 版开始，Kubernetes 允许滚动重启 Deployment，这是最快的重启方式： 1kubectl rollout restart deployment [deployment_name] 该命令会逐步关闭并重启 Deployment 中的每个 Pod 容器，重启过程中应用仍然可用，因为大多数容器仍在运行。 方法2：使用环境变量通过设置或更改环境变量，可以强制 Pod 重新启动并同步变更。例如，更改容器部署日期： 1kubectl set env deployment [deployment_name] DEPLOY_DATE="$(date)" 方法3：缩放副本数使用 scale 命令将副本数设置为 0 来关闭容器： 1kubectl scale deployment [deployment_name] --replicas=0 再将副本数恢复为大于零的值来重新启动： 1kubectl scale deployment [deployment_name] --replicas=1 Kubernetes 会销...
Kubernetes IP 地址完全指南：类型、范围与固定 IP 配置
概述Kubernetes 集群中存在多种类型的 IP 地址，包括 Cluster IP、Pod IP、Node IP 等。理解这些 IP 的作用范围和配置方法对于网络规划至关重要。 核心内容： 🌐 Kubernetes 各类 IP 地址详解 📋 IP 地址范围配置 🔒 固定 IP 地址实现方案 ⚙️ K8s/K3s 配置差异 Kubernetes IP 地址类型Cluster IP（服务 IP）定义： Service 的虚拟 IP 地址，用于集群内部服务访问 特点： 特性 说明 作用范围 仅集群内部可访问 生命周期 与 Service 绑定（除非删除 Service） DNS 解析 通过 Service Name 自动解析 负载均衡 自动分发流量到后端 Pod 工作机制： 1Client → Service Name → kube-dns 解析 → Cluster IP → kube-proxy → Pod 示例： 123456789101112apiVersion: v1kind: Servicemetadata: name:...
根据 PID 查找 Pod 信息
编辑 ~/.bashrc，粘贴以下函数，并执行 source ~/.bashrc 使其生效，使用时执行 podinfo $pid通过 PID 获取 Pod 名称12345podinfo() { CID=$(cat /proc/$1/cgroup | awk -F '/' '{print $5}') CID=$(echo ${CID:0:8}) crictl inspect -o go-template --template='{{index .status.labels "io.kubernetes.pod.name"}}' $CID} 通过 PID 获取 Pod UID123podUid() { cat /proc/$1/mountinfo | grep "etc-hosts" | awk -F / {'print $6'}...
最大最小内存设置为一致
在 Kubernetes 中，像 CPU 这样的资源被称作"可压缩资源"（compressible resources）。它的典型特点是，当可压缩资源不足时，Pod 只会"饥饿"，但不会退出。而像内存这样的资源，则被称作"不可压缩资源"（incompressible resources）。当不可压缩资源不足时，Pod 就会因为 OOM（Out-Of-Memory）被内核杀掉。 1. 容器最小内存和最大内存设置为一致简单来理解：最小内存等同于 k8s 的 resources.requests 资源，最大内存等同于 resources.limits 资源。参考：为容器和 Pod 分配内存资源 | Kubernetes 上述配置中，查看对应的 YAML 文件可以看到，对应的 memory 的请求和限制保持一致。 一般情况下，对于核心资源，我们推荐 requests == limits，这是为什么呢？ Pod 的三种 QoS 类别 Guaranteed：当 Pod 里的每一个 Container 都同时设置了 request...
滚动更新控制副本数
在 Kubernetes 中，Deployment 提供了两种更新策略： Recreate：适用于停机发布，设置 spec.strategy.type=Recreate，表示 Deployment 在更新 Pod 时，会先杀掉所有正在运行的 Pod，再创建新的 Pod RollingUpdate：适用于零停机发布，设置 spec.strategy.type=RollingUpdate，表示 Deployment 会以滚动更新的方式逐个更新 Pod 滚动更新控制参数服务在滚动更新时，Deployment 控制器的目的是：将旧版本（old_rs）副本数减少至 0、将新版本（new_rs）副本数量增至期望值（replicas）。Kubernetes 提供了以下两个参数： maxUnavailable：和期望 ready 的副本数相比，不可用副本数的最大比例（或最大值），这个值越小，越能保证服务稳定，更新越平滑 maxSurge：和期望 ready 的副本数相比，超过期望副本数的最大比例（或最大值），这个值调得越大，副本更新速度越快 取值范围数值（两者不能同时为 0） maxUn...
公告