我叫 Viktor Yagofarov，作为 Ops（运营）团队的技术开发经理，正在 DomClick 开发 Kubernetes 平台。 我想谈谈我们的 Dev <-> Ops 流程的结构、运行俄罗斯最大的 k8s 集群之一的功能，以及我们团队应用的 DevOps/SRE 实践。
运营团队
Ops 团队目前有 15 人。 其中三人负责办公室，两人在不同时区工作，并且可以在晚上工作。 因此，运营部门的人员始终处于监控状态，随时准备对任何复杂的事件做出响应。 我们没有夜班，这保护了我们的精神，让每个人都有机会获得充足的睡眠，度过闲暇时间，而不仅仅是在电脑前。
每个人都有不同的能力：网络人员、DBA、ELK 堆栈专家、Kubernetes 管理员/开发人员、监控、虚拟化、硬件专家等。 有一件事将每个人团结在一起 - 每个人都可以在某种程度上取代我们中的任何一个人：例如，将新节点引入 k8s 集群、更新 PostgreSQL、编写 CI/CD + Ansible 管道、在 Python/Bash/Go 中自动化某些操作、将硬件连接到数据中心。 在任何领域的强大能力都不会阻止您改变活动方向并开始在其他领域取得进步。 例如，我作为 PostgreSQL 专家加入了一家公司，现在我的主要职责领域是 Kubernetes 集群。 在团队中，任何身高都是受欢迎的，杠杆意识非常发达。
顺便说一下，我们正在打猎。 对候选人的要求非常标准。 对我个人来说，一个人融入团队、不发生冲突、但也知道如何捍卫自己的观点、想要发展、不害怕做新事物、提出自己的想法，这一点很重要。 此外，还需要脚本语言的编程技能、Linux 基础知识和英语知识。 需要英语只是为了让发生 Fakap 的人可以在 10 秒内而不是 10 分钟内通过谷歌搜索到问题的解决方案。 现在很难找到对 Linux 有深入了解的专家：这很有趣，但三分之二的候选人无法回答“什么是平均负载？”这个问题。 它是由什么组成的？”，而“如何从 C 程序组装核心转储”这个问题被认为是来自超人……或恐龙世界的问题。 我们必须忍受这一点，因为通常人们都具有高度发展的其他能力，但我们将教授 Linux。 “为什么 DevOps 工程师需要了解现代云世界中的所有这些”这个问题的答案必须超出本文的范围，但用三个词来说：所有这些都是需要的。
团队工具
工具团队在自动化方面发挥着重要作用。 他们的主要任务是为开发人员创建方便的图形和 CLI 工具。 例如，我们的内部开发 Confer 允许您只需点击几下鼠标即可将应用程序部署到 Kubernetes，配置其资源、来自保管库的密钥等。 以前有 Jenkins + Helm 2，但我必须开发自己的工具来消除复制粘贴并为软件生命周期带来统一性。
Ops 团队不为开发人员编写管道，但可以就他们编写的任何问题提供建议（有些人仍然使用 Helm 3）。
DevOps的
对于 DevOps，我们是这样看待的：
开发团队编写代码，通过 Confer to dev -> qa/stage -> prod 将其推出。 确保代码不会变慢并且不包含错误的责任在于开发和运营团队。 白天，Ops 团队的值班人员应首先通过应用程序响应事件，而在晚上和晚上，值班管理员（Ops）应在发现值班开发人员知道情况后叫醒他。确保问题不在基础设施中。 监控中的所有指标和警报都会自动或半自动出现。
Ops 的职责范围从应用程序投入生产的那一刻起就开始了，但 Dev 的职责并没有就此结束——我们做同样的事情，同舟共济。
开发人员如果需要帮助编写管理微服务（例如，Go 后端 + HTML5），可以向管理员提供建议，管理员可以就任何基础设施问题或与 k8s 相关的问题向开发人员提供建议。
顺便说一句，我们根本没有单体应用，只有微服务。 如果按数量来衡量，到目前为止，它们的数量在 prod k900s 集群中波动在 1000 到 8 之间 部署。 pod 数量在 1700 到 2000 之间波动。目前 prod 集群中有大约 2000 个 pod。
我无法给出确切的数字，因为我们会监控不必要的微服务并半自动地删除它们。 K8s 帮助我们跟踪不必要的实体 ，从而节省大量资源和金钱。
资源管理
监控
结构良好且信息丰富的监控成为大型集群运行的基石。 我们尚未找到能够满足 100% 所有监控需求的通用解决方案，因此我们定期在此环境中创建不同的自定义解决方案。
- ZABBIX。 良好的旧式监控，主要用于跟踪基础设施的整体状况。 它告诉我们节点何时在处理、内存、磁盘、网络等方面死亡。 没什么超自然的，但我们还有一个单独的 DaemonSet 代理，例如，在它的帮助下，我们监视集群中 DNS 的状态：我们寻找愚蠢的 coredns pod，我们检查外部主机的可用性。 看起来为什么要为此烦恼，但对于大量流量，该组件是一个严重的故障点。 我已经 ，我如何在集群中与 DNS 性能作斗争。
- 普罗米修斯算子。 一组不同的导出器提供了集群所有组件的总体概览。 接下来，我们在 Grafana 的大型仪表板上可视化所有这些，并使用 Alertmanager 进行警报。
对我们来说另一个有用的工具是 。 我们在多次遇到一个团队与另一个团队的 Ingress 路径重叠、导致 50 倍错误的情况后编写了它。 现在，在部署到生产环境之前，开发人员会检查是否没有人会受到影响，对于我的团队来说，这是一个很好的工具，用于初步诊断 Ingress 问题。 有趣的是，一开始它是为管理员编写的，看起来相当“笨拙”，但在开发团队爱上这个工具之后，它发生了很大的变化，开始看起来不像“管理员为管理员制作了一个网页界面”。 ” 很快我们将放弃这个工具，甚至在管道推出之前，这种情况就会得到验证。
Cube 中的团队资源
在我们进入示例之前，有必要解释一下我们如何分配资源 微服务.
了解哪些团队以及使用的数量 资源 （处理器、内存、本地 SSD），我们为每个命令分配自己的 命名空间 在“立方体”中，并限制其在处理器、内存和磁盘方面的最大能力，之前已经讨论了团队的需求。 因此，一般来说，一个命令不会阻塞整个集群的部署，分配数千个核心和 TB 的内存。 对命名空间的访问是通过 AD 授予的（我们使用 RBAC）。 命名空间及其限制通过拉取请求添加到 GIT 存储库，然后所有内容都会通过 Ansible 管道自动推出。
为团队分配资源的示例：
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
要求和限制
立方” 请求 是保证保留资源的数量 荚 （一个或多个 docker 容器）在一个集群中。 限制是无保证的最大值。 您经常可以在图表中看到某些团队如何为其所有应用程序设置过多的请求，并且无法将应用程序部署到“Cube”，因为其命名空间下的所有请求都已“用完”。
解决这种情况的正确方法是查看实际的资源消耗并将其与请求量（Request）进行比较。
在上面的屏幕截图中，您可以看到“请求的”CPU 与实际线程数相匹配，并且限制可以超过 CPU 线程的实际数量 =)
现在让我们详细查看一些命名空间（我选择命名空间 kube-system - “Cube”本身组件的系统命名空间）并查看实际使用的处理器时间和内存与请求的比率：
很明显，为系统服务保留的内存和 CPU 比实际使用的要多得多。 在 kube-system 的情况下，这是合理的：nginx 入口控制器或 nodelocaldns 在其峰值时会占用 CPU 并消耗大量 RAM，因此这里这样的保留是合理的。 此外，我们不能依赖过去 3 小时的图表：希望看到很长一段时间内的历史指标。
开发了“建议”系统。 例如，在这里您可以看到哪些资源最好提高“限制”（允许的上限），以便不会发生“限制”：资源在分配的时间片内已经消耗了 CPU 或内存的时刻，并且正在等待“解冻”：
以下是可以抑制他们食欲的豆荚：
Про 节流 + 资源监控，你可以写多篇文章，所以在评论中提出问题。 简而言之，我可以说自动化此类指标的任务非常困难，需要大量时间并平衡“窗口”函数和“CTE”Prometheus / VictoriaMetrics（这些术语用引号引起来，因为几乎有PromQL 中没有类似的情况，您必须将可怕的查询划分为多个文本屏幕并对其进行优化）。
因此，开发人员可以使用工具来监控 Cube 中的命名空间，并且可以自行选择何时何地哪些应用程序可以“削减”资源，以及哪些服务器可以整晚获得整个 CPU 的使用权。
方法论
在现在的公司里 时髦，我们坚持 DevOps-并且 SRE-从业者当一家公司拥有 1000 个微服务、大约 350 名开发人员和 15 名管理员负责整个基础设施时，你必须“变得时尚”：在所有这些“基本词”的背后，迫切需要自动化一切和每个人，而管理员不应该成为瓶颈流程。
作为运营人员，我们为开发人员提供与服务响应率和错误相关的各种指标和仪表板。
我们使用的方法例如： , и 将它们组合在一起。 我们尝试最大程度地减少仪表板数量，以便一目了然地了解当前正在降级的服务（例如，每秒响应代码、第 99 个百分位的响应时间）等等。 一旦通用仪表板需要一些新指标，我们就会立即绘制并添加它们。
我已经一个月没有画图表了。 这可能是一个好兆头：这意味着大部分“愿望”已经实现。 碰巧这周我每天至少会画一些新图表。
由此产生的结果很有价值，因为现在开发人员很少向管理员询问“在哪里查看某种指标”的问题。
引进 服务网格 即将到来，应该会让每个人的生活变得更加轻松，Tools 的同事已经接近实现抽象的“健康人的 Istio”：每个 HTTP(s) 请求的生命周期将在监控中可见，并且在服务间（而不仅仅是）交互过程中，始终可以了解“一切都在什么阶段发生了故障”。 订阅来自 DomClick 中心的新闻。 =)
Kubernetes 基础设施支持
历史上，我们使用修补版本 库贝喷雾 — 用于部署、扩展和更新 Kubernetes 的 Ansible 角色。 在某些时候，主分支切断了对非 kubeadm 安装的支持，并且没有提出切换到 kubeadm 的过程。 因此，南桥公司制作了自己的分叉（具有 kubeadm 支持和关键问题的快速修复）。
更新所有 k8s 集群的过程如下所示：
- 我们拿 库贝喷雾 来自南桥，请查看我们的线程，Merjim。
- 我们正在推出更新 应力- “立方体”。
- 我们一次推出一个节点的更新（在 Ansible 中这是“serial: 1”） 开发- “立方体”。
- 我们更新 刺 周六晚上一次一个节点。
未来有计划更换 库贝喷雾 想要更快的东西，请访问 库贝德姆.
我们总共有三个“立方体”：压力、开发和生产。 我们正计划推出另一项（双机热备) 第二个数据中心的产品-“立方体”。 应力 и 开发 生活在“虚拟机”中（用于压力的 oVirt 和用于开发的 VMWare 云）。 刺- “Cube”依赖于“裸机”：这些是相同的节点，具有 32 个 CPU 线程、64-128 GB 内存和 300 GB SSD RAID 10 - 总共有 50 个。 三个“瘦”节点专属于“大师” 刺- “古巴”：16 GB 内存，12 个 CPU 线程。
对于销售，我们更喜欢使用“裸机”并避免不必要的层，例如 OpenStack的：我们不需要“吵闹的邻居”和CPU 偷时间。 对于内部 OpenStack，管理的复杂性大约增加了一倍。
对于 CI/CD “Cubic” 和其他基础设施组件，我们使用单独的 GIT 服务器 Helm 3（这是从 Helm 2 的一个相当痛苦的过渡，但我们对这些选项非常满意） 原子）、Jenkins、Ansible 和 Docker。 我们喜欢功能分支并从一个存储库部署到不同的环境。
结论
一般来说，从运维工程师的角度来看，DomClick 的 DevOps 流程就是这样的。 这篇文章的技术含量比我预期的要低：因此，请关注 Habré 上的 DomClick 新闻：将会有更多关于 Kubernetes 等的“硬核”文章。
来源： habr.com