服務模型圖
服務進程
假設現在有五臺機器，我們給其中的三臺安裝了Mysql，那麼這三臺機器上就有了Mysql的服務進程，我們把三個服務進程叫做K8s的一個Service。在實際的應用中，通過在一臺機器上部署多個docker實例來達到這種效果。
服務隔離
然後給Service貼個標籤，比如起個名字“MySQL_XXX”。那麼，在k8s容器中，它就是唯一確定的一個服務，也就是k8s的一個pod對象，我們通過虛擬ip+端口號的方式可以訪問到這個Servidce。k8s通過貼標籤的方式實現了應用間的隔離。
服務通信
在k8s內部，Service的服務進程通過socket通信的方式對外提供服務。所以，k8s服務一定是實現了某個具體業務的TCP進程。
故障恢復
即使在使用的過程中，某個服務進程掛掉了或者重啓了，或者轉移到了其他的機器上，都不會影響我們對服務的正常調用，因爲這個Service本身一單創建就不會再變化了，我們也不用爲了服務ip地址的變化而頭疼了。
集羣管理
k8s將集羣中的機器劃分爲一個master節點和一堆工作節點node，
其中，master節點運行着集羣管理相關的一組進程kube-api-server、kube-controller-mananger和kube-scheduler，這些進程實現了整個集羣的資源管理、pod調度，彈性伸縮、安全控制、系統監控和糾錯等管理能力，並且都是全自動完成的。
node作爲集羣中的一個工作及誒單那，運行真正的應用程序，在node上k8s管理的最小運行單元是pod。node上運行着k8s的kubelet、kube-proxy服務進程，這些服務進程負責pod的創建、啓動、監控、重啓、銷燬以及實現軟件模式的負載均衡器。
服務擴容和升級
只需爲需要擴容的Service關聯的pod創建一個Reapplication
Controller（簡稱RC），則改Service的擴容以及後續的升級問題將迎刃而解。在一個RC定義文件中包含3個關鍵信息：目標pod的定義、目標pod需要運行的副本數量（replicas）、要監控的目標pod標籤（Label）。在創建好RC後，k8s會通過RC中定義的Label篩選出對應的pod實例並實施監控器狀態和數量。如果實例數量少於定義的副本數量，則會根據RC中定義的pod模板來創建一個新的pod，然後將pod調度到合適的node上啓動執行，直到pod實例的數量達到預定目標，這個過程完全是自動化。
核心概念
Master
k8s的管理節點，負責管理集羣，提供集羣的數據訪問入口，擁有Etcd存儲服務（可選）。運行Api Server進程，Controller
Manager服務進程及Scheduler服務進程，關聯工作及節點Node。
kubernetes Api Server**：提供Http
Rest接口的關鍵服務進程，是kubernetes裏所有資源的增刪改查等操作的唯一入口，也是集羣控制的入口進程。
kubernetes Controller Manager**：是kubernetes Controller
Manager是kuberbetes所有資源對象的自動化控制中心；
kubernetes Schedule**：是負責資源調度的（pod調度）進程。
Node
Node是kubernetes集羣架構中運行pod的服務及誒點。Node是kubernetes集羣操作的單元，用來成單被分配pod的運行，是pod的宿主機。關聯Master管理節點，擁有名稱和ip，系統資源信息。運行docker engine服務，守護進程kunelet以及負載均衡器kube-proxy。
kubelet：服務隊pod對於容器的創建，啓停等任務；
kube-proxy：實現kubernetes
Service的通信與負載均衡的重要組件； Docker Engine(Docker):負責本機容器的創建和管理工作。
Node節點可以在運行期間動態增加到kubernetes集羣中，默認情況下，kubelete會向master註冊自己，這也是Kubernetes推介的node管理方式，kubelet進程會定時向master彙報自身情報，如操作系統，docker版本，Cpu和內存，以及哪些pod在運行等等，這樣master可以在獲知每個node及誒點的資源使用情況，並實現高效負載均衡的資源調度策略。
Pod
運行在node節點上，若干相關容器的組合。pod內包含的容器運行在同一宿主機上，使用相同的網絡命名空間，ip地址和端口，能夠通過localhost進行通信。pod是kubernetes進行創建，調度和管理的最小單位，他提供了比容器更高層次的抽象，使得部署和管理更加靈活。一個pod可以包含一個容器或者多個相關容器。
pod其實有兩種類型，普通pod和靜態pod，後者比較特殊，它並不存在kubernetes村村中，而是存在在某個具體的node上的具體文件，並且只在此node上啓動。普通pod一單被創建，就會被放入etcd存儲中，隨後會被kubernetes master調度到某個具體的node上進行綁定，隨後改pod對應的node上的kubelet進程實例化成一組相關的docker容器並啓動起來。在默認情況下，當pod裏某個容器停止時，kubernetes會自動檢測到這個問題並且重啓這個pod（重啓pod裏所有進程）。如果pod所在的node宕機，則會將這個node上的所有pod重新調度到其他節點上。
Repplication Controller
Repplication Controller用來管理pod的副本，保證集羣中UC妮子啊指定數量的pod副本。集羣中副本數量大於指定數量，則會停止多餘容器數量。反之，則會啓動少於指定數量個數的容器。保證數量不便，Repplication Controller是實現彈性繩索，動態擴容和滾動升級的核心。
Service
Service定義了Pod的邏輯接和訪問該集合的策略，是真實服務的抽象。Service提供了一個統一的服務訪問入口以及服務代理和發現機制，關聯多個相同Label的Pod。用戶不需要了解後臺Pod是如何運行。
外部系統訪問Service的問題，需要弄明白kubernetes的三種Ip問題：
Node ip：Node節點的IP地址 Pod ip：Pod的IP地址 Cluster ip： Service的ip地址首先，Node IP是kubernetes集羣中節點的物理網卡IP地址。所有屬於這個網路ode服務器之間都你能通過這風格網絡直接通信。
Pod IP是每個Pod的ipo地址，它是Docker Enhine根據docker網橋的up地址段進行分配的，通常是虛擬二層網絡。
Cluster Ip是一個虛擬ip，更像一個僞造的ip網絡。
Label
Kubernetes中的任意API對象都是通過Label進行標識，Label的實質是一系列的Key/Value鍵值對，其中key於value由用戶自己指定。Label可以附加在各種資源對象上，如Node、Pod、Service、RC等，一個資源對象可以定義任意數量的Label，同一個Label也可以被添加到任意數量的資源對象上去。Label是Replication Controller和Service運行的基礎，二者通過Label來進行關聯Node上運行的Pod。
我們可以通過給指定的資源對象捆綁一個或者多個不同的Label來實現多維度的資源分組管理功能，以便於靈活、方便的進行資源分配、調度、配置等管理工作。
一些常用的Label如下：
版本標籤："release":"stable","release":"canary"......
環境標籤："environment":"dev","environment":"qa","environment":"production"
架構標籤："tier":"frontend","tier":"backend","tier":"middleware"
分區標籤："partition":"customerA","partition":"customerB"
質量管控標籤："track":"daily","track":"weekly"
Label相當於我們熟悉的標籤，給某個資源對象定義一個Label就相當於給它大了一個標籤，隨後可以通過Label Selector（標籤選擇器）查詢和篩選擁有某些Label的資源對象，Kubernetes通過這種方式實現了類似SQL的簡單又通用的對象查詢機制。
kube-Controller進程通過資源對象RC上定義Label Selector來篩選要監控的Pod副本的數量，從而實現副本數量始終符合預期設定的全自動控制流程
kube-proxy進程通過Service的Label Selector來選擇對應的Pod，自動建立起每個Service島對應Pod的請求轉發路由表，從而實現Service的智能負載均衡
通過對某些Node定義特定的Label，並且在Pod定義文件中使用Nodeselector這種標籤調度策略，kuber-scheduler進程可以實現Pod”定向調度“的特性。
參考博客：https://blog.csdn.net/weixin_43277643/article/details/83382532