目錄

一、理論

1.云原生

2.K8S

3.k8s集群架構(gòu)與組件

4.K8S網(wǎng)絡

二、總結(jié)

一、理論

1.云原生

（1）概念

云原生是一種基于容器、微服務和自動化運維的軟件開發(fā)和部署方法。它可以使應用程序更加高效、可靠和可擴展，適用于各種不同的云平臺。

如果要更直接通俗的來解釋下上面的概念，云原生更準確來說就是一種文化，是一種潮流，它是云計算時代的一個必然導向，更重要的意義在于讓云能夠成為云化戰(zhàn)略成功的基石，而不是障礙。

（2）架構(gòu)

①?微服務

內(nèi)聚更強，更加敏捷。把一個龐大的app拆成幾個獨立小的獨立服務，再把服務串起來的一種架構(gòu)設(shè)計。

②?DevOps

以終為始，運維合一。不是工具或技術(shù)，是一組過程、方法與系統(tǒng)的統(tǒng)稱，用于促進開發(fā)、技術(shù)運營和質(zhì)量保障部門之間的溝通、寫作與整合。

③??容器化

資源調(diào)度、微服務更容易。一種輕量級的虛擬化技術(shù)，能夠在單一主機上提供多個隔離的操作系統(tǒng)環(huán)境，通過一系列的namespace進行進程隔離，每一個容器都有唯一的可寫文件系統(tǒng)和資源配額。

④?持續(xù)交付

縮小開發(fā)者認知，靈活開發(fā)方向。

（3）價值

云原生應用程序具有許多優(yōu)點，這也是為什么越來越多的人開始推廣使用云原生的原因。

①?更快地部署和擴展

由于容器化應用程序可以輕松地在不同的云平臺上移植，因此它們可以更快地部署到云平臺上。此外，由于每個微服務都是獨立的，可以根據(jù)需要獨立擴展，而無需影響整個應用程序。

②?更好地利用云資源

容器化應用程序可以更好地利用云平臺的資源，因為它們可以在需要時動態(tài)分配和釋放資源。此外，由于微服務架構(gòu)將應用程序拆分成小型服務單元，可以更好地利用資源，從而提高了應用程序的效率。

③??更好的可維護性和可靠性

由于自動化運維工具可以自動化部署、監(jiān)控和管理應用程序，因此可以減少人工干預和錯誤，從而提高了應用程序的可靠性和可維護性。

云原生應用程序具有更快的部署和擴展速度、更好的資源利用率以及更好的可維護性和可靠性等優(yōu)點，這使得越來越多的人開始推廣云原生。

（4）實現(xiàn)

①?容器化應用

容器化是云原生的核心概念之一。通過將應用程序打包到容器中，可以更輕松地在不同的環(huán)境中部署和運行應用程序。Docker 是目前最流行的容器化工具之一，可以幫助容器化應用程序。

此外這里也推薦類似 FinClip 這樣的小程序容器，能夠?qū)⒃械膹碗s App 解耦，拆成多個獨立的小程序跑起來，在運行互補影響的情況下，還能把服務串起來。

②?使用容器編排工具

一旦應用程序被容器化，需要使用容器編排工具來管理它們。容器編排工具可以幫助在集群中部署和管理容器，例如 Kubernetes 和 Docker Swarm。

③?利用云原生服務

大多數(shù)云提供商都提供了一些云原生服務，用于簡化開發(fā)和部署云原生應用程序。例如，Elastic Kubernetes Service（EKS）、Kubernetes Engine 等。

④?實踐 DevOps

DevOps 實踐是云原生開發(fā)的重要組成部分。通過實踐 DevOps，可以實現(xiàn)持續(xù)集成和持續(xù)交付，并通過自動化測試和部署來提高應用程序的質(zhì)量和可靠性。

⑤?遵循云原生最佳實踐

最后，應該遵循云原生的最佳實踐來確保應用程序在云環(huán)境中運行良好。這包括使用微服務架構(gòu)來提高可擴展性和可靠性，使用容器鏡像來確保應用程序的一致性，以及減少應用程序的依賴性。

⑥??總結(jié)

如今，在IT領(lǐng)域中，云計算的出現(xiàn)和發(fā)展相當于數(shù)字世界的“全球化”大發(fā)現(xiàn)，而云原生則等于“集裝箱式”創(chuàng)新變革。正是隨著云計算服務和容器技術(shù)的發(fā)展，越來越多的軟件開發(fā)人員和IT運營與維護管理員開始改變過去獨立開發(fā)操作的傳統(tǒng)模式，從而提出了基于云計算特性的新軟件應用程序開發(fā)架構(gòu)和模型。

要使企業(yè)業(yè)務真正云化，不僅必須在基礎(chǔ)設(shè)施和平臺層面實現(xiàn)，而且應用本身也應基于云特性進行開發(fā)。從本質(zhì)上講，云原生就是基于云開發(fā)，部署和維護的架構(gòu)的基礎(chǔ)。

2.K8S

（1）概念

K8S 的全稱為?Kubernetes(k12345678s)

（2）作用

? ??? ? 用于自動部署、擴展和管理“容器化( containerized) 應用程序”的開源系統(tǒng)

? ? ? ? 可以理解成K8S是負責自動化運維管理多個容器化程序(比如Docker)的集群，是–個生態(tài)極其豐富的容器編排框架工具

（3）由來
k8s 有g(shù)oogle的Borg系統(tǒng)（博格系統(tǒng)，google內(nèi)部使用的大規(guī)模容器容器編排工具）作為原型，后經(jīng)GO語言延用Borg的思路重寫并捐獻給CNCF基金會開源。

含義：

根源于希臘語的舵手、飛行員

官網(wǎng)：

https://kubernetes.io

GitHub:

https://github.com/kubernetes/kubernetes

（4）背景

? ? ? ? 試想下傳統(tǒng)的后端部署辦法:把程序包(包括可執(zhí)行二進制文件、配置文件等)放到服務器上，接著運行啟動腳本把程序跑起來，同時啟動守護腳本定期檢查程序運行狀態(tài)、必要的話重新拉起程序，如果服務的請求量上來，已部署的服務響應不過來怎么辦?傳統(tǒng)的做法往往是，如果請求量、內(nèi)存、CPU超過閾值做了告警，運維人員馬上再加幾臺服務器，部署好服務之后，接入負載均衡來分擔已有服務的壓力。這樣問題就出現(xiàn)了:從監(jiān)控告警到部署服務，中間需要人力介入! 那么，有沒有辦法自動完成服務的部署、更新、卸載和擴容、縮容呢?而這就是K8S要做的事情: 自動化運維管理容器(Docker) 程序。K8s的目標是讓部署容器化應用簡單高效
?

（5）痛點問題

K8S解決了裸跑 Docker 的若干痛點：
? 單機使用，無法有效集群

? 隨著容器數(shù)量的上升，管理成本攀升

? 沒有有效的容災、自愈機制

? 沒有預設(shè)編排模板，無法實現(xiàn)快速、大規(guī)模容器調(diào)度

? 沒有統(tǒng)一的配置管理中心工具

? 沒有容器生命周期的管理工具

? 沒有圖形化運維管理工具

? k8s提供了容器編排，資源調(diào)度，彈性伸縮，部署管理，服務發(fā)現(xiàn)等一系列功能

（4）特性

①?彈性伸縮
使用命令、UI或者基于CPU使用情況自動快速擴容和縮容應用程序?qū)嵗?，保證應用業(yè)務高峰并發(fā)時的高可用性:業(yè)務低峰時回收資源，以最小成本運行服務

②?自我修復
在節(jié)點故障時重新啟動失敗的容器，替換和重新部署，保證預期的副本數(shù)量:殺死健康檢查失敗的容器，并且在未準備好之前不會處理客戶端請求,確保線上服務不中斷

③?服務發(fā)現(xiàn)和負載均衡
K8s為多個容器提供一-個統(tǒng)一訪問入口(內(nèi)部IP地址和一個DNS名稱)，并且負載均衡關(guān)聯(lián)的所有容器，使得用戶無需考慮容器IP問題

④?自動發(fā)布(默認滾動發(fā)布模式)和回滾
K8S采用滾動更新策略更新應用，一次更新一個Pod，而不是同時刪除所有Pod，如果更新過程中出現(xiàn)問題，將回滾更改，確保升級不受影響業(yè)務

⑤?集中化配置管理和密鑰管理
管理機密數(shù)據(jù)和應用程序配置，而不需要把敏感數(shù)據(jù)暴露在鏡像里，提高敏感數(shù)據(jù)安全性。并可以將一些常用的配置存儲在K8S中，方便應用程序使用

⑥?存儲編排，支持外掛存儲并對外掛存儲資源進行編排
掛載外部存儲系統(tǒng)，無論是來自本地存儲，公有云( 如AWS)，還是網(wǎng)絡存儲( 如NFS、Glusterfs、Ceph) 都作為集群資源的一部分使用， 極大提高存儲使用靈活性

⑦?任務批處理運行
提供一次性任務，定時任務:滿足批量數(shù)據(jù)處理和分析的場景

3.k8s集群架構(gòu)與組件

(1) 架構(gòu)

?K8S是屬于主從設(shè)備模型(Master-Slave 架構(gòu))，即有Master 節(jié)點負責集群的調(diào)度、管理和運維，Slave 節(jié)點是集群中的運算工作負載節(jié)點。

在K8S中，主節(jié)點一般被稱為Master 節(jié)點，而從節(jié)點則被稱為Worker Node 節(jié)點，每個Node 都會被Master 分配一些工作負載。

Master組件可以在群集中的任何計算機上運行，但建議Master節(jié)點占據(jù)一個獨立的服務器。因為Master是整個集群的大腦，如果Master所在節(jié)點宕機或不可用，那么所有的控制命令都將失效。除了Master， 在K8s集群中的其他機器被稱為Worker Node節(jié)點，當某個Node宕機時，其上的工作負載會被Master自動轉(zhuǎn)移到其他節(jié)點上去。

?

（2）核心組件

①?Master 組件

==●Kube-apiserver==
用于暴露Kubernetes API，任何資源請求或調(diào)用操作都是通過kube-apiserver提供的接口進行。以HTTP Restful API
提供接口服務，所有對象資源的增刪改查和監(jiān)聽操作都交給API Server處理后再提交給Etcd存儲
 
可以理解成API Server 是K8S的請求入口服務。API Server 負責接收K8S所有請求(來自UI界面或者CLI命令行工具)，
然后根據(jù)用戶的具體請求，去通知其他組件干活?？梢哉fAPI Server 是K8S集群架構(gòu)的大腦
 
==●Kube-controller-manager==
運行管理控制器，是K8S 集群中處理常規(guī)任務的后臺線程，是K8S集群里所有資源對象的自動化控制中心。
在K8S集群中，一個資源對應一個控制器，而Controller manager就是負責管理這些控制器的
 
由一系列控制器組成，通過APIServer監(jiān)控整個集群的狀態(tài)，并確保集群處于預期的工作狀態(tài)，比如當某個Node意外宕機時，Controller Manager會及時發(fā)現(xiàn)并執(zhí)行自動化修復流程，確保集群始終處于預期的工作狀態(tài)
 
這些控制器主要包括:
●Node Controller(節(jié)點控制器):負責在節(jié)點出現(xiàn)故障時發(fā)現(xiàn)和響應
●Replication Controller (副本控制器) :負責保證集群中一個RC (資源對 象Replication Controller) 所關(guān)聯(lián)的Pod
副本數(shù)始終保持預設(shè)值。可以理解成確保集群中有且僅有N個Pod實例，N是RC中定義的Pod副本數(shù)量
●Endpoints Controller (端點控制器) :填充端點對象 (即連接Services 和Pods) ，負責監(jiān)聽 Service 和對應的Pod副本的變化
可以理解端點是一個服務暴露出來的訪問點，如果需要訪問一個服務，則必須知道它的endpoint
●Service Account & Token Controllers ( 服務帳戶和令牌控制器) :為新的命名空間創(chuàng)建默認帳戶和API訪問令牌
●ResourceQuota Controller(資源配額控制器):確保指定的資源對象在任何時候都不會超量占用系統(tǒng)物理資源
●Namespace Controller ( 命名空間控制器) :管理namespace的生命周期
●Service Controller (服務控制器) :屬于K8S集群與外部的云平臺之間的一個接口控制器
 
==●Kube-scheduler==
是負責資源調(diào)度的進程，根據(jù)調(diào)度算法為新創(chuàng)建的Pod選擇-一個合適的Node節(jié)點
可以理解成K8S所有Node節(jié)點的調(diào)度器。當用戶要部署服務時，Scheduler 會根據(jù)調(diào)度算法選擇最合適的Node 節(jié)點來部署Pod
●預算策略(predicate)
●優(yōu)選策略( priorities)
 

②?配置存儲中心

==●etcd==
K8S的存儲服務。etcd 是分布式鍵值存儲系統(tǒng)，存儲了K8S 的關(guān)鍵配置和用戶配置，K8S中僅API Server 才具備讀寫權(quán)限，其他組件必須通過API Server的接口才能讀寫數(shù)據(jù)。

③?Node組件

==●Kubelet==
Node節(jié)點的監(jiān)視器，以及與Master節(jié)點的通訊器。Kubelet 是Master節(jié)點安插在Node節(jié)點上的“眼線”，它會定時向API Server匯報自己
Node節(jié)點上運行的服務的狀態(tài)，并接受來自Master節(jié)點的指示采取調(diào)整措施
 
從Master節(jié)點獲取自己節(jié)點上Pod的期望狀態(tài)(比如運行什么容器、運行的副本數(shù)量、網(wǎng)絡或者存儲如何配置等)，
直接跟容器引擎交互實現(xiàn)容器的生命周期管理，如果自己節(jié)點上Pod的狀態(tài)與期望狀態(tài)不一致，則調(diào)用對應的容器平臺接口(即docker的接口)達到這個狀態(tài)
 
管理鏡像和容器的清理工作，保證節(jié)點上鏡像不會占滿磁盤空間，退出的容器不會占用太多資源
 
==●Kube-Proxy==
在每個Node節(jié)點上實現(xiàn)pod網(wǎng)絡代理，是Kubernetes Service 資源的載體，負責維護網(wǎng)絡規(guī)則和四層負載均衡工作。負責寫入規(guī)則至iptables、ipvs實現(xiàn)服務映射訪問的
 
Kube-Proxy本身不是直接給Pod 提供網(wǎng)絡，Pod的網(wǎng)絡是由Kubelet 提供的，Kube-Proxy 實際上維護的是虛擬的Pod集群網(wǎng)絡
Kube-apiserver通過監(jiān)控Kube-Proxy 進行對Kubernetes Service 的更新和端點的維護
 
在K8S集群中微服務的負載均衡是由Kube-proxy實現(xiàn)的。Kube-proxy是K8S集群內(nèi)部的負載均衡器。它是一個分布式代理服務器，在K8S的每個節(jié)點上都會運行一個Kube-proxy 組件
 
==●docker或rocket==
容器引擎，運行容器，負責本機的容器創(chuàng)建和管理工作

1)?kube-proxy 運行模式

kube-proxy 有三種運行模式，每種都有不同的實現(xiàn)技術(shù)：userspace、iptables 或者 IPVS。

1.userspace 模式
非常陳舊、緩慢，已經(jīng)不推薦使用。


2.iptables 模式
iptables 是一個 Linux 內(nèi)核功能，是一個高效的防火墻，并提供了大量的數(shù)據(jù)包處理和過濾方面的能力。它可以在核心數(shù)據(jù)包處理管線上用 Hook 掛接一系列的規(guī)則。iptables 模式中 kube-proxy 在 NAT pre-routing Hook 中實現(xiàn)它的 NAT 和負載均衡功能。這種方法簡單有效，依賴于成熟的內(nèi)核功能，并且能夠和其它跟 iptables 協(xié)作的應用（例如 Calico）融洽相處。
然而 kube-proxy 的用法是一種 O(n) 算法，其中的 n 隨集群規(guī)模同步增長，這里的集群規(guī)模，更明確的說就是服務和后端 Pod 的數(shù)量。

3.IPVS 模式
IPVS 是一個用于負載均衡的 Linux 內(nèi)核功能。IPVS 模式下，kube-proxy 使用 IPVS 負載均衡代替了 iptable。這種模式同樣有效，IPVS 的設(shè)計就是用來為大量服務進行負載均衡的，它有一套優(yōu)化過的 API，使用優(yōu)化的查找算法，而不是簡單的從列表中查找規(guī)則。
這樣一來，kube-proxy 在 IPVS 模式下，其連接過程的復雜度為 O(1)。換句話說，多數(shù)情況下，他的連接處理效率是和集群規(guī)模無關(guān)的。
另外作為一個獨立的負載均衡器，IPVS 包含了多種不同的負載均衡算法，例如輪詢、最短期望延遲、最少連接以及各種哈希方法等。而 iptables 就只有一種隨機平等的選擇算法。
IPVS 的一個潛在缺點就是，IPVS 處理數(shù)據(jù)包的路徑和通常情況下 iptables 過濾器的路徑是不同的。如果計劃在有其他程序使用 iptables 的環(huán)境中使用 IPVS，需要進行一些研究，看看他們是否能夠協(xié)調(diào)工作。（Calico 已經(jīng)和 IPVS kube-proxy 兼容）

Netfilter和iptables之間的關(guān)系:

1. 具體的四表
filter表——過濾數(shù)據(jù)包
Nat表——用于網(wǎng)絡地址轉(zhuǎn)換（IP、端口）
Mangle表——修改數(shù)據(jù)包的服務類型、TTL、并且可以配置路由實現(xiàn)QOS
Raw表——決定數(shù)據(jù)包是否被狀態(tài)跟蹤機制處理

2. 具體的五鏈
INPUT鏈——進來的數(shù)據(jù)包應用此規(guī)則鏈中的策略
OUTPUT鏈——外出的數(shù)據(jù)包應用此規(guī)則鏈中的策略
FORWARD鏈——轉(zhuǎn)發(fā)數(shù)據(jù)包時應用此規(guī)則鏈中的策略
PREROUTING鏈——對數(shù)據(jù)包作路由選擇前應用此鏈中的規(guī)則（所有的數(shù)據(jù)包進來的時侯都先由這個鏈處理）
POSTROUTING鏈——對數(shù)據(jù)包作路由選擇后應用此鏈中的規(guī)則（所有的數(shù)據(jù)包出來的時侯都先由這個鏈處理）

四表五鏈之間的關(guān)系:

ipvs工作原理

LVS 是基于 netfilter 框架，工作在 INPUT 鏈上，在 INPUT 上注冊 ip_vs_in HOOK 函數(shù)，會根據(jù)訪問的 vip+port 判斷請求是否 IPVS 服務，如果是則調(diào)用注冊的 IPVS HOOK 函數(shù)，進行 IPVS 相關(guān)主流程，強行修改數(shù)據(jù)包的相關(guān)數(shù)據(jù)，并將數(shù)據(jù)包發(fā)往 POSTROUTING 鏈上大概原理如圖所示：

（3）k8s核心概念

① 資源類型

Kubernetes包含多種類型的資源對象: Pod、 Label、 Service、 Replication Controller 等

所有的資源對象都可以通過Kubernetes 提供的 kubectl工具進行增、刪、改、查等操作，并將其保存在etcd中持久化存儲

Kubernets其實是一個高度自動化的資源控制系統(tǒng)，通過跟蹤對比etcd存儲里保存的資源期望狀態(tài)與當前環(huán)境中的實際資源狀態(tài)的差異，來實現(xiàn)自動控制和自動糾錯等高級功能

② 資源對象

==●Pod==
Pod是Kubernetes 創(chuàng)建或部署的最小/最簡單的基本單位，一個Pod 代表集群上正在運行的一個進程
可以把Pod理解成豌豆莢，而同一Pod內(nèi)的每個容器是一顆顆豌豆
 
一個Pod由一個或多個容器組成，Pod中容器共享網(wǎng)絡、存儲和計算資源，在同一臺Docker主機上運行
一個Pod里可以運行多個容器，又叫邊車模式(sideCara) 模式。而在生產(chǎn)環(huán)境中一般都是單個容器或者具有強關(guān)聯(lián)互補的多個容器組成一個Pod
 
同一個Pod之間的容器可以通過localhost 互相訪問，并且可以掛載Pod內(nèi)所有的數(shù)據(jù)卷;但是不同的Pod之間的容器不能用localhost訪問，也不能掛載其他Pod的數(shù)據(jù)卷
 
==●Pod 控制器==
Pod控制器是Pod啟動的一種模版，用來保證在K8S里啟動的Pod 應始終按照用戶的預期運行(副本數(shù)、生命周期、健康狀態(tài)檢查等)
 
K8S內(nèi)提供了眾多的Pod 控制器，常用的有以下幾種:
●Deployment：無狀態(tài)應用部署。Deployment 的作用是管理和控制Pod和Replicaset， 管控它們運行在用戶期望的狀態(tài)中
 
●Replicaset: 確保預期的Pod副本數(shù)量。Replicaset 的作用就是管理和控制Pod，管控他們好好干活。 但是，Replicaset 受控于Deployment 
可以理解成Deployment 就是總包工頭，主要負責監(jiān)督底下的工人Pod干活，確保每時每刻有用戶要求數(shù)量的Pod在工作。
如果一旦發(fā)現(xiàn)某個工人Pod不行了，就趕緊新拉一個Pod過來替換它。而ReplicaSet 就是總包工頭手下的小包工頭
 
從K8S使用者角度來看，用戶會直接操作Deployment 部署服務，而當Deployment 被部署的時候，K8S 會自動生成要求的ReplicaSet 和Pod。
用戶只需要關(guān)心Deployment 而不操心ReplicaSet
資源對象Replication Controller是ReplicaSet 的前身，官方推薦用Deployment 取代Replication Controller來部署服務
 
●Daemonset: 確保所有節(jié)點運行同一類Pod，保證每個節(jié)點上都有一個此類Pod運行，通常用于實現(xiàn)系統(tǒng)級后臺任務
●Statefulset:有狀態(tài)應用部署
●Job: 一次性任務。根據(jù)用戶的設(shè)置，Job管理的Pod把任務成功完成就自動退出了
●Cronjob: 周期性計劃性任務
 
==●Label==
標簽，是K8S特色的管理方式，便于分類管理資源對象
Label可以附加到各種資源對象上，例如Node、Pod、Service、 RC等，用于關(guān)聯(lián)對象、查詢和篩選。
一個Label是一個key-value 的鍵值對，其中key 與value 由用戶自己指定
一個資源對象可以定義任意數(shù)量的Label，同一個Label也可以被添加到任意數(shù)量的資源對象中，也可以在對象創(chuàng)建后動態(tài)添加或者刪除
可以通過給指定的資源對象捆綁一個或多個不同的Label，來實現(xiàn)多維度的資源分組管理功能
 
與Label 類似的，還有Annotation (注釋)
區(qū)別在于有效的標簽值必須為63個字符或更少，并且必須為空或以字母數(shù)字字符([a-z0-9A-Z]) 開頭和結(jié)尾，中間可以包含橫杠(-)、下劃線(_)、點(.)和字母或數(shù)字。注釋值則沒有字符長度限制
 
==●Label選擇器(Label selector )==
給某個資源對象定義一個Label， 就相當于給它打了一個標簽;隨后可以通過標簽選擇器(Label selector) 查詢和篩選擁有某些Label的資源對象
 
標簽選擇器目前有兩種:基于等值關(guān)系(等于、不等于)和基于集合關(guān)系(屬于、不屬于、存在)
 
==●Service==
在K8S的集群里，雖然每個Pod會被分配一個單獨的IP地址，但由于Pod是有生命周期的(它們可以被創(chuàng)建，而且銷毀之后不會再啟動)，
隨時可能會因為業(yè)務的變更，導致這個IP地址也會隨著Pod 的銷毀而消失
 
Service就是用來解決這個問題的核心概念。
K8S中的Service 并不是我們常說的“服務”的含義，而更像是網(wǎng)關(guān)層，可以看作一組提供相同服務的Pod的對外訪問接口、流量均衡器
 
Service作用于哪些Pod 是通過標簽選擇器來定義的。
在K8S集群中，Service 可以看作一組提供相同服務的Pod 的對外訪問接口。客戶端需要訪問的服務就是Service 對象。
每個Service都有一個固定的虛擬ip (這個ip也被稱為Cluster IP) ，自動并且動態(tài)地綁定后端的Pod, 所有的網(wǎng)絡請求直接訪問Service 的虛擬ip，Service會自動向后端做轉(zhuǎn)發(fā)
 
Service除了提供穩(wěn)定的對外訪問方式之外，還能起到負載均衡(Load Balance) 的功能，自動把請求流量分布到后端所有的服務上，
service可以做到對客戶透明地進行水平擴展(scale)
 
而實現(xiàn)service 這一功能的關(guān)鍵， 就是kube-proxy。 kube -proxy運行在每個節(jié)點上，監(jiān)聽API Server中服務對象的變化，
可通過以下三種流量調(diào)度模式: userspace (廢棄)、iptables (瀕臨廢棄)、ipvs (推薦，性能最好)來實現(xiàn)網(wǎng)絡的轉(zhuǎn)發(fā)。
 
Service是K8S服務的核心，屏蔽了服務細節(jié)，統(tǒng)一對外暴露服務接口， 真正做到了“微服務”。比如我們的一個服務A，部署了3
個副本，也就是3個Pod;對于用戶來說，只需要關(guān)注一個Service 的入口就可以，而不需要操心究競應該請求哪一個Pod。
 
優(yōu)勢非常明顯:一方面外部用戶不需要感知因為Pod. 上服務的意外崩潰、 K8S 重新拉起Pod 而造成的IP變更，外部用戶也不需要感知因升級、變更服務帶來的Pod替換而造成的IP變化。
 
==●Ingress==
Service主要負責K8S 集群內(nèi)部的網(wǎng)絡拓撲，那么集群外部怎么訪問集群內(nèi)部呢?這個時候就需要Ingress了。
Ingress是整個K8S集群的接入層，負責集群內(nèi)外通訊
 
Ingress是K8S 集群里工作在OSI網(wǎng)絡參考模型下，第7層的應用，對外暴露的接口，典型的訪問方式是http/https
 
Service只能進行第四層的流量調(diào)度，表現(xiàn)形式是ip+port。Ingress則可以調(diào)度不同業(yè)務域、不同URL訪問路徑的業(yè)務流量。
比如:客戶端請求http://www.david.com:port ---> Ingress ---> Service ---> Pod
 
==●Name==
由于K8S內(nèi)部，使用“資源”來定義每一種邏輯概念(功能)，所以每種“資源”，都應該有自己的“名稱”
 
“資源”有api版本(apiversion) 、類別(kind)、元數(shù)據(jù)(metadata) 、定義清單(spec)、狀態(tài)(status) 等配置信息
 
“名稱”通常定義在“資源”的“元數(shù)據(jù)”信息里。在同一個namespace 空間中必須是唯一的
 
==●Namespace==
隨著項目增多、人員增加、集群規(guī)模的擴大，需要一種能夠邏輯上隔離K8S 內(nèi)各種“資源"的方法，這就是Namespace
Namespace是為了把一個K8S集群劃分為若千個資源不可共享的虛擬集群組而誕生的
不同Namespace 內(nèi)的“資源”名稱可以相同，相同Namespace 內(nèi)的同種“資源”， “名稱”不能相同
合理的使用K8S的Namespace，可以使得集群管理員能夠更好的對交付到K8S里的服務進行分類管理和瀏覽
K8S里默認存在的Namespace 有: default、 kube-system、 kube-public 等
查詢K8S 里特定“資源”要帶上相應的Namespace

（4）常見的k8s部署方式

①?Mini kube
Minikube是一個工具，可以在本地快速運行一個單節(jié)點微型K8s，僅用于學習預覽K8s的一些特性使用
部署地址: https: / /kubernetes.io/docs/setup/minikube

②?Kubeadmin
Kubeadmin也是一個工具，提供kubeadm init和kubeadm join，用于快速部署K8S集群，相對簡單
https: / /kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/

③?二進制安裝部署
生產(chǎn)首選，從官方下載發(fā)行版的二進制包，手動部署每個組件和自簽TLS證書，組成K8s集群，新手推薦
https: / /github.com/kubernetes/kubernetes/releases

（5）k8s工作流程

①?API Server 接收請求創(chuàng)建一批Pod，會存儲pod數(shù)據(jù)到etcd

②?Controller-manager 通過API Server 到etcd中讀取按照預設(shè)的模板去創(chuàng)建Pod。Controller-manager 又會通過API Server讓Scheduler為新創(chuàng)建的Pod 根據(jù)預算策略以及優(yōu)選策略，選擇最適合的Node 節(jié)點把pod調(diào)度過來

比如運行這個Pod需要2C 4G 的資源，Scheduler 會通過預算策略在所有Node’節(jié)點中挑選最優(yōu)的。Node 節(jié)點中還剩多少資源是通過匯報給API Server 存儲在etcd 里，API Server 會調(diào)用一個方法找到etcd里所有node節(jié)點的剩余資源，再對比pod所需要的資源，在所有node節(jié)點中查找哪些node節(jié)點符合要求
如果都符合，預算策略就交給優(yōu)選策略處理，優(yōu)選策略再通過CPU 的負載、內(nèi)存的剩余量等因素選擇最合適的Node節(jié)點，并把Pod調(diào)度到這個Node’節(jié)點上運行

③?scheduler通過Api server來讓Kubelet根據(jù)調(diào)度結(jié)果執(zhí)行Pod創(chuàng)建操作，并且對node節(jié)點進行監(jiān)視，會定時向api server匯報自己node節(jié)點運行的服務狀態(tài)

在這期間，Controller Manager同時會根據(jù)K8S的mainfiles文件執(zhí)行RC Pod的數(shù)量來保證指定的Pod副本數(shù)

④?在每個node上都會有一個kube-proxy，來實現(xiàn)pod的網(wǎng)絡代理，它是Kubernetes Service 資源的載體。在任何一個節(jié)點上訪問一個service的虛擬ip，都可以訪問到pod。
所有Node上運行的Proxy進程通過APIServer查詢并監(jiān)聽service對象與其對應的Endponts信息，建立一個軟件方式的負載均衡器來實現(xiàn)Service訪問到后端Pod的流量轉(zhuǎn)發(fā)功能

小結(jié)：

1.首先運維人員使用kubectl命令行工具向API Server發(fā)送請求，API Server接收到請求后會寫入到etcd中，API Server會讓Controller-manager按照預設(shè)的模板去創(chuàng)建pod，Controller-manager通過 API Server讀取etcd中用戶的預設(shè)信息，再通過API Server去找 Scheduler可以為新創(chuàng)建的pod選擇最適合的node節(jié)點。scheduler會通過API Server在Etcd存儲中心根據(jù)存儲的node節(jié)點元信息、剩余資源等，用預選策略和優(yōu)選策略挑選最優(yōu)的node節(jié)點
2.scheduler確定node節(jié)點后通過API Server交給這個Node節(jié)點上的kubelet進行pod資源的創(chuàng)建，kubelet調(diào)用容器引擎交互創(chuàng)建pod，同時將pod監(jiān)控信息通過API server存儲到etcd中
3.用戶訪問時，通過kube-proxy負載、轉(zhuǎn)發(fā)，訪問相應的pod

（6）k8s創(chuàng)建pod過程

創(chuàng)建pod時序圖

②過程

第一步：kubectl   create  pod

      首先進行認證（RBAC方式 或者 key方式進行認證 ）后獲得具體的權(quán)限，然后kubectl會調(diào)用master  api創(chuàng)建對象的接口，然后向k8s  apiserver發(fā)出創(chuàng)建pod的命令

第二步：k8s  apiserver
      apiserver收到請求后，并非直接創(chuàng)建pod，而是先創(chuàng)建一個包含pod創(chuàng)建信息的yaml文件，并將文件信息寫入到etcd中（如果此處是用yaml文件創(chuàng)建pod，則這兩步就可以忽略）

 這里用pod創(chuàng)建也給出具體cd 部署思路,創(chuàng)建pod形式有二種方案。一種是通過api直接創(chuàng)建生成yaml,另外一種是通過yaml直接應用。

第三步：controller  manager
        創(chuàng)建Pod的yaml信息會交給controller  manager ,controller  manager根據(jù)配置信息將要創(chuàng)建的資源對象（pod）放到等待隊列中。

     注意創(chuàng)建的資源對象是并發(fā)過程，但是放入隊列是一個串行，主要目的還是為了防止1、應用資源創(chuàng)建的先后順序  2、資源調(diào)度過程的優(yōu)先情況 應用有無狀態(tài) 
第四步：scheduler
    scheduler （死循環(huán)）查看k8s api ，類似于通知機制。首先判斷：pod.spec.Node == null? 若為null，表示這個Pod請求是新來的，需要創(chuàng)建；然后進行預選調(diào)度和優(yōu)選調(diào)度計算，找到最“閑”的且符合調(diào)度條件的node。最后將信息在etcd數(shù)據(jù)庫中更新分配結(jié)果：pod.spec.Node = node2(設(shè)置一個具體的節(jié)點)同樣上述操作的各種信息也要寫到etcd數(shù)據(jù)庫中。

      分配過程需要兩層調(diào)度：預選調(diào)度和優(yōu)選調(diào)度

（1）預選調(diào)度：一般根據(jù)資源對象的配置信息進行篩選。例如NodeSelector、HostSelector和節(jié)點親和性等。

（2）優(yōu)選調(diào)度：根據(jù)資源對象需要的資源和node節(jié)點資源的使用情況，為每個節(jié)點打分，然后選出最優(yōu)的節(jié)點創(chuàng)建資源對象（pod）。

     運維小助手：調(diào)度策略在后期成本控制 資源使用 費用計算都是一個好的方案。

第四步：kubelet
 節(jié)點（選中node）上的kubelet進程通過API Server，查看etcd數(shù)據(jù)庫（kubelet通過API Server的WATCH接口監(jiān)聽Pod信息，如果監(jiān)聽到新的pod副本被調(diào)度綁定到本節(jié)點）監(jiān)聽到kube-scheduler產(chǎn)生的Pod綁定事件后獲取對應的Pod清單，然后調(diào)用（被選中node）本機中的docker  api初始化volume、分配IP、下載image鏡像，創(chuàng)建容器并啟動服務。

        注意順序 有狀態(tài)和無狀態(tài)創(chuàng)建過程中，有狀態(tài)是有先后順序的無狀態(tài)是沒有的

第五步：controller  manager
 controller  manager會通過API Server提供的接口實時監(jiān)控資源對象的當前狀態(tài)，當發(fā)生各種故障導致系統(tǒng)狀態(tài)發(fā)生變化時，會嘗試將其狀態(tài)修復到“期望狀態(tài)”。

③創(chuàng)建過程注意點

1、合理的設(shè)置cicd塊 網(wǎng)絡劃分，注意網(wǎng)絡隔離資源及網(wǎng)絡沖突預留擴展性

2、在master進行高可用的冗余部署，以防止單可用區(qū) 或者 單機房宕機情況

3、注意etcd數(shù)據(jù)庫容量問題

4、注意services 暴露過多導致網(wǎng)絡調(diào)用鏈的問題

4.K8S網(wǎng)絡

K8S有三種網(wǎng)絡模式：

（1）service網(wǎng)絡

service是虛擬IP地址，即cluster IP 。

（2）pod網(wǎng)絡

pod的IP地址，即docker容器的IP，為虛擬地址

（3）node網(wǎng)絡

節(jié)點網(wǎng)絡為服務器上面的物理網(wǎng)卡IP

二、總結(jié)

在K8S集群中，一個資源對應一個控制器，而Controller manager就是負責管理這些控制器的。

K8S中僅API Server 才具備讀寫權(quán)限，其他組件必須通過API Server的接口才能讀寫數(shù)據(jù)。

資源對象Replication Controller是ReplicaSet 的前身，官方推薦用Deployment 取代Replication Controller來部署服務。
?K8S中的Service 并不是我們常說的“服務”的含義，而更像是網(wǎng)關(guān)層，可以看作一組提供相同服務的Pod的對外訪問接口、流量均衡器。
?每個Service都有一個固定的虛擬ip (這個ip也被稱為Cluster IP) ，自動并且動態(tài)地綁定后端的Pod, 所有的網(wǎng)絡請求直接訪問Service 的虛擬ip，Service會自動向后端做轉(zhuǎn)發(fā)。

?controller manager創(chuàng)建的資源對象是并發(fā)過程，但是放入隊列是一個串行，主要目的還是為了防止1、應用資源創(chuàng)建的先后順序 ?2、資源調(diào)度過程的優(yōu)先情況 應用有無狀態(tài) 。

K8S有三種網(wǎng)絡模式：service網(wǎng)絡、pod網(wǎng)絡、node網(wǎng)絡。文章來源地址http://www.zghlxwxcb.cn/news/detail-687014.html

到了這里，關(guān)于云原生Kubernetes:K8S概述的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！