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的實現必不可少。