互动赠书 | 云上云下K8s多集群如何实现集群管理和安全治理的一致体验？

Posted 2021-11-02 阿里系统软件技术

本文将主要为您介绍如何实现对公共云 ACK 集群和数据中心自建 Kubernetes 集群一致体验的集群管理和安全治理。

作者｜郝树伟（流生）

以 Kubernetes 为代表的云原生技术不仅屏蔽了各个云厂商和数据中心在基础设施上的差异性，还使得应用可以在不同的云上使用标准化的方式描述和部署运行。在此基础之上，我们才可以低成本管理处于任何地理位置的 Kubernetes 集群。本文将主要为您介绍如何实现对公共云 ACK 集群和数据中心自建 Kubernetes 集群一致体验的集群管理和安全治理。

ACK 注册集群安全架构

要实现对公共云 ACK 集群和数据中心自建 Kubernetes 集群一致体验的集群管理和安全治理，就必须先将其统一到同一控制平面，ACK 注册集群允许处于任何地理位置的自建 Kubernetes 集群通过公网或私网（云上云下网络打通）连接端点接入阿里云容器服务管理系统。下面是 ACK 注册集群的架构示意图：

在 ACK 注册集群架构示意图中，主要包括以下几个组成部分：

• ACK 容器服务控制台。

• ACK 注册集群 Agent 组件：Agent 组件以 Deployment 的形式部署在自建 Kubernetes 集群中（或者其他云厂商的容器集群中），用于接收 ACK 注册集群 Stub 组件（使用 ACK 容器服务控制台或 ACK 注册集群 kubeconfig）下发的请求，并将其转发给目标集群的 Kubernetes API Server，同时接收 Kubernetes API Server的响应并将其发送回 Stub 组件。

• ACK 注册集群 Stub 组件：Stub组件部署的容器服务管控侧，每一个注册集群都对应一个 Stub 组件，用于代理转发 ACK 容器服务控制台或 ACK 注册集群 kubeconfig 访问集群产生的请求，转发到 Agent 组件并接收来自 Agent 组件的响应，最终返回响应到用户端。

• Kubernetes API Server：目标自建 Kubernetes 集群或其他云厂商容器集群的 Kubernetes API Server。

单向注册双向通信

前面我们提到，ACK 注册集群可以接入处于任何地理位置的自建 Kubernetes 集群，数据中心内自建的 Kubernetes 集群有一个特点就是通常情况下，这些自建集群处于一个受限的私有网络环境下，只能集群出公网访问外部环境。ACK 注册集群为了解决这个问题，将 Stub/Agent 组件设计为 Agent 主动单向注册到 Stub 组件，Agent 连接 Stub 时，会带上预先生成的 token 和证书等信息进行验证，整个通信链路采用 TLS 协议确保数据加密。

非“托管式”安全接入机制

通过 ACK 注册集群将自建 Kubernetes 集群接入到阿里云容器服务管控系统，用户最大的安全担忧就是自有集群访问权限的管理和控制，我们通过以下几点来保证用户对自有集群的绝对安全控制。

• ACK 管控侧不存储用户自有集群的任何秘钥信息。用户自建 Kubernetes 集群拥有自己的一套证书体系，如果 ACK 注册集群使用用户自建 Kubernetes 集群的 kubeconfig 对其进行访问，那么势必会造成用户集群访问权限的不可控。实际上，无论是从安全角度考虑，还是从管控侧一致性体验的角度考虑，都要求我们通过 ACK 注册集群来屏蔽管控侧与用户自建集群证书体系的差异性。那么具体的解法就是管控侧会使用 ACK 统一颁发的证书体系访问注册集群 Stub 组件，在 Stub 和 Agent 组件完成请求认证后，经由 Agent 以身份扮演的方式向目标 API Server作 7 层代理转发，最终在 API Server 完成请求的 RBAC 鉴权和审计，如下图所示。

• 集群访问权限的管控收敛到 Agent 组件。Agent 组件部署在用户自建集群中，ACK 管控侧通过 Stub/Agent 链路访问用户自建集群的权限收敛在 Agent 组件侧，这样可以保证用户对自有集群访问权限的全权控制。

• Agent 组件“非侵入式”部署。Agent 组件以 Deployment 的形式部署在自建 Kubernetes 集群中，不对自建集群做任何更改和操作，后续会将 Agent 组件的源码开源出来。

• 支持开启安全审计。用户可以在注册集群中开启安全审计功能，任何对集群的操作都可以进行查询和审计。

一致体验的集群管理

假设当前用户 A 已经在公共云创建了一个 ACK 集群，在数据中心内创建了一个自建 Kubernetes 集群，那么如何使用一致的体验来管理这两个处于不同云环境的 Kubernetes 集群呢？很简单，创建一个 ACK 注册集群并接入自建集群即可。

创建 ACK 注册集群

我们只需在 ACK 容器服务控制台创建注册集群页面选择离自建 Kubernetes 集群地理位置最近的区域并配置 VPC 网络和安全组，3 分钟即可完成注册集群的创建，如下图所示。

集群详情页面可以看到连接信息中分别有一个用于公网接入和私网接入自建 Kubernetes 集群的集群导入代理配置，如下图所示：

接入自建 Kubernetes 集群

在自建 Kubernetes 集群中部署上述集群导入代理配置：

$ kubectl apply -f agent.yaml

agent 组件运行正常后，我们就可以在 ACK 容器服务控制台查看集群列表，如下图所示，名为 ack 的集群为 ACK 托管版集群，Kubernete 版本为 1.20.4-aliyun.1，名为 idc-k8s 的集群为 ACK 注册集群，接入的是用户自建的 Kubernetes 集群，Kubernetes版本为 1.19.4。

使用注册集群 idc-k8s 即可管理自建 Kubernetes 集群，集群概览信息和节点列表信息如下图所示。

接下来，用户就可以通过 ACK 容器服务控制台，使用一致体验来对云上云下集群进行集群管理、节点管理、应用管理和运维等操作。

一致体验的安全治理

在使用不同云平台上的 Kubernetes 集群时，不同云平台的安全治理能力和安全策略配置及管理方式也都不尽相同，这种参差不齐的安全治理能力会导致运维团队在定义用户角色、访问权限的时候都每个云平台的安全管理机制都十分熟悉，如果管理和安全访问控制能力不足，则非常容易出现角色违规、访问管理风险等问题。

例如，在一个各种项目都在使用 Kubernetes 容器集群，且容器集群属于不同的云平台的场景下，管理员需要能够将所有用户和他们的活动都引导到对应的容器集群，这样才能知道谁在什么时候做了什么，你可能会遇到有多个账户需要分别设置不同的访问层级，或者有越来越多的人加入、离开、变换团队和项目的情况，如何管理这些用户的权限会变得越来越复杂。

ACK 注册集群从以下几个方面为自建 Kubernetes 集群提供安全治理能力一致性体验。

使用阿里云主子账号认证体系和 Kubernetes RBAC 鉴权体系管理集群访问控制

假设当前企业内有 2 个不同工作职责的用户，分别是开发人员 testuser01，测试人员 testuser02，那么管理员就可以为开发和测试人员创建子账号 testuser01 和 testuser02，接下来根据开发测试人员工作职责的不同，分配 ack 集群和 idc-k8s 集群的以下权限：

• 开发人员 testuser01，授予 ack 集群所有命名空间的读写权限，授予 idc-k8s 集群test 命名空间的读写权限。

• 测试人员testuser02，只授予idc-k8s集群test命名空间的读写权限。

使用主账号为开发人员 testuser01 和测试人员 testuser02 授权，在ACK容器服务控制台授权管理中选择对应的 testuser01 和 testuser02 子账号，授权配置分别如下图所示：

按照向导完成 testuser01 和 testuser02 的授权后，使用子账号 testuser01 登录容器服务控制台可以测试 testuser01 对 ack 集群所有命名空间拥有读写权限，只对 idc-k8s 集群test命名空间拥有读写权限。

使用子账号 testuser02 登录容器服务控制台可以测试 testuser02 看不到 ack 集群，且只对 idc-k8s 集群 test 命名空间拥有读写权限。

集群审计

在 Kubernetes 集群中，API Server 的审计日志可以帮助集群管理人员记录或追溯不同用户的日常操作，是集群安全运维中重要的环节。在注册集群中可以使用集群审计功能帮助用户可视化追溯不同用户的日常操作。

下面是自建 Kubernetes 集群的日志审计示例。

配置巡检

配置巡检功能可以用来扫描集群中 Workload 配置的安全隐患，提供巡检详情和报告，对结果进行分析解读，帮助用户实时了解当前状态下运行应用的配置是否有安全隐患。

下面是自建 Kubernetes 集群的巡检详情示例。

作者简介

郝树伟（流生），阿里云容器服务技术专家，云原生分布式云团队核心成员，专注于云原生多集群的统一管理和调度、混合集群、应用交付和迁移等云原生技术的研究。

点击下方链接，查看相关视频解读~
https://www.bilibili.com/video/BV1WU4y1c7x7/

PingCAP Clinic 服务：贯穿云上云下的 TiDB 集群诊断服务

伴随着 TiDB 6.0 的发布，PingCAP Clinic 服务也揭开了她的面纱，提供 Tech Preview 版本给广大用户试用。 Clinic 服务源于 TiDB Cloud， 以智能诊断提升 TiDB Cloud SLA ，以 AIOPS 方式降低 TiDB Cloud 成本；同时 Clinic 也会将 Cloud 中积累的诊断经验、运维最佳实践以诊断服务方式提供给本地部署的集群，使所有的云下用户也从中受益。

本次发布的 Tech Preview 版本，对本地部署的用户提供了诊断数据的快速采集和诊断环境的线上复现，当 TiDB 集群遇到问题，邀请 PingCAP 技术支持人员协助远程定位时，或者在 AskTUG 社区提问时，通过 Clinic 服务采集并上传诊断数据，将大大加快问题定位的速度。

Clinic 在 TiDB Cloud 中的应用

小吴是 TiDB Cloud 的技术工程师，在协助 TiDB Cloud 用户进行 POC 时，需要实时关注客户集群的健康状态和各种监控指标，根据客户的业务压力指标，推荐最优的集群拓扑配置和数据库参数配置；当用户集群出现异常时，及时分析并解决问题，保证集群 SLA。

Clinic 诊断场景

小吴登录到 Clinic 诊断服务，可以快速查询到用户所在集群的各个时间段的诊断数据。Clinic 将 TiDB Cloud 平台上的日志、监控指标等诊断数据实时导出、安全存储，并提供可视化的展示。

除了基础查看以外，Clinic 还提供智能分析。

智能分析延迟问题

某个用户抱怨这段时间的延迟突然变大了，小吴同学会很直觉地去找在系统哪个环节哪个实例中耗时更大，这似乎不是一件很难的事情，但是他需要在各个 Grafana 面板之间反复横跳地查找瓶颈，并从中众多节点中找出一个问题节点，这是一件费时费力并且考验耐心的工作。 Clinic 诊断服务的智能分析很贴心地直接为小吴准备好了结果如下： 

在诊断延迟变大问题时，识别当前的负载类型也是一个重要的步骤。如果只是单单看读写的比例可能还好，但是如果要看哪个实例间的读写不平衡度呢？现在有些用户集群的 TiKV 实例已经达到数十甚至上百，想要分析这些实例上的读写不平衡，几乎是一件不适宜人眼工作的事情。但对于机器来说，计算这些并不是一个难事，Clinic 会结合上述问题时间段(比如延迟升高时)，给出这段时间内不平衡度与平时（基线数据）的区别。下图是一个智能分析输出的例子： 

从上图的分析上可以看出，在问题时间段内，点读请求和 coprocessor 读请求比平时上升，小吴可以根据这个线索继续定位。

智能日志聚类分析

小吴同学除了分析 Metrics ，也要对集群日志进行分析查看。咱们 TiDB 集群的日志量是相当惊人的，组件再正交上实例，这个工作量也是非常大的。Clinic 提供智能日志聚类，帮助小吴同学在海量的日志中快速发现问题。

日志聚类将每个时间段内的不同日志的趋势以可视化的方式展示，哪类日志的数量发生了突变，哪个实例的日志数量发生了突变，小吴同学一目了然，抓大放小，迅速聚焦到主要矛盾上。从下图来看，当前时间段，TiDB 集群处理最多的是红框中的两件事，数量占比多的可以考虑优先排查。 

TiDB Cloud 场景小结

Clinic 的智能诊断还处于初级阶段，在近期还会有更多的分析模型上线并应用到 TiDB Cloud 的诊断中，在实战中不断的训练模型，输出高准确率的问题判断规则，提前发现集群风险点，提高问题修复速度，从而不断提升 TiDB Cloud 服务的 SLA。

Try TiDB Cloud

适用于中国出海企业和开发者

下载 TiDB 社区版

咨询 TiDB 企业版

Clinic 助力云下本地部署集群的问题诊断

Clinic 诊断服务在 TiDB Cloud 上为小吴带来了巨大的帮助，我们把 Clinic 的功能也提供给本地部署的集群，让云下集群也能使用该功能进行问题诊断，这样可以大大加速用户问题的解决。

在 Tech Preview 阶段，Clinic 中数据导出、诊断环境重建的功能开放给了本地部署的集群。当本地部署的TiDB集群遇到问题，邀请 PingCAP 技术支持人员协助远程定位时，或者在 AskTUG 社区提问时，通过 Clinic 服务采集并上传诊断数据，将大大加快问题定位的速度。

注意： Clinic 的智能分析相关功能暂时未在 Tech Preview 阶段开放给本地部署的集群。我们需要在 TiDB Cloud 中做更多的数据训练，当分析模型的准确度和计算成本都达到一定标准后，即会对云下的集群开放。

数据采集和上传

小宇是 TiDB 集群的 DBA，近期集群接入了一个新的上层业务，集群出现性能问题， 小宇向 PingCAP 技术支持上报了问题，期望能尽快得到优化的建议。

在以往的类似场景中，上报问题以后，PingCAP 技术支持会要求小宇上传各种诊断信息，小宇需要去集群上手动执行多个复杂的命令，包括抓取各个节点的日志文件、使用 Metrics Tool 逐个 Dashboard 保存数据等，一套采集、沟通和传送数据，往往就花了大半天时间。如今 PingCAP 技术支持同学建议小宇使用 Clinic 的采集工具，只需要一条命令，快速完成数据采集，然后直接上传数据分享给技术支持。

小宇运行一条简单的命令，就能采集最近 2 小时的集群各节点日志、metrics、配置项、硬件参数信息：

tiup diag collect $cluster-name

采集完成后，直接上传至 Clinic 服务：

tiup diag upload $filepath 

Clinic 的诊断环境复现

数据上传后，小宇登录 Clinic，就能可视化的查看自己的诊断数据。将数据链接分享给 PingCAP 技术支持以后，PingCAP 技术专家也能立即查看全面的诊断数据，加速问题定位。

查看 Metrics

支持在线查看 Metrics，提供多个 Grafana Dashboard 模板以方便查看。 

查看日志

支持在线查看日志，可以通过各种过滤条件高效查看日志。 

查看慢查询

支持在线查看慢查询信息，与在集群内部的 TiDB Dashboard 上看到的信息一致。 

Clinic 的未来

Clinic 服务的发布，代表 PingCAP 会在保证数据库的健康运行方面持续地投入，Clinic 的最终愿景是通过 TiDB Cloud 的技术积淀，整体提升云上云下 TiDB 集群的稳定性，降低运维成本，让数据库的运维更简单。

Clinic 服务后续发展的方向主要集中在这几点：

• 云上云下兼顾：Clinic 服务始终坚持在云上做技术沉淀，将云上积累的经验通过诊断服务、运维服务的方式提供给云下集群 ，让所有部署类型的集群都受益。
• AI for DB：Clinic 服务使用最新的 AI 技术，由数据库领域专家和 AI 领域专家深入合作进行模型建立和训练，最大限度地借助 AI 能力进行问题预判、问题诊断和根因排查。
• 数据库自治服务：Clinic 服务逐步实现数据库自预判、自优化、自修复，以自治的方式替代人工运维操作，帮助用户消除数据库管理的复杂性及人工操作引发的服务故障，及时分析并解决问题，保证集群稳定运行。