Kubernetes 學習門檻在哪兒
學習 Kubernetes 之前灶芝，必須具備的知識儲備：
- Linux 基礎
- 網(wǎng)絡基礎
- 容器技術，例如 https://www.docker.com/
學習 Kubernetes 的過程中可能碰到的難關：
- 理解 Kubenetes 為了實現(xiàn)容器編排而提出的各種抽象概念以及他們之間的關系：容器組（Pod）、存儲卷（Volume）冀偶、存儲卷聲明（PVC）、Ingress、Service 等
- 安裝及配置 Kubernetes 環(huán)境
- 編寫和維護 Kubernetes Yaml 文件
- 熟悉 kubectl 命令行工具中常用的 10 多個命令
降低 Kubernetes 學習門檻
學習路線
單純地按章節(jié)學習 Linux 基礎知識羽嫡、網(wǎng)絡知識、容器技術等肩袍，每一塊兒的基礎入門書籍就有幾百頁之多杭棵。作者認為，最好的學習方法是在實踐中學習氛赐，碰到問題時去尋求答案魂爪，解決問題后去反思總結。這種學習方法趣味性強艰管，得來的知識也最為牢靠滓侍，如果選對了方向，所學知識通常也是工作中實用性最高的知識牲芋。讀了100頁 K8S 文檔撩笆，也不如安裝一遍 K8S
Kuboard 為初學者學習 Kubernetes 時設計了如下學習路徑：
- 跟隨文檔 安裝 Kubernetes 單Master節(jié)點 快速安裝一個可以練習使用的 Kubernetes 環(huán)境，（初學者也許要花費2小時或更多）
- 跟隨文檔 安裝 Kuboard （5分鐘）
- 使用 Kuboard 工作負載編輯器 創(chuàng)建 busybox （10分鐘）
- 嘗試 Kuboard 設計的其他 example 使用 Kuboard
進階路線：
- 在 Kubernetes 中部署 Spring Cloud 微服務應用
快速入門
? 在向 Kubernetes 集群部署應用時缸浦，開發(fā)者或者運維團隊必須花大量的時間去理解 Kubernetes 中各種對象的概念夕冲，并編寫 Yaml 文件去描述 Kubernetes 對象以及他們之間的關系，然而裂逐，不同的人因為經(jīng)驗歹鱼、視角的不同，對Kubernetes 中各對象之間關系的理解并不完全一致卜高，也因此產(chǎn)生了一系列問題：
- 由于理解的不到位醉冤，剛入門Kubernetes的技術人員在使用 Kubernetes 部署應用時經(jīng)常性地受挫；
- 由于理解方式的不一致篙悯，不同技術人員編寫的 yaml 文件結構各不一樣蚁阳，降低了部署在后期的可維護性；
- 由于部署數(shù)量的增加鸽照，導致 YAML 文件的數(shù)量和代碼行數(shù)不斷增長螺捐；
? Kubernetes 官方提供的 Kubernetes Dashboard 充分意識到了 Kubernete 對象類型在種類上的多樣性以及關系上的復雜性，到目前為止并沒有在全功能 Dashboard 上做出過多努力，尤其是沒有付出過多努力去打造工作負載的 UI 編輯器定血。在 Kubernetes Dashboard 中赔癌，如果想要對 Service、Deployment澜沟、StatefulSet灾票、ConfigMap 等各種 Kubernetes 對象執(zhí)行新增或者變更操作時，您必須編寫 YAML 文件茫虽。從這個意義上來講刊苍，截止到作者寫這篇文章的時間點，Kubernetes 的官方 Dashboard 仍然是一個 “只讀” 型 Dashboard濒析，幾乎所有的運維操作仍然需要技術人員去編寫和維護冗長的 YAML 文件正什，并通過 kubectl 命令來完成。
? 由于 Kubernetes YAML 文件復雜性号杏，以及開發(fā)/運維團隊在多環(huán)境復制（開發(fā)環(huán)境婴氮、測試環(huán)境、準上線環(huán)境盾致、生產(chǎn)環(huán)境等）方面的普遍需求主经，Kubernetes 社區(qū)提出了各種各樣的解決方案，例如 kustomize / helm chart 等庭惜，這些解決方案在解決一個問題的同時旨怠，又在另一方面增加了復雜度，為 Kubernetes 愛好者增加了新的學習門檻蜈块。
入門利器
為了降低 Kubernetes 的學習難度和使用難度鉴腻，Kuboard 對 Kubernetes 中管理的各種對象做了一個梳理，并以此為基礎百揭，設計了 Kuboard 工作負載編輯器爽哎。
Kuboard 工作負載編輯器以下圖的方式理解和管理 Kubernetes 對象。
上圖中各概念與 Kuboard 工作負載編輯器界面的映射關系如下：
1. 基本信息
基本信息對應到 Kubernetes 的 Workload Controller器一，當前 Kuboard 工作負載編輯器已經(jīng)支持了使用頻率最高的幾類 Workload Controller ：
- Deployment
- StatefulSet
- DaemonSet
Kuboard 將陸續(xù)支持其他低頻使用的 Controller: Garbage Collection, TTL Controller, Jobs, Cron Job课锌。
Kubernetes Workload Controller 主要用于：
- 根據(jù)容器組模板的定義，創(chuàng)建和管理多個容器組
- 處理容器組的復制和上線
- 在集群范圍內(nèi)提供自修復能力
例如：Workload Controller 起初在節(jié)點 A 上創(chuàng)建并運行了一個容器組 pod_a祈秕，當節(jié)點 A 出現(xiàn)故障不能正常工作時渺贤，Workload Controller 可以自動地在其他可用的節(jié)點上運行一個完全相同的容器組實例 pod_a' 以替代 pod_a。
不同類型的 Workload Controller 在處理容器組時请毛，會有各自不同的行為志鞍。
請參考 https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/#pods-and-controllers
基本信息編輯器的界面如下圖所示：
| 字段名稱 | 字段描述 |
|---|---|
| 服務類型 | 即工作負載類型， |
| 當前支持： Deployment方仿、StatefulSet固棚、DaemonSet | |
| 服務分層 | 決定了 Kuboard 將該工作負載展示在哪一個分層统翩，同時，也確定了該工作負載名稱的前綴此洲，可選項有： |
- 展現(xiàn)層 web厂汗、網(wǎng)關層 gateway、服務層 svc呜师、持久層 db娶桦、中間件層 cloud、監(jiān)控層 monitor汁汗；
- 默認層當前不可選擇 |
| 標簽 | 用于確定 Service 的 labelSelector衷畦、Controller 的 labels、容器組的 labels |
| 服務描述 | 展示在 Kuboard 界面上的一段描述信息 |
| 副本數(shù)量 | 對于 Deployment 和 StatefulSet 可以填寫碰酝，決定了該控制器應該維持的容器組副本的數(shù)量 |
2. 數(shù)據(jù)卷
? 容器每次啟動時，從鏡像中初始化所有文件戴差，后續(xù)對文件系統(tǒng)的修改送爸、新增、刪除操作的結果都是不能持久化的暖释。當容器崩潰時袭厂， kubelet 重啟該容器，但是原容器已經(jīng)做的修改將丟失球匕，因為每次啟動容器纹磺，都是從鏡像中初始化；此外亮曹，多個容器運行在同一個容器組中時橄杨，通常伴隨著在不同容器之間共享文件的需求。
? Kubernetes的抽象出了數(shù)據(jù)卷 Volume 的概念照卦，以解決上述的問題式矫。
? Kuboard 目前支持如下類型的數(shù)據(jù)卷：
- NFS
- 存儲卷聲明
- emptyDir
- 配置 ConfigMap
- Secrets
Kubernetes 支持的數(shù)據(jù)卷類型，請參考：https://kubernetes.io/docs/concepts/storage/volumes/#types-of-volumes
Kuboard 認為當前支持的數(shù)據(jù)卷類型已經(jīng)滿足絕大多數(shù)應用場景役耕，目前正在添加對更多類型數(shù)據(jù)卷的支持采转。
? 容器組中的不同容器都可以通過掛載點引用該容器組加載的數(shù)據(jù)卷。Kuboard 工作負載編輯中瞬痘，使用如下界面定義數(shù)據(jù)卷：
| 字段名稱 | 說明 |
|---|---|
| 數(shù)據(jù)卷名稱 | 如圖中的 example-data 故慈、 empty-dir |
| 數(shù)據(jù)卷類型 | |
| 數(shù)據(jù)卷詳細信息 | 不同類型的數(shù)據(jù)卷需要填寫的信息不盡相同，例如 |
存儲卷聲明框全，需要選擇事先已經(jīng)在名稱空間中創(chuàng)建好的存儲卷聲明
NFS察绷，需要填寫 NFS Server 的地址，以及 NFS Path |
3. 身份信息
身份信息區(qū)域主要為容器組定義兩類信息：
- imagePullSecrets津辩，容器組調用鏡像倉庫接口抓取鏡像時所使用的用戶名密碼克婶。如果您使用了私有鏡像倉庫筒严，您需要在此指定鏡像倉庫的用戶名密碼；如果您使用 docker 公共倉庫情萤，則無需填寫 imagePullSecrets
- ServiceAccount鸭蛙，容器組調用 kubernetes apiserver 時，所使用的身份信息
Kuboard 工作負載編輯器中關于身份信息的編輯界面如下所示：
4. 容器
容器是我們真正應用程序鏡像被加載和運行的地方筋岛，按照 Kubernetes 的設計娶视，一個容器組 Pod 中可以包含多個容器 Container，這些容器被分為兩類：
- 初始化容器
- 初始化容器總是執(zhí)行后結束執(zhí)行
- 初始化容器按其定義的順序執(zhí)行睁宰，前一個初始化容器執(zhí)行結束后肪获，才開始后一個初始化容器的執(zhí)行
- 只有初始化容器執(zhí)行成功后，容器組才啟動工作容器
- 請參考 https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
- 工作容器
- 容器組可以包含一個或多個工作容器
- https://kubernetes.io/docs/concepts/workloads/pods/pod-overview
Kuborad中柒傻，定義容器的界面如下圖所示：
5. 訪問方式
? 訪問方式孝赫，即 Kubernetes Service。
請參考： https://kubernetes.io/docs/concepts/services-networking/service/
? Kuboard 中红符，支持 ClusterIP（集群內(nèi)訪問） 以及 NodePort（VPC 內(nèi)訪問） 兩種 Service 訪問方式青柄，您也可以不為該工作負載定義 Service 訪問方式。訪問方式的界面如下所示：
6. 互聯(lián)網(wǎng)入口
? 互聯(lián)網(wǎng)入口预侯，即 Kubernetes Ingress致开。
請參考： https://kubernetes.io/docs/concepts/services-networking/ingress/
? Kuboard 并不限定您使用何種類型的 Ingress Controller， 但是 安裝 Kubernetes 用于測試 文檔中萎馅，推薦使用的 Ingress Controller 是 Nginx-Ingress双戳。
? 在您使用 Nginx-Ingress 的情況下，要想確保您能按照互聯(lián)網(wǎng)入口中定義的域名訪問您的服務糜芳，請確保以下兩點：
- 域名解析指向 Kubernetes 集群中 Worker 節(jié)點對應的負載均衡的 IP 地址
- 如果是測試環(huán)境飒货，也可以只指向其中一臺 Worker 節(jié)點的 IP 地址
- 通過該域名，可以訪問 Worker 節(jié)點的 80 端口
- 如果您啟用了 HTTPS峭竣，請同時確保通過該域名可以訪問 Worker 節(jié)點的 443 端口
? Kuboard 中膏斤，定義互聯(lián)網(wǎng)入口的界面如下所示：
