优雅停止(Gracful 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 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:...
Kubernetes 资源监控脚本:定时检测并企业微信告警
概述本文介绍一个轻量级的 Kubernetes 资源监控脚本,定期检测节点和 Pod 的 CPU、内存使用情况,超过阈值时通过企业微信 Webhook 发送告警通知。 核心功能: 🔍 节点资源监控(CPU/内存) 📦 Pod 资源监控(CPU/内存) 📢 企业微信告警推送 ⚙️ 阈值可配置 🔄 定时任务执行 适用场景: 轻量级资源监控 快速告警通知 开发测试环境 补充监控方案 脚本完整代码1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101111121131141151161171181191201211221231241251261271281291301...
定时自动重启Pod服务
方法1:滚动重启从1.15版开始,Kubernetes允许您滚动重启部署。作为Kubernetes的新增功能,这是最快的重启方法。 kubectl rollout restart deployment [deployment_name] 上面提到的命令将逐步执行关闭操作,并重新启动deployment中的每个pod容器。在重启过程中应用仍然可用,因为大多数容器仍在运行。 方法2:使用环境变量另一种方法是设置或更改环境变量,以强制Pod重新启动并与您所做的更改同步。 例如,可以更改容器部署日期: kubectl set env deployment [deployment_name] DEPLOY_DATE="$(date)" 在上面的示例中,该命令**set env设置环境变量的更改,deployment [deployment_name]选择您的部署,并DEPLOY_DATE="$(date)"**更改部署日期。 方法3:缩放副本数我们可以使用该**scale**命令来更改deployment的副本数。将此数量设置为0实际上会关闭...
最大最小内存设置为一致
在 Kubernetes 中,像 CPU 这样的资源被称作“可压缩资源”(compressible resources)。它的典型特点是,当可压缩资源不足时,Pod 只会“饥饿”,但不会退出。而像内存这样的资源,则被称作“不可压缩资源(incompressible resources)。当不可压缩资源不足时,Pod 就会因为 OOM(Out-Of-Memory)被内核杀掉。 1.容器最小内存和最大内存设置为一致简单来理解:最小内存等同于k8s的resources:requests资源,最大内存等同于resources:limits资源。参考:为容器和 Pod 分配内存资源 | Kubernetes 刚才的配置,我们查看对应yml文件可以看到,对应的memory的请求和限制保持一致。 一般情况下,对于核心资源,我们推荐 requests == limits,这个是为什么呢? 这里涉及pod的三种模式: Guaranteed 类别:当 Pod 里的每一个 Container 都同时设置了 requests 和 limits,并且 requests 和 l...
查看pod是否正常打印日志
查看pod是否正常打印日志,并发送webhook到企微 12345678910111213141516171819202122232425262728293031323334#!/bin/sh# 获取当前UTC时间utc_now=`date -u`# 将时间转换为timestamptimestamp_now=`date -d "$utc_now" +%s`PODNAME=NAMASPACE=function restart_pod() { for i in `kubectl get pod -n iot|grep $PODNAME|awk '{print $1}'`;do for time in `kubectl logs --tail=1 --timestamps $i -n $NAMASPACE | awk '{print $1}'`;do timestamp_pod=`date -d "$time" +%s` d...
根据pid查找到pod的一些信息
编辑~/.bashrc, 粘贴以下函数,并执行source ~/.bashrc使其生效, 使用的时候执行函数podinfo $pid通过pid 获取pod name12345podinfo() { 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 id123podUid() { cat /proc/$1/mountinfo | grep "etc-hosts" | awk -F / {'print $6'}&...
