Kubernetes 脫胎於 Google 的 Borg 系統,是一個功能強大的容器編排系統。Kubernetes 及其整個生態系統(工具、模塊、插件等)均使用 Go 語言編寫,從而構成一套面向 API、可高速運行的程序集合,這些程序文檔精良、易於參與貢獻或在其上構建應用程序。數據庫
每一個開發、運維或感興趣的讀者都應熟悉它的一些核心概念,以便理解這個系統及其不一樣的功能,以及爲何幾乎全部人都在使用它。安全
在繼續以前,我想提一下 Kubernetes 的幾個頂級朋友(或競爭對手):ECS、Nomad 和 Mesos。ECS 是 AWS 本身的編排解決方案,最近它又推出了託管在 AWS 上的 Kubernetes 系統——EKS。二者都支持 FARGATE,讓用戶無須關心所運行的物理資源。服務器
Kubernetes 毫無疑問是最大贏家,做爲一個開源系統,三大主流雲服務商都以託管的方式提供了這項功能。可是,它比其餘幾個產品都要來得複雜和混亂。Kubernetes 能夠處理幾乎任何類型的容器負載,也有不少技巧,但這並不意味着每一個人都應該使用它。其餘解決方案或許也能知足某些公司的要求,例如,徹底部署在 AWS 上的互聯網產品公司,使用 ECS 會比 Kubernetes 具備更佳的生產環境體驗,是的,也好於 EKS。網絡
話雖如此,Kubernetes 的魔力在於:它能夠部署在任何地方、它擁有一個活躍的社區,有數百個核心開發人員及數千個生態系統開源貢獻者。它運行快速、具備創新性、模塊化且面向 API,是一個對構建插件或服務很是友好的系統。app
好了,閒話少說,開始咱們的旅程。運維
Pod 是 Kubernetes 中最小的可互動單元。一個 Pod 能夠由多個容器組成,這些容器共同部署在單個節點上造成一個單元。一個 Pod 具備一個 IP,該 IP 在其容器之間共享。 在微服務世界中,一個 Pod 能夠是執行後臺工做或服務請求的微服務的單個實例。模塊化
Node 是機器。它們是 Kubernetes 用於部署 Pod 的「裸機」(或虛擬機)。Node 爲 Kubernetes 提供可用的集羣資源用於以保持數據、運行做業、維護工做負載、建立網絡路由等。微服務
Label 是 Kubernetes 及其最終用戶用於過濾系統中類似資源的方式,也是資源與資源相互「訪問」或關聯的粘合劑。好比說,爲 Deployment 打開端口的 Service。不管是監控、日誌、調試或是測試,任何 Kubernetes 資源都應打上標籤以供後續查驗。例如,給系統中全部 Worker Pod 打上標籤:app=worker,以後便可在 kubectl 或 Kubernetes API 中使用 --selector 字段對其進行選擇。 Annotation 與 Label 很是類似,但一般用於以自由的字符串形式保存不一樣對象的元數據,例如「更改緣由: 安全補丁升級」。工具
做爲編排系統,Kubernetes 控制着不一樣工做負載的衆多資源,負責管理 Pod、做業及全部須要通訊的物理資源的網絡。爲此,Kubernetes 使用了 ETCD。測試
ETCD 是 Kubernetes 的「內部」數據庫,Master 經過它來獲取全部資源的位置。Kubernetes 還爲服務提供了實際的「服務發現」——全部 Pod 使用了一個自定義的 DNS 服務器,經過解析其餘服務的名稱以獲取其 IP 地址和端口。它在 Kubernetes 集羣中「開箱即用」,無須進行設置。
雖然 Pod 是一個物理性的運行任務,但一般使用單個實例是不夠的。爲了冗餘並處理負載,出於某種緣由(好比「伸縮」)須要對 Pod 進行復制。爲了實現負責擴展和複製的層,Kubernetes 使用了 ReplicaSet。這個層以副本的數量表示系統的指望狀態,並在任意給定時刻保持該系統的當前狀態。
這也是配置自動伸縮的所在,在系統高負載時建立額外的副本,並在再也不須要這些資源來支撐所運行的工做負載時進行縮容。
有時候,應用程序每一個節點須要的實例不超過一個。好比 FileBeat 這類日誌收集器就是個很好的例子。爲了從各個節點收集日誌,其代理須要運行在全部節點上,但每一個節點只須要一個實例。Kubernetes 的 DaemonSet 便可用於建立這樣的工做負載。
儘管多數微服務涉及的都是不可變的無狀態應用程序,但也有例外。有狀態的工做負載有賴於磁盤卷的可靠支持。雖然應用程序容器自己能夠是不可變的,可使用更新的版本或更健康的實例來替代,可是全部副本仍是須要數據的持久化。StatefulSet 便是用於這類須要在整個生命週期內使用同一節點的應用程序的部署。
它還保留了它的「名稱」:容器內的 hostname 以及整個集羣中服務發現的名稱。3 個 ZooKeeper 構成的 StatefulSet 能夠被命名 zk-一、zk-2 及 zk-3,也能夠擴展到更多的成員 zk-四、zk-5 等等…… StatefulSets 還負責管理 PersistentVolumeClaim(Pod 上鍊接的磁盤)。
Kubernetes 核心團隊考慮了大部分使用編排系統的應用程序。雖然多數應用程序要求持續運行以同時處理服務器請求(好比 Web 服務器),但有時仍是須要生成一批做業並在其完成後進行清理。好比,一個迷你的無服務器環境。 爲了在 Kubernetes 中實現這一點,可使用 Job 資源。正如其名,Job 的工做是生成容器來完成特定的工做,並在成功完成時銷燬。舉個例子,一組 Worker 從待處理和存儲的數據隊列中讀取做業。一旦隊列空了,就再也不須要這些 Worker 了,直到下個批次準備好。
若是你還不熟悉十二要素應用清單,請先行了解。現代應用程序的一個關鍵概念是無環境,並可經過注入的環境變量進行配置。應用程序應與其位置徹底無關。爲了在 Kubernetes 中實現這個重要的概念,就有了 ConfigMap。實際上這是一個環境變量鍵值列表,它們會被傳遞給正在運行的工做負載以肯定不一樣的運行時行爲。在一樣的範疇下,Secret 與正常的配置條目相似,只是會進行加密以防相似密鑰、密碼、證書等敏感信息的泄漏。
我我的認爲 Hashicorp 的 Vault 是使用機密配置的最佳方案。請務必閱讀一下我去年寫的有關文章,文章講述了將 Vault 做爲生產環境一部分的緣由,以及個人一位同事寫的另外一篇更技術性的文章。
一切看起來都很美好,Pod 能夠正常運行,若是上層有 ReplicaSet,還能夠根據負載進行伸縮。不過,你們蜂擁而來,爲的是能用新版本快速替換應用程序。咱們想小規模地進行構建、測試和發佈,以縮短反饋週期。使用 Deployments 便可持續地部署新軟件,這是一組描述特定運行工做負載新需求的元數據。舉個例子,發佈新版本、錯誤修復,甚至是回滾(這是 Kubernetes 的另外一個內部選項)。 在 Kubernetes 中部署軟件可以使用 2 個主要策略:
替換——正如其名,使用新需求替換所有負載,天然會強制停機。對於快速替換非生產環境的資源,這頗有幫助。
滾動升級——經過監聽兩個特定配置慢慢地將容器替換成新的:
a. MaxAvailable——設置在部署新版本時可用的工做負載比例(或具體數量),100% 表示「我有 2 個容器,在部署時要保持 2 個存活以服務請求」; b. MaxSurge——設置在當前存活容器的基礎上部署的工做負載比例(或數量),100% 表示「我有 X 個容器,部署另外 X 個容器,而後開始滾動移除舊容器」。
Kubernetes 在存儲之上添加了一層抽象。工做負載能夠爲不一樣任務請求特定存儲,甚至能夠管理超過 Pod 生命週期的持久化。爲簡短起見,請閱讀做者以前發佈的關於 Kubernetes 存儲的文章,特別重點看看爲何它不能徹底解決相似數據庫部署這樣的數據持久性要求。
Kubernetes(如今仍然)是根據一些指導原則進行設計和開發的,構建在系統裏的每一個功能、概念和想法都考慮了社區因素。此外,最終用戶會被引導以某種方式使用該系統,但這不是強迫的;最佳實踐也是公開的,但做爲一個開源免費的系統,你徹底能夠根據自身須要進行操做。
面向 API——系統每一個部分構建時經過優良的文檔和可操做的 API 來實現可交互性。核心開發人員會確保最終用戶能夠進行更改、查詢和更新,以避免將其阻擋在外或有不想要的過濾器。
歡迎包裝工具——做爲前一點的衍生產品,Kubernetes 對在其 API 之上構建的工具和包裝器表示歡迎。做爲一個原始平臺,Kubernetes 是以一個很是可定製的方式進行構建的,以便他人使用,並進一步開發用於不一樣用例的工具。有些工具已經變得很是有名並被普遍使用,好比 Spinnaker、Istio 等等。
聲明性狀態——鼓勵用戶在系統中使用聲明性描述而非命令式描述。這意味着,系統的狀態和組件最好被描述爲在某種版本控制(如 Git)中管理的代碼,以此避免手工修改形成的困擾。所以,Kubernetes 減小了災難恢復的難度、更易於在團隊之間分享並傳遞責任。
原文連接:https://medium.com/prodopsio/an-8-minute-introduction-to-k8s-94fda1fa5184<br />
掃描下方二維碼添加小助手,與 8000 位雲原生愛好者討論技術趨勢,實戰進階!
進羣暗號:公司-崗位-城市