从应用开发角度认识 K8s
生活随笔
收集整理的這篇文章主要介紹了
从应用开发角度认识 K8s
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
簡介：K8S作為目前最流行的云原生平臺架構，對于一組微服務的交互，持續化數據的存儲，或者實施多個具有依賴關系的微服務運行，以及容量規劃等問題，能夠提供一套自動化的系統性解決方案。
云原生應用
我們正經歷從單體應用轉向分布式微服務架構應用的技術趨勢。分布式微服務架構作為越來越多的軟件開發設計模式，以領域設計模型來指導業務需求的抽象與封裝。對業務的實體抽象還是邊界劃分，會以微服務架構作為落地點，形成微服務集群。并實施運行在云原生編排平臺。
云原生應用結構 from Kubernetes-Patterns
云原生應用的基石是干凈整潔，業務邏輯相對單一，并與其他領域對象獨立的代碼實現。這一階段保證業務質量的主要是編程基本功，以及高覆蓋率的自動化測試能力。
- 領域設計驅動是近年微服務技術熱潮下的主流設計模式，主要解決的問題是如何拆解一個復雜的業務場景需求到多個微服務單元。領域設計驅動是微服務架構的設計模式，微服務架構是基于領域設計模式的實現方式。一個微服務可以對應一個領域對象，也可以是一個領域服務。
- 分布式微服務架構實現的云原生應用具有高可用，彈性伸縮，容忍失敗以及健康自省等特點。它使得我們處理日益增長的業務需求的能力從開發編程的復雜性逐漸轉移到了資源整合，操作與管理的復雜性上。
- 微服務是單一的，運行在一個單進程中的簡單應用。容器技術恰好能夠提供這種隔離封裝，將一個簡單的微服務以Dockfile模版方式標準化，可無差別得運行在分布式集群的任意資源節點。
- K8S作為目前最流行的云原生平臺架構，對于一組微服務的交互，持續化數據的存儲，或者實施多個具有依賴關系的微服務運行，以及容量規劃等問題，能夠提供一套自動化的系統性解決方案。
用OOP方式解讀K8S
對于應用開發者，面向對象模式想必了然于胸。OOP設計了一套對一個邏輯對象的生命周期管理的方法論，類比OOP思路，筆者接下來詳細介紹一些K8S核心資源對象以及應用方式。
OOP vs K8S from Kubernetes-Patterns
構建/部署保持隔離性Pod/Deployment
Image
容器鏡像類比OOP的類，定義了一個模塊的全部屬性與功能，提供了唯一暴露在外的API調用方式以及參數集合，對應著一個獨立完整的發布周期，就像容器的設計藍圖。這種靜態定義方式，可以定義并初始化容器進行，使其在任意環境任意時刻行為完全一致。一個容器鏡像對應著一個微服務，屬于開發團隊的產物。
Container
容器類比OOP的對象，是容器鏡像的運行態。一個容器是一個容器鏡像的運行進程，而一個容器鏡像則可以在任意時刻任意環境下創建任何數量容器。
Pod
- Java應用開發者都知道基于Springboot-MVC框架的Java應用部署時只需提供一個Jar包，Jar包內部源碼被編譯后不可再改變。Pod是云原生編排平臺的資源調度部署的最小單元。Pod和容器的關系類似Java的Jar包和對象，應用開發者交付的容器鏡像通過Pod在K8S集群上部署并調度，容器則是Pod的內部資源對象，K8S無法感知也無法干預。
- K8S設計Pod為部署調度的最小單元，是因為Pod實現了內部一組容器在存儲空間，網絡空間及進程空間可共享該Pod資源，類似一個虛擬機上同時運行多個進程。容器間通信類似單節點進程間通信。Pod 的設計，就是要讓它里面的容器盡可能多地共享 Linux Namespace，僅保留必要的隔離和限制能力。
- Pod類似OOP的Module，即邏輯緊密的對象集合通常屬于一個獨立模塊。Pod的定義示例如下：
- Pod->spec下包含了一個或多個容器模版定義。PodYAML提供了很多屬性，有興趣深入的讀者可以參考學習https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/api/core/v1/types.go
- Pod->spec有一個很特殊的容器模版定義，關鍵詞為initContainer，顧名思義是做初始化的容器。初始化容器必須先于應用容器啟動執行完畢，并且只能執行成功。
- Pod->spec除了定義了容器模版，還定義容器間共享的存儲資源Volume掛載方式，和影響Pod資源調度的節點選擇器標簽，親和性以及容忍性等。
NameSpace
- 命名空間是一個組的概念，為集群資源提供了邏輯劃分的能力。這種使用方式類似OOP的Package。當項目變大，時常有同名的類或者對象，為了區分會以packge為路徑前綴，定義和引用相應對象。K8S集群中常常運行著數百個應用服務，也會出現同名資源的情況。命名空間可以在K8S上實現對一組資源對象隔離與權限管理。
- 命名空間最常用的場景是在一個K8S集群區分開發環境和測試環境。命名空間也可以提供多租戶運行環境，或者為了應用運行具有隔離性，為某個應用部署命名一個單獨的命名空間。
- 命名空間雖然提供了資源范圍邏輯劃分的能力，但是并沒有真正隔離一個集群內部Pod之間的通信，即屬于同一集群內的多個命名空間下的Pod仍能在集群內互相通信。如果需要做到命名空間之間的完全隔離，可以采用NetworkPolicy實現。
Deployment
- 在K8S運行的應用服務升級就是創建一個新版本Pod，并銷毀舊版本Pod的過程，由Deployment資源對象定義。微服務架構應用的數量成百上千，如果手動部署，則會引入人為錯誤并且部署操作很容易成為整個系統的瓶頸。K8S將部署Pod全部操作定義在Deployment資源對象，由平臺自動化地部署Pod。
- Deployment資源對象除了要定義部署Pod是什么樣的以外，還會定義預期部署狀態。比如，預期部署Pod數量，或在哪個節點上部署。
- 部署一個新版本要么生成新版本Pod，待健康檢查等確認新Pod可對外提供服務，再將舊版本Pod銷毀，最終達到預期部署狀態；要么就銷毀原有舊版本Pod，再生成新版本Pod，直到達到預期部署狀態。第一種方式為Rolling Update，好處是部署時沒有任何downtime，壞處是會存在多個版本同時提供服務，導致服務狀態不一致。第二種方式為Recreate，好處是在任意時刻都不會存在多個版本的應用服務，壞處則是部署時存在downtime。K8S默認的部署策略為Rolling Update。
- Deployment通過ReplicaSet控制器創建和管理Pod，確保Pod能如預期運行成功，并且滿足Deployment的部署定義，比如開啟幾個副本，滿足部署策略等。ReplicaSet解耦了部署與Pod運行，Pod處于Running狀態并不能代表應用部署成功。Deployment對Pod副本數量以及應用容器的Health Probe做了設置，以確保進程啟動以及應用運行成功。只有當新建ReplicaSet所屬的Pod運行成功，并且副本數量達到Deployment設置ReplicaSet的數量，舊的ReplicaSet管理的Pod不再承接任何負載或被銷毀時，Deployment達到預期部署狀態，才能代表部署成功。
構造器InitContainer
- 初始化在OOP中，比如Java類定義，是構造器。封裝了對象使用之前必要的初始化操作。初始化容器InitContainer，InitContainer是Pod級別的初始化，同理，是Pod->spec的一類特殊的容器模版定義，隔離了主應用容器進程與初始化操作，確保初始化操作能夠在應用容器啟動之前完成。
- 在容器級別也可以完成初始化，利用容器鏡像模版Dockerfile->ENTERPOINT定義。容器級別的初始化影響范圍是該容器鏡像定義內部，而Pod級別初始化操作InitContainer是對Pod內的全部容器組定義。一般情況下，容器初始化更多是Devops關心，與應用開發者工作相關性不大。InitContainer可以將初始化容器模版定義從研發周期上隔離。
- Pod級別初始化操作InitContainer的好處是可以統一設置訪問共享Volume的訪問權限；在應用服務啟動之前準備好依賴的組件或者數據；驗證應用服務運行的依賴運行健康等。在應用服務主容器進程啟動之前，確保前置條件準備完備，進而確保應用服務能夠運行成功。
- 處于訪問控制等安全性考慮，一般不建議在應用容器鏡像定義里開放Pod共享資源的訪問權限。我們盡量將Pod的共享資源管理操作留給編排平臺設置與控制，與應用服務本身隔離。最大化地確保應用服務本身不帶有平臺依賴屬性。所以，InitContainer也提升了微服務應用開發的安全性。
- 一個Pod模版可定義多個InitContainer以及多個應用容器。K8S確保InitContainer按定義順序依次執行初始化操作，在應用容器啟動前執行完畢，而應用容器啟動是并行的。
- InitContainer與一般的應用容器基本相同，但是，InitContainer一般為Completed，不會存在Failure終止狀態，因為當InitContainer執行失敗會直接導致Pod重啟，重新開始執行InitContainer。
組合模式Sidecar
- 在前文我們把容器鏡像和容器類比OOP的類和對象，因為容器鏡像定義了一個職責單一的應用微服務。那如果在應服務運行時，我們需要擴展或添加一些旁路操作，此時，類似OOP的組合設計模式，我們其實可以直接整合另一個容器鏡像定義到同一個Pod，這就是Sidecar。
- Sidecar保證了應用容器的職責單一，同時，也能在Pod級別為其添加更新數據，配置文件，靜態資源或者采集日志數據這種能夠獨立復用的旁路操作集合。Sidecar能夠通過組合多個職責單一的容器，提供一個功能完備，具備上線能力的應用微服務，同時，確保開發團隊只用考慮業務應用功能本身。
- Sidecar與InitContainer是兩種不同的容器定義。首先InitContainer定義的是Pod級別的初始化操作集合，必須在所有應用容器啟動之前執行完畢，具有嚴格的執行順序。Sidecar與應用容器執行順序沒有嚴格控制，兩者通常是同時運行在一個Pod內，共享Pod資源，共同完成Pod暴露的服務能力。
配置管理ConfigMap/Secret
- 應用開發的12原則中有一條是在環境中存儲配置。配置信息與應用隔離，可以通過環境變量來存儲應用的配置信息。環境變量具有全局性，可將其在應用進程運行時加載。當配置信息較大時，利用環境變量傳遞配置信息就不是什么好辦法了。Java-Springboot應用提供了Profile文件，記錄和保存應用相關的配置信息，開發者可以依據環境區分不同的Profile文件。
- 在K8S里配置管理ConfigMap和Secret同時支持環境變量Key/Value形式和應用配置Profile文件形式。環境變量的Key一般是全大寫字母字母表示；應用配置Profile文件是小寫字母表示額文件名。
- K8S提供Secret資源對象來配置敏感數據。比如，數據庫鏈接的用戶名，密碼等。
- ConfigMap與Secret對象通過Volume掛載到Pod里，所以該配置信息被Pod內的容器組共享。ConfigMap與Secret的數據存儲上限為1MB，故當應用配置文件過大，可考慮使用InitContainer初始化一個配置管理容器在同一個Pod下。在應用容器啟動前，傳遞應用配置到應用指定掛載目錄，從而更新應用配置信息。
異步/并發執行Job/Cronjob
- 應用開發過程中，常會面對批處理任務/定時任務需求。目前流行的應用框架，比如Java的Spring-Batch或者Python的Celery都可以實現異步任務/定時任務。但是這種應用級別的實現方法，在云原生中，會使應用服務實現的很重，比如異步任務通常要求所屬應用滿足高可用，資源彈性伸縮以及故障自愈。這些特性都是K8S平臺天然自帶的，可以考慮將應用的異步任務實現委托給K8S的Job/Cronjob控制器對象。
- K8S的Job控制器對象，類似Deployment，是創建與管理Pod生命周期的一種實現方式。與Deployment不同的是，Job控制的Pod是運行結束就終止，即Pod的終態為Completed。Job的Pod默認不會直接銷毀，主要目的是提供查看任務運行日志結果。
- K8S的Cronjob控制器對象，顧名思義，在Job對象之上組合了定時觸發事件邏輯。主要使用的場景包括但不限于文件傳輸，發送郵件或者短信通知，以及備份與定時清理過期備份等。
結語
筆者整理了一部分K8S基礎知識點的初衷是為了審視一下K8S這個龐大的技術棧里開發者掌握和使用K8S所要了解的最小知識點集合。筆者相信未來的應用都是建立在云之上，所以不論是哪個角色，都得掌握必要的K8S知識點才能流暢地開啟云原生開發之旅。
以上很多內容都是筆者在學習https://time.geekbang.org/column/intro/116以及Kubernetes-patternshttps://developers.redhat.com/blog/2020/05/11/top-10-must-know-kubernetes-design-patterns/時的心得和讀書體會，受益于大師們對K8S技術棧多種角度的解讀與梳理。
最后這次比較系統的學習梳理的契機也源于團隊對于K8S技術的重視，特別感謝團隊領導的重視與支持。
原文鏈接：https://developer.aliyun.com/article/778451?
版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。總結
以上是生活随笔為你收集整理的从应用开发角度认识 K8s的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Fluid 0.4 新版本正式发布
- 下一篇： Serverless化微服务架构实战