云原生方案下的自动化运维方案

云原生方案下的自动化运维方案总结

探针（Probes）

​

• 就绪探针（Readiness Probe）：用于判断容器是否准备好接收流量，只有当就绪探针成功时，Kubernetes的服务代理（如kube-proxy）才会将请求转发至该容器。当应用初始化、升级或者故障恢复期间，如果就绪探针检测到Pod未准备好提供服务，那么即使Pod已经启动并运行，Kubernetes也不会将该Pod加入到负载均衡列表中，从而避免了不健康Pod处理用户请求导致的服务质量下降

• 健康检查探针（Liveness Probe）：Kubernetes使用健康检查探针来检测容器的运行状况。如果容器未能通过健康检查，Kubernetes会重启该容器以确保服务的高可用性，并在重新通过就绪探针验证后接入服务流量

• 启动探针（Startup Probe）（可选）：用于在容器启动初期进行额外的初始化检查，避免在应用启动阶段过早地执行其他探针。

• 触发类型

  1. HTTP GET请求：

• Liveness Probe、Readiness Probe 和 Startup Probe 都支持通过发送HTTP GET请求到容器内指定的端口和路径来判断容器的健康状况。

  • Kubernetes会根据响应的状态码（通常期望是200-399之间表示成功）以及其他可选参数（如超时时间、重试次数和成功阈值）来决定容器是否健康或已启动完成。
  • 常用这个，比如java springboot应用的/actuator/health/liveness或/actuator/health/readiness端点（支持好像在springboot2.3.2之后）

2. TCP Socket连接：

• 除了HTTP GET请求之外，也可以通过尝试建立TCP连接到容器内的特定端口来探测容器的存活与就绪状态。
  • 如果能够成功建立连接，则认为该探针成功。类似nc localhost <监听端口>

3. 执行命令：

• 可以定义一个命令（Exec Action），当运行这个命令并返回退出代码为0时，探针则被认为是成功的。
• 这个方法允许用户自定义更复杂的健康检查逻辑，例如检查服务内部的日志文件、数据库连接或者任何其他适合容器内部运行的健康检查脚本。

高可用机制

在一个具有多个副本的Deployment等K8S资源中，结合Kubernetes的自动负载均衡机制和服务探针功能，实现了对服务流量的高可用保障。
当某个Pod因就绪探针失败而暂时退出负载均衡时，其他健康的Pod仍能持续处理流量，保持服务整体可用性。
同时，存活探针可以及时发现并处理异常情况，使得系统具备自我修复能力，降低人工介入运维的需求。

控制器（Controllers）

Kubernetes的核心设计理念之一是声明式配置和自愈机制。控制器作为Kubernetes系统的重要组成部分，负责监控集群的实际状态并将其与期望状态进行对比，根据差异自动执行相应操作以实现状态同步。例如：

• ReplicaSet Controller 管理Pod副本数量，确保实际运行的Pod实例数量符合用户定义的目标数量。
• Deployment Controller 提供了更高级别的抽象，它管理ReplicaSets，并提供了滚动更新、回滚等功能。
• StatefulSet Controller 为有状态应用提供有序创建、扩展和缩容的能力，保证每个Pod具有稳定的持久化存储和网络标识。

K8S工作负载控制器

Kubernetes中工作负载控制器负责管理和调度不同类型的Pod集合，常见的工作负载控制器包括：

• Deployment 用于部署无状态应用，支持版本升级和回滚。
• StatefulSet 适用于需要稳定网络标识符和持久存储的有状态应用。
• DaemonSet 确保每个Node上都运行一个指定的Pod副本，常用于日志收集、监控等系统级守护进程。
• Job/CronJob 用于一次性任务或定时任务的执行。

自动拓展 (Auto Scaling)

• Horizontal Pod Autoscaler (HPA) 根据CPU和内存使用率或其他自定义metrics自动调整Pod的数量，实现水平伸缩。
• Vertical Pod Autoscaler (VPA) 动态调整单个Pod的资源请求，以优化资源利用率和性能。
• Kubernetes Event Driven Autoscaling (KEDA) 基于事件驱动进行弹性扩缩容，特别适合处理基于消息队列的任务或应对突发流量。

持续交付方案 (Continuous Delivery, CD)

• CI/CD Pipeline集成 将Git仓库中的代码变更通过Jenkins触发构建、测试、打包镜像和发布到Docker Registry/Harbor。并触发镜像tags的变更到git上.
• Helm Chart 使用Helm包管理工具定义和部署应用的完整生命周期，简化复杂应用的安装和升级过程。
• ArgoCD 实现GitOps模式，将Kubernetes资源定义文件存放在版本控制系统中，CI和运维人员可以修改定义,CD通过对比实际与期望状态自动执行应用部署和更新。

指标告警

• Prometheus Operator 部署Prometheus及相关的Exporter，采集集群内各种指标数据。
• Grafana 结合Prometheus,Loki展示实时监控图表。
• Alertmanager 与Prometheus，Loki集成(需要配置Prometheus rule和Loki的log alert)，统一处理告警通知，发送邮件、短信或Slack消息给运维团队。

分布式存储与Pod工作负载控制器的故障转移

存储类和持久卷（Persistent Volumes, PVs）

• Kubernetes通过StorageClass定义了不同类型的存储服务，允许动态分配持久卷资源。
• PersistentVolumeClaim (PVC) 用于请求特定大小和访问模式的存储资源，与合适的StorageClass结合，能够为Pod提供具有容错性和可扩展性的数据存储。

ReadWriteMany (RWX) 访问模式

• 对于需要跨多个Pod共享数据或进行故障转移的应用场景，需要支持ReadWriteMany（多读写）访问模式的PV。
• 这种访问模式下的分布式存储系统如NFS、GlusterFS、Ceph RBD等可以被Kubernetes识别并绑定到PVC上，使得多个副本集中的Pod都能够同时访问同一份数据。

工作负载控制器与故障转移

• 使用像StatefulSet这样的工作负载控制器时，结合RWX访问模式的存储，可以确保即使在Pod发生故障时也能快速恢复服务，并且数据不会丢失。
• 当StatefulSet中的一个Pod失效时，控制器会自动创建一个新的Pod实例，并将该Pod连接到同一个持久卷，从而实现数据的无缝迁移和应用的连续性。同时也依旧有headless和sts机制的稳定网络表示

Operator与分布式存储集成

• 在Operator设计中，对于依赖分布式存储的有状态应用，Operator需要了解如何正确地创建和管理包含RWX PVC的Pod模板。
• 例如，数据库Operator（如PostgreSQL Operator或MySQL Operator）通常会根据用户提供的CRD（Custom Definition）配置信息，自动创建具备故障转移能力的集群实例，其中包括合理配置存储以支持高可用性。

备份和容灾

Kubernetes Pod的自动调度机制

在Kubernetes集群中，无论是无状态应用还是有状态应用，其运行实例——Pod都会由Kubernetes调度器根据资源需求、节点条件、亲和性和容忍性策略等自动分配到合适的节点上。调度过程无需额外的备份或恢复操作，是Kubernetes平台内建的服务功能。

调度原理与流程：

1. 调度器监控与发现：
   • Kubernetes调度器持续通过API服务器监听（watch）集群中创建的新Pod。
   • 当检测到有新的Pod处于Pending状态且尚未被调度时，调度器会将其加入到调度队列中。
2. 节点评估与选择：
   • 调度器基于对集群内所有节点的实时信息缓存进行评估，这些信息包括但不限于节点的CPU、内存、磁盘空间等资源可用性。
   • 调度器还会考虑每个节点上已运行的Pod及其资源请求和限制，确保新Pod调度后不会导致节点资源超限。
3. 亲和性和容忍性策略应用：
   • 调度器遵循PodSpec中定义的调度约束条件，如节点选择器、标签亲和性和/或反亲和性规则。
   • 根据这些规则，调度器筛选出满足特定要求的节点列表。
4. 优先级与抢占：
   • 高优先级的Pod会被优先安排调度。如果必要，低优先级的Pod可能被抢占以释放资源给高优先级Pod使用。
   • 调度器还考虑Pod之间的互斥关系以及Pod间的本地性需求（例如，尽量将相关Pod调度至同一节点以减少网络延迟）。
5. 调度决策执行：
   • 经过上述步骤筛选后，调度器选择一个最适合的节点，并将调度决定记录在API服务器中。
   • 被选中的节点上的kubelet接收到调度指令后，开始拉取Pod的镜像并启动容器。

应用程序备份与恢复

无状态应用

• 备份方案说明：
  • 主要关注配置资源（ConfigMap和Secrets）、应用程序镜像和编排文件（如Deployment YAML）。
  • 将这些内容纳入版本控制系统，定期更新并存储到远程安全位置。(前面提到的CD gitops)
• 恢复步骤操作：
  • 当需要恢复时，从版本控制库获取对应版本的配置和资源定义文件，并使用kubectl apply命令重新部署,或者在ArgoCD进行回滚

有状态应用

• 备份方案说明：
  • 对于分布式存储的存储类（如使用Longhorn，Rook Ceph），除了K8S集群内部的多副本或纠错码的PV可调度外，也可以设置自动备份PV数据至外部存储如S3或其他云存储服务。
  • 若应用由特定Operator管理（如数据库Operator），利用Operator提供的接口或集成第三方工具执行定期全量/增量备份，并保存至安全冗余的位置（外部存储或内部PV）。
• 恢复步骤操作：
  • PV数据恢复：选择适当的备份点，通过Longhorn或其他工具将数据还原到新的或原有PV上。
  • Operator管理应用恢复：根据Operator文档指引，从备份文件中恢复应用状态。

分布式存储（Persistent Volumes, PVs）

• 备份方案说明：
  • 如前所述，对于支持外部备份的分布式存储系统（如Longhorn），配置自动或手动备份策略，确保PV数据被定期备份到云端存储。
• 恢复步骤操作：
  • 根据备份系统的操作指南，选取合适的时间点备份文件进行数据恢复，通常涉及加载快照并重新挂载到目标PV。

Kubernetes核心组件：etcd

• 备份方案说明：
  • 定期执行etcd快照备份，并通过CronJob自动化上传备份文件至远程对象存储以实现异地容灾。
• 恢复步骤操作：
  • 在新环境中初始化或重建etcd集群，然后下载最新的etcd快照备份文件。
  • 使用etcdctl snapshot restore命令加载快照恢复集群状态，并同步缺失的事务日志。

其他K8S集群备份工具velero

GitHub - vmware-tanzu/velero: Backup and migrate Kubernetes applications and their persistent volumes

推荐阅读

周志明老师的凤凰架构 凤凰架构：构筑可靠的大型分布式系统 | 凤凰架构 (jingyecn.top)

operator介绍 Welcome to Operator framework