在与 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 利用率指标中竟然完全无法发现！
KubeAdmiral 是字节跳动于 2023 年 7 月正式开源的多云多集群管理引擎，它孵化于字节跳动内部，从上线至今一直强力支撑抖音、今日头条等大规模业务的平稳运行，目前管理着超过 21 万台机器、超过 1000 万 Pod。 自正式开源以来，KubeAdmiral 自身也经历了不断发展和完善，在系统功能、扩展性、稳定性和运行效率均有大幅提升，也吸引了业界最终用户的使用和贡献。因此，我们相信 KubeAdmiral 已经准备好在生产环境落地，并很高兴地宣布 1.0.0 版本正式发布。
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 的规格进行调整，以达到时延和资源的完美平衡。
