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

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)

分享創造快樂