只挑选从 研发人员使用的角度 上看，常用到的基础概念。并且不会精确准确，有的还不是纯的 k8s 基础，会混杂着 kuboard 一起说。

namespace

命名空间，就是个分类，方便管理。

可以一个项目划一个命名空间。可以公共的服务划一个命名空间。

除了分类分着好看，还有其他一些用处。网络策略，可以按 命名空间 来隔离。集群资源的使用，可以按 命名空间 来限额。

yaml

我们可以在 kuboard 界面上，通过鼠标点几下，创建一个命名空间。

也可以在 kuboard 界面上，找到一个输入 yaml 文件内容的地方，通过黏贴保存这样一份 yaml 配置，来创建：

---
apiVersion: v1
kind: Namespace
metadata:
  name: ns-xxx

与 k8s 之间的交互，其实都是通过 yaml 文件，给它一份我们想要的资源清单。kuboard 上的一切操作，最后都等同于 kubectl apply -f xxx.yaml 命令。

通过 --- 分割，一个 yaml 文件里，可以定义多个资源。

pod

pod 是最小的资源调度单位。就当作是 一个 pod 里包含一个容器吧。调度一个 pod，就是在找一个物理节点启停一个容器。

一个 pod 里包含一个容器，这么理解是不准的，根据实际部署的需要，一个 pod 里其实可以有多个容器，但是他们是被当作一个整体来一起被调度的。

service

启动了一个 pod 后，就启动了容器，容器里跑着我们的程序。。程序需要被访问到，但 pod 是会被不断的调度启停的，它的 ip 地址会变。。pod 还可以多实例，有多个 ip。

service 就是给 pod 提供固定内部 ip 访问的。pod 多实例的情况下，它还为 pod 提供 服务发现、负载均衡。

配完一个 service，也就有了一个集群内的域名，service名称.namespace名称.svc.cluster.local。如果是在同一个命名空间下，只用 service名称 就可以当域名。

ingress

service 只能集群内访问。如果希望在集群外，通过 http 请求访问，就可以给 service 配一个 ingress。

kuboard 里 service 就叫 “服务”。ingress 叫 “应用路由”

service 只能集群内访问，这么理解也是不准的，这说的是 ClusterIP 类型的 service。NodePort 类型的 service 就直接能集群外访问。

应用路由 用起来似乎只是一个 http 协议的端点。如果要对外提供 tcp 协议呢，也可以用 NodePort 类型的 service。

工作负载

工作负载 是 kuboard 里的概念，他把 pod、service、ingress、configMap 等等 整合起来，把整合起来的一套配置，叫 工作负载。

狭义上，日常交流的时候，也可以把 pod 说成 工作负载。

工作负载 是 kuboard 一个挺优秀的设计，也是灵活度不足的一个缺陷。pod service ingress 凭啥会整合到同一个工作负载下一起展示，在 k8s 里他们都是零碎的资源，资源内部的具体配置才会配置到他们的相互关联。kuboard 并不识别每个资源内部的配置信息来整合展示关联资源。每个资源都有一个名字，他把 pod、service、ingress 取成一样的名字，靠名字相同来在界面上整合到一起展示，这是个挺好的规范。但有时候，我想给一个 pod 配两个 service，这时候我们心里要有概念，要去 service 列表去管理 service。

configMap

service 可以做多实例的服务发现。configMap（在 kuboard 里叫 配置字典）可以拿来做配置中心。微服务里两大组件，可以省略不要了。