第三讲：k8s核心概念和专业术语

序言：这里只对概念继续基础阐述，不做具体案例，这位博主写的特别详细，想要对k8s深入的了解可以跳转了，作为小白的我看的有点懵，毕竟没实践过 链接地址→  http://t.csdn.cn/ZYtEF

 这篇文章写了将近两万字对各个常见的概念进行详细的解释，尽可能做到全面，读起来也会枯燥无味，我只想说k8s是个大坑，好难，根本记不住。。。。下面有几张思维导图可以帮助理解

 

 

 

一、服务的分类

        1.1 无状态服务               

                无状态服务是指在运行时不维护任何持久状态的服务。这意味着每个请求都可以由任何副本处理，而无需考虑请求的上下文或之前的请求状态。无状态服务的好处在于它们可以水平扩展，因为它们不需要维护任何状态或会话信息。这可以通过自动添加或删除Pod实例来实现。无状态服务还可以更容易地管理，因为它们不涉及任何持久化状态或数据存储。通常，Web服务器，负载均衡器，API端点和处理存储在队列中的消息的服务都可以构建为无状态服务。例如：nginx和Apache

优点：
        1. 横向扩展性强：由于无状态服务没有任何状态，因此可以很容易地横向扩展，通过增加更多的实例来分摊负载。
        2. 弹性能力强：无状态服务可以轻松重启和重新部署，因为他们没有任何状态需要保存，这使得它们更加可靠和有弹性。
        3. 更容易管理：无状态服务可以更容易地管理，因为它们将状态转移到持久化数据存储中，这使得维护和管理更加容易。
        4. 更好的容错能力：由于无状态服务可以轻松重启和重建，因此在出现故障时，很容易将服务恢复到正常状态，从而提高系统的容错能力。

缺点：
        1. 实现复杂：由于需要使用持久化数据存储来保存状态，无状态服务的实现可能比有状态服务更加复杂。
        2. 更多的存储成本：由于需要使用持久化数据存储，因此无状态服务可能需要更多的存储成本。
        3. 更多的网络IO：由于无状态服务需要频繁地读取和写入数据，因此可能会产生更多的网络IO开销。

        1.2 有状态服务

                有状态服务是指在运行过程中会有持久化数据的服务，例如数据库服务、消息队列服务等。在Kubernetes中，有状态服务采用StatefulSet控制器进行管理，通过为每个Pod分配唯一的固定标识符和持久化存储卷来确保数据一致性和可靠性。有状态服务的管理相较于无状态服务更加复杂，需要额外考虑数据备份、恢复、扩缩容等问题。例如：MySQL和Redis

Kubernetes的有状态服务相对于无状态服务来说，有以下优缺点：

优点：
        1. 数据持久化：有状态服务需要保存数据，数据不能丢失，需要使用持久化存储卷进行存储，这样能够保证数据的持久化，不会因为Pod的重启而丢失。

        2. 稳定性高：有状态服务通常需要保证高可用性，防止单点故障，Kubernetes在管理有状态服务的时候会采用StatefulSet来进行管理，在Pod的创建、删除、滚动更新等操作时，会保证有序进行，避免业务数据的丢失或损坏，从而保证了服务的稳定性。

        3. 线性扩展：由于对于有状态服务来说，数据的一致性和稳定性是非常关键的，因此需要采用分布式的架构来实现，在Kubernetes中，可以通过StatefulSet的scaling策略，实现分布式的扩展，以满足服务的需求。

缺点：
        1. 配置复杂：由于有状态服务涉及到数据的持久化存储，因此需要采用一些额外的配置，例如存储卷的选择、挂载路径、数据备份与恢复等，这些配置会导致服务配置的复杂度增加。

        2. 处理不当可能会导致数据丢失或损坏：对于有状态服务来说，处理不当可能会导致数据的丢失或损坏，如Pod的被意外删除、网络异常等情况，需要采用一些方式来避免这种情况的发生，如备份与恢复、复制等。

        3. 部署周期长：由于有状态服务涉及到数据的持久化存储，因此在部署的过程中，需要先部署存储相关的资源，如Volume、PV、PVC，然后再部署有状态服务，这个过程相对于无状态服务来说会更加复杂，需要耗费更长的时间。

二、资源和对象

        Kubernetes 中的所有内容都被抽象为“资源”，如 Pod、Service、Node 等都是资源。“对象”就是“资源”的实例，是持久化的实体。如某个具体的 Pod、某个具体的 Node。Kubernetes 使用这些实体去表示整个集群的状态。
         对象的创建、删除、修改都是通过 “Kubernetes API”，也就是 “Api Server” 组件提供的 API 接口，这些是 RESTful 风格的 Api，与 k8s 的“万物皆对象”理念相符。命令行工具 “kubectl”，实际上也是调用 kubernetes api。
         K8s 中的资源类别有很多种，kubectl 可以通过配置文件来创建这些 “对象”，配置文件更像是描述对象“属性”的文件，配置文件格式可以是 “JSON” 或 “YAML”，常用 “YAML”。

        在Kubernetes中，资源和对象是非常重要的概念，资源是Kubernetes管理的计算或存储资源，如Pod、Service、Deployment、ConfigMap等，而对象则是在Kubernetes中表示资源的实体。一个对象包括两个部分：

        1. 对象的描述：描述了资源的属性和规范，使用yaml文件对其进行定义。
        2. 对象的状态：描述了资源的实际状态，如Pod的运行状态、Service的IP地址等。

在Kubernetes中，对象通常以yaml文件的形式进行定义和管理，对象的定义通常包括以下内容：

        1. “apiVersion”：定义对象所属的API版本，如“v1”。
        2. “kind”：定义对象的类型，如Deployment、Pod、Service等。
        3. “metadata”：定义对象的元数据，如名称、命名空间、标签等。
        4. “spec”：定义对象的规范，如容器镜像、容器数量等。
        5. “status”：定义对象的状态，如Pod的运行状态、Service的IP地址等。

        通过这些属性，Kubernetes可以对资源进行管理和调度，以保证资源的高可用性和资源的有效利用。在Kubernetes中，所有的资源和对象都是管理的基本单位，用户可以通过kubectl等命令对其进行管理和操作。

        2.1 资源的分类

                2.1.1 元数据

                       2.1.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

                                当使用HPA时，可以指定一个最小和最大的Pod副本数，这些副本数将在当前负载下保持不变，直到负载开始波动。一旦负载开始增加，HPA将向Kubernetes API服务器发送缩放请求以在集群中创建更多的Pod实例。在负载下降时，HPA将向Kubernetes API服务器发送另一个请求，以删除一些Pod实例并将副本数恢复到最小值。

                                总之，Kubernetes HPA可以自动监视和控制Pod副本数量，以确保在各种负载条件下实现最佳的性能和资源利用率。

                       2.1.1.2 PodTemplate                  

                                Kubernetes中的PodTemplate是一种资源对象，它定义了一个Pod的规范模板，可以用来创建或更新一个Pod。PodTemplate允许用户将相同的Pod规范应用于多个Pod，从而简化了管理和更新Pod的过程。

                                PodTemplate包含以下几个重要的字段：

                                    - metadata：指定PodTemplate的元数据，包括名称、标签和注释等。
                                   - spec：指定PodTemplate的规范，包括容器和卷的规范、Pod的生命周期和容器的调度策略等。
                                    - annotations：指定PodTemplate的注解，可以为PodTemplate提供更多的信息，如数据来源、部署时间等。

                                使用PodTemplate可以方便地创建和管理多个Pod，尤其在需要多副本的场景下，可以使用PodTemplate来一次性创建多个Pod，并且可以在PodTemplate上进行更新操作，可以在不影响正在运行的Pod的情况下快速更新Pod的规范。

                                PodTemplate还可以与Deployment、ReplicaSet、StatefulSet等Kubernetes资源对象一起使用。这些对象可以通过PodTemplate来创建或更新Pod，并且可以自动控制Pod副本数量、故障恢复等方面的功能。使用PodTemplate还可以实现灰度发布、滚动更新等高级的部署策略，从而进一步提高应用的可用性和可靠性。

                       2.1.1.3 LimitRange

                        Kubernetes中的LimitRange是一种用于限制Pod资源使用的机制。LimitRange可以帮助管理员或开发者在资源使用方面实现更细粒度的控制，避免过度使用集群中的资源，从而提高应用程序的可用性和性能。

                        LimitRange可以限制Pod中各种资源的使用，比如：

                          - CPU和内存：可以限制Pod中容器的CPU和内存使用量。
                          - 存储：可以限制Pod中各个容器的存储卷使用量。
                          - 网络带宽：可以限制Pod的网络带宽使用量。
                          - 端口：可以限制Pod中容器的端口数和端口范围。

                        在创建LimitRange时，需要指定以下几个重要的参数：

                                  - limits：指定要限制的资源和使用限制，例如CPU和内存使用量、存储卷使用量、网络带宽等。
                                  - maxLimitRequestRatio：指定最大请求比例。如果一个Pod的请求超过了限制范围，那么Kubernetes会自动终止这个Pod并返回错误。

                                使用LimitRange可以避免由于资源使用过度而导致的应用程序崩溃和整个集群的不可用。管理员或开发者可以通过LimitRange在不影响正常运行的前提下，对资源占用进行细粒度控制，从而提高集群的使用效率和稳定性。

                2.1.2 集群级

                        2.1.2.1 NameSpace

                                Kubernetes中的namespace（命名空间）是用于对集群资源进行逻辑隔离的一种机制。在同一个Kubernetes集群中，可以创建多个namespace，每个namespace中包含了一组独立的资源对象，比如Pod、Service、Volume等。

                                使用namespace可以将集群中的应用程序进行逻辑分组，从而避免应用程序之间的冲突和干扰。同一namespace中的资源对象可以互相访问，而不同namespace中的资源对象则需要使用全局唯一的名称进行访问。

                                在创建namespace时，需要注意以下几点：

                                   - namespace的名称必须唯一，并且只能包含小写字母、数字和"-"符号，长度在63个字符以内。
                                   - Kubernetes默认创建了三个namespace：default、kube-system和kube-public。
                                   - default namespace是默认的namespace，如果没有在kubectl命令中指定namespace，则使用default。
                                   - kube-system namespace中包含了一些Kubernetes系统组件，如kube-dns、kube-controller-manager、kube-scheduler等。
                                   - kube-public namespace中包含了一些公共资源，如configmap、secret等。

                                使用namespace可以让多个应用程序在同一个Kubernetes集群中共享底层基础设施，同时又能够实现逻辑上的隔离和保护。管理员或开发者可以通过namespace来组织自己的应用程序，从而使应用程序更加容易管理和维护。

                        2.1.2.2 Node

                                在 Kubernetes 中，Node 是 Kubernetes 集群中的一个工作节点，通常是一台物理机器或虚拟机器。Node 是 Kubernetes 中的一个资源类型，可以被 Kubernetes 用来调度和管理容器化应用程序。

                                Node 资源包含了集群中每个工作节点的状态和属性信息，如节点的名称、地址、运行状态等。在一个 Kubernetes 集群中，Node 资源维护了所有节点的状态信息，包括节点的可用性、节点的健康状态、节点的资源使用情况等等。

                                Node 资源还可以关联其他的资源类型，如 Pod 资源和 ConfigMap 资源。例如，每个 Node 资源可以包含一组 Pod 资源，表示在该节点上运行的容器化应用程序。Node 资源也可以关联 ConfigMap 资源，以便将配置信息传递给节点上的应用程序。

                                Kubernetes 集群中的 Node 资源在很多场景下都比较重要，例如：

                                        1. 在部署容器化应用程序时，Kubernetes 会将 Pod 调度到可用的 Node 上。因此，Node 资源的可用性和配置信息对于应用程序的部署和管理至关重要。

                                        2. 在扩容或缩容应用程序时，Kubernetes 会动态地将 Pod 调度到可用的 Node 上，以确保应用程序具备足够的计算和存储资源。Node 资源的状态信息对于这些操作非常关键。

                                        3. 在监控和故障排除时，管理员需要查看 Node 资源的状态信息，以判断节点是否出现故障或资源使用情况是否正常。

                        2.1.2.3 ClusterRole  

                                Kubernetes 中的 ClusterRole 是一种授权机制，它是定义对 Kubernetes 集群中资源的访问权限的一种方式。ClusterRole 可以被赋予用户、服务账户和组，以控制他们在集群中对资源的访问和操作。

                                与 Role 不同，ClusterRole 是 Kubernetes 集群范围内的授权机制。它允许对集群范围内的资源进行授权，而不是仅限于某个命名空间中的资源。ClusterRole 在整个 Kubernetes 集群中都是可用的，用户可以定义 ClusterRole，并将其赋予用户或者服务账户，以实现对集群资源的精细控制。

                                一个 ClusterRole 可以授权多个 API 资源的操作，例如可以授权对 Deployment、Pod、ConfigMap、Ingress 等资源的访问权限。在定义 ClusterRole 时，可以通过使用标准 Kubernetes 的 API 特定的动词（GET、LIST、WATCH、CREATE、UPDATE、DELETE、PATCH、PROXY 等）来精细控制对资源的访问、操作和管理。

                                Kubernetes 中的 ClusterRole 可以分为两种类型：系统内置 ClusterRole 和自定义 ClusterRole。系统内置 ClusterRole 是 Kubernetes 预先定义的 ClusterRole，可以被快速使用，常见的有 cluster-admin、edit、view 等。自定义 ClusterRole 则是用户自定义的 ClusterRole，可以根据实际需求定义资源的访问和操作权限。

                                总之，ClusterRole 通过定义 Kubernetes 集群内的资源访问权限来保障集群的安全性和稳定性，可以授权用户或服务账户对特定的资源进行操作和管理。

                        2.1.2.4 ClusterRoleBinding

                                Kubernetes 中的 ClusterRoleBinding 是一种授权机制，它用于将 ClusterRole 绑定到用户、服务账户或组上，以授予他们在 Kubernetes 集群中的资源访问权限。

                                ClusterRoleBinding 定义了哪些用户或服务账户具有哪些 ClusterRole 的权限。通过创建 ClusterRoleBinding，可以让用户或服务账户具有对 Kubernetes 集群中资源的操作权限。与 RoleBinding 不同，ClusterRoleBinding 是 Kubernetes 集群范围内的授权机制，可以授权集群内的所有命名空间。

                                ClusterRoleBinding 可以指定多个用户、服务账户或组，以及多个 ClusterRole。对于每个 ClusterRole，可以指定不同的 API 资源和操作权限。因此，ClusterRoleBinding 具有很高的灵活性和可扩展性，可以通过它来实现 Kubernetes 集群中资源的细粒度访问控制。

                                例如，可以创建一个 ClusterRoleBinding，将 cluster-admin ClusterRole 绑定到某个用户或者服务账户上，从而允许该用户或服务账户对整个 Kubernetes 集群拥有完全的操作权限。或者可以创建一个自定义的 ClusterRole，然后将其绑定到一个组上，以授权该组对某些资源的访问权限。

                                需要注意的是，ClusterRoleBinding 只能绑定已经存在的 ClusterRole，而不能创建新的 ClusterRole。同时，ClusterRoleBinding 的优先级高于 RoleBinding，如果在同一个命名空间中同时存在 RoleBinding 和 ClusterRoleBinding，则 ClusterRoleBinding 的权限会覆盖 RoleBinding。

总之，通过 ClusterRoleBinding 可以将 ClusterRole 绑定到用户、服务账户或组上，从而授予其在 Kubernetes 集群中的资源访问权限，实现对集群资源的管理和控制。

                2.1.3 命名空间级

                        2.1.3.1 工作负载型

                           pod

                                Kubernetes 中的 Pod（Pod）是最小的可部署对象，是容器化应用程序的基本构建块。Pod 包含一个或多个容器，它们共享相同的网络命名空间和存储卷，并被部署到同一台物理或虚拟机器上，因此可以方便地进行通信和数据共享。

                                Pod 是 Kubernetes 中最小的可调度和可拓展单元，也是最基本的资源分配单位。Pod 中的容器可以通过本地进程间通信（IPC）、网络和文件系统共享（hostPath），从而实现了更紧密的协作。

                                Pod 具有以下几个重要特点：

                                   - Pod 是一个部署的最小单位。一个 Pod 中可以包含一个或多个容器，这些 容器共享网络、存储等资源，可以互相访问。
                                   - Pod 具有唯一的 IP 地址和 DNS 名称。 这使得容器间通信非常方便，也使得容器可以作为服务部署。
                                   - Pod 可以使用各种控制器来进行管理，例如 Deployment、StatefulSet 和 DaemonSet等。

                                在 Pod 中，容器是运行的主体。Pod 可以包含一个或多个容器，这些容器共享同一资源，可以访问共享的存储卷和网络。它们可以作为一个整体进行部署，也可以在多个计算节点上进行部署，以实现负载均衡和故障恢复。当一个 Pod 中的容器需要协同工作时，它们使用本地网络和文件系统共享来进行通信。

                                Pod 对于 Kubernetes 平台来说非常重要，它提供了一种多容器、异构网络、共享存储卷的轻量级抽象，便于开发人员在 Kubernetes 上构建、部署应用程序。

                                2.1.3.1.1 副本

                                   在 Kubernetes 中，副本（Replica）是指用于副本控制器（Replica Controller）或副本集（ReplicaSet）来管理的一组 Pod。副本的存在可以实现应用程序的高可用和负载均衡。

                                   副本控制器是 Kubernetes 中的一种控制器，用于确保在任何给定时间可用的 Pod 数量。它定期检查集群中的 Pod 数量是否与用户定义的副本数量相匹配，如果不匹配，则启动或停止 Pod，以确保达到指定的副本数量。当 Pod 失败或从集群中删除时，控制器会自动创建另一个 Pod 来替代它。这样可以确保应用程序始终处于可用状态。

                                    副本集是 Kubernetes 中的一种资源，可以用来替代旧版的副本控制器。副本集可以实现 Pod 的自动扩展和缩减，以适应应用程序的实时负载变化。它还支持滚动升级，可以实现无中断应用程序升级和回滚。

                                   副本是一种抽象概念，它可以代表一个或多个 Pod。副本的用途是确保在 Kubernetes 集群中有足够的 Pod 来满足应用程序的需求，并确保应用程序在出现故障时仍然可用。

                                2.1.3.1.2 控制器

                                        2.1.3.1.2.1 适用无状态的服务

                                                ① ReplicationController（RC）

                                                ReplicationController 是 Kubernetes 中的一个控制器，用于确保在任何给定时间可用的 Pod 数量。它可以自动地创建、管理和监控一组相同的 Pod，并确保它们始终处于运行状态。当 Pod 失败或从集群中删除时，ReplicationController 会自动创建另一个 Pod 来替代它。

                                                ReplicationController 用于确保在集群中运行的 Pod 数量始终等于用户定义的副本数。当需要扩展或缩小 Pod 数量时，ReplicationController 会自动创建或删除 Pod。它还支持滚动升级，可以实现无中断应用程序升级和回滚。

                                                ReplicationController 的主要作用是：

                                                - 确保在指定的时间内运行指定数量的 Pod；
                                                - 监视 Pod 的状态，当 Pod 失败或从集群中删除时，自动启动新的 Pod 以替代它；
                                                - 可以扩展或缩小 Pod 数量，以适应应用程序的实时负载变化；
                                                - 支持滚动升级，可实现无中断应用程序升级和回滚。

                                                在 Kubernetes 中，很多资源都依赖于 ReplicationController，例如 Deployment、ReplicaSet 等。ReplicationController 已经成为 Kubernetes 中非常重要的一个组件，它可以确保应用程序始终处于运行状态，从而提高了应用程序的可靠性和可用性。

                                                ② ReplicaSet（RS）

                                                ReplicaSet 是 Kubernetes 中的一个控制器，它可以确保在任何给定时间可用的 Pod 数量，并且支持根据指定的副本数量和选择器部署和管理 Pod。在 Kubernetes 中，ReplicaSet 是用于管理 Pod 副本的推荐方式，它可以确保指定数量的 Pod 副本在集群中运行。

                                                ReplicaSet 与 ReplicationController 的最大不同在于，ReplicaSet 支持根据 Pod 的标签选择器进行 Pod 管理，而 ReplicationController 只能使用等式选择器。选择器是在 Pod 配置中定义的一组键值对，用于标识和分类 Pod，可以根据选择器匹配到的标签来对 Pod 进行管理。因此，相对于 ReplicationController，ReplicaSet 更加灵活，可以根据选择器定制化进行管理。

                                                ReplicaSet 的主要作用是：

                                                - 确保在指定的时间内运行指定数量的 Pod；
                                                - 监视 Pod 的状态，当 Pod 失败或从集群中删除时，自动启动新的 Pod 以替代它；
                                                - 可以扩展或缩小 Pod 数量，以适应应用程序的实时负载变化；
                                                - 支持根据 Pod 的标签选择器进行 Pod 管理。

                                                与 ReplicationController 相比，ReplicaSet 有更好的可扩展性和灵活性，可以更加准确地管理 Pod 的复制数量和标签选择器。在实践中，ReplicaSet 也往往用于支持 Deployment、StatefulSet 等高级应用控制器的实现。

                                                label （标签）是附加到 Kubernetes 对象（比如 Pods）上的键值对，用于区分对象（比如Pod、Service）。 label 旨在用于指定对用户有意义且相关的对象的标识属性，但不直接对核心系统有语义含义。 label 可以用于组织和选择对象的子集。label 可以在创建时附加到对象，随后可以随时添加和修改。可以像 namespace 一样，使用 label 来获取某类对象，但 label 可以与 selector 一起配合使用，用表达式对条件加以限制，实现更精确、更灵活的资源查找。

label 与 selector 配合，可以实现对象的“关联”，“Pod 控制器” 与 Pod 是相关联的 —— “Pod 控制器”依赖于 Pod，可以给 Pod 设置 label，然后给“控制器”设置对应的 selector，这就实现了对象的关联。

                                                ③  Deployment              

                                                Deployment 是 Kubernetes 中用于管理 Pod 的高级控制器之一，它可以确保应用程序的多个副本在集群中平稳地升级和回滚。Deployment 可以自动为创建的 Pod 副本配置卷、网络和其他资源，从而简化了应用程序的部署、更新和管理。

                                                Deployment 在 Kubernetes 中的主要作用：

                                                - 控制应用程序的副本数量：可以根据需要增加或减少副本数量，适应应用程序的实时负载变化；
                                                - 自动完成应用程序的升级和回滚：可以轻松地更新应用程序的部署，或者回滚到以前的版本，以满足特定的需求；
                                                - 保证应用程序的可用性：在 Pod 发生故障或节点崩溃时，Deployment 会自动重新启动 Pod，确保应用程序的正常运行；
                                                - 管理应用程序的配置：Deployment 可以将应用程序的配置信息与 Pod 副本关联起来，从而简化应用程序的部署和管理。

                                                在 Deployment 的实现中，每个 Pod 都由一个唯一的标识符表示，称为 Pod 模板。Pod 模板包含了 Pod 副本所需要的所有信息，例如镜像、容器端口、卷和环境变量等。当需要添加或删除 Pod 副本时，Deployment 会根据 Pod 模板自动创建或删除 Pod，保证指定数量的 Pod 副本在集群中运行。

                                                Deployment 还支持滚动升级功能，可以在进行应用程序更新时，一次性升级指定数量的 Pod 副本，以减少应用程序升级期间的服务中断时间。同时，Deployment 还支持回滚功能，可以在应用程序升级失败或出现问题时，快速回滚到以前的版本，保证应用程序的可用性。

                                        2.1.3.1.2.2 适用有状态的服务

                                               StatefulSet 

StatefulSet 是 Kubernetes 中一种用于管理有状态应用的控制器，与 Deployment 类似，但是相比于 Deployment，它更适合于有状态应用的部署和管理。

有状态的应用通常需要满足以下几个条件：

• 每个 Pod 都有唯一的标识符，如 DNS 名称或网络标识符；
• Pod 启动顺序和停止顺序非常重要；
• Pod 之间有顺序的依赖关系，如数据库的主从节点；
• 应用程序需要有持久化存储；

StatefulSet 就是为了解决这些有状态应用的问题而设计的。StatefulSet 可以确保每个 Pod 有唯一的名称，如 Pod 的 DNS 名称，使得有状态应用可以通过这个唯一的标识符访问到其他 Pod，从而实现有序启动和停止。同时，StatefulSet 支持有序的扩展和收缩，以及自动完成应用程序的升级和回滚，而不会影响有状态应用的稳定性。

StatefulSet 在实现上，可以为每个 Pod 分配一个唯一的标识符，如 Pod 的名称、网络 ID 或存储名称等。这个标识符可以方便地让有状态应用识别其他 Pod，并与之通信。同时，StatefulSet 还可以自动为每个 Pod 分配独立的持久化存储，确保数据的可靠性和一致性。

StatefulSet 与 Deployment 不同，它不支持滚动升级和回滚功能，因为有状态应用的数据状态非常重要，不允许出现数据不一致或丢失的情况。因此，在进行应用程序的更新时，需要采用其他机制，如灰度发布，以确保应用程序的稳定性。

总之，StatefulSet 是 Kubernetes 中一种非常重要的控制器，它可以帮助开发者更好地部署和管理有状态应用，提高应用程序的可靠性和稳定性。

一、StatefulSet 的作用

StatefulSet 提供了一种稳定、有序、可靠的方式来部署和管理有状态服务。有状态服务通常需要以下特性：

1. 持久化存储：状态是持久化存储的，例如数据库。如果 Pod 被删除，数据仍然存在。

2. 稳定的网络标识：有状态服务需要固定的网络标识，以便其他服务和客户端可以稳定地访问它。

3. 有序的副本管理：有状态服务的每个实例都有唯一的标识符，例如名称或 ID。在扩展、缩小、升级和回滚时，需要确保有序进行。

StatefulSet 提供了这些功能，同时还提供了扩展、缩小、升级和回滚有状态服务的机制。

二、StatefulSet 的特点

1. 安装有序：在创建和删除 Pod 时保持有序。这遵循了有状态服务中的常见模式。

2. 稳定的网络标识符：每个 Pod 都有一个稳定的网络标识符，这可以是 Pod 名称或其他用户定义的唯一标识符。

3. 点对点通信：Pod 可以直接通过 DNS 或其他网络协议进行点对点通信。这有助于减少不必要的流量，提高网络性能。

4. 有序的升级和回滚：升级和回滚有状态服务时，StatefulSet 会按照有序的方式创建新的 Pod，删除旧的 Pod，确保有序过渡。

5. 持久化存储：StatefulSet 可以使用多种持久化存储技术，包括 PersistentVolumeClaim（PVC）、云存储和本地存储，以便在 Pod 被重新调度或重新创建时保留数据。

6. 可扩展性：可以创建多个 StatefulSet，每个 StatefulSet 包含一个有状态服务的实例，并可以使用 Kubernetes 的自动扩展功能来动态增加或减少 Pod 的数量。

三、StatefulSet 的组成

一个 StatefulSet 包括以下组成部分：

1. Pod 模板：定义要创建的 Pod 的规范。只有一个 Pod 模板，用于创建所有的 Pod。

2. 稳定的网络标识符：由服务名称和每个 Pod 的唯一编号组成。例如，一个名为 my-app 的服务，分别创建了 my-app-0、my-app-1 和 my-app-2 三个实例。

3. VolumeClaim templates：定义每个 Pod 使用的 VolumeClaim（如果有的话）。这样，每个 Pod 都有自己的独立的卷，可以存储持久化数据。

4. 更新策略：定义 StatefulSet 如何升级、扩展和收缩 Pod。

四、StatefulSet 注意事项

以下是在使用 StatefulSet 时需要注意的事项：

1. 不支持滚动更新：在升级或回滚时，只会使用标识符最大的 Pod 进行升级。

2. Pod 必须有唯一的名称：StatefulSet 使用 Pod 名称作为唯一标识符，并据此创建有序的 Pod 序列。

3. 不能直接删除 Pod：必须通过 StatefulSet 进行管理，否则会破坏有序性和稳定性。

4. 稳定的网络标识符必须是 DNS 主机名：这些 DNS 主机名必须是唯一的，并且 Service 必须支持此类型的 DNS 记录。

5. StatefulSet 不支持自动水平扩展：必须手动调整或使用 HPA 进行调整。

总之，StatefulSet 提供了一种管理有状态服务的方法，它提供了有序性、稳定性和可靠性，并支持持久化存储、有序的副本管理和稳定的网络标识符等特性。但是，使用 StatefulSet 也有一些限制和注意事项，需要认真考虑。

                                        2.1.3.1.2.3 守护进程（DaemonSet）

                                        Kubernetes 的守护进程是在 Kubernetes 系统中运行的一种类型的 Pod，其主要作用是在 Kubernetes 集群中运行一些持续运行的任务，例如监控、日志收集、数据库备份等。

                                        简单来说，Kubernetes 的守护进程是指一种专门负责在 Kubernetes 集群中运行常驻任务的 Pod。与一般的 Pod 不同，守护进程 Pod 中的容器是“无限循环”的，它们会持续地运行，直到它们被手动删除或者整个守护进程被停止。

                                        Kubernetes 的守护进程 Pod 有以下特点：

                                        1. 持续运行：与一般的 Pod 不同，守护进程 Pod 的容器是“无限循环”的，它们会持续地运行。

                                        2. 监管进程：守护进程 Pod 会自动重启容器，确保容器始终处于运行状态，从而保证任务的连续性。

                                        3. 均衡负载：可以通过部署多个守护进程 Pod 实例来进行负载均衡，以便处理更大的任务负载。

                                        4. 自动扩展：可以通过 Kubernetes 的自动扩展机制来自动扩展守护进程 Pod 的数量，以应对更高的工作负载。

                                        5. 持久化存储：可以使用 Kubernetes 的 PV 和 PVC 来配置容器，以便可以持久保存数据。

                                        Kubernetes 守护进程 Pod 主要用于运行一些常驻任务，例如监控、日志收集、数据库备份等。这些任务通常需要持续运行，并且需要在容器故障时能够自动重启容器，以便确保任务的连续性。

                                        Kubernetes中的DaemonSet是一种控制器，它确保在Kubernetes集群中的每个节点上运行一个Pod。它被用来管理运行在每个节点上的守护进程，例如日志或监控代理，或其他需要在每个节点上运行的系统级别任务。DaemonSet用于确保每个节点上都有一个Pod实例运行，并在节点添加或删除时自动调整Pod实例的数量。 

                                        DaemonSet通常用于部署一些运行在每个节点上的任务或服务，例如日志收集或监控代理。DaemonSet中的Pod被部署到每个节点上，其中每个Pod都会在该节点上运行一个实例。当新节点加入集群时，Kubernetes会自动在新节点上启动一个Pod实例。同样，当节点被删除时，Kubernetes会自动从该节点中删除相关的Pod。

                                        DaemonSet的实现依赖于Kubernetes的调度器，因此可以使用标签选择器对节点进行筛选，以便只在特定的节点上运行。 例如，可以使用标签选择器仅在拥有特定硬件或软件的节点上运行特定的守护进程。 

                                        总之，DaemonSet是一种非常有用的Kubernetes资源，它确保在集群中的每个节点上都运行一个Pod实例。它可以方便地管理运行在每个节点上的守护进程或服务，并自动跟随节点的变化进行调整。

                                        2.1.3.1.2.4 任务/定时任务

                        在Kubernetes中，有两种类型的任务：Job和CronJob。 

                        1. Job 

                Job负责管理一次性任务，在任务完成后可以让Pod自动终止。它是通过创建一个或多个Pod来实现的，这些Pod会一直运行，直到完成任务。完成任务后，Pod将被自动终止。Job的主要作用是确保任务能够成功完成。

Job的参数包括任务需要执行的镜像，任务的数量，任务的重启策略（如在任务失败时重启等），并行度等。在Job中，Pod并不会自动重启，而是会创建新的Pod实例来替换已经完成任务的Pod。

                        2. CronJob

                CronJob是一种可以定期执行任务的机制。它是基于cron表达式的，可以定义任务需要运行的时间和频率。CronJob可以非常方便地用于周期性的任务，例如数据备份或清理任务等。

                CronJob的主要参数包括作业需要执行的镜像，任务的调度时间和频率，任务执行时使用的命令和参数，以及任务调度失败时的处理方式等。

                总之，Job和CronJob是Kubernetes中两种非常有用的任务调度机制。Job适用于一次性的任务，而CronJob适用于定期性的任务。这两种资源可以帮助用户方便地管理和调度任务，确保任务能够成功完成，并自动清理完成任务的Pod。

                        2.1.3.2 服务发现

                                2.1.3.2.1 service                       

                                        在Kubernetes中，Service（缩写为svc）是一种抽象的概念，用于将一组Pods公开到集群内部或外部。它可以提供一组Pods的负载均衡，方便访问和发现服务。Service可以根据各种选择器（Labels）来选择相关的Pod，并将它们组织在一起以提供一组虚拟服务。

                                        Service之间通常通过集群内部网络（ClusterIP）来进行通信，也可以将外部网络（LoadBalancer、NodePort或ExternalIP）与Service相关联，以提供在Kubernetes集群外访问Service的能力。在使用Service时，可以引用服务名称和端口号，并通过这种方式来访问Service后面的Pods，而无需了解这些Pods的具体位置。

                                        在运行Kubernetes的集群中，Service是一项必需的组件。它提供了计算资源的透明访问，并为应用程序提供了独立于基础设施的绑定服务的能力。它可以使开发人员和负责运维的人员更轻松地管理应用程序、协调和发现服务，并提高应用程序的可伸缩性和容错性。

                                2.1.3.2.2 ingress

                                在Kubernetes中，Ingress是一种API对象，用于管理对集群内部的HTTP和HTTPS路由流量的访问。Ingress可以将一组服务暴露到集群外部，并通过定义HTTP规则来对流量进行路由。它通过使用不同的域名、URL路径或方法（如GET、POST），将流量路由到不同的服务。

                                在使用Ingress时，需要将所有服务暴露到同一个IP地址上，然后由Ingress控制器来将流量路由到正确的服务上。Ingress控制器通常是由第三方提供的插件或者自己定义的插件来实现的。 常见的Ingress控制器有Nginx Ingress、Traefik、HAProxy Ingress等。

                                Ingress可以配置TLS（传输层安全）证书和安全连接，可以实现HTTP/2的多路复用，允许使用SNI（服务器名称指示）来路由HTTPS流量，并且能够使用不同的调度算法对流量进行负载均衡。

                                总之，Ingress是Kubernetes中非常有用的一种对象，可以帮助管理HTTP和HTTPS流量的路由，并且能够为应用程序提供安全、高效的访问。

                        2.1.3.3 存储

                                2.1.3.3.1 volume                            

                                在Kubernetes中，Volume是Pod中用于存储数据的一种机制。一个Volume可以被看作是容器和宿主机之间的一个共享存储卷，可以在容器中暴露一个文件系统，或者将宿主机上的某个目录挂载到Pod中的某个容器中。

                                Volume的主要作用是：

                                1. 解决容器中持久化数据的存储问题。在容器启动时创建一个新的Volume，并将其挂载到容器的某个目录下，容器就可以将数据写入此目录，当容器被销毁时，Volume上的数据并不会随之消失。

                                2. 实现容器之间的数据共享。在同一个Pod中的容器可以共享同一个Volume，从而实现数据传递。

                                Kubernetes中支持多种类型的Volume，包括：

                                1. emptyDir：临时性的Volume，当Pod被删除时，Volume中的数据也会被销毁。

                                2. hostPath：将宿主机上的某个目录挂载到Pod中的某个容器中，可以实现容器和宿主机之间的数据共享。

                                3. ConfigMap和Secret：可以将ConfigMap和Secret中的数据以文件的形式挂载到Pod中的容器中。

                                4. persistentVolumeClaim：使用Persistent Volume（PV）提供持久化存储，从而实现数据的持久化。

                                Volume是Kubernetes中非常重要的一个概念，可以为Kubernetes应用提供各种不同类型的存储解决方案。

                                2.1.3.3.2 CSI                                       

                                  CSI（Container Storage Interface）是Kubernetes中的一种插件机制，用于与存储系统集成。它定义了一个标准接口，允许存储供应商编写外部插件，以便将其本地存储系统与Kubernetes集成。通过使用CSI插件，Kubernetes可以使用各种不同类型的存储设备，包括本地存储、网络存储和云存储等。

                                  CSI可以与Kubernetes的所有容器运行时（如Docker、CRI-O等）一起使用。它还提供了为应用程序提供卷和文件系统的能力，使得应用程序可以快速、灵活地获取和管理存储资源。

                                  CSI插件的实现方式比较灵活，存储供应商可以在插件中实现自己的存储设备管理逻辑。同时，CSI还提供了许多与安全、性能和容错相关的特性，可以为存储设备管理带来更加稳定和可靠的体验。

                        2.1.3.4 特殊类型配置

                                2.1.3.4.1 ConfigMap

ConfigMap是Kubernetes中一种用于存储配置信息的资源对象，可以存储键值对、字符串、JSON或INI格式的数据。ConfigMap可以被Pod、Deployment、StatefulSet、DaemonSet等对象引用，让应用程序可以在不修改代码的情况下获取配置信息。

ConfigMap适用于管理应用程序的配置信息，如数据库地址、端口号、用户名、密码等，同时还可以存储其他的非敏感信息，如全局变量、日志级别等。

ConfigMap资源对象可以使用kubectl命令行工具或Kubernetes API分别创建、更新和删除。当需要修改某个配置项时，只需要更新ConfigMap对象即可。此外，ConfigMap还支持热更新，即应用程序可在运行时动态地获取最新的配置信息，无需重启Pod等操作。

在应用程序中使用ConfigMap的方法有两种：

1. 通过环境变量：可以将ConfigMap中的某个键值对设置为环境变量，应用程序可以通过读取环境变量来获取配置信息。

2. 通过挂载文件：将ConfigMap中的某个键值对映射到文件中，应用程序可以通过读取文件来获取配置信息。

总的来说，ConfigMap提供了一种标准的方式来管理应用程序的配置数据，可以帮助开发人员快速、有效地管理应用程序的配置信息。

                                2.1.3.4.2 Secret

Secret是Kubernetes中一种用于存储敏感信息的资源对象，如密码、密钥、证书等。Secret可以被Pod、Deployment、StatefulSet、DaemonSet等对象引用，让应用程序可以在不修改代码的情况下获取敏感信息。

Secret适用于管理应用程序的敏感信息，如数据库密码、第三方API的密钥等。Secret的数据被存储在Master节点的etcd中，被加密后保存在其中。默认情况下，只有具备访问Secret的Pod才能解密其中的内容，确保了敏感数据的安全性。

Secret可以使用kubectl命令行工具或Kubernetes API分别创建、更新和删除。当需要修改敏感信息时，只需要更新Secret对象即可。此外，Secret也支持热更新。

在应用程序中使用Secret的方法有两种：

1. 通过环境变量：可以将Secret中的某个键值对设置为环境变量，应用程序可以通过读取环境变量来获取敏感信息。

2. 通过挂载文件：将Secret中的某个键值对映射到文件中，应用程序可以通过读取文件来获取敏感信息。

总的来说，Secret提供了一种标准的方式来管理应用程序的敏感信息，可以帮助开发人员快速、有效地保证敏感数据的安全性。

                                2.1.3.4.3 DownwardAPI

Downward API是Kubernetes中的一个特性，它允许Pod中的容器将自身的一些元数据或状态信息传递给其他容器或存储在容器外部的文件中。Downward API可以向下注入一些有用的信息，例如Pod的名称、命名空间、标签、容器的名称和IP地址等，这些信息对于容器内运行的进程来说非常重要。

Downward API可以将元数据注入到容器中的环境变量和卷中。在环境变量中注入的信息可以通过容器进程的环境变量进行访问，而卷中的信息可以通过文件系统进行访问。Downward API可以通过下面两种方式进行注入：

1. 环境变量

env:
- name: POD_NAME
  valueFrom:
    fieldRef:
      fieldPath: metadata.name
- name: NODE_NAME
  valueFrom:
    fieldRef:
      fieldPath: spec.nodeName

在上面的例子中，Pod的名称和节点名称会被注入到容器中的`POD_NAME`和`NODE_NAME`环境变量中。`valueFrom`字段中指定了使用哪种注入方式，`fieldRef`字段中指定了要注入的元数据和它的名称。

2. 卷

volumes:
- name: pod-info
  downwardAPI:
    items:
    - path: "labels"
      fieldRef:
        fieldPath: metadata.labels

在上面的例子中，Pod的标签信息会被注入到一个名为`pod-info`的卷中，卷中的文件路径为`/downward-api/volumes/pod-info/labels`。`downwardAPI`字段中定义了要注入的元数据，`items`字段中指定了要注入的元数据的名称和路径。

Downward API为应用程序提供了获取Pod及其容器的元数据信息的便捷方式，使得应用程序能够更好地与Kubernetes集群进行协作。

                        2.1.3.5 其他

                                2.1.3.5.1 Role

                                        Role 是一组权限的集合，例如 Role 可以包含列出 Pod 权限及列出 Deployment 权限，Role 用于给某个 Namespace 中的资源进行鉴权。

                                2.1.3.5.2 RoleBinding

                                        RoleBinding ：将 Subject 绑定到 Role，RoleBinding 使规则在命名空间内生效。

三、对象规约和状态

        3.1 规约

Kubernetes（k8s）中的spec是指Kubernetes API对象的规范（Specification），用于定义该对象的期望状态和属性。

在Kubernetes中，每个API对象都有一个spec字段，并且该字段的内容各不相同，因为每个API对象都有其自己独特的规范和属性。例如，Deployment对象的spec定义了Pod的副本数，更新策略和Pod的模板，而Service对象的spec定义了服务选择器和暴露类型。

spec通常包含关于API对象的以下信息：

1. 元数据（Metadata）：每个API对象都有一个元数据字段，用于存储名称、命名空间、标签和注释等信息。

2. 规范（Specification）：这是API对象的主要规范，它定义了对象的期望状态以及如何更新它。规范通常包含有关以下内容：

   a. PodTemplate： 对于控制器类型的API对象（如Deployment，ReplicaSet等），它们的spec通常包含一个PodTemplate字段，用于定义Pod的模板。该PodTemplate使用的镜像，容器端口，环境变量等信息。

   b. Selector和ServicePodLabels： 对于Service对象，它的spec字段包含服务选择器和服务Pod标签。

   c. 副本数： 对于控制器类型的API对象，如Deployment，ReplicaSet等，还包含有关期望副本数的信息。

   d. 升级策略： 对于控制器类型的API对象，如Deployment，它的spec中还可能包含有关如何升级Pod的策略。

   e. 访问控制： 对于与访问控制相关的API对象，如Secret，ConfigMap和ServiceAccount等，它们的spec字段通常包含有关如何访问或使用它们的信息。

3. 状态（Status）： API对象的状态信息，如当前副本数量、更新状态等。很多对象的状态信息并不在spec字段中，而是在status字段中。

在Kubernetes中，规范（spec）是非常重要的，因为它定义了Kubernetes如何将API对象部署和管理。通常，您可以在创建API对象之前定义它的规范，然后Kubernetes就会根据该规范来创建对象并将其带入所期望的状态。此外，在更新或扩展API对象时，您可以更新其规范，并让Kubernetes相应地更新对象。

        3.2 状态

在Kubernetes中，状态（Status）是指Kubernetes API对象的实际状态。每个API对象都有一个状态字段，其中包含有关该对象的当前状态的信息。

状态通常是由Kubernetes控制器或其他系统组件生成，以反映对象的实际状态。例如，Deployment控制器会定期检查它管理的Pod的状态，并将该状态信息写入Deployment对象的status字段中。

状态通常包含以下信息：

1. 有关对象当前状态的信息，例如对象的健康状况以及它是否处于运行状态。

2. 有关关联对象的信息，例如一个ReplicaSet包含有多少个Pod，或者一个Service正在向哪些Pod暴露服务。

3. 对象属性的实际值，例如镜像版本或容器端口号等。

4. 有关对象的事件和警报的信息，例如发生了什么错误或者请求被拒绝。

通过查看Kubernetes对象的状态，您可以了解对象的实际状态，而不仅仅是规约（spec）中所描述的期望状态。这对于诊断问题和监测应用程序运行状况非常有用。

需要注意的是，状态和规约是不同的，规约提供了API对象所期望的状态，而状态提供了API对象实际的状态。Kubernetes会自动更新对象的状态，以反映对象的实际状态，而不是您所期望的状态。在某些情况下，这可能会导致规约和状态之间存在差异，例如当Pod正在被删除时，规约可能指示Pod不存在，但是状态可能仍然显示该Pod的存在。

文章写的再细也不如看视频理解的透，我主要参照了该up主的视频，讲的非常好，我是基于该视频为基础进行补充和完善

【完整版Kubernetes（K8S）全套入门+微服务实战项目，带你一站式深入掌握K8S核心能力】 https://www.bilibili.com/video/BV1MT411x7GH/?p=13&share_source=copy_web&vd_source=921dd22b5670d69481670cf6655563f5