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 的访问受限于集群内部。 然而，我们在实际应用中，往往需要将服务暴露到集群外部，以便外部用户访问。这时，我们就需要额外的组件来实现集群服务的暴露。尤其是在一些高级应用场景下，如多集群、多云等，更需要一种灵活、动态的方式来暴露集群服务。
Linux下开发者习惯在物理机或者虚拟机环境下使用top和free等命令查看机器和进程的内存使用量，近年来越来越多的应用服务完成了微服务容器化改造，过去查看、监控和定位内存使用量的方法似乎时常不太奏效。如果你的应用程序刚刚迁移到K8s中，经常被诸如以下问题所困扰：容器的内存使用率为啥总是接近99%？malloc/free配对没问题，内存使用量却一直上涨？内存使用量超过了限制量却没有被OOM Kill? 登录容器执行top,free看到的输出和平台监控视图完全对不上？... 本文假设读者熟悉Linux环境，拥有常见后端开发语言(C/C++ /Go/Java等)使用经验，希望后面的内容能在读者面临此类疑惑时提供一些有效思路。
容器网络接口（CNI）在 Kubernetes 中常常是基础设施管理中最令人着迷的部分之一，至少对我而言如此。最近几周，我专注于研究 Calico CNI，特别是它的 BGP（边界网关协议）组件。我尝试通过创建类型为 LoadBalancer 的服务，并使用 BGP 将 Kubernetes 服务暴露到互联网。由于没有内部数据中心或裸金属服务器的条件，我需要在 Mac 上配置相关工具和设置。本博客适合有此需求的用户，或供我以后复习使用。请跟随以下步骤进行设置。
上篇 6 张图带你深入了解 kube-scheduler ，已经知道 kube-scheduler 的工作流程，以及如何实现自定义插件。koordinator 和 crane 都是基于Scheduler Framework 进行实现的 负载感知插件。本文不再赘述，感兴趣可以看上篇文章。
