Kubernetes无疑是容器化领域里一个优雅的解决方案。 Kubernetes能够让我们大规模地运行容器化应用程序，而不用淹没在负载平衡，网络容器，确保应用程序的高可用性或管理更新或回滚的细节上。许多复杂性被安全地隐藏起来。
但是使用Kubernetes并不是没有挑战。Kubernetes的启动和运行需要一些工作，许多围绕Kubernetes的管理和维护任务是很棘手的。
即便Kubernetes社区发展很活跃，我们也不能指望Kubernetes主体项目能立即解决每个问题。幸运地是，Kubernetes社区正在对那些Kubernetes团队由于种种原因没有关注到的问题找寻解决方案。
下面是3个新涌现出来的Kubernetes项目，目的是使操作人员不再那么难以部署，维护，操作和监督容器。
Heptio
两位从原谷歌Kubernetes开发团队离职的员工创建了Heptio，旨在使Kubernetes更易于使用。和其他旨在提供自己Kubernetes发行版本公司不同的是，他们注重在源头上提供开源工具来提升Kubernetes的使用效果。
本月早些时候，Heptio发布了第一批项目，Heptio Ark和Heptio Sonobuoy。Ark是Kubernetes 集群的灾难恢复系统–一种基于容器的集快照、备份和恢复于一体的应用程序。Ark记录了Kubernetes API对象和持久存储卷(PV)的状态。Ark的默认示例使用和S3兼容的存储服务(“Minio”)，但Ark也可以使用其他主要云提供商的存储服务–比如亚马逊的AWS，谷歌的云平台和微软的Azure。
Ark现在还没有提供一个在不同环境之间随意切换现有Kubernetes集群的解决方案。对此，Heptio解释说，Ark需要在不同的云提供商之间支持持久存储卷快照的迁移，目前尚不支持这一功能。
另外一个项目，Sonobuoy，用来检查给定的Kubernetes安装，看它是否能通过用于验证 Kubernetes发布版本的测试。
Kubernetes的部署通常会被供应商或用户做大量修改，这可能会使他们与更新不兼容。Sonobuoy的工作是去发现这些更改是否引起了不兼容。集群的状态也可以导出并用于诊断报告，Sonobuoy的测试也可以通过一个插件架构来扩展。
Sonobuoy仍在早期的开发阶段，不过，它不能检查Kubernetes一致性测试中标识出的所有问题。它的长期计划是和由Kubernetes核心团队创建的测试集保持同步。
Kubed
AppsCode，一个针对容器应用开发的协同编码平台供应商，最近发布了一个项目来填补Kubernetes集群管理方面的许多空白。
Kubed–发音为“Cube-dee”，是“Kubernetes守护进程”的简称，它将一大堆有用的功能整合到一个守护进程中。 Kubed可以执行定期集群快照，为已删除的对象提供临时存储（万一你需要再次使用它的话），执行自动事件转发，通过各种渠道发送通知等等。
Kubernetes也可以在Elasticsearch或InfluxDB的实例中存储日志数据，但清理旧数据是用户自己的责任。一个Kubed的功能，janitors，可以在指定的时间段之后自动清除日志数据。 Kubed还不支持执行这种清理的‘干运行’功能，但是添加该功能的请求已经被提交。
Kubed项目目前处于alpha、不稳定的状态，未来计划有许多突破性的变化。这些计划包括支持 Kubernetes最近推出的自定义资源定义(CRDs)和通过Kubernetes提供的用户API 服务器来将Kubed API作为Kubernetes扩展API集使用。
Kubicorn
Kubicorn项目旨在帮助用户在各种云服务中构建和管理Kubernetes的基础设施。 像Puppet和其他用于管理基础设施的现代化工具一样，Kubicorn采用了声明式理念：用户描述他们想要在其集群中看到的状态，Kubicorn确保集群的状态与该目标一致。
Kubicorn旨在可以作为一个独立工具来使用，同时也可以作为其他工具调用的库来使用。 同理，Kubicorn利用了Kubernetes的现有工具，例如kubeadm工具。 因此，Kubicorn旨在补充现有的工作流程，而不是替代它们。
Kubicorn采用的方法主要是使用快照。Kubicorn通过允许用户定义其集群的状态，检查该状态是否符合原子性（如果不符合，它将被回滚），并将该状态捕获为快照。这些快照也可以用于新的部署。
请注意，Kubicorn不是官方的Kubernetes项目，它仍然被认为是实验性的，不应该在生产环境中使用它。
但是当然，试验Kubernetes的时机已经成熟了。你可能也想试试Kubicorn，Kubed和Heptio。