k8s

在 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 限制看似能保护集群稳定性，实则可能因 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...

转自： https://www.51cto.com/article/704723.html Kubernetes 资源限制往往是一个难以调整的配置，因为你必须在太严格或者太宽松的限制之间找到最佳的平衡点。 通过本文，你可以学习到如何设置正确的 Kubernetes 资源限制：从检测到无限制的容器，到找出你应该在集群中正确配置的 Kubernetes 资源限制。我们假设你使用 Prometheus 来监控你的 Kubernetes 集群。这就是为什么本文中的每个步骤都使用 PromQL 查询进行示例说明的原因。 检测没有 Kubernetes 资源限制的容器 设置正确的 Kubernetes 资源限制的第一步是检测没有任何限制的容器。没有 Kubernetes 资源限制的容器可能会在你的节点中造成非常严重的后果。在最好的情况下，节点将开始按顺序或评分驱逐 pod。由于 CPU 节流，它们也会出现性能问题。在最坏的情况下，节点将由于内存不足而被终止。 查找没有 Kubernetes 资源限制的容器 根据命名空间查找没有限制 CPU 的容器 1sum by (namespace...

问题总结在 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 解析问题问题现象：...