Kubernetes一騎絕塵開掛來，那麽企業應該開始向Kubernetes遷移嗎?什麽情況下真正的接受它?一些技術前沿公司先行一步的實踐恐怕最有說服力和參考價值。本文即是一則很好的參考。

1

Kubernetes如今風靡一時，它是龐大的雲原生運動中的一部分。所有主要的雲提供商都將其作為部署雲原生應用的解決方案。就在幾個星期前，AWS重新推出了EKS（Amazon Elastic Container Service for Kubernetes)，這是一個完全托管的Kubernetes集群。

這是一個巨大的進步，因為AWS是最大的公有雲提供商，大多數Kubernetes的部署都在AWS上。官方kops工具用於部署和管理Kubernetes集群，目前已準備就緒。隨著Kubernetes越來越受歡迎，企業正在努力接受它，希望借助Kubernetes解決許多常見問題。

那麽，企業真的應該開始向Kubernetes遷移嗎?什麽情況下真正的接受它?本篇文章，將試圖回答這個問題，並給出遷移到K8S和雲原生的一些挑戰和建議。

The Problem 問題

今年早些時候，我們開始對Sematext雲進行容器化部署，這看起來似乎非常簡單。企業所要做的就是將所有應用程序打包，為其資源（如部署、服務等）創建一些Kubernetes配置，然後即可進行操作。然而，並不是那麽容易。

問題主要在於，用於管理發布過程的所有東西都不適合雲原生模式。企業的應用程序不是雲原生的，就無法使用CI/CD部署管道，運行狀況檢查或使用監視工具來記錄日誌、指標和警報。企業的應用程序可能非常靜態且部署復雜。這種復雜性不會隨著遷移到Kubernetes而消失，只會讓事情變得更糟。雲原生意味著將操作系統從應用程序中解耦出來，這就是容器正在做的事情。

在軟件行業的演進中，首先是瀑布流，然後是敏捷，如今有了DevOps管理。這是一個非常重要的難題，這裏沒有規則可循。每個團隊使用最適合他們的方式，如果你想堅持現有的常規，沒什麽問題，請照常做。只需要確保你的日常工作適用於雲原生，這意味著需要做出一些改變。要切換整個團隊來接受DevOps原則並不容易，需要一些時間做準備。

The Solution解決方案

這不是一個需要盲目跟隨的解決方案。它給出一個想法，並解釋可能遇到的過程和問題。

第一步，首先對所有未使用的組件進行清理。軟件在開發了幾年之後，會變得非常復雜，因為總有更重要的事情要做——新功能、新產品修復等等。

其次，對Kubernetes readiness and liveness probes進行健康檢查，這點不難。花費時間管理配置才是最難的部分。我的建議是利用配置地圖（config maps）和secrets ，遠離環境變量。你可以使用其中一部分，但不要僅使用環境變量來進行整個配置管理。應用程序應該充分發揮Kubernetes的潛力。

Kubernetes應用程序正在使用服務進行通信。在Kubernetes中有不同類型的服務，並將它們視為負載均衡器。定義的服務名稱是你的端點http://service_name:port。

如果正在使用有狀態應用程序，會希望使用 headless services，能夠訪問特定的Pod。Kubernetes的服務也在某種程度上解決了服務發現問題。如果你已經使用了Consul之類的服務發現，恭喜你!可以堅持下去，並將它部署在Kubernetes上。

從Kubernetes的角度來看，在無狀態應用程序下，應用程序容易擴展。使用部署作為資源，這種類型的服務還可以管理簡單的升級-滾動更新。當然，你的應用程序需要在沒有任何問題的情況下處理擴展，並且需要一些代碼更改來實現它。

主要問題在於有狀態的應用程序，如數據庫。Kubernetes為這類應用程序提供了一種StatefulSet資源，但不知道在添加新節點或出現故障時，特定的應用程序應該如何反應，這是運維人員在管理時通常要做的事情。不過，編寫Kubernetes的操作符不是多麽困難的事情。

簡而言之，操作符是Kubernetes custom resource definition（即CRD），可以自行編寫或使用現有的。我們使用的是 Elastic search Operator，很樂意為這個項目做出貢獻。我已經提出了一些pull requests。

你可能已經開始把所有的片段連接起來了。有兩種計算資源：請求，它在一個節點上指定最小數量的空閑資源，用於Kubernetes調度程序運行特定的Pod，以及限制，這是Pod可以使用的最大計算資源數量。這一點非常重要，特別是對於Java應用程序來說。對於Java應用，還需要根據heap memory需求調整限制。根據對Docker CPU和內存限制的了解，我的建議是使用Java version 8u131或更新版本。

給你的應用標上標簽——當需要監控容器和應用程序時，這真的很有用，而元數據信息通常就是如何通過選擇器連接不同的資源。例如，部署和服務。

當開始編寫Kubernetes配置文件時，你會覺得很好，並且認為維護不是什麽大問題。但是，在嘗試實現部署管道時，你會發現使用一堆配置文件是一個非常糟糕的想法。這時Helm可以拯救，Helm是一個用於打包Kubernetes應用程序的工具，我強烈推薦使用它來部署管道。諸如支持多種環境、依賴關系、版本控制、回滾和不同hooks(考慮DB遷移)就足夠描述Helm的所有優點了。壞消息是你需要學習另一種工具，但它很容易學，值得你花時間。

企業不需要多個集群來搭建不同的環境，只需使用不同的Kubernetes命名空間。例如，為了創建一個新環境，只需要創建一個單獨的命名空間，完成測試後把它刪除，節省了大量時間和資金。但是，不要忘記安全。Kubectl就像集群中的根用戶。讓每個人都訪問kubectl可能不是一個好主意。有時，創建一個全新的集群比管理RBAC更好，而這可能非常復雜。盡管如此，還是強烈建議使用RBAC。

那麽，企業將如何為容器鏡像、Helm packages等提供版本呢?這取決於自己的選擇。最常用的方法是提交ID給鏡像打標簽，然後release tag。此時，需要將Docker鏡像存儲到某個地方，即私人或公共註冊中心。我的建議是使用DockerHub。這或許是最具成本效益的。如果解決了所有問題，那麽需要創建一個部署管道。企業可以使用Jenkins來部署所有內容，並將其作為DevOps的主要工具之一。

The Conclusion 結論

最近，人們關註的焦點是雲原生，而並非僅僅Kubernetes本身。Kubernetes只是一個工具，我們向Kubernetes遷移Sematext雲和Sematext的工作正在進行中。需要把它看作一個過程，這不是一項一次性的工作，也從來沒有完全完成。

遷移到雲原生和Kubernetes的過程，既困難又費時，但對企業的公司文化和軟件非常有益。擴展不再是問題，基礎設施只是代碼和軟件問題。擁抱Kubernetes，但要準備好面對挑戰。

2
Kubernetes可以在任一環境下部署

在開始進行雲原生開發和部署時，來看看Kubernetes所扮演的角色，以及如何從編排中獲得更多的功能。

容器提供了將應用程序及其依賴與操作系統分離的能力。通過與虛擬機鏡像不同的方式打包操作系統，容器節省了大量系統資源：計算、內存和磁盤空間。容器也更快地下載、更新、部署和叠代。因此，在技術領域，容器已經引起了一場小型革命，並被谷歌、微軟和亞馬遜等公司采用。

容器的小型革命也帶來了激烈的競爭，以滿足編排和管理的需要。Kubernetes，谷歌的開源容器編排工具，已經成為領先的解決方案(替代方案有有亞馬遜ECS和DockerSwarm等)，歸功於三個主要原因：

雲原生設計：支持部署和運行下一代應用程序。
開源特性：快速創新，避免廠商鎖定。
可移植性：在任何地方部署，無論是在雲中、on-premise、還是虛擬機中等等。

下圖顯示了Kubernetes在雲原生部署中所扮演的角色:

                                                                  Kubernetes容器編排

Kubernetes可以部署和管理容器應用，其中包括NGINX、MySQL、Apache和其他許多應用程序。它可以為容器提供布局、縮放、復制、監視和其他功能。

一旦選擇了容器編排平臺，下一步就是部署Kubernetes。如前所述，Kubernetes是一個可移植的解決方案。因為Kubernetes使用相同的鏡像和配置，它在筆記本電腦上、雲裏、或在本地所使用的方式完全相同。

Kubernetes-as-a-Service

這些解決方案提供了在各種基礎設施中部署Kubernetes的能力：公有雲或內部部署。為Kubernetes集群選擇這種方法的優勢包括:

1.通過KaaS供應商進行升級、監控和支持。
2.輕松擴展混合雲或多雲環境。
3.多集群的單一窗格視圖。
4.高可用性，多主Kubernetes集群，根據工作負載自動擴縮。
5.通用企業集成，如SSO /獨立命名空間; 以及通過Helm圖表部署應用程序的能力。
6.集群聯合，提供跨多個雲或數據中心的真正無縫混合環境。

                              Kubernetes-as-a-Service（Kubernetes即服務）

Kubernetes即服務的例子包括Platform9和StackPoint.io。

托管的基礎設施

谷歌雲平臺和Microsoft Azure分別通過谷歌容器引擎(GKE)和Azure容器服務(ACS)提供Kubernetes。容器放置在公有雲中可以快速啟動，但是現在企業的數據將留存在網絡防火墻之外。

谷歌GKE領導著其他公有雲供應商。谷歌通過一個名為Borg的集群管理器，廣泛地將容器用於內部項目，並擁有超過十年的開發經驗(來源: TheNextPlatform)。相比之下，微軟的ACS是一個更年輕的產品，Kubernetes支持僅在2017年2月才被引入。

然而，ACS提供了靈活性:用戶可以選擇容器編排平臺(Kubernetes, Docker Swarm, DCOS)，以及選擇除了Linux以外，在Windows中部署容器化的應用程序的選項。如下所示，GKE和ACS完全基於公有雲，Kubernetes服務和基礎設施由托管提供商部署和管理。

                                    Hosted Infrastructure for Kubernetes

本地部署

Minikube是在本地部署Kubernetes最流行的方式。它支持各種虛擬化管理程序，包括VirtualBox、VMware Fusion、KVM、xhyve和OSs，包括OSX、Windows和Linux。下面的插圖進一步描述了Minikube的部署:

                                                                      部署與Minikube

如上所示，用戶使用Minikube CLI和Kubernetes的原生CLI Kubectl與筆記本電腦部署進行交互。 Minikube CLI可用於在虛擬機上啟動，停止，刪除，獲取狀態以及執行其他操作。一旦Minikube虛擬機啟動，Kubectl CLI將在Kubernetes群集上執行操作。 以下命令啟動現有的Minikube虛擬機並創建NGINX Kubernetes部署：# minikube start# cat > example.yaml<<EOF
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 1
template:
metadata:
labels:
app: nginx
spec:
containers:

• name: nginx
  image: nginx
  ports:
  • containerPort: 80
    EOF

    kubectl create -f example.yaml

    （手動往下翻）

原文鏈接：
1、Embracing Kubernetes Successfully
https://sematext.com/blog/embracing-kubernetes-successfully/
2、Deploy Kubernetes Anywhere
https://dzone.com/articles/deploy-kubernetes-anywhere

推薦活動：
數人雲聯合ServiceComb、ServiceMesh社區舉辦的 Building Microservice Meetup系列活動第2站--3月31日，北京站開始報名啦！本期主題為《微服務，從架構到發布》依舊大咖匯集，點擊最下方的“鏈接請添加鏈接描述”快來報名~

kubernetes落地 |不捧不踩，國外公司向Kubernetes遷移實踐