kube-proxy
四层与七层1、四层负载均衡(例如nginx中直接配置stream,如下)1234567891011stream { upstream k3s { least_conn; server 10.0.2.0:6443 max_fails=3 fail_timeout=5s; server 10.0.2.6:6443 max_fails=3 fail_timeout=5s; } server { listen 6443; proxy_pass k3s; }} 0、负载均衡器用 ip+port 接收请求,再直接转发到后端对应服务上 1、四层负载均衡仅能转发TCP/IP协议、UDP协议、通常用来转发端口,如:tcp/22、udp/53; 2、四层负载均衡可以用来解决七层负载均衡端口限制问题;(七层负载均衡最大使用65535个端口号) 3、四层负载均衡可以解决七层负载均衡高可用问题;(多台后端七层负载均衡能同事的使用) 4、四层的转发效率比七层的高得多,但仅支持tcp...
优雅停止(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 中,像 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...
Kubernetes CPU 限制深度解析:为何移除反而提速 22 倍
概述Kubernetes CPU 限制看似能保护集群稳定性,实则可能因 Linux 内核 Bug 导致不必要的 CPU 流控,严重影响服务性能。Buffer 团队通过移除 CPU 限制,实现了服务响应速度最高 22 倍的提升。 核心发现: ⚠️ CPU 限制触发不必要流控 🐛 Linux 内核 < 4.19 存在 Bug 🚀 移除限制后性能大幅提升 ⚖️ 需要权衡稳定性和性能 适用场景: 服务响应延迟高 CPU 未满但仍被流控 追求极致性能 内核版本 < 4.19 原文链接: https://blog.fleeto.us/post/k8s-faster-services-no-cpu-limits/推荐配合阅读: 站内《最大最小内存设置为一致》文章 背景Buffer 的 Kubernetes 实践基本情况: 项目 数据 开始时间 2016 年 管理工具 kops 节点数量 ~60 个(AWS) 容器数量 ~1500 个 服务架构 微服务 参考: Kubernetes 官方案例研究 CPU 限制机制工作原理CPU 限制(C...
记录一次 Kubernetes 网络 DNS 问题排查过程
问题总结在 Kubernetes 环境下,服务间访问遇到多个 DNS 和网络相关问题: 问题 1:Alpine 镜像 DNS 解析失败服务使用 node:xxx-alpine 镜像,服务间访问报错:getaddrinfo EAI_AGAIN 问题 2:ClusterIP 访问超时非 Alpine 镜像,使用 ClusterIP 访问频繁出现超时问题:connect ECONNRESET、read ECONNRESET 以及 axios 的 timeout 问题 3:DNS 访问报错非 Alpine 镜像,使用 DNS 访问报错:getaddrinfo ENOTFOUND 问题 4:CoreDNS I/O 超时CoreDNS 报错:[ERROR] plugin/errors: 2 . NS: read udp 10.42.2.5:38764->183.60.82.98:53: i/o timeout 详细背景见:https://github.com/k3s-io/k3s/issues/5897 问题排查过程问题 1:Alpine 镜像 DNS 解析问题问题现象:...
Docker Buildx
前言Docker Buildx 是一个 docker CLI 插件,其扩展了 docker 命令,支持 Moby BuildKit 提供的功能。提供了与 docker build 相同的用户体验,并增加了许多新功能。 该功能仅适用于 Docker v19.03+ 版本 BuildKitBuildKit 是下一代的镜像构建组件,在 https://github.com/moby/buildkit 开源。 注意:如果您的镜像构建使用的是云服务商提供的镜像构建服务(腾讯云容器服务、阿里云容器服务等),由于上述服务提供商的 Docker 版本低于 18.09,BuildKit 无法使用,将造成镜像构建失败。建议使用 BuildKit 构建镜像时使用一个新的 Dockerfile 文件(例如 Dockerfile.buildkit) 目前,Docker Hub 自动构建已经支持 buildkit,具体参考 https://github.com/docker-practice/docker-hub-buildx Dockerfile 新增指令详解启用 BuildKit 之后,我们可以使用...
