K8S是管理業務程式的，所以可推出K8S自身肯定有管理端，相應的，K8S負責管理的節點可以叫做Master節點，K8S中負責業務程式的節點，可以叫做Worker節點，
Worker組件結構
基本物理結構如下：
其中，Node就對應于一臺實際的服務器，也叫位元組點，一個Node上可以有多個Pod，Pod就是K8S調度的最小單位，每個Pod中又可以有多個容器，這里的容器就是Docker或者其他容器實作，
如果將容器看做是一般意義上的行程，那么每個Pod又可以看做是一個行程組，
這樣，整個K8S內部結構可以看成：
由于Pod是最小的調度單位，當一個Pod例外時，K8S會重新拉起Pod，此時新的Pod有可能部署到其他Node上，對于外部應用來說，不可能直接去尋址Pod，所以要引入一個中間抽象層，這個抽象層就是Service，
所以加入Service后，就可以表現為：注意，其中的Service是抽象層，就是對Pod的或者Service的進一步封裝，
一個服務器對應一個Node，每個Node又包含幾個關鍵組件，Node內部整體結構如下：
-
kubelet：就是管理這個Node，負責Pod的管理并和Master通信
-
kube-proxy：類似反向代理，將外部流量代理到Pod中，也是實作Service抽象機制的關鍵
-
Container Runtime：就是容器運行時，如果是Docker容器，那么就是Docker Engine，
Master組件結構
-
客戶端：指的是比如我們通過命令列控制K8S的行為，命令列工具為 kubectl，那么它就是客戶端，
-
kube-apiserver：因為Master節點提供了一些可以控制K8S行為的API介面，如果要呼叫這些介面，就需要通過 kube-apiserver來執行，
-
kube-controller-manager：維持K8S各資源處于正常狀態
-
kube-scheduler：調度Pod到最合適的Node上
-
Etcd：持久化存盤，用來存盤K8S集群內部正常運轉需要的資料資訊
根據宣告式API啟動創建pod流程
理清流程的目的，是對網路流量走向做到心中有數，
首先，什么是宣告式API，見下圖：
也是就是一個yaml檔案，里面的欄位就是K8S規定的描述欄位，然后只需要通過客戶端kubectl 來執行這個yaml即可，等執行完成后，我們需要的Pod或者service就已經啟動好了，這一切都是自動實作的，所以這就是宣告式API，
整理流程如下：
經過流程圖我們就可以看出來，圖中沒有體現 Service和kube-proxy這兩個關鍵概念，所以接下來我們要看下K8S網路，否則無法真正在線上進行部署，
K8S網路和Service
K8S網路
實際生產中，一個完整的流程為：外部流量匯入K8S集群，集群內流量匯入對應的Service，因為Service是抽象概念，所以是流量匯入到Node，最后匯入到具體的Pod中，
上述程序就體現了四種網路層次，分別是：
-
物理層的Node網路：就是服務器之間的實際ping通的網路
-
構建在Node之上的Pod網路：也就是pod之間通信的網路，因為pod才是真正的物體
-
實作抽象Service功能的網路：因為有Serviec抽象層，所以Service肯定通過某種機制對流量做了轉發控制，才能夠實作代理的功能，
-
溝通K8S集群和外部環境的網路
對于K8S網路的流量路由，目前還不是重點，需要單獨來看，現在只要清楚實際生產中，需要匯入外部流量，而且我們直接關注是Service，所以只要理清Service如何處理外部流量和內部流量，
K8S的Service
K8S提供了多種Service，如下：
-
NodePort：顧名思義，就是在Node節點上，開了一個port，所以NodePort是節點之間，或者說是節點外部流量的關鍵入口，也就是NodePort Service是最基礎的Service，所以上文才提到了Service嵌套，
-
ClusterIp：就是集群內部的反向代理，用于集群的Pod之間通信
-
LoadBalancer：就是接入外部流量
前文提到，Service具有負載均衡的功能，所以Service有一種標簽label機制，就和域名一樣，根據label來尋址，所以又會配合kube-dns實作DNS的效果，
這樣，Service就可以實作服務發現并轉發流量，轉發流量就是通過 kube-proxy執行的，但是和一般的反向代理不一樣，流量并不會經過kube-proxy內部，因為kube-proxy是直接修改Node的iptables轉發規則，所以沒有性能損耗，
K8S接入外部網路的實作
-
通過NodePort對外映射埠
-
通過LoadBalancer對接外部流量
-
通過Ingress實作
NodePort通過kube-proxy可以對外提供流量入口，每個Node都可以像這樣對外提供入口，所以如何進行負載均衡呢？這就是 LoadBalancer需要解決的問題，雖然LoadBalancer可以解決，但是一個LoadBalancer只能代理一種我們的服務，因為他只是轉發全部的流量到對應的kube-proxy，
所以，Ingress就是解決這個問題的方案，Ingress一側對接負載均衡，接入外部流量，一側對接內部的Service，根據請求域名等實作流量轉發，
所以，真正生產環境可用，ingress或者說類似ingress的實作必不可少，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/246154.html
標籤：其他