关于 K8s 的一些基础概念整理-补充【k8s系列之二】

〇、前言

本文继续整理下 K8s 的一些基础概念，作为前一篇概念汇总的补充。

前一篇博文链接：关于 K8s 的一些基础概念整理【k8s系列之一】_集群 master节点控制节点宿主机-CSDN博客

一、详情

1.1 Label

Label 在 k8s 中是一个非常核心的概念，我们可以将 Label 指定到对应的资源对象中，例如 Node、Pod、Replica Set、Service 等，在配置文件中一般为 labels。

一个资源可以绑定任意个 Label，k8s 通过 Label 可实现多维度的资源分组管理，后续可通过 Label Selector 查询和筛选拥有某些 Label 的资源对象。

例如创建一个 Pod，给定一个 Label，workerid=123，后续可通过 workerid=123 删除拥有该标签的 Pod 资源。

参考：图解 K8s 核心概念和术语 - 后端进阶 - 博客园

1.2 DaemonSet 守护进程

DaemonSet 是 k8s 中的一种控制器，用于管理 Pod 的部署，确保每个节点上都有一个 Pod 在运行。

DaemonSet 控制器会监视集群中的节点状态，一旦有新的节点加入集群，或者节点状态发生变化（如节点重新启动），控制器就会触发相应操作。

创建 Pod：当检测到新节点时，控制器会在该节点上创建一个新的 Pod，并确保每个节点上只运行一个 Pod 实例。
更新 Pod：如果 DaemonSet 的配置发生变化，控制器会自动更新每个节点上的 Pod 实例。
删除 Pod：如果节点发生故障或者被删除，控制器会自动删除该节点上的 Pod 实例。
扩容和缩容：DaemonSet 还支持扩容和缩容，可以根据需要增加或减少 Pod 的数量。

DaemonSet 常用于运行一些系统级别的服务或者监控应用程序，使集群中的服务更加健壮和可靠。例如：

日志收集器：在每个节点上运行日志收集器（如 Fluentd 或 Filebeat），收集所有节点的日志数据，并将其发送到中心日志服务器进行存储和分析。
监控代理：在每个节点上运行监控代理（如 Prometheus Node Exporter 或 cAdvisor），收集所有节点的运行状态数据，并将其发送到中心监控服务器进行分析和展示。
网络代理：在每个节点上运行网络代理（如 kube-proxy 或 Istio Sidecar），负责节点之间的网络通信和流量管理。
安全代理：在每个节点上运行安全代理（如 Sysdig Falco 或 Aqua Security），检测所有节点的安全事件，并及时报警或进行防御

1.3 探针（Probe）

一个 Pod 被调度之后，就要进行初始化。初始化肯定是得有一个反馈的，否则都不知道最终有没有启动成功。这些健康检查的功能，叫做探针（Probe）。

常见的有 livenessProbe、readinessProbe、startupProbe 等三种探针。

livenessProbe 存活探针

LivenessProbe 用于检测容器是否仍然处于运行状态。如果探测失败，k8s 将根据 Pod 的重启策略决定是否重新启动该容器。

适用于需要监控容器内主进程或服务是否正常运行的情况。

例如，当宿主机故障或资源不足导致容器停止工作时，可以通过 LivenessProbe 来检测并采取相应的恢复措施。

livenessProbe:httpGet:path: /healthport: 8080initialDelaySeconds: 60periodSeconds: 10successThreshold: 1timeoutSeconds: 5

ReadinessProbe（就绪探针）在这个示例中，kubelet 会每 10 秒发送一次 HTTP GET 请求到/health路径，如果连续失败 5 次，则认为容器不健康，并根据重启策略进行处理。

ReadinessProbe 用于检测容器是否已经准备好接收流量。如果探测失败，k8s 会将该 Pod 从 Service 的 Endpoints 列表中移除，直到它再次通过探测为止。

适用于需要在容器启动或重启后，等待其完全准备就绪，再开始接收流量的场景。

例如，在滚动更新过程中，新版本的容器需要通过 ReadinessProbe 验证后才能开始处理请求。

readinessProbe:exec:command: ["cat", "/tmp/ready"]initialDelaySeconds: 5periodSeconds: 10successThreshold: 1failureThreshold: 3

在这个示例中，kubelet 会每 10 秒执行一次cat /tmp/ready命令，如果连续失败 3 次，则认为容器未就绪。

StartupProbe（启动探针）

StartupProbe 用于判断容器内的应用程序，是否已经成功启动并完成初始化任务。它在容器启动初期生效，先于 LivenessProbe 和 ReadinessProbe。

适用于启动时间较长或启动过程中有复杂初始化序列的应用程序。StartupProbe 可以防止在这些应用程序还未完全启动时就被误判为不健康或就绪。

startupProbe:httpGet:path: /startupport: 8080initialDelaySeconds: 10periodSeconds: 15successThreshold: 1failureThreshold: 3

在这个示例中，kubelet 会在容器启动后等待 10 秒，然后每 15 秒发送一次 HTTP GET 请求到 /startup 路径，如果连续失败 3 次，则认为启动失败。

一般，花费 120s startupProbe 的启动实践，每隔 5s 检测一下 livenessProbe，每隔 10s 检测一下 readinessProbe，是常用的操作，一般都是在 yml 配置文件中进行详细配置。

参考：https://zhuanlan.zhihu.com/p/379270517

1.4 钩子（Hook）

钩子（Hook），主要有 PostStart 和 PreStop 两种。

PostStart 在容器启动后立即触发执行，用于完成启动后的初始化操作，例如加载配置、启动辅助进程。它与主进程无直接依赖关系，不会阻塞主进程启动。

lifecycle:postStart:exec:command: ["sh", "-c", "echo 'Container started'"]

PreStop 在容器收到终止信号（如 kubectl delete pod 或 kubectl scale）时触发执行，用于执行停止前的清理工作，例如保存状态、关闭连接、释放资源。

preStop:exec:command: ["sh", "-c", "echo 'Container stopping'; sleep 5"]

其实 Hook 就是一些 shell 脚本，需要在指定的事件点执行，因为比较常用就升级到关键字级别了。钩子是Kubernetes中一种强大的机制，能够在容器生命周期的特定阶段执行自定义操作。通过合理利用钩子，可以在容器启动后或停止前完成必要的初始化和清理工作，从而提高应用的可靠性和自动化水平。

1.5 Stateful Sets

StatefulSet 是 k8s 中用于管理有状态应用的控制器，它提供了稳定的网络标识符、持久化存储以及有序部署和扩展等功能。

它与 deployment 类似，唯一的区别是 deployment 创建一组任意名称的 pod，并且 pod 的顺序对它来说并不重要。

而 StatefulSet 为每个 Pod 维护了一个有粘性的 ID，这些 Pod 是基于相同的规约创建的，但不可相互替换，且每个 Pod 都有一个永久不变的 ID。

如果要为 example 的 pod 创建 3 个副本，那么 StatefulSet 将会创建为：example-0、example-1、example-2。因此，这一创建方式最重要的好处就是你可以通过 pod 的名称就了解大致的情况。

两个核心组件：

Headless Service：无头服务（Headless Service）是一种特殊的 Service，其 ClusterIP 设置为 None，不会分配 Cluster IP，也不会进行负载均衡和路由。这种服务主要用于为 Pod 提供稳定的 DNS 记录，使得 Pod 可以通过域名进行访问。
VolumeClaimTemplates：StatefulSet 要求每个 Pod 都挂载持久化存储卷，以确保数据在 Pod 重建时得以保留。VolumeClaimTemplates 允许为每个 Pod 动态创建 PersistentVolumeClaim（PVC），从而绑定到相应的 PersistentVolume（PV）。

主要特性：

稳定的唯一网络标识符：每个 StatefulSet 的 Pod 都有一个稳定的网络标识符（如 DNS 名称），这个标识符由控制器自动生成，并与 Pod 的生命周期保持关联。这使得有状态应用更容易被其他应用或服务访问和发现。
有序部署和扩展：StatefulSet 会按照指定的顺序逐个创建和更新 Pod。每个 Pod 都有一个唯一的序号，用于标识其在集群中的位置。在扩展时，新的 Pod 会按照相同的顺序创建，确保有状态应用的数据一致性和可用性。
稳定的存储：每个 StatefulSet 的 Pod 都可以使用持久卷（PersistentVolume）存储数据，这些存储可以在 Pod 重新启动或迁移时保持不变。这使得有状态应用可以继续使用之前的数据，保证数据的持久性和可靠性。
域名解析：每个 StatefulSet 的 Pod 都有一个稳定的域名，可以通过该域名进行访问。域名的格式为<statefulset名称>-<序号>..svc.cluster.local>，这使得有状态应用可以通过域名进行服务发现和通信。
有序删除：在删除 StatefulSet 时，控制器会按照指定的顺序逐个删除 Pod。这可以确保有状态应用在删除过程中不会丢失数据，并且能够有序地关闭服务。

StatefulSet 通过提供稳定的网络标识符、持久化存储以及有序部署和扩展等功能，为 k8s 中的有状态应用提供了强大的支持。

然而，在使用 StatefulSet 时也需要注意一些事项，如删除 StatefulSet 并不会自动删除其关联的 PVCs 和 PVs 等存储资源。因此，在删除 StatefulSet 前需要明确是否也需要删除这些存储资源并确保应用数据已经妥善备份或具备迁移数据的能力。

参考：一文带你理解14个K8S必备基础概念_架构_Rancher_InfoQ精选文章

1.6 ConfigMap

ConfigMap 是 k8s 中一种用于配置管理的 API 资源对象，它允许用户将配置信息与容器镜像解耦，从而使得应用程序的配置更加灵活和可移植。用于存储非密钥/值数据，如配置文件、环境变量和命令行参数等。

通过合理地使用ConfigMap，可以提高应用程序的可移植性和可维护性，同时确保配置的安全性和一致性。

ConfigMap 的主要特点是，可以将应用程序的配置信息以键值对的形式保存，并且这些配置信息可以独立于应用程序代码进行管理和更新。

四种创建方式：

命令行创建：可以通过 kubectl 命令行工具使用 --from-literal 参数来创建一个 ConfigMap，其中包含键值对。
文件创建：可以从文件中创建 ConfigMap，支持单个文件或目录。
目录创建：从目录创建 ConfigMap 时，只会读取文件夹第一级内容。
YAML 文件创建：可以使用 YAML 文件定义 ConfigMap 的内容和结构。

主要的作用：

解耦配置与镜像：通过使用 ConfigMap，应用程序的配置信息不再硬编码在容器镜像中，而是存储在 k8s 集群中，这样可以在不修改容器镜像的情况下更新配置，更新完成后重启服务即可。
提高安全性：敏感信息不应存储在 ConfigMap 中，因为它是明文存储没有特殊的安全措施，而应使用 Secrets 来保护，下文将详细介绍。
适应不同环境：ConfigMap 可以用于不同环境应用环境的配置统一，通过使用不同的 ConfigMap，应用程序可以在不同的环境中保持一致的行为。

使用方式：

作为环境变量注入：Pod 可以通过 envFrom 字段引用 ConfigMap，将其所有数据定义为容器的环境变量。
作为命令行参数传递：Pod 可以将 ConfigMap 的数据保存在环境变量中，然后通过 $(VAR_NAME) 的方式引用环境变量。
作为 Volume 挂载：Pod 可以通过 volumeMounts 将 ConfigMap 作为文件或目录挂载到容器内部。

1.7 Secrets

Secrets 是 k8s 中的一种资源类型，专门用于存储和管理敏感信息。这些信息通常包括密码、OAuth 令牌以及 SSH 密钥等，它们被 Base64 编码后存储在 k8s 集群中。

通过使用 Secrets，可以避免将这些敏感信息硬编码在应用程序代码或 Docker 镜像中，从而提高了安全性和灵活性，同时也可确保配置的灵活性和可移植性。

三种创建方式：

命令行创建：可以通过 kubectl 命令行工具使用 --from-literal 参数来创建一个 Secret，其中包含键值对。
文件创建：可以从文件中创建 Secret，支持单个文件或目录。
YAML 文件创建：可以使用 YAML 文件定义 Secret 的内容和结构。

主要的四种类型：

Opaque 类型：用户定义的任意数据，通常用于存储密码、秘钥等敏感信息。
Service Account：由 k8s 自动创建，用于访问 API 服务器，并会自动挂载到 Pod 的 /run/secrets/kubernetes.io/serviceaccount 目录中。
kubernetes.io/dockerconfigjson：用来存储私有 Docker Registry 的认证信息。
kubernetes.io/tls：用于存储 TLS 证书和其关联的私钥。

使用方式：