K8s 是容器编排领域的事实标准，作为一名后端开发，如果对 K8s 的技术原理不够了解，未来无论是在日常工作还是求职面试中，可能都会面临一些挑战问题。 本文是腾讯云可观测平台工程师柯开所总结的 K8s 核心技术原理，帮助你轻松拿捏！长文干货预警，建议先点赞转发收藏一键三连再来仔细阅读，对照问题场景印证效果更佳！
Argo Workflows是一个开源的容器原生工作流引擎，允许用户在Kubernetes集群上定义并执行复杂的业务流程。支持对相关流程进行个性化编排，包括执行顺序、相互之间的依赖等等。 Argo Workflows 是以 Kubernetes 自定义资源定义（Custom Resource Definitions，简称 CRD）的形式来实现其功能。CRD 是 Kubernetes 提供的一种机制，它允许用户在不修改 Kubernetes 核心代码的情况下，扩展 API Server，定义新的资源类型。
多集群部署微服务带来了可扩展性和容灾性等优势，但也引入了全局层面的脆弱性——中心控制平面的任何问题都会级联影响所有被管理集群，造成灾难性后果。其中最严重的场景之一是由于Pod删除导致的服务容量丢失。这在Kubernetes复杂的事件链中可能由多种原因引发，例如： 意外删除所有Deployment的owner资源类型的CRD 集群拓扑配置错误，导致用其他集群的spec覆盖当前集群 多集群滚动更新实现缺陷，同时在所有集群触发更新 联邦主集群的etcd磁盘损坏，导致Deployment对象从索引中移除 多个集群同时独立进行Pod驱逐操作，并发度不受控 虽然这些问题均可单独解决，但成因多样且在持续变化的基础设施中难以穷举。更便捷的方式是采用端到端处理：只要全局要求未满足就阻止Pod删除。因此我们开发了Podseidon项目——当跨集群的最小可用性要求不满足时，拒绝删除请求的准入webhook。
本文讲述作者如何解决客户集群中出现的OOM（Out of Memory）和Pod驱逐问题。文章不仅详细记录了问题的发生背景、现象特征，还深入探讨了排查过程中的关键步骤和技术细节。
一、项目背景 1.传统运维的痛点与挑战 2.Kubernetes 与 Operator 的优势 3.平台建设的核心目标 二、建设历程 1.平台架构概览 2.多云管理：跨云资源托管，告别 kubeconfig 切换地狱 3.中间件运维：Kafka 扩容，从黑屏脚本到白屏可视化 4.Node 管理：从黑屏脚本到白屏化平台 5.PV 云盘管理：打破孤盘与繁琐操作的枷锁 6.CPU Burst 管理：关键时刻的“应急电源” 7.YAML 管理服务：让配置变更安全、可控、可回滚 三、项目收益总结 四、经验总结与反思 五、未来展望
Kubernetes(K8s)架构已经是当今IT架构的主流与事实标准（CNCF Survey[1]）。随着承接的业务规模越来越大，用户也在使用越来越大的K8s集群。Kubernetes官方建议的最大集群规模是5000节点。甚至，如OpenAI通过技术优化，曾将K8s集群扩展至7500节点（Scaling Kubernetes to 7,500 nodes[2]）。这种千级别节点的大规模K8s集群，会容易引起分布式系统内部瓶颈，但也增加了系统的脆弱性。
集群服务暴露的需求来自 Kubernetes 服务的虚拟化和网络隔离。众所周知，Kubernetes 的 Pod 是动态的，可能会频繁的删除、重建，重新调度到不同的节点，IP 地址也会随之变化。Kubernetes 使用 Service 来提供访问 Pod 的稳定接口，实现对服务的抽象。 Service 为 Pod 提供了一个稳定的 DNS 名称和虚拟 IP 地址，而不依赖于 Pod 的临时 IP。因此在集群内部的通信，通过 Service 的 ClusterIP 访问完全不存在问题。 不过 Service 的 ClusterIP 只能在集群内部访问，外部无法直接访问。Service DNS 名称的解析，只能在集群内部进行。这种网络隔离作为网络保护机制，确保 Pod 和 Service 的访问受限于集群内部。 然而，我们在实际应用中，往往需要将服务暴露到集群外部，以便外部用户访问。这时，我们就需要额外的组件来实现集群服务的暴露。尤其是在一些高级应用场景下，如多集群、多云等，更需要一种灵活、动态的方式来暴露集群服务。
