Kubernetes 学习门槛在哪儿
学习 Kubernetes 之前，必须具备的知识储备：
- Linux 基础
- 网络基础
- 容器技术，例如 https://www.docker.com/
学习 Kubernetes 的过程中可能碰到的难关：
- 理解 Kubenetes 为了实现容器编排而提出的各种抽象概念以及他们之间的关系：容器组（Pod）、存储卷（Volume）、存储卷声明（PVC）、Ingress、Service 等
- 安装及配置 Kubernetes 环境
- 编写和维护 Kubernetes Yaml 文件
- 熟悉 kubectl 命令行工具中常用的 10 多个命令
降低 Kubernetes 学习门槛
学习路线
单纯地按章节学习 Linux 基础知识、网络知识、容器技术等，每一块儿的基础入门书籍就有几百页之多。作者认为，最好的学习方法是在实践中学习，碰到问题时去寻求答案，解决问题后去反思总结。这种学习方法趣味性强，得来的知识也最为牢靠，如果选对了方向，所学知识通常也是工作中实用性最高的知识。读了100页 K8S 文档，也不如安装一遍 K8S
Kuboard 为初学者学习 Kubernetes 时设计了如下学习路径：
- 跟随文档 安装 Kubernetes 单Master节点 快速安装一个可以练习使用的 Kubernetes 环境，（初学者也许要花费2小时或更多）
- 跟随文档 安装 Kuboard （5分钟）
- 使用 Kuboard 工作负载编辑器 创建 busybox （10分钟）
- 尝试 Kuboard 设计的其他 example 使用 Kuboard
进阶路线：
- 在 Kubernetes 中部署 Spring Cloud 微服务应用
快速入门
在向 Kubernetes 集群部署应用时，开发者或者运维团队必须花大量的时间去理解 Kubernetes 中各种对象的概念，并编写 Yaml 文件去描述 Kubernetes 对象以及他们之间的关系，然而，不同的人因为经验、视角的不同，对Kubernetes 中各对象之间关系的理解并不完全一致，也因此产生了一系列问题：
- 由于理解的不到位，刚入门Kubernetes的技术人员在使用 Kubernetes 部署应用时经常性地受挫；
- 由于理解方式的不一致，不同技术人员编写的 yaml 文件结构各不一样，降低了部署在后期的可维护性；
- 由于部署数量的增加，导致 YAML 文件的数量和代码行数不断增长；
Kubernetes 官方提供的 Kubernetes Dashboard 充分意识到了 Kubernete 对象类型在种类上的多样性以及关系上的复杂性，到目前为止并没有在全功能 Dashboard 上做出过多努力，尤其是没有付出过多努力去打造工作负载的 UI 编辑器。在 Kubernetes Dashboard 中，如果想要对 Service、Deployment、StatefulSet、ConfigMap 等各种 Kubernetes 对象执行新增或者变更操作时，您必须编写 YAML 文件。从这个意义上来讲，截止到作者写这篇文章的时间点，Kubernetes 的官方 Dashboard 仍然是一个 “只读” 型 Dashboard，几乎所有的运维操作仍然需要技术人员去编写和维护冗长的 YAML 文件，并通过 kubectl 命令来完成。
由于 Kubernetes YAML 文件复杂性，以及开发/运维团队在多环境复制（开发环境、测试环境、准上线环境、生产环境等）方面的普遍需求，Kubernetes 社区提出了各种各样的解决方案，例如 kustomize / helm chart 等，这些解决方案在解决一个问题的同时，又在另一方面增加了复杂度，为 Kubernetes 爱好者增加了新的学习门槛。
入门利器
为了降低 Kubernetes 的学习难度和使用难度，Kuboard 对 Kubernetes 中管理的各种对象做了一个梳理，并以此为基础，设计了 Kuboard 工作负载编辑器。
Kuboard 工作负载编辑器以下图的方式理解和管理 Kubernetes 对象。
上图中各概念与 Kuboard 工作负载编辑器界面的映射关系如下：
1. 基本信息
基本信息对应到 Kubernetes 的 Workload Controller，当前 Kuboard 工作负载编辑器已经支持了使用频率最高的几类 Workload Controller ：
- Deployment
- StatefulSet
- DaemonSet
Kuboard 将陆续支持其他低频使用的 Controller: Garbage Collection, TTL Controller, Jobs, Cron Job。
Kubernetes Workload Controller 主要用于：
- 根据容器组模板的定义，创建和管理多个容器组
- 处理容器组的复制和上线
- 在集群范围内提供自修复能力
例如：Workload Controller 起初在节点 A 上创建并运行了一个容器组 pod_a，当节点 A 出现故障不能正常工作时，Workload Controller 可以自动地在其他可用的节点上运行一个完全相同的容器组实例 pod_a' 以替代 pod_a。
不同类型的 Workload Controller 在处理容器组时，会有各自不同的行为。
请参考 https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/#pods-and-controllers
基本信息编辑器的界面如下图所示：
| 字段名称 | 字段描述 |
|---|---|
| 服务类型 | 即工作负载类型， |
| 当前支持： Deployment、StatefulSet、DaemonSet | |
| 服务分层 | 决定了 Kuboard 将该工作负载展示在哪一个分层，同时，也确定了该工作负载名称的前缀，可选项有： |
- 展现层 web、网关层 gateway、服务层 svc、持久层 db、中间件层 cloud、监控层 monitor；
- 默认层当前不可选择 |
| 标签 | 用于确定 Service 的 labelSelector、Controller 的 labels、容器组的 labels |
| 服务描述 | 展示在 Kuboard 界面上的一段描述信息 |
| 副本数量 | 对于 Deployment 和 StatefulSet 可以填写，决定了该控制器应该维持的容器组副本的数量 |
2. 数据卷
容器每次启动时，从镜像中初始化所有文件，后续对文件系统的修改、新增、删除操作的结果都是不能持久化的。当容器崩溃时， kubelet 重启该容器，但是原容器已经做的修改将丢失，因为每次启动容器，都是从镜像中初始化；此外，多个容器运行在同一个容器组中时，通常伴随着在不同容器之间共享文件的需求。
Kubernetes的抽象出了数据卷 Volume 的概念，以解决上述的问题。
Kuboard 目前支持如下类型的数据卷：
- NFS
- 存储卷声明
- emptyDir
- 配置 ConfigMap
- Secrets
Kubernetes 支持的数据卷类型，请参考：https://kubernetes.io/docs/concepts/storage/volumes/#types-of-volumes
Kuboard 认为当前支持的数据卷类型已经满足绝大多数应用场景，目前正在添加对更多类型数据卷的支持。
容器组中的不同容器都可以通过挂载点引用该容器组加载的数据卷。Kuboard 工作负载编辑中，使用如下界面定义数据卷：
| 字段名称 | 说明 |
|---|---|
| 数据卷名称 | 如图中的 example-data 、 empty-dir |
| 数据卷类型 | |
| 数据卷详细信息 | 不同类型的数据卷需要填写的信息不尽相同，例如 |
存储卷声明，需要选择事先已经在名称空间中创建好的存储卷声明
NFS，需要填写 NFS Server 的地址，以及 NFS Path |
3. 身份信息
身份信息区域主要为容器组定义两类信息：
- imagePullSecrets，容器组调用镜像仓库接口抓取镜像时所使用的用户名密码。如果您使用了私有镜像仓库，您需要在此指定镜像仓库的用户名密码；如果您使用 docker 公共仓库，则无需填写 imagePullSecrets
- ServiceAccount，容器组调用 kubernetes apiserver 时，所使用的身份信息
Kuboard 工作负载编辑器中关于身份信息的编辑界面如下所示：
4. 容器
容器是我们真正应用程序镜像被加载和运行的地方，按照 Kubernetes 的设计，一个容器组 Pod 中可以包含多个容器 Container，这些容器被分为两类：
- 初始化容器
- 初始化容器总是执行后结束执行
- 初始化容器按其定义的顺序执行，前一个初始化容器执行结束后，才开始后一个初始化容器的执行
- 只有初始化容器执行成功后，容器组才启动工作容器
- 请参考 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（集群内访问） 以及 NodePort（VPC 内访问） 两种 Service 访问方式，您也可以不为该工作负载定义 Service 访问方式。访问方式的界面如下所示：
6. 互联网入口
互联网入口，即 Kubernetes Ingress。
请参考： https://kubernetes.io/docs/concepts/services-networking/ingress/
Kuboard 并不限定您使用何种类型的 Ingress Controller， 但是 安装 Kubernetes 用于测试 文档中，推荐使用的 Ingress Controller 是 Nginx-Ingress。
在您使用 Nginx-Ingress 的情况下，要想确保您能按照互联网入口中定义的域名访问您的服务，请确保以下两点：
- 域名解析指向 Kubernetes 集群中 Worker 节点对应的负载均衡的 IP 地址
- 如果是测试环境，也可以只指向其中一台 Worker 节点的 IP 地址
- 通过该域名，可以访问 Worker 节点的 80 端口
- 如果您启用了 HTTPS，请同时确保通过该域名可以访问 Worker 节点的 443 端口
Kuboard 中，定义互联网入口的界面如下所示：
