1. 前言
在前面两篇文章我们简单介绍了什么是K8S，以及K8S的集群架构和组件，我们今天继续来学习核心概念篇的的最后一节核心概念和专业术语((下一章就可以开始实战部署操作啦))。
2. 服务的分类
2.1. 有状态服务
有状态服务指的是那些需要持久化数据并且对数据一致性有要求的服务。这些服务通常需要稳定的网络标识符（如持久化 IP）、持久化存储以及有顺序的部署和扩展。有状态服务常见的例子包括数据库、消息队列和分布式存储系统。有状态服务一般会涉及到持久化数据，也就是保持了数据(也就可以理解为保存了状态)。
代表应用有Mysql，Redis这种数据库
优点是可以独立存储数据，实现数据管理
缺点是集群环境下需要实现主从、数据同步、备份、水平扩容复杂
2.2. 无状态服务
无状态服务是指那些不需要保存用户数据或状态的服务，每个请求都是独立的，不需要考虑之前的请求状态。这类服务更容易水平扩展，因为它们不需要关心数据一致性问题。常见的无状态服务包括 web 服务器、API 服务器等。
代表应用有Apache，Nginx等
优点是对客户端透明，无依赖关系，可以高效实现扩容、迁移
缺点是不能存储数据，需要额外的数据服务支撑
3. 资源和对象
在 Kubernetes（K8s）中，资源是集群内部用于表示系统组件的对象。这些资源可以是 API 对象，也可以是系统内部用于管理集群状态的数据结构。资源定义了集群中的工作负载、服务、存储和网络配置等。
3.1. 资源的分类
K8S的资源我们可以分为三大类，元数据型，集群级，命名空间级
3.1.1元数据型
Horizontal Pod Autoscaler（HPA）
Pod 自动扩容：可以根据 CPU 使用率或自定义指标（metrics）自动对 Pod 进行扩/缩容。
- 控制管理器每隔30s（可以通过–horizontal-pod-autoscaler-sync-period修改）查询metrics的资源使用情况
- 支持三种metrics类型
- 预定义metrics（比如Pod的CPU）以利用率的方式计算
- 自定义的Pod metrics，以原始值（raw value）的方式计算
- 自定义的object metrics
- 支持两种metrics查询方式：Heapster和自定义的REST API
- 支持多metrics
PodTemplate
Pod Template 是关于 Pod 的定义，但是被包含在其他的 Kubernetes 对象中（例如 Deployment、StatefulSet、DaemonSet 等控制器）。控制器通过 Pod Template 信息来创建 Pod。
LimitRange
可以对集群内 Request 和 Limits 的配置做一个全局的统一的限制，相当于批量设置了某一个范围内（某个命名空间）的 Pod 的资源使用限制。
3.1.2.集群级
Namespace
Kubernetes 支持多个虚拟集群，它们底层依赖于同一个物理集群，这些虚拟集群被称为命名空间。
作用是用于实现多团队/环境的资源隔离。
命名空间 namespace 是 k8s 集群级别的资源，可以给不同的用户、租户、环境或项目创建对应的命名空间。
默认 namespace：
- kube-system 主要用于运行系统级资源，存放 k8s 自身的组件
- kube-public 此命名空间是自动创建的，并且可供所有用户（包括未经过身份验证的用户）读取。此命名空间主要用于集群使用，关联的一些资源在集群中是可见的并且可以公开读取。此命名空间的公共方面知识一个约定，但不是非要这么要求。
- default 未指定名称空间的资源就是 default，即你在创建pod 时如果没有指定 namespace，则会默认使用 default
Node
不像其他的资源（如 Pod 和 Namespace），Node 本质上不是Kubernetes 来创建的，Kubernetes 只是管理 Node 上的资源。虽然可以通过 Manifest 创建一个Node对象（如下 json 所示），但 Kubernetes 也只是去检查是否真的是有这么一个 Node，如果检查失败，也不会往上调度 Pod。
ClusterRole
ClusterRole 是一组权限的集合，但与 Role 不同的是，ClusterRole 可以在包括所有 Namespace 和集群级别的资源或非资源类型进行鉴权。
ClusterRoleBinding
ClusterRoleBinding：将 Subject 绑定到 ClusterRole，ClusterRoleBinding 将使规则在所有命名空间中生效。
3.1.3.命名空间级
命名空间级的资源有点多，我这里就讲个大概哈哈，后面实战再了解
工作负载型
Pod：Pod（容器组）是 Kubernetes 中最小的可部署单元。一个 Pod（容器组）包含了一个应用程序容器（某些情况下是多个容器）、存储资源、一个唯一的网络 IP 地址、以及一些确定容器该如何运行的选项。Pod 容器组代表了 Kubernetes 中一个独立的应用程序运行实例，该实例可能由单个容器或者几个紧耦合在一起的容器组成。
服务发现
- Service：“Service” 简写 “svc”。Pod 不能直接提供给外网访问，而是应该使用 service。Service 就是把 Pod 暴露出来提供服务，Service 才是真正的“服务”，它的中文名就叫“服务”。
- Ingress：Ingress 可以提供外网访问 Service 的能力。可以把某个请求地址映射、路由到特定的 service。
存储
- Volume：数据卷，共享 Pod 中容器使用的数据。用来放持久化的数据，比如数据库数据。
- CSI：CSI 规范定义了存储提供商实现 CSI 兼容的 Volume Plugin 的最小操作集和部署建议。CSI 规范的主要焦点是声明 Volume Plugin 必须实现的接口。
特殊类型配置
- ConfigMap：用来放配置，与 Secret 是类似的，只是 ConfigMap 放的是明文的数据，Secret 是密文存放。
- Secret：Secret 解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者 Pod Spec 中。Secret 可以以 Volume 或者环境变量的方式使用。
- DownwardAPI：downwardAPI 这个模式和其他模式不一样的地方在于它不是为了存放容器的数据也不是用来进行容器和宿主机的数据交换的，而是让 pod 里的容器能够直接获取到这个 pod 对象本身的一些信息。
其他
- Role：Role 是一组权限的集合，例如 Role 可以包含列出 Pod 权限及列出 Deployment 权限，Role 用于给某个 Namespace 中的资源进行鉴权。
- RoleBinding ：将 Subject 绑定到 Role，RoleBinding 使规则在命名空间内生效。
3.2. 资源清单
创建 k8s 的对象都是通过 yaml 文件的形式进行配置的，具体的资源清单如下：
| 参数名 | 类型 | 字段说明 |
| apiVersion | String | K8S APl 的版本，可以用 kubectl api versions 命令查询 |
| kind | String | yam 文件定义的资源类型和角色 |
| metadata | Object | 元数据对象，下面是它的属性 |
| metadata.name | String | 元数据对象的名字，比如 pod 的名字 |
| metadata.namespace | String | 元数据对象的命名空间 |
| Spec | Object | 详细定义对象 |
| spec.containers[] | list | 定义 Spec 对象的容器列表 |
| spec.containers[].name | String | 为列表中的某个容器定义名称 |
| spec.containers[].image | String | 为列表中的某个容器定义需要的镜像名称 |
4. 对象规约和状态
“spec” 是 “规约”、“规格” 的意思，spec 是必需的，它描述了对象的期望状态（Desired State）—— 希望对象所具有的特征。当创建 Kubernetes 对象时，必须提供对象的规约，用来描述该对象的期望状态，以及关于对象的一些基本信息（例如名称）。
表示对象的实际状态，该属性由 k8s 自己维护，k8s 会通过一系列的控制器对对应对象进行管理，让对象尽可能的让实际状态与期望状态重合。
5. 总结
本文是K8S核心概念篇的的最后一节(应该是的吧，主要纯理论太枯燥了，下次开始实操)，主要介绍了服务的分类、资源和对象以及对象规约和状态。服务的分类主要包括有状态服务和无状态服务，有状态服务需要持久化数据并且对数据一致性有要求，例如数据库、消息队列等；无状态服务不需要保存用户数据或状态，例如web服务器、API服务器等。资源和对象介绍了K8S中资源的定义和分类，资源是集群内部用于表示系统组件的对象，可以分为元数据型、集群级和命名空间级。对象规约和状态中，"spec"表示对象的期望状态，而"status"表示对象的实际状态，由K8S自己维护。
