RuntimeClassnode
構成Kubernetes 的 Components (組件) 主要有三類,Master 組件, Node 組件,Addons (輔助類插件) 。分別承擔不一樣的工做,共同構建了kubernetes。nginx
Master 組件提供羣集的控制平面。主組件對集羣作出全局決策(例如,調度),而且它們檢測並響應集羣事件(例如,當複製控制器的replicas
字段未知足時啓動新的pod )。主組件能夠在羣集中的任何計算機上運行。可是,爲簡單起見,設置腳本一般會在同一臺計算機上啓動全部主組件,而且不在此計算機上運行用戶容器。git
***上述說明來自官方解釋,我理解就是一個控制檯,在現有IT 架構中不少硬件或者軟件採用這種方式,Master 和node 的方式。Master 負載策略下發,管理node 運行的生命週期。至關於Kubernetes 的大腦,負責整個集羣的管理和控制。那麼一般不會在這臺機器上部署node 不會運行容器(container )的功能。docker
Master 節點上運行了如下一組關鍵進程:編程
kube-apiserver :提供了 HTTP Rest ful 風格的接口的關鍵服務進程,是Kubernetes 裏全部資源的增,刪,改,查等操做的惟一入口,也是Kubernetes 集羣的管理的入口進程。後端
kube-controller-manager :Kunernetes 裏全部資源的自動化控制中心,api
這些控制器包括:服務器
kube-scheduler : 負責 pod 調度的進程,調度決策所考慮的因素包括我的和集體資源需求,硬件/軟件/策略約束,親和力和反親和性規範,數據位置,工做負載間干擾和最後期限網絡
etcd :負責Kubernetes 全部資源存儲的進程。架構
除了Master Kubernetes 中其餘節點都稱爲Node 節點,Node 能夠是物理機也能夠是虛擬機,Node 節點是Kubernetes 中的工做負載節點,每一個Node 都會由Master 調度承擔運行
容器(Docker )的工做。
*****注意Node 節點能夠在Kubernetes 集羣動態運行時加入,前提是這個Node 完成可初始化配置,默認狀況下Kublete 模塊向Master 申請註冊,一旦Node 申請被接受,Kublete 會
定時向master 節點提交本身的狀態,軟件和硬件資源信息。由 master 評估後進行資源調度,若是超時不上報。就會被標記爲不可用,Master 會進行故障轉移的調度。
每一個節點都運行一組關鍵進程:
Kubelet :負責Pod 對應容器的建立,啓停等任務,同時與master 協同工做,實現Kubernetes 運行的基本組件。
Kube-proxy :是在羣集中的每一個節點上運行的網絡代理。它經過維護主機上的網絡規則並執行鏈接轉發來實現Kubernetes服務抽象。kube-proxy
負責請求轉發。kube-proxy
容許經過一組後端功能進行TCP和UDP流轉發或循環TCP和UDP轉發。實現kubernetes service 的通訊和與負載工做
Container Runtime:負責容器運行,容器建立和管理。
插件是實現集羣功能的pod和服務工具,能夠是第三方工具。
DNS:雖然其餘插件並不是嚴格要求,但全部Kubernetes集羣都應具備集羣DNS,由於許多示例都依賴於它。羣集DNS是DNS服務器,除了您環境中的其餘DNS服務器以外,它還爲Kubernetes服務提供DNS記錄。
Kubernetes啓動的容器會在DNS搜索中自動包含此DNS服務器
Web UI:Kubernetes 集羣可視化管理工具和圖表工具
Container Resource Monitoring:容器資源監視工具。‘
Cluster-level Logging: 集羣運行日誌分析工具。
’
Containers
Images : 鏡像倉庫,Kubernetes 對容器的管理依賴於選擇的容器管理工具,好比 Docker
Container Environment Variables:
RuntimeClass: RuntimeClass是用於選擇容器運行時配置的功能。容器運行時配置用於運行Pod的容器
Container Lifecycle Hooks: 相似於許多具備組件生命週期hooks的編程語言框架,例如Angular,Kubernetes爲Containers提供了生命週期hooks。hooks使Container可以瞭解其管理生命週期中的事件,並在執行相應的生命週期hooks時運行在處理程序中實現的代碼。
Workloads
1.Pods
pod 是一組一個或一個以上的 容器(例如Docker容器),具備共享存儲/網絡,以及如何運行容器的規範。Pod的內容始終位於同一位置並共同調度,並在共享上下文中運行。Pod模擬特定於應用程序的「邏輯主機」 - 它包含一個或多個相對緊密耦合的應用程序容器 - 在預容器世界中,在同一物理或虛擬機上執行意味着在同一邏輯主機上執行。就Docker構造而言,Pod被建模爲一組具備共享命名空間和共享文件系統卷的Docker容器.
Pod是多個合做過程模式的模型,造成了一個有凝聚力的服務單元。它們經過提供比其組成應用程序集更高級別的抽象來簡化應用程序部署和管理。Pod用做部署,水平擴展和複製的單元。對Pod中的容器自動處理共置(共同調度),共享命運(例如終止),協調複製,資源共享和依賴關係管理。
2.pod controllers ReplicaSet
ReplicaSet使用字段定義,包括指定如何識別它能夠獲取的Pod的選擇器,指示它應該維護多少Pod的多個副本,以及指定它應該建立的新Pod的數據的pod模板以知足該數量複製品標準。而後,ReplicaSet經過根據須要建立和刪除Pod來達到其目的,以達到所需的數量。當ReplicaSet須要建立新Pod時,它使用其Pod模板。
ReplicaSet與其Pods的連接是經過Pods的metadata.ownerReferences 字段,該字段指定當前對象所擁有的資源。ReplicaSet獲取的全部Pod在其ownerReferences字段中擁有其擁有的ReplicaSet標識信息。經過此連接,ReplicaSet知道它正在維護的Pod的狀態並相應地進行計劃。
ReplicaSet使用其選擇器標識要獲取的新Pod。若是Pod沒有OwnerReference或者OwnerReference不是控制器而且它與ReplicaSet的選擇器匹配,則它將當即由所述ReplicaSet獲取。
Services, Load Balancing, and Networking
Service : 一種抽象的方式暴露在一組運行的應用程序pod做爲網絡服務。無需修改應用程序便可使用不熟悉的服務發現機制。Kubernetes爲pod提供了本身的IP地址和一組pod的單個DNS名稱,而且能夠在它們之間進行負載平衡。爲pod 提供了對外業務的入口。
DNS for Services and Pods :Kubernetes DNS在羣集上安排DNS Pod和服務,並配置kubelet以告知各個容器使用DNS服務的IP來解析DNS名稱
Connecting Applications with Services:默認狀況下,Docker使用主機 - 專用網絡,所以只有當容器位於同一臺計算機上時,容器才能與其餘容器通訊。爲了使Docker容器跨節點進行通訊,必須在計算機自己的IP地址上分配端口,而後將其轉發或代理到容器。這顯然意味着容器必須很是當心地協調它們使用的端口,或者必須動態分配端口。跨多個開發人員協調端口很是難以大規模地進行,並使用戶暴露在他們沒法控制的集羣級別問題以外。Kubernetes假設豆莢能夠與其餘豆莢通訊,不管它們落在哪一個主機上。咱們爲每一個pod提供了本身的集羣專用IP地址,所以您無需在pod之間顯式建立連接或將容器端口映射到主機端口。這意味着Pod中的容器能夠在localhost上到達彼此的端口,而且羣集中的全部pod均可以在沒有NAT的狀況下看到彼此。本文檔的其他部分將詳細說明如何在這種網絡模型上運行可靠的服務
Ingress: 管理羣集中服務的外部訪問的API對象,一般是HTTP。Ingress能夠提供負載平衡,SSL終止和基於名稱的虛擬主機。
Ingress Controllers:
爲了使Ingress資源正常工做,羣集必須運行入口控制器。
與做爲kube-controller-manager
二進制文件一部分運行的其餘類型的控制器不一樣,Ingress控制器不會自動與集羣一塊兒啓動。使用此頁面選擇最適合您的羣集的入口控制器實施。Kubernetes做爲一個項目目前支持和維護GCE和 nginx控制器。
Kubeadm 是一個工具,它提供了 kubeadm init
以及 kubeadm join
這兩個命令做爲快速建立 kubernetes 集羣的最佳實踐。