- 0x00 基礎簡述
- Borg 系統
- Kubernetes 系統
- 1.發展經曆
- 2.簡要介紹
- 3.系統架構
- 0x01 元件詳述
- 1.Kubernetes-Master
- 2.Kubernetes-Node
- 3.Kubernetes-插件
- 4.小結
0x00 基礎簡述
1.發展經曆
描述:近些年由于Cloud雲計算(公有雲)以及大資料的發展促進了企業從傳統轉型到數字資訊化再到上雲, 其中運維部署應用技術也從實體機轉向虛拟化再轉向了容器化，而又随着分布架構應用的火熱，以及對業務快速疊代的的需要，便推動了如今的Kubernetes分布式架構運維平台，它實作了對容器資源的編排與控制, 這也是本次學習的重中之重;
# 公有雲類型
Infrastructure as a Service (基礎設施及服務) ：阿裡雲、騰訊雲、百度雲、京東雲、Google Cloud、AWS Cloud
# 提供給消費者的服務是對所有計算基礎設施的利用，包括處理CPU、記憶體、存儲、網絡和其它基本的計算資源，使用者能夠部署和運作任意軟體，包括作業系統和應用程式。
Platform as a Service (平台及服務) ：新浪雲(SAE) | Google Cloud 平台(GCP)
# 提供給消費者的服務是把客戶采用提供的開發語言和工具（例如Java，python, .Net等開發環境）開發的或收購的應用程式部署到供應商的雲計算基礎設施上去。
Software as a Service (軟體即服務) : Office 365(雲辦公) 、 騰訊文檔
# 提供給客戶的服務是bai營運商運作在雲計算基礎設施上的應用程式，使用者可以在各種裝置上通過用戶端界面通路，如浏覽器。 部署時代變遷流程
描述:又回到部署時代變遷流程, 大緻來說在部署應用程式的方式上，我們主要經曆了三個時代：
- (1)傳統部署時代：早期企業直接将應用程式部署在實體機上。由于實體機上
不能為應用程式定義資源使用邊界
- (2)虛拟化部署時代：針對上述問題，虛拟化技術應運而生。使用者可以在單台實體機的CPU上運作多個虛拟機(Virtual Machine)。
- 虛拟化技術使得
應用程式被虛拟機互相分隔開
- 虛拟化技術
提高了實體機的資源使用率
- 每一個虛拟機可以認為是被虛拟化的實體機之上的一台完整的機器，其中運作了一台機器的所有元件，包括虛拟機自身的作業系統。
- (3)容器化部署時代：容器與虛拟機類似，但是
降低了隔離層級，共享了作業系統
- 與虛拟機相似，每個容器擁有自己的檔案系統、CPU、記憶體、程序空間等
- 運作應用程式所需要的資源都被容器包裝，并和底層基礎架構解耦(
不強制依賴宿主系統硬體環境
- 容器化的應用程式可以跨雲服務商、跨Linux作業系統發行版進行部署
容器因具有許多優勢而變得流行起來,這裡再老生重談一下容器化對我們帶來的諸多好處:
- 1.靈活地建立和部署應用程式: 比VM建立容器鏡像更快更友善;
- 2.持續開發、內建和部署:通過快速、簡便的復原(由于映像不變性)，提供可靠且頻繁的容器映像生成和部署。
- 3.分離開發和運維的關注點: 降低了開發和運維的耦合度
- 4.可監控性: 作業系統級别的資源監控資訊以及應用程式健康狀态以及其他信号的監控資訊
- 5.開發、測試、生産不同階段的環境一緻性: 一次build到處運作;
- 6.跨雲服務商、跨作業系統發行版的可移植性: 在 Ubuntu、RHEL、CoreOS、本地、主要公共雲和其他任何位置上運作。
- 7.以應用程式為中心的管理:問題的焦點則是在作業系統的邏輯資源上運作一個應用程式,而VM注重于在虛拟硬體上運作一個作業系統
- 8.松耦合、分布式、彈性、無限制的微服務:應用程式被切分成更小的、獨立的微服務，并可以動态部署和管理，而不是一個部署在專屬機器上的龐大的單片應用程式
- 9.資源隔離：確定應用程式性能不受幹擾
- 10.資源利用：資源高效、高密度利用
前世今生
言歸正傳，讓我們回顧一下 Kubernetesd 的前世今生，在KUbernetes出現前的一些資料總管。
- 1.Apache MESOS 分布式的資源管理架構 (2019-8 Twitter 宣布棄用MESOS轉向Kubernetes) -> 退出舞台
- 2.Docker Swarm 針對于 Docker 最薄弱的叢集化、容器編排與服務建構 (2019-07 阿裡雲宣布 Docker Swarm從雲平台建構選項中剔除) -> 即将退出舞台
- 優點: 系統資源占用少(幾十兆) 、支援大規模叢集化
- 缺點：功能單一滾動更新以及復原需要運維人員自定義流程費時
- 3.Kubernetes 由 Google 基于 Borg (博格)10年的容器化基礎架構采用GO語言進行重寫
在2015年4月份
- Google 每周運作數十億個容器，Kubernetes 基于與之相同的原則來設計，能夠在不擴張運維團隊的情況下進行規模擴充。
- 無論是本地測試，還是跨國公司，Kubernetes 的靈活性都能讓你在應對複雜系統時得心應手。
- Kubernetes 是開源系統，可以自由地部署在企業内部，私有雲、混合雲或公有雲，讓您輕松地做出合适的選擇。
- Kubernetes 的生态系統更大、增長更快，有更多的支援、服務和工具可供使用者選擇,可以将Kubernetes看做為Docker的上層架構。
以下是使用 google trends 對比在對于上述的容器編排工具
kubernetes
、
docker swarm
、
mesos
三個關鍵詞搜尋熱度的截圖。
Q:那什麼是Kubernetes系統?
答: Kubernetes (K8s)是一個用于自動化部署、擴充和管理容器化應用程式的開源系統。
簡單的說它就是一個全新基于容器技術的分布式架構方案，Kubernetes 是一個可移植的、可擴充的開源平台，用于管理容器化的工作負載和服務，可促進聲明式配置(
)和自動化。Kubernetes 擁有一個龐大且快速增長的生态系統。依據配置資訊自動地執行容器化應用程式的管理
參考位址: https://kubernetes.io/zh/docs/concepts/overview/what-is-kubernetes/
名稱含義
描述: Kubernetes的名字起源于希臘語，含義是
舵手
、
領航員
、
向導
，其logo即像一張漁網又像一個羅盤。
Google于2014年将Brog系統開源并命名為Kubernetes，它是建構在
Google Brog
十五年運作大規模分布式系統的經驗 基礎之上，同時凝聚了社群的最佳創意和實踐。
PS深層含義: 既然Docker把自己定位是馱着集裝箱在大海遨遊的鲸魚，那麼Kubernetes則是掌控大海進而捕獲和指引這條鲸魚按照其設定的路線巡遊，從這裡可以看出Google對其打造了新一代容器世界的偉大藍圖;
kubernetes 官網: https://kubernetes.io
2.簡要介紹
Kubernetes 能完成什麼工作
Q: 為什麼需要 Kubernetes? 它能做什麼?
答：容器是打包和運作應用程式的好方式但是免不了容器發生故障，在生産環境中您需要管理運作應用程式的容器并確定不會停機；
例如：當一個容器故障停機，需要另外一個容器需要立刻啟動以替補停機的容器。類似的這種對容器的管理動作由系統來執行會更好更快速(
而放棄傳統的手工方式
)。
Kubernetes針對此類問題提供了一個可彈性運作分布式系統的架構，可以使你非常健壯地運作分布式系統，它可以處理
應用程式的伸縮、failover(故障轉移)、部署模式
等多種需求。
例如:Kubernetes 可以輕松管理系統的 Canary 部署。
Kubernets 也提供了完善的管理工具涵蓋了開發/部署測試/運維監控的各個環節;
Q: Kubernetes 設計理念?
描述:其功能與架構都遵循了
"一切以服務為中心，一切圍繞服務運轉"
以及微服務的架構，簡化開發流程與運維的成本;
Q: 什麼是容器編排技術?
答:容器編排的技術定義是
預定義流程的執行(先做A、再做B、然後做C)
。與此相對應Kubernetes建構了一系列
互相獨立、可預排的控制過程
，以持續不斷地将系統從目前狀态調整到聲明的目标狀态。
比如: 如何從 A 達到 C，并不重要集中化的控制也就不需要了,就是這樣的設計思想使得Kubernetes
使用更簡單、更強大、穩健、反脆弱和可擴充
。
Q: K8s提供特性說明
- 服務發現和負載均衡：通過
DNS 名稱或 IP 位址
容器内分發負載以實作負載均衡
- 存儲編排:可以自動挂載指定的存儲系統，例如
本地存儲/nfs/iscsi/雲存儲
- 自動釋出和復原: 描述已部署容器的所需狀态并将以合适的速率調整容器的實際狀态, 可以
自動執行部署建立新容器、删除現有容器并将其所有資源采用到新容器
- 自愈: 重新啟動發生故障、替換容器、kill殺死不滿足自定義健康檢查條件的容器 (
在容器就緒之前，避免調用者發現該容器
- 密鑰及配置管理: 可以存儲和管理敏感資訊(例如，密碼、OAuth token、ssh密鑰等), 您可以更新容器應用程式的密鑰、配置等資訊,
而無需重新建構容器的鏡像
Kubernetes 不是什麼
描述：Kubernetes不是一個傳統意義的、保羅萬象的 PaaS(Platform as a Service)系統。
它主要在
容器層面上工作而不是硬體層面
，它提供了與PaaS相似的通用特性例如：
部署、伸縮、負載均衡、日志、監控
等; 然而K8a并不是一個單一整體，這些特性都是可選、可插拔的(
高自定義
)
Kubernetes提供用于搭建開發平台的基礎子產品，同時為使用者提供了不同子產品的選擇性和多樣性。
- 1.不限制應用程式的類型: K8s目的廣泛支援不同類型的工作負載，包括：
有狀态、無狀态、資料處理
隻要能在容器中運作的就可以在k8s上運作
- 2.不部署源碼、不編譯或建構應用程式: 可以作為部署平台參與到 CI/CD 流程，但是不涉及鏡像建構和分發的過程 ，即
持續內建、傳遞和部署 (CI/CD) 工作流
- 譯者注：可選的有 Jenkins / Gitlab Runner / docker registry / harbor 等
- 3.不提供應用程式級服務: 包括：中間件(例如，消息總線)、資料處理架構(例如Spark)、資料庫(例如，mysql)、緩存(例如，Redis)，或者分布式存儲(例如，Ceph)。
此類元件可以在 Kubernetes 上運作，或者可以被運作在 Kubernetes 上的應用程式通路
- 4.不限定日志、監控、報警的解決方案: k8s提供一些樣例展示如何與日志、監控、報警等元件內建，同時提供收集、導出監控度量(metrics)的一套機制，使用者可根據自己的需求進行選擇
日志、監控、以及報警元件
- 譯者注：可選的有 ELK(日志) / Graphana(
日志展示平台
分布式系統性能監控工具
Skywalking分布式追蹤與監控
英 /ˈmetrɪks/ 容器監控
容器監控
- 5.不提供或者限定配置語言(例如jsonnet): 提供一組聲明式的 API您可以按照自己的方式定義部署資訊。
- 譯者注：可選的有
helm / kustomize / kubectl / kubernetes dashboard / kuboard /octant / k9s
- 6.不提供或限定任何機器的配置、維護、管理或自愈的系統。
- 譯者注：在這個級别上，可選的元件有
puppet、ansible、open stack
- 7.實際上 Kubernetes
不是一個純粹意義上的容器編排系統
總結簡要K8s優點與劣勢
- (1) 優點
- 開源(由于東家是Google不用擔心項目更新疊代)
- 輕量級、消耗資源小
- 貼近底層
- 彈性收縮
- 負載均衡
- (2) 劣勢
- 前期學習成本高, 體系龐大且冗雜;
Kubernetes 版本号格式
Kubernetes 版本号格式遵循 Semantic Versioning 版本控制規則, 版本号格式為 x.y.z，其中 x 為大版本号，y 為小版本号，z 為更新檔版本号。
一般 Kubernetes 項目會維護最近的三個小版本分支（例如:2020年11月 ->
1.19, 1.18, 1.17
）。
- Kubernetes 1.19 及更高的版本将獲得大約1年的更新檔支援。
- Kubernetes 1.18 及更早的版本獲得大約9個月的更新檔支援。
https://kubernetes.io/zh/docs/setup/release/version-skew-policy/
Q：如何學習Kubernetes系統?從哪幾方面進行入手學習?
答: 筆者最初學習時候由于K8s知識體系太龐大了導緻零零散散的學習了一些基礎知識, 但是越學到後面就越吃力，是以又不得重新學習一些基礎知識，下面就是本人學習思路:
- 介紹說明：前世今生 Kubernetes基礎介紹 Borg / Kubernetes 架構 KUbernetes關鍵字含義
- 基礎概念：什麼是 Pod 控制器類型 K8S 網絡通訊模式
- 工具部署：單節點 建構 K8S 叢集
- 資源清單：資源 掌握資源清單的文法 編寫 Pod 掌握 Pod 的生命周期***
- Pod 控制器：掌握各種控制器的特點以及使用定義方式
- 服務發現：掌握 SVC 原理及其建構方式
- 存儲：掌握多種存儲類型的特點 并且能夠在不同環境中選擇合适的存儲方案(有自己的簡介)
- 排程器：掌握排程器原理 能夠根據要求把Pod 定義到想要的節點運作
- 安全：叢集的認證 鑒權 通路控制 原理及其流程
- HELM：Linux yum 掌握 HELM 原理 HELM 模闆自定義 HELM 部署一些常用插件
- 運維：修改Kubeadm 達到證書可用期限為 10年 能夠建構高可用的 Kubernetes 叢集
- 開發：Kubernetes 自開發實作特殊功能
Q: k8s适合人群學習研究?
描述: 項目經理、軟體架構師、軟體工程師、測試工程師、運維工程師以及其它網絡技術愛好者;
Q: 學習參考文檔?
答:入門必看文檔系列以後看到K8s一律等同于Kubernetes隻是友善國人發音;
- K8S文檔:https://kubernetes.io/docs/home/
- Kuboard(國人文檔):https://kuboard.cn/learning/
3.系統架構
描述: 為了更好的了解與學習Kubernets就需借鑒對照Brog系統架構, 看出K8s如何基于Brog系統進行演變更新;
Borg 系統
1) Borg系統架構圖如下:
2) 元件簡單說明:
- BorgMaster : 叢集大腦主要負責各元件請求的分發，為了防止其單節點故障, 高可用叢集副本資料最好是
>= 3
- Borglet : 工作節點提供各類資源運作對應的容器, 并實時與Paxos進行聯系監聽，如果有請求取出(消費者)去執行該任務;
- Persistent Store : 簡寫 Paxos 它是Google的一個鍵值對資料庫;
- Scheduler : 排程器将任務排程的資料寫入Persistent Store(Paxos)而不是直接與Borglet節點進行聯系;
- 通路方式 : Borgcfg(Config File), Command-line Tools, Web Browsers;
Kubernetes 系統
1) K8s系統架構圖如下:
2) 元件簡單說明:
- Kubernetes Master (Control Plane)
- Control Plane Components : 控制平面元件對叢集做出全局決策(比如排程)，以及檢測和響應叢集事件(例如當不滿足部署的 replicas 字段時啟動新的 pod)
- Kube-api-server : 所有服務請求通路統一入口, 基于HTTP協定進行的C/S架構開發；PS 由于HTTP協定本身支援多種請求方式和驗證則沒有必要采用TCP協定重寫;
- Kube-controller manager : 控制器元件其内部包含多個控制器，并且每個控制器都是一個單獨的程序(
節點控制器(NC)/ 副本控制器(RC 機制維持副本期望數目)/ 端點控制器(EC) / 服務帳戶和令牌控制器 (SA & TC)
- Cloud-controller manager : 雲控制器管理器是1.8的alpha 特性在未來釋出的版本中将 Kubernetes 與任何其他雲內建的最佳方式， 它主要用于
特定于雲平台的控制回路
- kube-scheduler : 排程器負責任務排程選擇合适的節點進行配置設定任務
- Etcd : 它是一個可信賴(自身支援叢集化)的分布式(擴容縮友善)鍵值對存儲服務資料庫, 它能夠為整個K8S分布式叢集存儲某些關鍵性資料, 并協助分布式叢集的正常運轉;
- Kubernetst Nodes
- Kubelet : 通過CRI(Cinatiner/Runtime/Interface)直接跟容器引擎(Docker)互動實作容器的生命周期管理
- Kube-proxy : 負責寫入規則至 IPTABLES、IPVS 實作服務映射通路的
- Container Runtime : 容器運作環境是負責運作容器的軟體Kubernetes 支援多個容器運作環境: docker、 containerd、CRI-O 以及任何實作 Kubernetes CRI 容器運作環境接口。
- Cloud ：共有雲、私有雲
PS : 不管是K8S的master節點還是Nodes節點都需要依賴容器引擎但不限于docker(主流預設)或者其它的一些容器引擎(podman)
參考位址：https://kubernetes.io/zh/docs/concepts/overview/components/
補充記錄時間:
[2020年4月22日 14:51:04]
PS : etcd Storage 有
v3 與 v2
版本, 先K8S叢集中使用的是etcd v3版本, v2版本已在K8s v1.11中棄用, 更多資訊請參考官網或者部落格中
<Etcd基礎學習之架構及工作原理.md>
;
- v3 : Database 存儲在磁盤便于資料的持久化進而保證資料不會在誤操作的情況下丢失
- v2 : Memory 存儲在記憶體存儲資料随着機器重新開機而導緻資料丢失
元件說明:
- HTTP SERVER : 與K8S一樣也是采用HTTP協定進行服務請求送出入口
- Raft : 實時讀寫的資訊
- WAL : 預寫日志
- Entry : 實體資訊
- Snapshot : 快照資訊(按照一定的時間将某個時間節點的大版本與其後的增量子版本進行整合備份便于後期資料恢複)
-
Store : 将資料存入到本地存儲中進行資料的持久化
etcd 官方位址：https://etcd.io/docs/v3.4.0/
0x01 元件詳述
通過上面的簡單的K8s元件說明，下面詳述了 Kubernetes 的主要元件(該章節
非常的重要
了解其元件是了解其K8s架構的基礎)
1.Kubernetes-Master
Q:Control Plane Components控制平面元件的作用說明
答:它是叢集的控制平台元件()，主要負責叢集中的全局決策(Control Plane Components
)和探測并響應叢集事件(例如排程
例如: 當 Deployment 的實際 Pod 副本數未達到 replicas 字段的規定時，啟動一個新的 Pod
);
控制平面元件可以運作于叢集中的任何機器上，但是為了簡潔性該元件
;通常是在運作在一台無其業務容器下的機器上
Master節點下元件的介紹:
- 1.kube-apiserver : 主要用于提供
Kubernetes API
kubectl / kubernetes dashboard / kuboard
- 2.etcd : 支援一緻性和高可用的鍵值對存儲元件，Kubernetes叢集的所有配置資訊都存儲在 etcd 中,是以etcd 資料庫通常需要有個備份計劃;
- 3.kube-scheduler : 主要用于任務排程，此元件監控所有新建立尚未配置設定到節點上的 Pod，并且自動選擇為 Pod 選擇一個合适的節點去運作。
- 影響排程的因素有：
單個或多個 Pod 的資源需求、硬體、軟體、政策的限制、親和與反親和(affinity and anti-affinity)的約定、資料本地化要求、工作負載間的幹擾和最後時限
- 4.kube-controller-manager: 在主節點上運作控制器的元件(資源對象的自動化控制中心)，
從Logic上來說每一個控制器是一個獨立的程序
控制器都被編譯到同一個可執行檔案并運作在一個程序
- 節點控制器(Node Controller):
負責監聽節點停機的事件并作出對應響應
- 副本控制器(Replication Controller) :
負責為叢集中每一個副本控制器對象(Replication Controller Object)維護期望的 Pod 副本數
- 端點控制器(Endpoints Controller):
負責為端點對象(Endpoints Object，連接配接 Service 和 Pod)指派
- 服務帳戶和令牌控制器(Service Account & Token Controllers): 負責為新的
名稱空間建立 default Service Account 以及 API Access Token
- 5.cloud-controller-manager: 雲控制器管理器是 1.8 的 alpha 特性,這是将 Kubernetes 與任何其他雲內建的最佳方式。雲控制器管理器允許您
将叢集連結到雲提供商的API
用于特定于雲平台的控制回路
。與 kube-controller-manager 類似，cloud-controller-manager 将若幹邏輯上獨立的 控制回路組合到同一個可執行檔案中，供你以同一程序的方式運作。你可以對其執行水準擴容(運作不止一個副本)以提升性能或者增強容錯能力。
以下控制器可以有雲提供商依賴:
(1) 節點 (Node) 控制器(Node Controller)：當某一個節點停止響應時，調用雲供應商的接口，以檢查該節點的虛拟機是否已經被雲供應商删除 #譯者注：私有化部署Kubernetes時，我們不知道節點的作業系統是否删除，是以在移除節點後，要自行通過 kubectl delete node 将節點對象從 Kubernetes 中删除 (2) 路由 (Router) 控制器 (Route Controller)：在雲供應商的基礎設施中設定網絡路由（`即用于在底層雲基礎架構中設定路由`） #譯者注：私有化部署Kubernetes時，需要自行規劃Kubernetes的拓撲結構，并做好路由配置，例如 安裝Kubernetes單Master節點 中所作的 (3) 服務(Service) 控制器 (Service Controller)：`建立、更新、删除`雲供應商提供的負載均衡器 #譯者注：私有化部署Kubernetes時，不支援 LoadBalancer 類型的 Service，如需要此特性，需要建立 NodePort 類型的 Service，并自行配置負載均衡器 (4) 資料卷 (Volume) 控制器：`建立、綁定、挂載`資料卷，并協調雲供應商編排資料卷 #譯者注：私有化部署Kubernetes時，需要自行建立和管理存儲資源，并通過Kubernetes的存儲類、存儲卷、資料卷等與之關聯 - ccm(簡稱)使得雲供應商的代碼和 Kubernetes 的代碼可以各自獨立的演化，使得K8核心代碼不在高度依賴于雲供應商的代碼的; ccm(簡稱)與kcm(簡稱)一樣
将幾個邏輯上獨立的控制循環組合成一個二進制檔案作為一個程序運作
- 注意在進行K8s叢集安裝時候可能預設不會安裝
cloud-controller-manager
cloud-controller-manager，Kubernetes
補充說明:
Q:什麼是alpha階段?
答:即開發内部測試階段;
2.Kubernetes-Node
描述：Node 元件運作在每一個節點上(包括 worker 節點或者 master 節點)，
負責維護運作中的 Pod 并提供 Kubernetes 運作時環境
。
Node下元件的介紹:
- 1.kubelet: 此元件是運作在每一個叢集節點上的代理程式
確定 Pod 中的容器處于運作狀态
- 它通過多種途徑獲得 PodSpec 定義，并確定 PodSpec 定義中所描述的容器處于運作和健康的狀态。
- 注意:Kubelet它是不管理
不是通過 Kubernetes 建立的容器
- 2.kube-proxy: 此元件是一個網絡代理程式，運作在叢集中的每一個節點上，是實作
Kubernetes Service
- 它維護節點上的網絡規則使得您可以在叢集内、叢集外正确地與 Pod 進行網絡通信, 同時它也是負載均衡中最重要的點；
- 如果有可用的作業系統包過濾層kube-proxy将使用它，否則kube-proxy将轉發流量本身。
- 3.容器引擎: 負責運作容器Kubernetes支援多種容器引擎：Docker 、containerd 、cri-o 、rktlet 以及任何實作了 Kubernetes CRI (容器運作環境接口) 的容器引擎
補充說明:
[2020年4月22日 16:41:04]
Q:什麼是引擎?
答:建立和管理容器的工具，通過讀取鏡像來生成容器，并負責從倉庫拉取鏡像或送出鏡像到倉庫中；
Q:多種容器引擎介紹
- (1) Docker Engine : 是一種開源容器化技術，用于建構和容器化應用程式(
C/S架構應用
守護程序dockerd,與 Docker 守護程序進行對話和指導的接口的 API,指令行接口 (CLI) 用戶端使用Docker API通過腳本或直接指令控制與 Dockerd 守護程序互動
1-Kubernetes基礎入門體系架構學習(一) - (2) Containerd Engine : 是容器運作環境的核心引擎(
容器編排/排程技術的基礎
提供定制化
前面我們說過在Node節點中Kubelet主要負責Pod的建立、啟動、監控、重新開機、銷毀;但它并不是直接面向最終使用者, 主要是用于內建到更上層的系統裡, 比如
Docker Swarm, Kubernetes, Mesos
等容器編排系統。
PS : 例如 Docker
- Docker 是 Kubernetes 社群支援或生态系統中用來在本地計算機上設定 Kubernetes 叢集的一種工具。
3.Kubernetes-插件
描述：插件使用 Kubernetes 資源（DaemonSet、 Deployment等）實作叢集功能。因為這些插件
提供叢集級别的功能
，插件中命名空間域的
資源屬于 kube-system 命名空間
。
下面描述了一些經常用到的 addons 更多插件請參考K8s的 Addons List
- 1.CoreDNS: 可以為叢集中的SVC建立一個域名IP的對應關系解析，它實際上就是一個 DNS 伺服器和環境中的其他 DNS 伺服器一起工作，它是實作負載均衡最重要的一環，所有 K8s 叢集都應該有
Cluster DNS
- 2.Web UI(Dashboard):是一個Kubernetes叢集的 Web (
B/S 結構通路體系
- 3.Kuboard:是一款基于Kubernetes的微服務管理界面，相較于 Dashboard 來說Kuboard的特點 ：
無需手工編寫 YAML 檔案 、微服務參考架構、上下文相關的監控、場景化的設計(導出配置、導入配置)
- 4.Container Resource Monitoring(容器資源監控): 将容器的度量名額(metrics)記錄在時間序列資料庫中，并提供了 UI 界面檢視這些資料;
- 5.Cluster-level Logging(叢集級别的日志記錄): 機制負責将容器的日志存儲到一個統一存儲中，并提供搜尋浏覽的界面;
- 6.Prometheus: 提供K8S叢集的監控能力，将關于容器的一些常見的時間序列路徑成本儲存到一個集中的資料庫中，并提供用于浏覽這些資料的界面。
- 7.ELK / EFK : 提供 K8S 叢集日志統一分析接入平台，負責将容器的日志資料 儲存到一個集中的日志存儲中，該存儲能夠提供搜尋和浏覽接口。
- 8.Federation ：提供一個可以跨叢集中心多K8S統一管理功能
- 9.Ingress: 官方隻能實作四層代理,但是他可以實作七層代理，例如
Ingress-Nginx 、 Ingress-traefik
Q:什麼是Cluster DNS
答:
Cluster DNS
(
英 /ˈklʌstə(r)/
) 是一個 DNS 伺服器，是對您已有環境中其他 DNS 伺服器的一個補充，存放了 Kubernetes Service 的 DNS 記錄。
4.小結
描述: 前面我們說了k8s能夠對容器化軟體進行部署管理，在不停機的前提下
提供簡單快速的釋出和更新方式
, Kubernetes是
自動化部署，縮放，以及集裝箱應用管理一個開放源碼的容器業務流程引擎
;
簡單的說: 如果項目需要多機器節點的微服務架構，并且采用
Docker image(鏡像)進行容器化部署
，那麼k8s可以幫助我們屏蔽掉叢集的複雜性，自動選擇最優資源配置設定方式進行部署;
下圖描述的是擁有一個Master(主)節點和六個Worker(工作)節點的k8s叢集, 可以通平面化檢視其K8s元件展示；
-
Master 節點
- 運作着叢集管理的一組程序:
kube-apiserver , kube-controller-manager 和 Kube-scheduler
-
Worker 節點
- 每個Worker節點都運作着一組程序:
Kubelet / Kubelet-proxy
- 每個Worker節點還安裝了用于處理容器操作的工具: 例如Docker或者Container.io;
- 工作負載是在 Kubernetes 上運作的應用程式。
1-Kubernetes基礎入門體系架構學習(一)