DNS是Kubernetes集群中非常重要的基础服务，在客户端设置不合理、集群规模较大等情况下比较容易出现解析超时、解析失败等现象，严重时可能会对业务造成相关影响。 尤其在节点异常宕机，或集群整体负载、coredns所分布在的节点负载较大时，该情况会非常常见，我们不定期会收到相关解析异常报警和业务线同学反馈，虽然每次持续时间较短，但在高峰期频繁出现也非常折磨。经过多种方案对比考量，我们最终决定对原生DNS架构做下改动： 将原架构集中请求pod→kube-dns svc→coredns pod的方式改造为：各node节点上的pod首选请求所在node本地的dns服务（后续称为q-dnsmasq），在q-dnsmasq服务不可用时再去请求kube-svc； 并将q-dnsmasq启用all-servers模式，让其识别请求域名是K8S内部（如cluster.local）还是外部，内部则同时转发多个Coredns并取最快响应结果； 如为K8S外部域名则在转发请求至公司dns-server时，也通过并发的方式同时请求3台公司dns-server（后续称为localdns），取最快响应结果；
公众号之前翻译了一篇 Sysdig 的文章，Kubernetes 容量规划：如何合理设置集群资源介绍了如何设置合理的资源参数。虽然按照那篇文章设置可以有一定的帮助，但仍然可能存在风险。本文将详细说明这些风险，并介绍如何通过北极星指标对 POD 的规格进行调整，以达到时延和资源的完美平衡。
现代软件部署中，容器技术已成为不可或缺的一环，在云计算和微服务架构中发挥着核心作用。随着容器化应用的普及，确保容器环境的可靠性成为了一个至关重要的任务。这就是容器SRE（Site Reliability Engineering，站点可靠性工程）的职责所在。容器SRE工程师不仅要保证系统的高可用性，还需要优化运行效率，确保系统在各种压力和突发情况下的韧性。 然而，容器SRE的工作常常是背后默默的付出，通常涉及着大量看似琐碎却极其关键的维护任务。例如某一天，你可能发现K8s集群中的Kubelet进程CPU使用异常飙高，这就需要容器SRE工程师立即介入，进行深入的诊断和问题排查，避免类似问题成为生产环境中的隐患。这种排查过程往往涉及复杂且难以预测的环境，通常需要SRE工程师具备高度的专业知识和快速应变能力。因此，虽然容器SRE工程师的努力可能不为大众所见，但对于现代依赖软件和云服务的任何系统来说，这些工作显得尤为严谨和重要。 通过本文，我们将深入探讨容器SRE在日常工作中面临的挑战和如何通过专业技能和创新技术方案来定位和解决问题，确保技术平台的稳健运行。
Service 作为 K8s 中的一等公民，其承载了核心容器网络的访问管理能力，包括： 暴露/访问一组 Pod 的能力 Pod 访问集群内、集群外服务 集群外客户端访问集群内 Pod 的服务 无论是作为应用的开发者还是使用者，一般都需要先经过 Service 才会访问到真正的目标 Pod。因此熟悉 Service 网络管理机制将会使我们更加深入理解 K8s 的容器编排原理，以期更好的服务各类业务。
多活建设：提高业务应用的可用性，避免单个集群或单个数据中心故障导致业务应用暂时不可用。 混合云建设：引入公有云弹性资源解决业务大促节假日资源洪峰 控制故障爆炸半径
几天前，K8s Network SIG 发布了 Gateway API（简称 gwapi）的 v1.1 版本[1]，这个版本的发布包含了多项重要功能的 GA（一般可用），以及一些实验功能的引入。这两部分分别通过标准渠道和实验渠道发布。
