歡迎光臨
每天分享高質量文章

8分鐘瞭解Kubernetes

 

Kubernetes脫胎於Google的Borg系統,是一個功能強大的容器編排系統。Kubernetes及其整個生態系統(工具、模組、外掛等)均使用Go語言編寫,從而構成一套面向API、可高速執行的程式集合,這些程式檔案精良、易於參與貢獻或在其上構建應用程式。
每個開發、運維或感興趣的讀者都應熟悉它的一些核心概念,以便理解這個系統及其不同的功能,以及為什麼幾乎所有人都在使用它。
在繼續之前,我想提一下Kubernetes的幾個頂級朋友(或競爭對手):ECS、Nomad和Mesos。ECS是AWS自己的編排解決方案,最近它又推出了託管在AWS上的Kubernetes系統——EKS。兩者都支援FARGATE,讓使用者無須關心所執行的物理資源。
雖然Kubernetes毫無疑問是最大贏家,作為一個開源系統,三大主流雲服務商都以託管的方式提供了這項功能。但是,它比其他幾個產品都要來得複雜和混亂。Kubernetes可以處理幾乎任何型別的容器負載,也有很多技巧,但這並不意味著每個人都應該使用它。其他解決方案或許也能滿足某些公司的要求,例如,完全部署在AWS上的網際網路產品公司使用ECS會比Kubernetes具有更佳的生產環境體驗,是的,也好於EKS。
話雖如此,Kubernetes的魔力在於:它可以部署在任何地方、它擁有一個活躍的社群,有數百個核心開發人員及數千個生態系統開源貢獻者。它執行快速、具有創新性、模組化且面向API,是一個對構建外掛或服務非常友好的系統。
好了,閑話少說,開始我們的旅程。介紹Kubernetes的11個部分:
1. Pod
Pod是Kubernetes中最小的可互動單元。一個Pod可以由多個容器組成,這些容器共同部署在單個節點上形成一個單元。一個Pod具有一個IP,該IP在其容器之間共享。
在微服務世界中,一個Pod可以是執行後臺工作或服務請求的微服務的單個實體。
2. Node(節點)
Node是機器。它們是Kubernetes用於部署Pod的“裸機”(或虛擬機器)。Node為Kubernetes提供可用的叢集資源用於以保持資料、執行作業、維護工作負載、建立網路路由等。
3. Label(標簽)與Annotation(註解)
Label是Kubernetes及其終端使用者用於過濾系統中相似資源的方式,也是資源與資源相互“訪問”或關聯的粘合劑。比如說,為Deployment開啟埠的Service。不論是監控、日誌、除錯或是測試,任何Kubernetes資源都應打上標簽以供後續查驗。例如,給系統中所有Worker Pod打上標簽:app=worker,之後即可在kubectl或Kubernetes API中使用–selector欄位對其進行選擇。
Annotation與Label非常相似,但通常用於以自由的字串形式儲存不同物件的元資料,例如“更改原因: 安全補丁升級”。
4. Service Discovery(服務發現)
作為編排系統,Kubernetes控制著不同工作負載的眾多資源,負責管理Pod、作業及所有需要通訊的物理資源的網路。為此,Kubernetes使用了ETCD。
ETCD是Kubernetes的“內部”資料庫,Master透過它來獲取所有資源的位置。Kubernetes還為服務提供了實際的“服務發現”——所有Pod使用了一個自定義的DNS伺服器,透過解析其他服務的名稱以獲取其IP地址和埠。它在Kubernetes叢集中“開箱即用”,無須進行設定。
5. ReplicaSet(副本集)
雖然Pod是一個物理性的執行任務,但通常使用單個實體是不夠的。為了冗餘並處理負載,出於某種原因(比如“伸縮”)需要對Pod進行複製。為了實現負責擴充套件和複製的層,Kubernetes使用了ReplicaSet。這個層以副本的數量表示系統的期望狀態,併在任意給定時刻保持該系統的當前狀態。
這也是配置自動伸縮的所在,在系統高負載時建立額外的副本,併在不再需要這些資源來支撐所執行的工作負載時進行縮容。
6. DaemonSet(守護行程集)
有時候,應用程式每個節點需要的實體不超過一個。比如FileBeat[1]這類日誌收集器就是個很好的例子。為了從各個節點收集日誌,其代理需要執行在所有節點上,但每個節點只需要一個實體。Kubernetes的DaemonSet即可用於建立這樣的工作負載。
7. StatefulSet(有狀態集)
儘管多數微服務涉及的都是不可變的無狀態應用程式,但也有例外。有狀態的工作負載有賴於磁碟捲的可靠支援。雖然應用程式容器本身可以是不可變的,可以使用更新的版本或更健康的實體來替代,但是所有副本還是需要資料的持久化。StatefulSet即是用於這類需要在整個生命週期內使用同一節點的應用程式的部署。它還保留了它的“名稱”:容器內的hostname以及整個叢集中服務發現的名稱。3個ZooKeeper構成的StatefulSet可以被命名zk-1、zk-2及zk-3,也可以擴充套件到更多的成員zk-4、zk-5等等……StatefulSets還負責管理PersistentVolumeClaim(Pod上連線的磁碟)。
8. Job(任務)
Kubernetes核心團隊考慮了大部分使用編排系統的應用程式。雖然多數應用程式要求持續執行以同時處理伺服器請求(比如Web伺服器),但有時還是需要生成一批作業併在其完成後進行清理。比如,一個迷你的無伺服器環境。為了在Kubernetes中實現這一點,可以使用Job資源。正如其名,Job的工作是生成容器來完成特定的工作,併在成功完成時銷毀。舉個例子,一組Worker從待處理和儲存的資料佇列中讀取作業。一旦佇列空了,就不再需要這些Worker了,直到下個批次準備好。
9. ConfigMap(配置對映)及Secret(機密配置)
如果你還不熟悉十二要素應用清單[2],請先行瞭解。現代應用程式的一個關鍵概念是無環境,並可透過註入的環境變數進行配置。應用程式應與其位置完全無關。為了在Kubernetes中實現這個重要的概念,就有了ConfigMap。實際上這是一個環境變數鍵值串列,它們會被傳遞給正在執行的工作負載以確定不同的執行時行為。在同樣的範疇下,Secret與正常的配置條目類似,只是會進行加密以防類似金鑰、密碼、證書等敏感資訊的洩漏。
我個人認為Hashicorp的Vault是使用機密配置的最佳方案。請務必閱讀一下我去年寫的有關文章[3],文章講述了將Vault作為生產環境一部分的原因,以及我的一位同事寫的另一篇更技術性的文章[4]。
10. Deployment(部署)
一切看起來都很美好,Pod可以正常執行,如果上層有ReplicaSet,還可以根據負載進行伸縮。不過,大家蜂擁而來,為的是能用新版本快速替換應用程式。我們想小規模地進行構建、測試和釋出,以縮短反饋週期。使用Deployments即可持續地部署新軟體,這是一組描述特定執行工作負載新需求的元資料。舉個例子,釋出新版本、錯誤修複,甚至是回滾(這是Kubernetes的另一個內部選項)。
在Kubernetes中部署軟體可使用2個主要策略:
  1. 替換——正如其名,使用新需求替換全部負載,自然會強制停機。對於快速替換非生產環境的資源,這很有幫助。

  2. 滾動升級——透過監聽兩個特定配置慢慢地將容器替換成新的:a. MaxAvailable——設定在部署新版本時可用的工作負載比例(或具體數量),100%表示“我有2個容器,在部署時要保持2個存活以服務請求”。b. MaxSurge——設定在當前存活容器的基礎上部署的工作負載比例(或數量),100%表示“我有X個容器,部署另外X個容器,然後開始滾動移除舊容器”。

11. Storage(儲存)
Kubernetes在儲存之上添加了一層抽象。工作負載可以為不同任務請求特定儲存,甚至可以管理超過Pod生命週期的持久化。為簡短起見,請閱讀作者之前釋出的關於Kubernetes儲存的文章[5],特別重點看看為什麼它不能完全解決類似資料庫部署這樣的資料永續性要求。

 

概念性理解

 

Kubernetes(現在仍然)是根據一些指導原則進行設計和開發的,構建在系統裡的每個功能、概念和想法都考慮了社群因素。此外,終端使用者會被引導以某種方式使用該系統,但這不是強迫的;最佳實踐也是公開的,但作為一個開源免費的系統,你完全可以根據自身需要進行操作。
面向API——系統每個部分構建時透過優良的檔案和可操作的API來實現可互動性。核心開發人員會確保終端使用者可以進行更改、查詢和更新,以免將其阻擋在外或有不想要的過濾器。
歡迎包裝工具——作為前一點的衍生產品,Kubernetes對在其API之上構建的工具和包裝器表示歡迎。作為一個原始平臺,Kubernetes是以一個非常可定製的方式進行構建的,以便他人使用,併進一步開發用於不同用例的工具。有些工具已經變得非常有名並被廣泛使用,比如Spinnaker、Istio等等。
宣告性狀態——鼓勵使用者在系統中使用宣告性描述而非命令式描述。這意味著,系統的狀態和元件最好被描述為在某種版本控制(如Git)中管理的程式碼,以此避免手工修改造成的困擾。因此,Kubernetes減少了災難恢復的難度、更易於在團隊之間分享並傳遞責任。
相關連結:
  1. https://www.elastic.co/products/beats/filebeat

  2. https://12factor.net/

  3. https://medium.com/prodopsio/security-for-dummies-protecting-application-secrets-made-easy-5ef3f8b748f7

  4. https://medium.com/prodopsio/taking-your-hashicorp-vault-to-the-next-level-8549e7988b24

  5. https://medium.com/prodopsio/k8s-will-not-solve-your-storage-problems-5bda2e6180b5

原文連結:https://medium.com/prodopsio/an-8-minute-introduction-to-k8s-94fda1fa5184

贊(0)

分享創造快樂