雲原生
概述
雲原生是一條最佳路徑或者最佳實踐。更詳細的說，
雲原生為使用者指定了一條低心智負擔的、敏捷的、能夠以可擴充套件、可複製的方式最大化地利用雲的能力、發揮雲的價值的最佳路徑。
雲原生的技術範疇包括了以下幾個方面：
l第一部分是雲應用定義與開發流程。這包括應用定義與映象製作、配置CI/CD、訊息和 Streaming 以及資料庫等。
l第二部分是雲應用的編排與管理流程。這也是Kubernetes 比較關注的一部分，包括了應用編排與排程、服務發現治理、遠端呼叫、API 閘道器以及 Service Mesh。
l第三部分是監控與可觀測性。這部分所強調的是雲上應用如何進行監控、日誌收集、Tracing 以及在雲上如何實現破壞性測試，也就是混沌工程的概念。
l第四部分就是雲原生的底層技術，比如容器執行時、雲原生儲存技術、雲原生網路技術等。
l第五部分是雲原生工具集，在前面的這些核心技術點之上，還有很多配套的生態或者周邊的工具需要使用，比如流程自動化與配置管理、容器映象倉庫、雲原生安全技術以及雲端密碼管理等。
l最後則是Serverless。Serverless 是一種 PaaS 的特殊形態，它定義了一種更為“極端抽象”的應用編寫方式，包含了 FaaS 和 BaaS 這樣的概念。而無論是 FaaS 還是 BaaS，其最為典型的特點就是按實際使用計費（Pay as you go），因此 Serverless 計費也是重要的知識和概念。
雲原生的特點
l容器化：所有的服務都必須跑在容器中。
l微服務：實現雲原生最好採用微服務架構。
lDevOps：開發+運維，開發和運維的結合體。
如何使用雲原生？
1、本地部署應用可能需要停機更新，而云原生不需要，始終是最新的狀態，支援頻繁的變更。
2、本地部署應用無法進行動態擴充套件，雲原生可以利用雲資源的彈性進行自動伸縮容，從而為企業降本增效。
3、本地部署應用對物理硬體IP，網路埠有強依賴，雲原生就不需要。
4、本地部署應用需要人肉運維方式，雲原生實現自動化運維。
如何實現雲原生？
1、採用微服務架構，微服務是雲原生環境的標配。微服務架構的專案離開了雲原生，部署，運維的效率就會大打折扣。
2、虛擬化，採用openstack進行管理。
3、容器化，使用Kubernets進行管理。
為什麼要管理容器？
1、怎麼擴容？
2、容器宕機了，怎麼恢復？
3、更新容器會不會影響業務？
4、如何監控？
5、如何排程？
6、資料安全。
容器編排技術
應用部署變遷
物理機模式：服務部署在物理機。
虛擬機器模式：為了充分利用物理機的計算資源，使用虛擬機器方式部署服務。
雲原生模式：應用部署在容器中。
容器管理
怎麼去管理這麼多的容器
l怎麼橫向擴充套件
l容器down 了，怎麼恢復
l更新容器後不影響業務
l如何監控容器
l如何排程新建立的容器
l資料安全問題
docker-compose
容器編排工具
Swarm
目前三大主流的容器平臺Swarm， Mesos和Kubernetes具有不同的容器排程系統 ；Swarm的特點是直接排程Docker容器，並且提供和標準Docker API一致的API。
每臺伺服器上都裝有Docker並且開啟了基於HTTP的DockerAPI。這個叢集中有一個SwarmManager的管理者，用來管理叢集中的容器資源。管理者的管理物件不是伺服器層面而是叢集層面的，也就是說透過Manager，我們只能籠統地向叢集發出指令而不能具體到某臺具體的伺服器上要幹什麼（這也是Swarm的根本所在）。至於具體的管理實現方式，Manager向外暴露了一個HTTP介面，外部使用者透過這個HTTP介面來實現對叢集的管理。
Mesos
Mesos針對不同的執行框架採用相對獨立的排程系統，其框架提供了Docker容器的原生支援。Mesos並不負責排程而是負責委派授權，畢竟很多框架都已經實現了複雜的排程。
Kubernetes
Kubernetes則採用了
Pod和Label
這樣的概念把容器組合成一個個的互相存在依賴關係的邏輯單元。相關容器被組合成Pod後被共同部署和排程，
形成服務（Service）
。這個是Kubernetes和Swarm，Mesos的主要區別。
Kubernetes（k8s）是自動化容器操作的開源平臺，這些操作包括部署，排程和節點叢集間擴充套件。
如果你曾經用過Docker容器技術部署容器，那麼可以將Docker看成Kubernetes內部使用的低級別元件。Kubernetes不僅僅支援Docker，還支援Rocket，這是另一種容器技術。
使用Kubernetes可以：
l自動化容器的部署和複製
l隨時擴充套件或收縮容器規模
l將容器組織成組，並且提供容器間的負載均衡
l很容易地升級應用程式容器的新版本
l提供容器彈性，如果容器失效就替換它，等等。。。
Kubernets基本結構：
1、Master節點：負責排程，儲存叢集狀態，提供統一API入口。一個Master對應一群Node節點。
2、Node節點：儲存Pod，一個Node節點理論上可以儲存無數個Pod，但是Node節點儲存Pod的數量受限於硬體資源的限制，同時受限於Pod內部服務執行所佔用的資源。
Kubernetes
borg系統
Borg. Google的Borg系統執行幾十萬個以上的任務，來自幾千個不同的應用，跨多個叢集，每個叢集（cell）有上萬個機器。
它透過管理控制、高效的任務包裝、超售、和程序級別效能隔離實現了高利用率。它支援高可用性應用程式與執行時功能，最大限度地減少故障恢復時間，減少相關故障機率的排程策略。以上就是Borg的系統架構圖。其中Scheduler負責任務的排程。
k8s基本介紹
就在Docker容器技術被炒得熱火朝天之時，大家發現，如果想要將Docker應用於具體的業務實現，是存在困難的——編排、管理和排程等各個方面，都不容易。於是，
人們迫切需要一套管理系統，對Docker及容器進行更高階更靈活的管理
。就在這個時候，K8S出現了。
K8S，就是基於容器的叢集管理平臺，它的全稱，是kubernetes。
k8s主要功能
Kubernetes是docker容器用來編排和管理的工具，它是基於Docker構建一個容器的排程服務，提供資源排程、均衡容災、服務註冊、動態擴縮容等功能套件。Kubernetes提供應用部署、維護、 擴充套件機制等功能，利用Kubernetes能方便地管理跨機器執行容器化的應用，其主要功能如下：
l
資料卷
： Pod中容器之間共享資料，可以使用資料卷。
l
應用程式健康檢查
： 容器內服務可能程序堵塞無法處理請求，可以設定監控檢查策略保證應用健壯性。
l
複製應用程式例項
： 控制器維護著Pod副本數量，保證一個Pod或一組同類的Pod數量始終可用。
l
彈性伸縮
： 根據設定的指標（CPU利用率）自動縮放Pod副本數。
l
服務發現
： 使用環境變數或DNS服務外掛保證容器中程式發現Pod入口訪問地址。
l
負載均衡:
一組Pod副本分配一個私有的叢集IP地址，負載均衡轉發請求到後端容器。在叢集內部其他Pod可透過這個ClusterIP訪問應用。
l
滾動更新
： 更新服務不中斷，一次更新一個Pod，而不是同時刪除整個服務。
l
服務編排
： 透過檔案描述部署服務，使得應用程式部署變得更高效。
l
資源監控
： Node節點元件整合cAdvisor資源收集工具，可透過Heapster彙總整個叢集節點資源資料，然後儲存到InfluxDB時序資料庫，再由Grafana展示。
l
提供認證和授權
： 支援屬性訪問控制（ABAC）、角色訪問控制（RBAC）認證授權策略。
k8s叢集
這個叢集主要包括兩個部分：
l一個Master節點（主節點）
一群Node節點（計算節點）
一看就明白：Master節點主要還是負責管理和控制。Node節點是工作負載節點，裡面是具體的容器。
Master節點
Master節點包括API Server、Scheduler、Controller manager、etcd。
API Server是整個系統的對外介面，供客戶端和其它元件呼叫，相當於“營業廳”。Scheduler負責對叢集內部的資源進行排程，相當於“排程室”。Controller manager負責管理控制器，相當於“大總管”。
node節點
Node節點包括Docker、kubelet、kube-proxy、Fluentd、kube-dns（可選），還有就是Pod。
k8s master
api server
Kubernetes API Server： Kubernetes API，叢集的統一入口，各元件協調者，以HTTP API提供介面服務，所有物件資源的增刪改查和監聽操作都 交給APIServer處理後再提交給Etcd儲存。
Api Server就是K8S的閘道器，所有的請求都會經過閘道器。
manager Controller
Kubernetes Controller: 處理叢集中常規後臺任務，一個資源對應一個控制器
，而ControllerManager就是負責管理這些控制器的各個資源控制器對於如下：
lReplication Controller： 管理維護Replication Controller，關聯Replication Controller和Pod，
保證Replication Controller定義的副本數量與實際執行Pod數量一致
。
lNode Controller： 管理維護Node，定期檢查Node的健康狀態，標識出（失效|未失效）的Node節點。
lNamespace Controller： 管理維護Namespace，定期清理無效的Namespace，包括Namesapce下的API物件，比如Pod、Service等。
lService Controller：
管理維護Service，提供負載以及服務代理
。
lEndPoints Controller： 管理維護Endpoints，關聯Service和Pod，建立Endpoints為Service的後端，當Pod發生變化時，實時更新Endpoints （即Pod Ip + Container Port）。
lService Account Controller： 管
理維護Service Account，為每個Namespace建立預設的Service Account
，同時為Service Account建立Service Account Secret。
l
Persistent Volume Controller: 管理維護Persistent Volume和Persistent Volume Claim，為新的Persistent Volume Claim分配Persistent Volume進行繫結，為釋放的Persistent Volume執行清理回收。
lDaemon Set Controller： 管理維護Daemon Set，負責建立Daemon Pod，保證指定的Node上正常的執行Daemon Pod。
lDeployment Controller： 管理維護Deployment，關聯Deployment和Replication Controller，保證執行指定數量的Pod。當Deployment更新時，控制實現Replication Controller和Pod的更新。
lJob Controller： 管理維護Job，為Jod建立一次性任務Pod，保證完成Job指定完成的任務數目
lPod Autoscaler Controller： 實現Pod的自動伸縮，定時獲取監控資料，進行策略匹配，當滿足條件時執行Pod的伸縮動作
etcd
etcd 是一個分散式的、可靠的 key-value 儲存系統，它用於儲存分散式系統中的關鍵資料
，這個定義非常重要。etcd避免了Redis的缺陷。Redis存在資料丟失的問題，而etcd不會。
etcd是一個第三方服務，分散式鍵值儲存系統。用於保持叢集狀態，比如Pod、Service等物件資訊。
etcd是一個高可用的分散式鍵值（key-value）資料庫。etcd內部採用raft協議作為一致性演算法，etcd基於Go語言實現。Etcd是Kubernetes叢集中的一個十分重要的元件，用於儲存叢集所有的網路配置和物件的狀態資訊。整個kubernetes系統中一共有兩個服務需要用到etcd用來協同和儲存配置，分別是：
l網路外掛flannel、對於其它網路外掛也需要用到etcd儲存網路的配置資訊。
lkubernetes本身，包括各種物件的狀態和元資訊配置。
scheduler
根據排程演算法為新建立的Pod選擇一個Node節點。
scheduler在整個系統中承擔了承上啟下的重要功能，承上是指它負責接收controller manager建立新的Pod，為其安排一個落腳的目標Node，啟下是指安置工作完成後，目標Node上的kubelet服務程序接管後繼工作。
也就是說scheduler的作用是透過排程演算法為待排程Pod列表上的每一個Pod從Node列表中選擇一個最合適的Node。
建立POD的流程
1、kubectl傳送建立pod的命令，此時這個指令被apiserver攔截，把建立的pod儲存在etcd。
2、scheduler發起呼叫請求，此時這個指令被apiserver攔截，獲取etcd中的pod。
3、把選擇合適的node，pod儲存在etcd。
4、node節點上有一個kubelet這個程序，傳送請求，獲取pod，node對應的建立資源。
5、如果kubelet發現pod是本機節點需要建立的，kubelet就開始建立pod。
k8s node
kubelet
kubelet是Master在Node節點上的Agent，每個節點都會啟動 kubelet程序，用來處理 Master 節點下發到本節點的任務，管理本機執行容器的生命週期
，比如建立容器、Pod掛載資料卷、 下載secret、獲取容器和節點狀態等工作。kubelet將每個Pod轉換成一組容器。
kubelet 預設監聽四個埠，分別為 10250 、10255、10248、4194
l10250（kubelet API）：kubelet server 與 apiserver 通訊的埠，定期請求 apiserver 獲取自己所應當處理的任務，透過該埠可以訪問獲取 node 資源以及狀態。
l10248（健康檢查埠）：透過訪問該埠可以判斷 kubelet 是否正常工作， 透過 kubelet 的啟動引數 ——healthz-port 和 ——healthz-bind-address 來指定監聽的地址和埠。
l4194（cAdvisor 監聽）：kublet 透過該埠可以獲取到該節點的環境資訊以及 node 上執行的容器狀態等內容，訪問 http：//localhost：4194 可以看到 cAdvisor 的管理介面，透過 kubelet 的啟動引數 `——cadvisor-port` 可以指定啟動的埠。
l10255 （readonly API）：提供了 pod 和 node 的資訊，介面以只讀形式暴露出去，訪問該埠不需要認證和鑑權。
kube-proxy
在Node節點上實現Pod網路代理
，維護網路規則和四層負載均衡工作，kube-proxy 本質上，類似一個反向代理。 我們可以把每個節點上執行的 kube-proxy 看作 service 的透明代理兼LB。
kube-proxy 監聽 apiserver 中service 與Endpoint 的資訊， 配置iptables 規則，請求透過iptables 直接轉發給 pod。
用來生成網路規則，建立訪問路由，建立service網路訪問規則，負載均衡規則。
docker
docker引擎，pod內部執行的都是容器，這些容器一般都是docker容器。
pod
Pod是最小部署單元
，一個Pod有一個或多個容器組成，Pod中容器共享儲存和網路，在同一臺Docker主機上執行。
pod基本結構：
Pause的作用：
我們看下在node節點上都會起很多pause容器，和pod是一一對應的。
每個Pod裡執行著一個特殊的被稱之為Pause的容器，其他容器則為業務容器，這些業務容器共享Pause容器的網路棧和Volume掛載卷，因此他們之間通訊和資料交換更為高效，在設計時我們可以充分利用這一特性將一組密切相關的服務程序放入同一個Pod中。同一個Pod裡的容器之間僅需透過localhost就能互相通訊。
kubernetes中的pause容器主要為每個業務容器提供以下功能：
lPID名稱空間：Pod中的不同應用程式可以看到其他應用程式的程序ID。
l網路名稱空間：Pod中的多個容器能夠訪問同一個IP和埠範圍。
lIPC名稱空間：Pod中的多個容器能夠使用SystemV IPC或POSIX訊息佇列進行通訊。
lUTS名稱空間：Pod中的多個容器共享一個主機名；Volumes（共享儲存卷）：Pod中的各個容器可以訪問在Pod級別定義的Volumes。
控制器pod，用來確保容器應用的副本數始終保持在使用者定義的副本數，即如果有容器異常退出，會自動建立新的Pod來替代，而如果異常多出的容器也會自動回收。在新版本的 Kubernetes 中建議使用ReplicaSet 來取代ReplicationControlle。ReplicaSet跟ReplicationController沒有本質的不同，只是名字不一樣，並且ReplicaSet支援集合式的selector。
雖然ReplicaSet可以獨立使用，但一般還是建議使用Deployment來自動管理ReplicaSet，這樣就無需擔心跟其他機制的不相容問題（比如 ReplicaSet 不支援 rolling-update 但 Deployment支援）。
Deployment為Pod和ReplicaSet 提供了一個 宣告式定義方法，用來替代以前的 ReplicationController 來方便的管理應用。典型的應用場景：
l定義Deployment 來建立 Pod 和 ReplicaSet
l滾動升級和回滾應用
l擴容和索容
l暫停和繼續Deployment
Deployment不僅僅可以滾動更新，而且可以進行回滾，如何發現升級到V2版本後，發現服務不可用，可以回滾到V1版本。
Horizontal Pod Autoscaling 僅適用於 Deployment 和 ReplicaSet，在V1版本中僅支援根據Pod的CPU利用率擴容，在vlalpha版本中，支援根據記憶體和使用者自定義的metric擴縮容
StatefullSet 是為了解決有狀態服務的問題（對應Deployments 和 ReplicaSets 是為無狀態服務而設計），其應用場景包括：
l穩定的持久化儲存，即Pod重新排程後還是能訪問的相同持久化資料，基於PVC來實現
l穩定的網路標誌，及Pod重新排程後其 PodName 和 HostName 不變，基於Headlesss Service（即沒有 Cluster IP 的 Service）來實現。
l有序部署，有序擴充套件，即Pod是有順序的，在部署或者擴充套件的時候要依據定義的順序依次進行（即從 0 到 N-1，在下一個Pod執行之前所有之前的Pod必須都是Running 和 Ready 狀態），基於 init containers 來實現。
l有序收縮，有序刪除（即從N-1 到 0）
解析：
l有狀態：需要實時的進行資料更新及儲存，把某個服務抽離出去，再加入回來就沒有辦法正常工作，這樣的服務就是有狀態服務。例如：mysql，Redis。。。。
l無狀態：docker主要面對的是無狀態服務，所謂的無狀態服務就是沒有對應的儲存資料需要實時的保留，或者是把服務摘除後經過一段時間執行後再把服務放回去依然能夠正常執行，就是無狀態服務。例如：Apache、lvs
DaemonSet確保全部（或者一些 ［ node打上汙點（可以想象成一個標籤），pod如果不定義容忍這個汙點，那麼pod就不會被排程器分配到這個node ］）Node上執行一個Pod的副本。當有Node加入叢集時，也會為他們新增一個Pod。當有Node從叢集移除時，這些Pod也會被回收。刪除DaemonSet將會刪除他建立的所有Pod，使用DaemonSet 的一些典型用法：
l執行叢集儲存daemon，例如在每個Node上執行glustered，ceph
l在每個Node上執行日誌收集Daemon，例如：fluentd、logstash。
l在每個Node上執行監控Daemon，例如：Prometheus Node Exporter
Job 負責批處理任務，即僅執行一次的任務，它保證批處理任務的一個或多個Pod成功結束，Cron Job管理基於時間Job，即：
l在給定時間點只執行一次
l週期性地在給定時間點執行
其他外掛
lCOREDNS：可以為叢集中的SVC建立一個域名IP的對應關係解析
lDASHBOARD：給 K8S 叢集提供一個 B/S 結構訪問體系
lINGRESS CONTROLLER：官方只能實現四層代理，INGRESS 可以實現七層代理
lFEDERATION：提供一個可以跨叢集中心多K8S統一管理功能
lPROMETHEUS：提供K8S叢集的監控能力
lELK：提供 K8S 叢集日誌統一分析介入平臺
