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的能力，使其既具有部署时间又具有运行时依赖性。还必须考虑与这些构件库相关的治理规则，例如谁可以在每个存储库中发布，并将这些规则与安全框架集成。
总结
Kubernetes插件或扩展是任何Kubernetes堆栈的重要组成部分。对于某些功能，例如覆盖网络，云本地存储或CI/CD框架，选择很简单。但是，安全和治理带来了复杂的问题。当你将各种工具组合在一起时，缺少单个综合工具就需要对安全性要求进行深入思考和考虑，这并非易事。
那么可能需要考虑使用企业级Kubernetes平台，例如Kublr，它通过默认设置关键扩展来解决Kubernetes的安全和治理挑战。此类平台还与身份管理系统和RBAC集成。
