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。
