下载掌阅APP，畅读海量书库
立即打开
相对于物理机和虚拟机而言，容器是很轻量化的技术，在等量资源的基础上能创建出更多的容器实例。一方面，当面对分布在多台主机上且拥有数百个容器的大规模应用时，传统或单机的容器管理解决方案就会变得“力不从心”。另一方面，由于为微服务提供了越来越完善的原生支持，因此一个容器集群中的容器颗粒度越来越小、数量越来越多，在这种情况下，容器或微服务都需要接受管理并有序接入外部环境，从而完成调度、负载均衡、分配等任务。简单且高效地管理快速增长的容器实例，是容器编排系统的主要任务，而Kubernetes就是容器编排和管理系统中的最佳选择。Kubernetes 的核心是如何解决自动部署、扩展和管理容器化应用程序。其发展路线注重规范的标准化和厂商“中立”，支持Rkt等不同的底层容器运行时和引擎，逐渐解除对容器的依赖。
下面就 Kubernetes 自动扩展功能修改后的创新方案进行介绍。Kubernetes 的弹性扩展是指根据应用程序的实际负载自动调整集群中 Pod 的数量。这种功能使得Kubernetes 集群能够在负载增加时自动扩展资源，以满足应用程序的需求，同时在负载降低时释放资源，以提高资源利用率并降低成本。Kubernetes 的弹性扩展可以帮助用户实现更加高效、可靠的应用程序部署和运维。在Kubernetes中，弹性扩展主要通过两种方式实现：水平弹性扩展（Horizontal Pod Autoscaling）和垂直弹性扩展（Vertical Pod Autoscaling）。水平弹性扩展根据应用程序的CPU使用率、内存使用率或者自定义指标自动调整Pod副本的数量。当监控到某个指标超过预定阈值时，Kubernetes会增加Pod副本数，从而分摊负载，如图5-4所示；而当指标低于阈值时，Kubernetes会减少Pod副本数，释放资源。垂直弹性扩展根据应用程序的实际资源使用情况自动调整Pod的CPU和内存资源限制，会根据过去的资源使用记录为Pod推荐合适的资源配置，并在必要时重新启动 Pod 以应用新的资源配置。垂直弹性扩展可与水平弹性扩展共同工作，以实现更加灵活的弹性扩展策略。
图5-4 Pod级别的水平弹性扩展
Kubernetes 的弹性扩展虽然在很大程度上提高了资源利用率和应用程序的可用性，但它也存在一些诸如响应延迟、预估不准确、资源限制等缺点和挑战，其中最重要的是响应延迟和资源限制等问题，即弹性扩展在负载突然增加时，可能需要一定时间才能扩展足够数量的Pod来应对负载。在某些场景下，这种延迟可能会导致服务暂时不可用或性能下降，而且在扩展过程中，集群的物理资源（如节点数量、CPU和内存）可能会成为瓶颈。如果集群没有足够的资源来满足扩展需求，那么弹性扩展可能就无法正常工作。
基于此，我们创新性地提出并实现了一种全新的Kubernetes自动扩展方案，此方案不需要复制Pod资源，只复制Pod的应用容器即可。这是一种针对Kubernetes水平弹性扩展的优化方案，主要解决了传统的水平弹性扩展在延迟响应和资源限制方面的问题，为Kubernetes的水平弹性扩展带来了更高的响应速度和资源利用率。如图5-5所示，由于复制的资源变少了，所以应用容器变多了，在某些场景下也能提高业务请求处理能力，满足了需求。
图5-5 Pod内部容器级别的水平弹性扩展
该方案具备以下创新和优势。
● 动态调整扩容速度：该方案利用自适应算法来动态计算扩容速度。这种算法根据实时监控数据（如 CPU 利用率、内存使用率等）和预测模型来确定何时以何种速度扩展Pod副本数量。这样，系统可以在负载增加时更快地提供所需资源，同时避免过度扩容导致的资源浪费。这有助于缩短响应时间，提高服务可用性。
● 突破资源限制：该方案在扩容时可以自动调整Pod的资源限制，使其能够充分利用节点上的可用资源。这可以通过修改 Kubernetes 资源对象（如Deployment、StatefulSet 等）中的资源限制来实现。在扩容期间，系统会动态调整资源限制，以便 Pod 能够在需要时获取更多的 CPU、内存等资源。这有助于提高资源利用率，降低运营成本。
● 预热容器：该方案使用预热容器来减少扩容时的启动延迟。预热容器是一组预先创建并初始化的容器，它们在正常情况下保持“空闲”状态，等待接收负载。在负载增加时，预热容器可以快速切换到“运行”状态，以缩短扩容所需的时间。预热容器的创建和管理可以通过Kubernetes的控制器和操作器来实现，这有助于进一步缩短响应时间，提高服务性能。
● 精细化资源控制：通过在Kubernetes资源对象中定义资源需求和限制实现，该方案支持更细颗粒度的资源控制，允许用户根据需要为Pod分配不同类型的资源。在运行时，该方案会根据实际负载情况动态调整资源分配，以实现更加高效和灵活的资源管理，同时优化策略。
这种创新技术方案在FaaS（Function as a Service，功能即服务）应用、机密计算、容器网络功能等情况下能达到优化性能的目的。初步实验证明，这种自动扩展应用的新方案可实现2～3倍的性能提升。
新的自动扩展方案的实现不仅涉及对Kubernetes核心组件（如API服务器、控制器、调度器等）的修改和扩展，以实现所需的动态调整、预热和资源控制功能，而且还需要深入了解Kubernetes的内部原理和架构，以确保与现有功能和生态系统的兼容性。为了确保代码质量和项目稳定性，Kubernetes 项目遵循一定的软件开发流程，下面介绍Kubernetes Pull Request（简称为PR）软件开发的简单流程。与其他开源软件项目类似，Kubernetes的源代码托管在GitHub上，开发人员可以通过各种Git工具提交PR，发起对Kubernetes代码的改动。
由于Kubernetes项目非常重视代码质量和稳定性，因此项目中广泛使用自动化测试和CI/CD来确保新代码的可靠性。Kubernetes项目包含大量的自动化测试，包括单元测试、集成测试和端到端测试。这些测试用于确保代码修改不会破坏现有功能，并确保新功能按预期工作。在提交 PR 之后，由于 GitHub 会执行一些自动化的测试，因此，我们在开发解决方案时，要确保添加了单元测试或集成测试，以验证代码的修改和预期的一样。
就CI/CD而言，与OpenStack使用Jenkins和Zuul等通用CI/CD系统的不同之处是，Kubernetes项目使用Prow作为主要的CI/CD系统。Prow是一个基于Kubernetes的开源CI/CD系统，由Kubernetes项目的维护者开发和维护。Prow的架构充分利用了Kubernetes的特性，如弹性伸缩、自动恢复和容器化，这使得Kubernetes的CI/CD系统能够更好地应对项目规模的增长和复杂性的增加。另外，为了使Kubernetes的CI/CD系统可以轻松地得到扩展和定制，以适应不断变化的项目需求，Prow提供了一套可插拔的插件系统，允许维护者根据需要添加或修改CI/CD功能。在提交PR 之后，Prow 会为有/ok-to-test标签的PR运行所有的单元测试和集成测试。
在提交PR之前，也可以在Slack频道上发送消息，以确认有人能帮助你审查代码 PR。对于非 Kubernetes 项目的成员，我们也需要在相关的特别兴趣组 Slack 频道中，找 Kubernetes GitHub组织的成员对PR添加评论/ok-to-test标签触发CI/CD，否则CI任务不会自动执行。在测试完成之后，GitHub也会自动为 PR 分派一些标签，以帮助代码审阅人明确自动化测试结果。如果需要，代码修改人员也可以向 PR添加标签。在代码审阅过程结束后，审阅人会合并PR，这样代码修改就会上线了。