雲原生Kubernetes全棧架構師實戰

本書比較全面的介紹了k8s以及以其爲基礎所涉及到雲原生應用各方面的知識，理論知識涉及相對較少，全書充斥着大量的實踐應用，對於k8s的學習來說這是合適的，因爲k8s不是看會的，是練會的，正如作者所言，要想學會k8s至少要搭建8次k8s集羣，所以一定要動手實踐反覆練習。

一本詳略得當的書，既可當作工具書用來翻閱，對 k8s 的初學者來說，作爲入門書籍也比較恰當。書中講解了雲原生涉及到的大部分比較實用的技術棧，但是有些技術則是大公司不屑用小公司不會用，不過拿來學習和練習也是比較不錯的。

雖然讀不太懂，但感覺內容很全，面面俱到，可以作爲實操的輔助工具書，比較實用

太細節了，光裝 k8s 就有40 頁，第一遍看直接勸退。第二遍勉強翻到了最後。

寫的挺好，雖然有些地方講的不夠深入

比較適合開發和運維閱讀了解雲原生和k8s的一本書，有概念、原理和實踐講述，循序漸進。 可以挑着看，比如k8s核心概念相關的1～10章（除第二章外）詳讀，有利於對k8s有大致理解。其他章節是擴展內容略讀，有助於瞭解雲原生生態組件，窺探企業級實踐的一部分。 不過個人覺得還是要有一定的devops實踐/使用經驗，才能更好理解書中講述的知識點。我閱讀的時候總會聯想到這幾年來使用公司內部devops平臺的一些場景，有助於理解，偶爾會有“原來如此”的感嘆。假如我是沒有任何使用經驗的開發者，我估計很難看下去。 我相信k8s還會在服務端屹立不倒十幾年，因爲它是從全球最大的生產流量實戰中誕生的。它的核心設計是簡潔的，比如用抽象的CRI/CNI/CSI標準描述服務端應用最核心的基礎設施；它的功能非常豐富，滿足服務應用在持續擴張和運維的需求（高可用，低維護成本，高資源利用率，使用靈活，安全防護，可擴展性高）；它的生態十分完善，全球互聯網公司都在用k8s，各式各樣的生產場景落地不斷反哺k8s，雲原生基金會陸續孵化衍生產品，擴大影響力。 這次閱讀挺有收穫的，特別推薦和我一樣，一直有使用devops平臺但未了解過其原理的服務端開發者閱讀。

一、K8S的基礎概念在應用端口方面，傳統架構中，一臺服務器可能跑了很多進程，每個進程都有一個端口，需要人爲地去配置端口，並且還需要考慮端口衝突的問題，如果有防火牆的話，還需要配置防火牆。在Kubernetes中，端口統一管理、統一配置，每個應用的端口都可以設置成一樣的，之後通過Service進行負載均衡，大大降低了端口管理的複雜度和端口衝突。 Kubernetes架構可簡單分爲主（Master）節點、從（工作/Worker/Node）節點和數據庫Etcd。其中主節點爲集羣的控制單元，一般不會運行業務應用程序，主要包含的組件有Kube-APIServer、Kube-ControllerManager、Kube-Scheduler。從節點爲工作節點，也就是部署應用程序容器的節點，主要包含的組件有Kubelet、Kube-Proxy，當然如果Master節點也要部署容器，也會包含這兩個組件。 負載均衡可以使用軟件負載均衡Nginx/LVS/HAProxy+KeepAlived或者硬件負載均衡F5等，通過負載均衡對Kube-APIServer提供的VIP即可實現Master節點的高可用，其他組件通過該VIP連接至Kube-APIServer。 Node節點包括：·　Kubelet：負責與Master通信協作，管理該節點上的Pod，對容器進行健康檢查及監控，同時負責上報節點和節點上面Pod的狀態。·　Kube-Proxy：負責各Pod之間的通信和負載均衡，將指定的流量分發到後端正確的機器上。·　Docker Engine：Docker引擎，負載對容器的管理。 Pod可簡單地理解爲一組、一個或多個容器，每個Pod還包含一個Pause容器，Pause容器是Pod的父容器，它主要負責殭屍進程的回收管理，同時通過Pause容器可以使同一個Pod裏面的不同容器共享存儲、網絡、PID、IPC等，容器之間可以使用localhost:port相互訪問，可以使用Volume等實現數據共享。根據Docker的構造，Pod可被建模爲一組具有共享命名空間、卷、IP地址和端口的容器。 在生產環境中，很少單獨運行一個Pod，因爲單獨創建的Pod並不能實現一些高級的發佈策略，所以在實際使用中經常會用Deployment、DaemonSet、StatefulSet等高級控制器調度並管理Pod。 二、K8S的調度基礎Replication Controller和ReplicaSet的創建、刪除和Pod並無太大區別，Replication Controller目前幾乎已經不在生產環境中使用，ReplicaSet也很少單獨被使用，都是使用更高級的資源Deployment、DaemonSet、StatefulSet管理Pod。 ReplicaSet可以確保在任何給定時間運行的Pod副本達到指定的數量，但是Deployment是一個更高級的概念，它管理ReplicaSet併爲Pod和ReplicaSet提供聲明性更新以及許多其他有用的功能，所以建議在生產環境下使用Deployment代替ReplicaSet。Deployment一般用於部署公司的無狀態服務，這個也是最常用的控制器，因爲企業內部現在都是以微服務爲主，而微服務實現無狀態化也是最佳實踐，可以利用Deployment的高級功能做到無縫遷移、自動擴容縮容、自動災難恢復、一鍵回滾等功能。 StatefulSet管理的Pod部署和擴展規則如下：·　對於具有N個副本的StatefulSet，將按順序從0到N‒1開始創建Pod。·　當刪除Pod時，將按照N‒1到0的反順序終止。·　在縮放Pod之前，必須保證當前的Pod是Running（運行中）或者Ready（就緒）。·　在終止Pod之前，它所有的繼任者必須是完全關閉狀態。 有時候我們需要在每個Kubernetes節點或符合條件的節點上都部署某個應用，那麼就可以使用Kubernetes的DaemonSet調度Pod。 三、K8S的服務發佈基礎在傳統架構配置多個相同服務的負載均衡可能使用的是Nginx的upstream，在Kubernetes中用Service實現。在傳統架構配置域名訪問應用可能使用Nginx的Server配置，在Kubernetes中用Ingress實現域名路由的配置（最終通過Ingress的配置生成對應控制器的配置，比如使用Nginx作爲Ingress控制器，Ingress資源最終生成的就是Nginx的配置文件）。 很多情況下，我們需要對各類資源進行分組管理，或者同一個應用的Pod可能會根據不同的功能進行劃分，比如有一個後端的應用，需要提供API接口供前端調用，也需要進行一些週期性的計劃任務，相當於同一個鏡像分兩個身份運行，所以就需要對這兩個資源文件用標籤進行區分，這樣的話就可以讓流量進入提供API接口的Pod，執行計劃任務的Pod不接收任何流量。 Service主要用於Pod之間的通信，對於Pod的IP地址而言，Service是提前定義好並且是不變的資源類型，在生產環境中最佳的實踐方式就是每個應用互相調用時使用Service的名字進行連接，而非IP地址。 假設有一個用作圖片處理的backend（後端），運行了3個副本，每個副本具有一個app=backend的Label，這些副本是可互換（無狀態）的，之後創建一個Service指定Selector爲app=backend，那麼frontend（前端）即可通過這個Service的名稱直接訪問backend，所以frontend不需要關心它調用了哪個backend副本。即使組成這一組backend程序的Pod發生了變化，frontend也沒有必要知道，而且也不需要跟蹤這一組backend的狀態，因爲Service能夠解耦這種關聯。 Kubernetes Service Type（服務類型）主要包括以下幾種：·　ClusterIP：在集羣內部使用，默認值，只能從集羣中訪問。·　NodePort：在所有安裝了Kube-Proxy的節點上打開一個端口，此端口可以代理至後端Pod，可以通過NodePort從集羣外部訪問集羣內的服務，格式爲NodeIP:NodePort。·　LoadBalancer：使用雲提供商的負載均衡器公開服務，成本較高。·　ExternalName：通過返回定義的CNAME別名，將Service映射到可被DNS解析的其他域名，需要1.7或更高版本kube-dns的支持。 在使用Kubernetes時，部署一個應用並使用域名進行發佈的流程如下：1）部署應用至Kubernetes集羣，容器內定義了程序啓動的方式。2）配置ClusterIP類型的Service，通過Selector鏈接到容器內的應用。3）配置Ingress鏈接到該應用的Service，之後將域名解析到Ingress（Ingress前面可能還有其他代理服務器）對應的宿主機上即可。 本章講解了服務發佈的兩種方式，即Service和Ingress。通常情況下，Service用於程序間的內部訪問，即後端服務之間的相互調用。而Ingress多用於對外發布服務，即通過域名的形式讓用戶能訪問到內部服務，這也是最普遍的發佈方式，但是如果一個不需要對外發布的後端服務，通過Ingress被另一個後端服務調用，則相當於從外部繞了一圈，這不是推薦的方式。 實際使用時，也會有架構直接通過Service的NodePort暴露服務，然後由上層的網關進行代理，域名都配置在上層，這樣的話，服務過多會引起端口維護非常複雜，可能還會有性能損耗。所以一般推薦在上層配置通配符域名，比如*.test.com到Kubernetes的Ingress Controller，之後由Ingress再做路由。比如a.test.com指向A項目，a.test.com/xxx指向A項目的xxx服務。 另外在程序設計時，有了Service無須再考慮負載均衡等問題，所以如果有程序間的調用，首選Service，並且以後可以無縫地接入服務網格，進行服務治理。在使用Kubernetes時，其實並不推薦使用Spring Cloud這類架構，因爲很多功能都是類似的，在Kubernetes上仍舊使用Spring Cloud屬於“套娃”型架構，應該向着單服務方向進行開發，比如直接使用Spring Boot即可。 雖然Operator和Helm實現的功能類似，但是兩者還是有很大的區別的。Operator更傾向於管理複雜的有狀態服務，比如MySQL集羣、Redis集羣、TiDB集羣等，而Helm更傾向於管理無狀態應用的部署，比如公司的服務、某些不需要持久化數據的中間件、不需要實現額外功能的服務等。 四、拓展篇服務網格（Service Mesh）是由Buoyant公司的CEO William Morgan發起的，他對服務網格的定義如下：·　專用基礎設施層：獨立的運行單元。·　包括數據層和控制層：數據層負責交付應用請求，控制層控制服務如何通信。·　輕量級透明代理：實現形式爲輕量級網絡代理。·　處理服務間通信：主要目的是實現複雜網絡中的服務間通信。·　可靠地交付服務請求：提供網絡彈性機制，確保可靠交付請求。·　與服務部署一起，但服務無須感知：儘管跟應用部署在一起，但對應用是透明的。 Istio最爲重要的一個概念就是VirtualService（虛擬服務），和Kubernetes的Service類似，但是兩種並不是對等的資源類型。VirtualService基於Istio和對應平臺提供的基本連通性和服務發現能力，將請求路由到對應的目標。每一個VirtualService包含一組路由規則，Istio將每個請求根據路由匹配到指定的目標地址。 和Kubernetes的Service不同的是，Kubernetes的Service只提供了最簡單的服務發現和負載均衡的能力，如果想要實現更加細粒度的流量分發，比如灰度、藍綠等流量管理，Kubernetes的Service顯得比較喫力或者無法實現，而VirtualService在流量管理方面有着比較好的靈活性和有效性，可以在代碼零侵入的情況下實現更加豐富的流量管理，比如灰度等。

二進制部署那節沒問題，我修改TLS Bootstrapping的$token_id"和"$token_secret，相應在bootstrap.secret.yaml修改3個地方： metadata: name: bootstrap-token-${token_id} stringData: token-id: ${token_id} token-secret: ${token_secret}

這本書內容全面，雖然沒有很深入，但對於入門和建立全局視角很有幫助

基本上方方面面都講到了，可以作爲入門或者檢驗自己知識體系的工具書