Kubernetes插件的该如何扩展，这6个方面必不可少

即将开播：6月19日，互联网银行架构师魏生谈互联网开放银行实施路径的探索与思考

Kubernetes插件或扩展是Kubernetes堆栈的重要组成部分，可帮助满足各种需求并增强使用体验，为了支持生产级的部署，Kubernetes需要许多可扩展的组件，比如日志记录和监控功能，安全治理等等。那么到底需要在哪些方面进行扩展，选择哪些插件呢?

1. 覆盖网络插件

容器必须以某种方式进行通信，所以覆盖网络(Overlay network)插件十分重要。尽管集群可以独立于覆盖网络运行，但使用此覆盖网络的扩展，将大大提升灵活性。

覆盖网络插件的有不少，比如Calico，Weave，Flannel，Canal(Calico + Flannel)和Kube Router。每个集群可以手动安装，也可以针对每个集群分别安装。但是，这可能很耗时，并且限制缩放比例。由于覆盖网络是Kubernetes集群的关键部分，因此请确保它是自动化的，并且是Kubernetes管理平台的一部分。

2. 云原生存储扩展

大多数用户，开始使用无状态应用程序进行Kubernetes时，但很快便涉足有状态应用程序领域。此时，需要一种使用特定扩展来管理云原生存储的方法。

Kubernetes提供基本的本地存储功能。但是，它们可能在诸如存储配置，访问管理或针对不同存储类型的SLA等方面不足。尽管可以通过半手动方式解决这些问题，但这给运营团队带来了负担，并带来了可伸缩性问题。

为了通过状态应用程序支持，可扩展的Kubernetes集群，需要自动执行云原生存储管理，操作和治理。这几个选项是不错的选择，比如Portworx，Storage OS和Robin。开源项目还可以选择Ceph和Rook。

所以在选择构建自己的云原生存储，利用商业产品(或具有商业支持的开源产品)，或使用Kubernetes扩展云原生存储功能。这三种选择，第一种方法显然不可行，因为构建自己的所需的工作和资源对大多数企业来说，都成本高昂的;最好考虑使用供应商提供的现有云本地存储框架，或使用Kubernetes内置的存储功能。

3. CI/CD管道插件

可以选择各种持续集成和持续交付(CI/CD)扩展。有些是特定于云原生的，而另一些是通用的，可以与Kubernetes或其他部署工具一起使用。这些工具中的每一个都有不同程度的可定制性。有些包装与预配置的管道打包在一起，这限制了自定义，而另一些限制较少，但需要更多的设置工作。

在查看选项时，请考虑开发团队正在使用的工具及其体验。可以通过插件，将CI/CD管道与Kubernetes和云原生堆栈集成在一起。如果没有，请考虑使用开源工具，如Jenkins，Spinnaker或两者的组合。

4. 安全管理和治理框架扩展

安全管理和治理框架对于企业至关重要，挑战也在所难免。通过不同的框架实现不同的治理规则，并且这些扩展可能与现有的安全框架重叠。如果没有一个能够满足所有治理需求的综合工具，可能需要混合搭配以最大程度地覆盖范围，而又不会过度使用治理框架的数量和给运营团队带来负担。

由于不同的企业的安全要求不同，因此安全插件也面临类似的挑战。首先，定义你的要求并确定正确的扩展;其次，在使覆盖范围最大化的同时，最小化所需的框架。

一些安全框架将与覆盖网络扩展集成，或者可以利用某些Kubernetes安全功能，包括网络策略，pod安全策略等。对于自动化而言，如NeuVector之类的解决方案可以在集群，环境和应用程序中应用通用策略。

5. 入口管理扩展

入口管理可以将Kubernetes集群服务提供给外部用户。为此，可以利用集群中的入口控制器。但是，更复杂的场景可能需要多个入口控制器并与API管理系统(如NGINX或Kong)集成。这两个工具都与Kubernetes，云原生工具和不同的API管理系统集成在一起。

6. 运行时框架

有许多应用程序运行时扩展可供选择。无服务器框架和服务网格通常与Kubernetes一起使用，并且能够在每个集群中自动部署这些框架的功能非常有用。特别是对于开发和质量保证。使用这些工具时，请务必注意，它们会从应用程序中收集其他指标维度，并应与Kubernetes日志收集和监控集成。例如，服务网格可以为监控和解决各种问题，提供有价值的跟踪信息。

镜像注册表是Kubernetes的另一个重要扩展。镜像管理或构建库管理远远超出了托管构建二进制文件，Helm软件包或Docker镜像的范围。它支持应用程序恢复以及Kubernetes重启Pod的能力，使其既具有部署时间又具有运行时依赖性。还必须考虑与这些构件库相关的治理规则，例如谁可以在每个存储库中发布，并将这些规则与安全框架集成。

总结