Etcd 概述及运维实践

Etcd 概述

什么是 Etcd ?

Etcd 是 CoreOS 团队于2013年6月发起的开源项目，它的目标是构建一个高可用的分布式键值(key-value)数据库。etcd内部采用raft协议作为一致性算法，Etcd基于 Go 语言实现。

名字由来，它源于两个方面，unix的“/etc”文件夹和分布式系统(“D”istribute system)的D，组合在一起表示etcd是用于存储分布式配置的信息存储服务。

kube on kube 实现思路分享

这里的 kube on kube ， 是指建立 K8s 元集群，纳管其他业务 K8s 集群，通过声明式 API 管理集群的创建、增删节点等。

参考 https://github.com/kubean-io/kubean 源码进行编写，进行了裁剪。感谢 DaoCloud 开源！ 👍👍

背景

随着容器化覆盖率的逐步增加，越来越多的业务迁移到 K8s 集群中， 考虑到同城双活、不同业务的复杂性以及耦合度，需要部署维护多套 K8s 集群，如何高效、可靠的在数据中心管理多个 k8s 集群是我们面临的关键挑战。

我们的虚拟化变革之旅

译自：https://blog.taboola.com/our-journey-of-virtualization-change/

黑暗时代

我们最初采用oVirt作为我们的虚拟化平台，事实证明它是一个很好的产品，具有几个显着的优势。其开源性质使我们能够利用广泛的功能和定制选项。

然而，尽管它具有优势，我们还是遇到了一些缺点和问题，迫使我们寻求更好的虚拟化解决方案。两个主要缺点是它没有任何可用的 DFS 和库存管理问题。此外，我们偶尔会遇到 oVirt 的性能问题和稳定性问题。一些资源密集型工作负载出现延迟或意外行为，影响了虚拟化环境的整体性能。随着我们的基础设施的发展，这些问题变得更加明显，导致生产力和用户满意度下降。

Calico 异常重启问题复盘

集群内网络架构为，基于Calico BGP 的路由模式，直接与交互机建联。

影响范围和故障时间线

影响范围

线下环境 node-xx 物理机上 Pod 网络不可用

影响时间线（2023-07-23 22:09 ~ 22:14）

[22:13] 收到网工反馈 Peer Down

K8s 无备份，不运维

出故障时，就知道是谁在裸泳 🙃

K8s 投产使用，备份是保命手段，必须要上，建议做一个 checklist，巡检通过，集群才能对外提供服务，比如，这样👇

备份方案制定

1. 物理备份：etcd 备份，保存某一个时刻的快照，快捷方便。
2. 逻辑备份：velero 备份 ，允许用户自己选择备份的内容，比如单个 namespace、指定资源类型等。

巧用 shell-operator 配置 K8s Pod 保护策略

保障 Pod 高可用分为以下几个方面

• 资源池划分 ：打污点、独占、隔离
• Qos 分级 & 优先级：按应用等级保障稳定性
• 自动弹性伸缩 HPA
• Pod 干扰预算 PDB

什么？相同型号物理机 容器性能不如虚拟机？

事件经过

该应用通过虚拟机和容器混合部署，上线前压测了虚拟机上的应用性能，理论上流量高峰能抗住。

[xx:xx] 流量突增，接口大量超时

[xx:xx] 限流

[xx:xx] 重启，虚拟机能重启成功，容器重启失败，容器流量摘除，暂时恢复

[xx:xx] 扩容， 容器虚拟机均扩容

[xx:xx] 两台容器异常，流量摘除

K8s 一条默认参数引起的性能问题

👉 Nodejs 应用 从虚拟机迁移到容器 产生的性能问题

问题时间线

[xx:xx] 开发收到业务反馈接口响应超时

[xx:xx] 开发&SRE&中间件 联合排查代码、网关、底层网络问题，无果

[xx:xx] 测试环境复现排查

[xx:xx] 利用差异法、排除法和经验解决，先上线

[xx:xx] 根因定位

问题现象

1）接口偶发性超时

云原生实践总结

👉 作为一名SRE，在运维云原生过程中的实践总结、沉淀，以便自己回顾和他人查阅，希望能帮助你在云原生领域的平稳落地。

企业落地云原生的目的

一句话概括：在保证稳定性的前提下，降本增效

目标拆解：

• 保障稳定性

  • 建设高可用性：基础组件（Master三大件/Etcd等）高可用、多机房、多集群、Pod 高可用
  • 持续进行风险治理：耦合度、故障发现、容量、容灾、变更及可运维性、安全性
  • 建设可观测性：Metrics、Logging、Tracing、Events、Chaos、Dashboard、Inspection
  • 故障演练：Apiserver 高可用故障演练、Etcd 高可用故障演练、双机房切换故障演练
  • 预案建设：Etcd 备份恢复、Velero 备份恢复、Master 节点紧急扩容、Etcd 节点紧急扩容、多集群故障迁移
  • 性能/容量评估：物理机性能压测、Master 组件性能压测、Etcd 性能压测、应用性能压测

• 节约成本

  • 推进无状态应用容器化
  • 推进无状态应用接入弹性伸缩
  • K8s 调度能力增强：预选、优选、重调度（使资源分配均匀、提高装箱率、提高资源使用率）
  • 持续进行应用容量治理：横向缩容（降副本数）、纵向缩容（降规格 CPU/MEM）
  • 建立资源画像：调度和容量治理依赖资源画像

• 提高效率（平台能力建设）

  • 自动化运维平台（面向开发）：容器生命周期管理、Ingress 生命周期管理、HPA 生命周期管理、扩缩容&升降配、容器资源预留、Java Dump & GCLog、屏蔽/恢复告警
  • 发布系统（面向开发）：Java/Nodejs/静态资源模版、自定义镜像、自定义模版、滚动发布、灰度发布、启动日志查看
  • 堡垒机（面向开发）：Web 终端、文件管理、日志审计
  • SRE 平台（面向运维）：集群安装、集群扩缩容、集群升级、插件安装、Ingress 节点扩缩容、Web Kubectl、集群自动化巡检、多集群迁移

  总结为下图，拿走不谢😏

  

容器化后无损上下线解决方案

说明： 本文主要以 Spring Cloud 应用举例

1. 背景

绝大数事故发生在应用上下线发布阶段，所以要尽可能避免发布过程中由于应用自身代码问题对用户造成的影响。

业界发布规范：

• 可灰度（可以通过 Argo Rollout/OpenKruise 支持）
• 可观测（容器状态、容器速查大盘、发布/配置变更/K8s 事件、业务日志/业务埋点、jstack/jvm/gc、链路，主要是通过指标、事件、日志、链路几大类进行收集分析，后续可观测性会介绍具体方案及关键指标收集/汇聚/展示）
• 可回滚（应用维度的快照回滚）