容器网络接口（CNI）在 Kubernetes 中常常是基础设施管理中最令人着迷的部分之一，至少对我而言如此。最近几周，我专注于研究 Calico CNI，特别是它的 BGP（边界网关协议）组件。我尝试通过创建类型为 LoadBalancer 的服务，并使用 BGP 将 Kubernetes 服务暴露到互联网。由于没有内部数据中心或裸金属服务器的条件，我需要在 Mac 上配置相关工具和设置。本博客适合有此需求的用户，或供我以后复习使用。请跟随以下步骤进行设置。
上篇 6 张图带你深入了解 kube-scheduler ，已经知道 kube-scheduler 的工作流程，以及如何实现自定义插件。koordinator 和 crane 都是基于Scheduler Framework 进行实现的 负载感知插件。本文不再赘述，感兴趣可以看上篇文章。
在与 Kubernetes 用户的对话中，经常会听到这样一句话：“我只想让我的所有流量在 Kubernetes 中实现 mTLS 加密。” 有时，这种要求还会加上一些附加条件，比如 “…… 但不要涉及服务网格的复杂性。” 这是一个合理的需求，市面上有很多解决方案，各自有不同的取舍。在本文中，我将介绍几种选择，并提供一些建议。
Kubernetes 是一个开源的容器编排平台，用于自动化部署、扩展和管理容器化应用程序。它提供了丰富的功能，如服务发现、负载均衡、自动缩放等。随着 Kubernetes 在云原生领域的广泛应用，「有效管理谁可以对 Kubernetes 集群执行何种操作变得至关重要」。本文将简要介绍 Kubernetes的认证与授权体系以及RBAC授权原理。通过实际案例展示RBAC管理不当可能导致的安全风险，然后向大家分享RBAC安全研发与运维的最佳实践，以及我们在字节跳动内部的安全防护和治理经验。
受内核调度控制周期（cfs_period）影响，容器的 CPU 利用率往往具有一定的欺骗性，下图展示了某容器一段时间的 CPU 使用情况（单位为0.01核），可以看到在 1s 级别的粒度下（图中紫色折线），容器的 CPU 用量较为稳定，平均在 2.5 核左右。根据经验，管理员会将 CPU Limit设置为 4 核。本以为这已经保留了充足的弹性空间，然而若我们将观察粒度放大到 100ms 级别（图中绿色折线），容器的 CPU 用量呈现出了严重的毛刺现象，峰值达到 4 核以上。此时容器会产生频繁的 CPU Throttle，进而导致应用性能下降、RT 抖动，但我们从常用的 CPU 利用率指标中竟然完全无法发现！
