【K8S核心概念与专业术语】

2.1 服务类型

有状态应用（Stateful Application）
● 在有状态应用中，应用程序会保存和维护客户端的状态信息。
● 客户端请求之间的状态信息会被保留，通常存储在服务器端的数据库或内存中。
● 这种应用程序通常会跟踪用户的会话和状态，以便提供个性化的服务。
● 有状态应用需要在多个请求之间保持状态，因此在分布式环境中的扩展性和高可用性可能变得更加复杂。
● MySQL
● Redis
无状态应用（Stateless Application）
● 无状态应用不会保存客户端的状态信息，每个请求都是独立的，服务器不会记住先前的请求。
● 客户端每次请求都需要提供所有必要的信息，而服务器只关心当前请求的处理。
● 无状态应用更容易扩展，因为它们不需要在多个服务器实例之间同步状态信息。
● 这种设计适用于RESTful API等无状态协议，其中每个请求都包含足够的信息以完成操作。
● Nginx，Apache

2.2 资源和对象

在kubernetes中，所有的内容都抽象为资源，用户需要通过操作资源来管理kubernetes。
kubernetes的本质上就是一个集群系统，用户可以在集群中部署各种服务，所谓的部署服务，其实就是在kubernetes集群中运行一个个的容器，并将指定的程序跑在容器中。kubernetes的最小管理单元是pod而不是容器，所以只能将容器放在Pod中，而kubernetes一般也不会直接管理Pod，而是通过Pod控制器来管理Pod的。Pod可以提供服务之后，就要考虑如何访问Pod中服务，kubernetes提供了Service资源实现这个功能。当然，如果Pod中程序的数据需要持久化，kubernetes还提供了各种存储系统。

2.3 资源的分类

元数据：是对资源的元数据描述，每个资源都可以使用元数据的数据
集群：集群级别的资源，作用于集群之上，集群下的所有资源都可以共享使用
命名空间：作用在命名空间之上，通常只能在该命名空间范围内使用
为了让管理员明白这个资源能否夸集群使用、或者跨命名空间使用。

2.3.1 元数据型

❖ Horizontal Pod Autoscaler（HPA）
    ➢ Pod 自动扩容：可以根据 CPU 使用率或自定义指标（metrics）自动对 Pod 进行扩/缩容。
❖ PodTemplate
    ➢ Pod Template 是关于 Pod 的定义，但是被包含在其他的 Kubernetes 对象中（例如 Deployment、StatefulSet、DaemonSet 等控制器）。控制器通过 Pod Template 信息来创建 Pod。
❖ LimitRange
    ➢ 可以对集群内 Request 和 Limits 的配置做一个全局的统一的限制，相当于批量设置了某一个范围内（某个命名空间）的 Pod 的资源使用限制。
​

2.3.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 将使规则在所有命名空间中生效。

2.4 命名空间级别（重点）

2.4.1 工作负载型（Pod）

Pod（容器组）是 Kubernetes 中最小的可部署单元。一个 Pod（容器组）包含了一个应用程序容器（某些情况下是多个容器）、存储资源、一个唯一的网络 IP 地址、以及一些确定容器该如何运行的选项。Pod 容器组代表了 Kubernetes 中一个独立的应用程序运行实例，该实例可能由单个容器或者几个紧耦合在一起的容器组成。
Docker 是 Kubernetes Pod 中使用最广泛的容器引擎；Kubernetes Pod 同时也支持其他类型的容器引擎。

Kubernetes 集群中的 Pod 存在如下两种使用途径：
● 一个 Pod 中只运行一个容器。“one-container-per-pod” 是 Kubernetes 中最常见的使用方式。此时，您可以认为 Pod 容器组是该容器的 wrapper，Kubernetes 通过 Pod 管理容器，而不是直接管理容器。
● 一个 Pod 中运行多个需要互相协作的容器。您可以将多个紧密耦合、共享资源且始终在一起运行的容器编排在同一个 Pod 中，可能的情况有：

2.4.1.1 副本（replicas）

先引入“副本”的概念——一个 Pod 可以被复制成多份，每一份可被称之为一个“副本”，这些“副本”除了一些描述性的信息（Pod 的名字、uid 等）不一样以外，其它信息都是一样的，譬如 Pod 内部的容器、容器数量、容器里面运行的应用等的这些信息都是一样的，这些副本提供同样的功能。
Pod 的“控制器”通常包含一个名为 “replicas” 的属性。“replicas”属性则指定了特定 Pod 的副本的数量，当当前集群中该 Pod 的数量与该属性指定的值不一致时，k8s 会采取一些策略去使得当前状态满足配置的要求。

2.4.1.2 控制器

当 Pod 被创建出来，Pod 会被调度到集群中的节点上运行，Pod 会在该节点上一直保持运行状态，直到进程终止、Pod 对象被删除、Pod 因节点资源不足而被驱逐或者节点失效为止。Pod 并不会自愈，当节点失效，或者调度 Pod 的这一操作失败了，Pod 就该被删除。如此，单单用 Pod 来部署应用，是不稳定不安全的。
Kubernetes 使用更高级的资源对象 “控制器” 来实现对Pod的管理。控制器可以为您创建和管理多个 Pod，管理副本和上线，并在集群范围内提供自修复能力。 例如，如果一个节点失败，控制器可以在不同的节点上调度一样的替身来自动替换 Pod。
❖ 适用无状态服务
    ➢ ReplicationController（RC）（废弃了）
    ➢ ReplicaSet（RS）（现在在用）
        ■ Label 和 Selector
    ➢ Deployment（重点）
        ■ ![在这里插入图片描述](https://img-blog.csdnimg.cn/direct/16671817559a4319acf921e3eff3b6d1.png
        ■ 创建Replica Set/Pod
        ■ 滚动升级/回滚
        ■ 平滑扩容和缩容
        ■ 暂停与恢复Deployment（想要多次更新一起升级）
        ■ 先创建新的后停用老的。平滑升级
❖ 适用有状态服务
    ➢ StatefulSet
    ➢
        ■ StatefulSet 中每个 Pod 的 DNS 格式为 statefulSetName-{0…N-1}.serviceName.namespace.svc.cluster.local
❖ serviceName 为 Headless Service 的名字
❖ 0…N-1 为 Pod 所在的序号，从 0 开始到 N-1
❖ statefulSetName 为 StatefulSet 的名字
❖ namespace 为服务所在的 namespace，Headless Servic 和 StatefulSet 必须在相同的 namespace
❖ .cluster.local 为 Cluster Domain
    ➢ 主要特点
        ■ 稳定的持久化存储
        ■ 稳定的网络标志
        ■ 有序部署、有序扩展
        ■ 有序收缩、有序删除
    ➢ 组成
        ■ Headless Service
❖ 用于定义网络标志（DNS domain）
❖ Domain Name Server：域名服务将域名与 ip 绑定映射关系
❖ 服务名 => 访问路径（域名） => ip
        ■ volumeClaimTemplate
❖ 用于创建 PersistentVolumes的模板
    ➢ 注意事项
❖ 守护进程
    ➢ DaemonSet
    ➢
    ➢ DaemonSet 保证在每个 Node 上都运行一个容器副本，常用来部署一些集群的日志、监控或者其他系统管理应用。典型的应用包括：
        ■ 日志收集，比如 fluentd，logstash 等
        ■ 系统监控，比如 Prometheus Node Exporter，collectd，New Relic agent，Ganglia gmond 等
        ■ 系统程序，比如 kube-proxy, kube-dns, glusterd, ceph 等
❖ 任务/定时任务
    ➢ 一运行完就销毁
    ➢ Job
    ➢ CronJob（定时/循环任务）

2.4.2 服务发现

2.4.2.1 Service

“Service” 简写 “svc”。Pod 不能直接提供给外网访问，而是应该使用 service。Service 就是把 Pod 暴露出来提供服务，Service 才是真正的“服务”，它的中文名就叫“服务”。
可以说 Service 是一个应用服务的抽象，定义了 Pod 逻辑集合和访问这个 Pod 集合的策略。Service 代理 Pod 集合，对外表现为一个访问入口，访问该入口的请求将经过负载均衡，转发到后端 Pod 中的容器。

2.4.2.2 Ingress

Ingress 可以提供外网访问 Service 的能力。可以把某个请求地址映射、路由到特定的 service。
ingress 需要配合 ingress controller 一起使用才能发挥作用，ingress 只是相当于路由规则的集合而已，真正实现路由功能的，是 Ingress Controller，ingress controller 和其它 k8s 组件一样，也是在 Pod 中运行。

2.4.3 存储

2.4.3.1 Volume

数据卷，共享 Pod 中容器使用的数据。用来放持久化的数据，比如数据库数据。

2.4.3.2 CSI

Container Storage Interface 是由来自 Kubernetes、Mesos、Docker 等社区成员联合制定的一个行业标准接口规范，旨在将任意存储系统暴露给容器化应用程序。
CSI 规范定义了存储提供商实现 CSI 兼容的 Volume Plugin 的最小操作集和部署建议。CSI 规范的主要焦点是声明 Volume Plugin 必须实现的接口。

2.4.4 特殊配置

❖ ConfigMap
    ➢ 用来放配置，与 Secret 是类似的，只是 ConfigMap 放的是明文的数据，Secret 是密文存放。
❖ Secret
    ➢ Secret 解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者 Pod Spec 中。Secret 可以以 Volume 或者环境变量的方式使用。
    ➢ Secret 有三种类型：
        ■ Service Account：用来访问 Kubernetes API，由 Kubernetes 自动创建，并且会自动挂载到 Pod 的 /run/secrets/kubernetes.io/serviceaccount 目录中；
        ■ Opaque：base64 编码格式的 Secret，用来存储密码、密钥等；
        ■ kubernetes.io/dockerconfigjson：用来存储私有 docker registry 的认证信息。
❖ DownwardAPI
    ➢ downwardAPI 这个模式和其他模式不一样的地方在于它不是为了存放容器的数据也不是用来进行容器和宿主机的数据交换的，而是让 pod 里的容器能够直接获取到这个 pod 对象本身的一些信息。
    ➢ downwardAPI 提供了两种方式用于将 pod 的信息注入到容器内部：
        ■ 环境变量：用于单个变量，可以将 pod 信息和容器信息直接注入容器内部
        ■ volume 挂载：将 pod 信息生成为文件，直接挂载到容器内部中去

2.4.5 其他

❖ Role
    ➢ Role 是一组权限的集合，例如 Role 可以包含列出 Pod 权限及列出 Deployment 权限，Role 用于给某个 Namespace 中的资源进行鉴权。
❖ RoleBinding
    ➢ RoleBinding ：将 Subject 绑定到 Role，RoleBinding 使规则在命名空间内生效。