从0到1构建 Kubernetes中间件运维平台：标准化、可视化与全栈运维的最佳实践｜得物技术

一、项目背景

传统运维的痛点与挑战

在传统的中间件运维过程中，存在以下几个突出问题：

• 管理分散：不同中间件（ Kafka和Elasticsearch）都有独立的管理台，运维逻辑分散，难以形成统一规范。
• 成本高昂：运维操作与各自的管理台强绑定，SRE 需要学习不同工具，操作复杂，维护成本高。
• 黑屏操作依赖：很多关键运维操作需要依赖 kubectl apply 等黑屏命令，操作门槛高，风险大。

Kubernetes与Operator的优势

Kubernetes（K8s）和 Operator 提供了一套通用的运维管理机制，将中间件运维操作抽象成 Kubernetes CR（Custom Resource）对象，由 Operator 负责具体的运维执行。这种模式具备以下优势：

标准化：运维操作可以以 CR 为中心进行统一管理。

自动化：减少了人工干预，降低了人为失误的风险。

可视化：可以通过 UI 平台降低运维复杂度。

平台建设的核心目标

基于上述背景，我们决定建设一个统一的中间件运维平台，目标包括：

• 标准化：统一规范中间件的运维操作，沉淀最佳实践。
• 自动化：减少对黑屏操作的依赖，提升运维效率。
• 可视化：通过 UI 界面，让运维操作更加直观、简单。

二、建设历程

平台架构概览

在展开详细的建设内容前，我们先看看整体的架构设计。本架构图展示了白屏化运维平台的核心组成和各层之间的交互关系，帮助我们更直观地理解平台的整体运作逻辑和功能分布。

运维平台层的核心作用

运维平台层是整个白屏化运维平台的中枢大脑，承上启下，连接用户层与 Kubernetes 集群层，同时对接外部系统，确保运维操作的标准化、自动化和可审计。它的架构图如下：

运维平台的具体作用包括：

多云管理服务

• 统一托管来自不同云厂商的 Kubernetes 集群，确保多云环境下的资源可视化和统一调度。
• 为大规模中间件部署提供基础支撑，保障平台跨云高可用性。

中间件运维服务

• 负责对 Kafka 和 Elasticsearch 进行统一的部署、运维和管理，规范操作流程，降低运维复杂度。
• 提供可视化操作界面，降低 SRE 的操作门槛。

K8s 通用资源管理服务

• 统一管理 Kubernetes 中常见的资源，包括 Node（打标、污点管理）、PV（云盘释放）、PVC（生命周期管理）、SVC（服务暴露与管理）、Pod（日志查看、终端登录、CPU BURST）。
• 减少对黑屏命令的依赖，降低运维风险，提高操作效率。

YAML 管理服务

• 版本管理：提供 YAML 文件的版本控制功能，支持版本新增、修改、回滚 和 差异对比（Diff）。
• 变更可审计：所有 YAML 配置的变更都会被详细记录，确保每次配置变更都可追溯。
• 配置可视化：提供可视化 YAML 编辑界面，降低操作错误率。

操作审计服务

• 平台操作审计：对平台内所有运维操作进行详细记录，确保操作可追溯。
• 对接 DCheck：将审计数据传送至 DCheck 和NOC事件中心，进行合规性检查和安全监控，保障操作安全性和可控性。

运维平台层不仅是各类运维操作的执行中枢，更是数据流通的核心枢纽，负责将用户的运维请求转化为 Kubernetes 资源变更操作，同时记录和审计所有操作，确保系统的安全性和可追溯性。

接下来，我们将深入剖析这些核心服务，看看它们是如何在实际场景中解决痛点、提升效率的。

多云管理：跨云资源托管，告别kubeconfig切换地狱

故事背景

“Kubeconfig 切换地狱，谁用谁知道。”

小卡作为一名资深 SRE，每天都要在多个 Kubernetes 集群之间穿梭，管理不同环境下的资源。这些集群来自不同的云厂商，运行在不同的 Kubernetes 版本上，甚至还有不同的认证和网络策略。

• 传统方式：每个 Kubernetes 集群都需要一个对应的 kubeconfig 文件，存储在本地的 ~/.kube 目录中。
• 上下文切换：每次操作前，需要执行kubectl --kubeconfig=/path/to/kubeconfig，或者使用 kubectl config use-context 切换上下文。
• 风险高：当集群数量增多时，小卡根本记不清当前所操作的集群是 kubeconfig1 还是 kubeconfig2。有时候，为了省事，直接用 cp kubeconfig1 config，再去执行 kubectl 命令，完全忘记当前上下文对应哪个集群。
• 灾难场景：一不小心，将生产集群当成测试集群，直接执行了 kubectl delete pods --all，后果不堪设想。

痛点分析

多 kubeconfig 文件管理混乱

• 每个集群一个 kubeconfig，本地目录下文件堆积如山，管理成本高。
• 使用 kubectl config use-context 切换上下文，容易混淆当前所在的集群。

操作风险高

• 一旦操作上下文错误，轻则资源误删，重则导致生产事故。
• 缺乏有效的权限隔离和审计，无法追踪到具体的操作人和上下文。

跨云兼容性问题

• 每个云厂商的 Kubernetes 集群可能存在不同的 API 版本和兼容性问题。
• 手动管理多个 Kubernetes 版本的集群，风险和维护成本极高。

访问性能瓶颈

• Kubernetes API 请求频繁直接访问集群，容易导致延迟和性能瓶颈。
• 每次查询都需要访问 Kubernetes API，缺乏高效的缓存机制。

解决方案

根据运维同学的痛点，我们计划构建一个多云 Kubernetes 集群管理平台，实现跨云环境资源的统一托管、可视化管理与快速访问，避免 kubeconfig 切换带来的混乱和风险。效果图如下：

目标和行动拆解：

截至目前，平台已跨云托管了30+套Kubernetes集群。

中间件运维：Kafka 扩容，从黑屏脚本到白屏可视化

故事背景

“Kafka 扩容——一个让人捏把汗的运维操作”

凌晨三点，运维小卡的手机突然爆炸式震动起来，屏幕上跳出无数条报警消息：“Kafka 集群负载过高，CPU 使用率接近 100%！”

小卡揉了揉惺忪的睡眼，坐在电脑前打开黑屏终端，迅速敲下一连串熟练的命令：

kubectl --kubeconfig=k8s-xxx-prd get kafka

他屏住呼吸，盯着屏幕上的滚动字符，一行一行地检查 Kafka 集群状态，判断哪些节点资源吃紧，哪些副本需要扩容。然而，每次操作都让他倍感焦虑——“这可是生产环境啊，万一一行命令敲错，就要上新闻头条了！”

• 第一步：修改 YAML，spec.replicas +1。
• 第二步：轮询所有 Pod 状态，检查是否都变为 Running。
• 第三步：调用 Cruise-Control API，触发数据迁移。
• 第四步：轮询数据迁移状态，直到所有分区完成重新分配。

四步流程，看似简单，但每一步都需要小卡屏息凝神，稍有差错，就可能导致数据丢失，甚至集群崩溃。

“这种凌晨抢救场面，为什么不能更简单一点？”
小卡心里忍不住嘀咕。

传统 Kafka 扩容黑屏脚本

在中间件运维场景中，Kafka 集群扩容是一项典型的复杂运维任务。这不仅仅是一个简单的「增加节点」操作，还涉及到集群状态监控、资源调度、数据迁移等多个环节。

传统方式下，SRE 需要通过黑屏脚本完成扩容任务，整个过程不仅繁琐，还充满了不确定性。

以下是一个 Kafka 集群扩容的典型黑屏脚本示例：

#!/bin/bash

# 设置 kubeconfig
export KUBECONFIG=/path/to/kubeconfig

# 1. 检查 Kafka 集群状态
echo "Step 1: 查询 Kafka 集群状态"
kubectl get kafka -n kafka-