扩展组件

• 1: TApp 介绍
• 2: CronHPA 介绍
• 3: 监控组件
• 4: LogAgent 介绍
• 5: GPUManager 介绍
• 6: CSIOperator 介绍

1 - TApp 介绍

TApp 介绍

Kubernetes 现有应用类型（如：Deployment、StatefulSet等）无法满足很多非微服务应用的需求。比如：操作（升级、停止等）应用中的指定 Pod；应用支持多版本的 Pod。如果要将这些应用改造为适合于这些 Workload 的应用，需要花费很大精力，这将使大多数用户望而却步。

为解决上述复杂应用管理场景，TKEStack 基于 Kubernetes CRD 开发了一种新的应用类型 TApp，它是一种通用类型的 Workload，同时支持 service 和 batch 类型作业，满足绝大部分应用场景，它能让用户更好的将应用迁移到 Kubernetes 集群。

TApp 架构

TAPP 其结构定义见 TAPP struct。TApp Controller 是 TApp 对应的Controller/operator，它通过 kube-apiserver 监听 TApp、Pod 相关的事件，根据 TApp 的 spec 和 status 进行相应的操作：创建、删除pod等。

TApp 使用场景

Kubernetes 凭借其强大的声明式 API、丰富的特性和可扩展性，逐渐成为容器编排领域的霸主。越来越多的用户希望使用 Kubernetes，将现有的应用迁移到 Kubernetes 集群，但 Kubernetes 现有 Workload（如：Deployment、StatefulSet等）无法满足很多非微服务应用的需求，比如：操作（升级、停止等）应用中的指定 Pod、应用支持多版本的 Pod。如果要将这些应用改造为适合于这些 Workload的应用，需要花费很大精力，这将使大多数用户望而却步。

腾讯有着多年的容器编排经验，基于 Kuberentes CRD（Custom Resource Definition，使用声明式API方式，无侵入性，使用简单）开发了一种新的 Workload 类型 TApp，它是一种通用类型的 Workload，同时支持 service 和 batch 类型作业，满足绝大部分应用场景，它能让用户更好的将应用迁移到 Kubernetes 集群。如果用 Kubernetes 的 Workload 类比，TAPP ≈ Deployment + StatefulSet + Job ，它包含了 Deployment、StatefulSet、Job 的绝大部分功能，同时也有自己的特性，并且和原生 Kubernetes 相同的使用方式完全一致。经过这几年用户反馈， TApp 也得到了逐渐的完善。

TApp 特点

1. 同时支持 service 和 batch 类型作业。通过 RestartPolicy 来对这两种作业进行区分。RestartPolicy值有三种：RestartAlways、Never、OnFailure
   1. RestartAlways：表示 Pod 会一直运行，如果结束了也会被重新拉起（适合 service 类型作业）
   2. Never：表示 Pod 结束后就不会被拉起了（适合 batch 类型作业）
   3. OnFailure：表示 Pod 结束后，如果 exit code 非0，将会被拉起，否则不会（适合 batch 类型作业）
2. 固定ID：每个实例（Pod）都有固定的 ID(0, 1, 2 … N-1，其中N为实例个数)，它们的名字由 TApp 名字+ID 组成，因此名字也是唯一的。 有了固定的ID和名字后，我们便可以实现如下能力：
   1. 将实例用到的各种资源（将实例用到的存储资源(如：云硬盘)，或者是IP）和实例一一对应起来，这样即使实例发生迁移，实例对应的各种资源也不会变
   2. 通过固定 ID，我们可以为实例分配固定的 IP（float ip）。
   3. 唯一的实例名字还可用来跟踪实例完整的生命周期，对于同一个实例，可以由于机器故障发生了迁移、重启等操作，虽然不是一个 Pod 了，但是我们用实例 ID 串联起来，就获得了实例真正的生命周期的跟踪，对于判断业务和系统是否正常服务具有特别重要的意义
3. 操作指定实例：有了固定的 ID，我们就能操作指定实例。我们遵循了 Kubernetes 声明式的 API，在 spec 中 statuses 记录实例的目标状态， instances 记录实例要使用的 template，用于停止、启动、升级指定实例。
4. 支持多版本实例：在 TApp spec 中，不同的实例可以指定不同的配置（image、resource 等）、不同的启动命令等，这样一个应用可以存在多个版本实例。
5. 原地更新(in place update)：Kubernetes 的更新策略是删除旧 Pod，新建一个 Pod，然后调度等一系列流程，才能运行起来，而且 Pod原先的绑定的资源（本地磁盘、IP 等）都会变化。TApp 对此进行了优化：如果只修改了 container 的 image，TApp 将会对该 Pod 进行本地更新，原地重启受影响的容器，本地磁盘不变，IP 不变，最大限度地降低更新带来的影响，这能极大地减少更新带来的性能损失以及服务不可用。
6. 云硬盘：云硬盘的底层由分布式存储 Ceph 支持，能很好地支持有状态的作业。在实例发生跨机迁移时，云硬盘能跟随实例一起迁移。TApp 提供了多种云硬盘类型供选择。
7. 多种升级发布方式：TApp除了支持常规的蓝绿布署、滚动发布、金丝雀部署等升级发布方式，还有其特有的升级发布方式：用户可以指定升级任意的实例。
8. 自动扩缩容：根据 CPU/MEM/用户自定义指标对 TAPP 进行自动扩缩容。 除了自动扩缩容，我们还开发了周期性扩缩容 CronHPA 支持对 TApp 等(包括 Kubernetes 原生的 Deployment 和 StatefulSet)进行周期性扩缩容，支持 CronTab 语法格式，满足对资源使用有周期性需求的业务。
9. Gang scheduling：有些应用必须要等到获取到资源能运行的实例达到一定数量后才开始运行，TApp 提供的 Gang scheduling 正是处理这种情况的。

部署在集群内 kubernetes 对象

在集群内部署 TApp Add-on , 将在集群内部署以下 kubernetes 对象

TApp 使用方法

安装 TApp 组件

• 登录 TKEStack
• 切换至 平台管理 控制台，选择扩展组件页面
• 选择需要安装组件的集群，点击【新建】按钮。如下图所示：

• 在弹出的扩展组件列表里，滑动列表窗口找到tapp组件。如下图所示：

• 单击【完成】

  安装完成后会在刚刚安装了 TApp 扩展组件的集群里 【工作负载】下面出现【TApp】，如下图所示：

使用 TApp 组件

在 TKEStack 控制台上使用 TApp 使用请参考：TApp Workload

对 TApp 架构和命令行使用请参考：TApp Repository

参考

手动部署 TApp

git clone https://github.com/tkestack/tapp.git
cd tapp
make build
bin/tapp-controller --kubeconfig=$HOME/.kube/config

原地升级

修改 spec.templatePool.{templateName}.spec.containers.image 的值实现原地升级。

挂在存储卷后的 Pod 依旧在 image 升级的时候没有任何影响，同时 PVC 也没有改变，唯一改变的只有镜像本身。

部分关键字解释

apiVersion: apps.tkestack.io/v1
kind: TApp
metadata:
  name: example-tapp
spec:
  replicas: 3
  # 默认模板
  template:
    metadata:
      labels:
        app: example-tapp
    spec:
      containers:
      - name: nginx
        image: nginx:latest
  # 模板池
  templatePool:
  	# 模板池中的模板
    "test2":
      metadata:
        labels:
          app: example-tapp
      spec:
        containers:
        - name: nginx
          image: nginx:1.7.9
  # 要使用模板池中模板的 Pod
  templates:
    # Pod 序号：模板池中的模板
    "1": "test2"
    "2": "test2"
  # 更新策略
  updateStrategy:
    # 更新指定模板。test2该模板有过修改，或者是在模板池里新增的，都可以通过 updateStrategy 设置模板来进行滚动更新
    template: test2
    # 使用该模板的 Pod 在更新时最大不可用的数量
    maxUnavailable: 1
  # 明确 Pod 的状态，TApp 会实现该状态
  statuses:
    # 编号为1的 Pod 将被 Kill
    "1": "Killed"

2 - CronHPA 介绍

CronHPA 介绍

Cron Horizontal Pod Autoscaler(CronHPA) 可让用户利用 CronTab 实现对负载（Deployment、StatefulSet、TApp 这些支持扩缩容的资源对象）定期自动扩缩容。

CronTab 格式说明如下：

# 文件格式说明
#  ——分钟（0 - 59）
# |  ——小时（0 - 23）
# | |  ——日（1 - 31）
# | | |  ——月（1 - 12）
# | | | |  ——星期（0 - 6）
# | | | | |
# * * * * *

CronHPA 定义了一个新的 CRD，cron-hpa-controller 是该 CRD 对应的 Controller/operator，它解析 CRD 中的配置，根据系统时间信息对相应的工作负载进行扩缩容操作。

CronHPA 使用场景

以游戏服务为例，从星期五晚上到星期日晚上，游戏玩家数量暴增。如果可以将游戏服务器在星期五晚上扩大规模，并在星期日晚上缩放为原始规模，则可以为玩家提供更好的体验。这就是游戏服务器管理员每周要做的事情。

其他一些服务也会存在类似的情况，这些产品使用情况会定期出现高峰和低谷。CronHPA 可以自动化实现提前扩缩 Pod，为用户提供更好的体验。

部署在集群内 kubernetes 对象

在集群内部署 CronHPA Add-on , 将在集群内部署以下 kubernetes 对象：

CronHPA 使用方法

安装 CronHPA

• 登录 TKEStack
• 切换至【平台管理】控制台，选择【扩展组件】页面
• 选择需要安装组件的集群，点击【新建】按钮，如下图所示：

• 在弹出的扩展组件列表里，滑动列表窗口找到 CronHPA 组件
• 单击【完成】

在控制台上使用 CronHPA

TKEStack 已经支持在页面多处位置为负载配置 CronHPA

• 新建负载页（负载包括Deployment、StatefulSet、TApp）这里新建负载时将会同时新建与负载同名的 CronHPA 对象：

每条触发策略由两条字段组成

1. Crontab ：例如 “0 23 * * 5"表示每周五23:00，详见crontab
2. 目标实例数 ：设置实例数量

• 自动伸缩的 CronHPA 列表页。此处可以查看/修改/新建 CronHPA：

通过 YAML 使用 CronHPA

创建 CronHPA 对象

示例1：指定 Deployment 每周五20点扩容到60个实例，周日23点缩容到30个实例

apiVersion: extensions.tkestack.io/v1
kind: CronHPA
metadata:
  name: example-cron-hpa	# CronHPA 名
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment	# CronHPA 操作的负载类型
    name: demo-deployment	# CronHPA 操作的负载类型名
  crons:
    - schedule: "0 20 * * 5"	# Crontab 语法格式
      targetReplicas: 60			# 负载副本（Pod）的目标数量
    - schedule: "0 23 * * 7"
      targetReplicas: 30

示例2：指定 Deployment 每天8点到9点，19点到21点扩容到60，其他时间点恢复到10

apiVersion: extensions.tkestack.io/v1
kind: CronHPA
metadata:
  name: web-servers-cronhpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-servers
  crons:
    - schedule: "0 8 * * *"
      targetReplicas: 60
    - schedule: "0 9 * * *"
      targetReplicas: 10
    - schedule: "0 19 * * *"
      targetReplicas: 60
    - schedule: "0 21 * * *"
      targetReplicas: 10

查看已有 CronHPA

# kubectl get cronhpa
NAME               AGE
example-cron-hpa   104s

# kubectl get cronhpa example-cron-hpa -o yaml
apiVersion: extensions.tkestack.io/v1
kind: CronHPA
...
spec:
  crons:
  - schedule: 0 20 * * 5
    targetReplicas: 60
  - schedule: 0 23 * * 7
    targetReplicas: 30
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: demo-deployment

删除已有 CronHPA

kubectl delete cronhpa example-cron-hpa

CronHPA 项目请参考 CronHPA Repository

3 - 监控组件

Prometheus

良好的监控环境为 TKEStack 高可靠性、高可用性和高性能提供重要保证。您可以方便为不同资源收集不同维度的监控数据，能方便掌握资源的使用状况，轻松定位故障。

TKEStack 使用开源的 Prometheus 作为监控组件，免去您部署和配置 Prometheus 的复杂操作，TKEStack 提供高可用性和可扩展性的细粒度监控系统，实时监控 CPU，GPU，内存，显存，网络带宽，磁盘 IO 等多种指标并自动绘制趋势曲线，帮助运维人员全维度的掌握平台运行状态。

TKEStack 使用 Prometheus 的架构和原理可以参考 Prometheus 组件

指标具体含义可参考：监控 & 告警指标列表

TKEStack 通过 Prometheus 组件监控集群状态，Prometheus 组件通过 addon 扩展组件自动完成安装和配置，使用 InfluxDB，ElasticSearch 等存储监控数据。监控数据和指标融入到平台界面中以风格统一图表的风格展示，支持以不同时间，粒度等条件，查询集群，节点，业务，Workload 以及容器等多个层级的监控数据，全维度的掌握平台运行状态。

同时针对在可用性和可扩展性方面，支持使用 Thanos 架构提供可靠的细粒度监控和警报服务，构建具有高可用性和可扩展性的细粒度监控能力。

安装 Prometheus

Prometheus 为 TKEStack 扩展组件，需要在集群的 【基本信息】 页下面开启 “监控告警”。

集群监控

• 登录 TKEStack
• 切换至【平台管理】控制台，选择【集群管理】
• 点击【监控】图标，如下图所示：

• 监控数据展示
• 通过下图中的1可以选择监控数据时间段
• 通过下图中的2可以选择统计粒度，以下图中“APIServer时延”为例，下图中的每个数据表示前1分钟“APIServer时延”平均数

• 上下滑动曲线图可以获得更多监控指标
• 点击曲线图，会弹出具体时间点的具体监控数据

指标具体含义可参考：监控 & 告警指标列表

节点监控

• 登录 TKEStack
• 切换至【平台管理】控制台，选择【集群管理】
• 点击【集群 ID】 -> 【节点管理】->【节点】->【监控】图标，如下图所示：

• 具体查看方式和集群监控完全一致

  指标具体含义可参考：监控 & 告警指标列表

• 此处还可以查看节点下的 Pod 监控

  1. 如下图所示，对比维度可选择 节点 或 Pod
  2. 选择 Pod ，需要在其右侧选择 Pod 所属节点

节点下的 Pod & Container 监控

有两种方式

• 节点监控 下选择 Pod 进行监控
• 在节点列表里，点击节点名，进入节点的 Pod 管理页，如下图所示，点击上方的【监控】按钮，实现对节点下的 Pod 监控

注意：此处还可以查看节点下的 Container 监控

1. 如下图所示，对比维度可选择 Pod 或 Container
2. 选择 Container ，需要在其右侧选择 Container 所属 Pod

指标具体含义可参考：监控 & 告警指标列表

负载监控

• 登录 TKEStack

• 切换至【平台管理】控制台，选择【集群管理】

• 点击【集群 ID】 -> 【工作负载】->【选择一种负载，例如 Deployment】->【监控】图标，如下图所示：

• 具体查看方式和集群监控完全一致

  指标具体含义可参考：监控 & 告警指标列表

负载下 Pod & Container 监控

1. 登录 TKEStack
2. 切换至【平台管理】控制台，选择【集群管理】
3. 点击【集群 ID】 -> 【工作负载】->【选择一种负载】，例如 Deployment】->【点击一个负载名】->【监控】图标，如下图所示：

注意：此处还可以查看负载下的 Container 监控

1. 如下图所示，对比维度可选择 Pod 或 Container
2. 选择 Container ，需要在其右侧选择 Container 所属 Pod 指标具体含义可参考：监控 & 告警指标列表

TKEStack 使用 Prometheus 的架构和原理可以参考 Prometheus 组件

4 - LogAgent 介绍

日志采集

LogAgent 介绍

TKESTack 通过 logagent 提供的集群内日志采集功能，支持将集群内服务或集群节点特定路径文件的日志发送至 Kafka、Elasticsearch 等消费端，支持采集容器标准输出日志，容器内文件日志以及主机内文件日志。更提供事件持久化、审计等功能，实时记录集群事件及操作日志记录，帮助运维人员存储和分析集群内部资源生命周期、资源调度、异常告警等情况。

TKEStack 老版本日志使用 LogCollector 扩展组件。LogAgent 用于替换 LogCollector，新版本统一用 LogAgent 完成日志采集功能。

日志收集功能需要为每个集群手动开启。日志收集功能开启后，日志收集组件 logagent 会在集群内以 Daemonset 的形式运行。用户可以通过日志收集规则配置日志的采集源和消费端，日志收集 Agent 会从用户配置的采集源进行日志收集，并将日志内容发送至用户指定的消费端。需要注意的是，使用日志收集功能需要您确认 Kubernetes 集群内节点能够访问日志消费端。

• 采集容器标准输出日志 ：采集集群内指定容器的 Stderr 和 Stdout 日志。，采集到的日志信息将会以 JSON 格式输出到用户指定的消费端，并会自动附加相关的 Kubernetes metadata， 包括容器所属 Pod 的 label 和 annotation 等信息。
• 采集容器内文件日志 ：采集集群内指定容器内文件路径的日志，用户可以根据自己的需求，灵活的配置所需的容器和路径，采集到的日志信息将会以 JSON 格式输出到用户指定的消费端， 并会附加相关的 Kubernetes metadata，包括容器所属 Pod 的 label 和 annotation 等信息。
• 采集主机内文件日志 ：采集集群内所有节点的指定主机文件路径的日志，logagent 会采集集群内所有节点上满足指定路径规则的文件日志，以 JSON 格式输出到用户指定的输出端， 并会附加用户指定的 metadata，包括日志来源文件的路径和用户自定义的 metadata。

部署在集群内 kubernetes 对象

在集群内部署 logagent Add-on , 将在集群内部署以下 kubernetes 对象

使用日志采集服务

注意：日志采集对接外部 Kafka 或 Elasticsearch，该功能需要额外开启，位置在集群 基本信息 下面，点击开启“日志采集”服务。

业务管理侧

• 登录 TKEStack
• 切换至【业务管理】控制台，选择 【运维中心】->【日志采集】
• 选择相应【业务】和【命名空间】，单击【新建】按钮，如下图所示：

• 在“新建日志采集”页面填写日志采集信息，如下图所示：

• 收集规则名称： 输入规则名，1～63字符，只能包含小写字母、数字及分隔符("-")，且必须以小写字母开头，数字或小写字母结尾
• 业务： 选择所属业务（业务管理侧才会出现）
• 集群： 选择所属集群（平台管理侧才会出现）
• 类型： 选择采集类型
  • 容器标准输出： 容器 Stderr 和 Stdout 日志信息采集
    • 日志源： 可以选择所有容器或者某个 Namespace 下的所有容器/工作负载
      • 所有容器： 所有容器
      • 指定容器： 某个 Namespace 下的所有容器或者工作负载
  • 容器文件路径： 容器内文件内容采集

    • 日志源： 可以采集具体容器内的某个文件路径下的文件内容

      • 工作负载选项： 选择某个 Namespace 下的某种工作负载类型下的某个工作负载
      • 配置采集路径： 选择某个容器下的某个文件路径

      • 文件路径若输入stdout，则转为容器标准输出模式
      • 可配置多个路径。路径必须以/开头和结尾，文件名支持通配符（*）。文件路径和文件名最长支持63个字符
      • 请保证容器的日志文件保存在数据卷，否则收集规则无法生效，详见指定容器运行后的日志目录

  • 节点文件路径： 收集节点上某个路径下的文件内容，不会重复采集，因为采集器会记住之前采集过的日志文件的位点，只采集增量部分
    • 日志源： 可以采集具体节点内的某个文件路径下的文件内容
      • 收集路径： 节点上日志收集路径。路径必须以/开头和结尾，文件名支持通配符（*）。文件路径和文件名最长支持63个字符
      • metadata： key：value 格式，收集的日志会带上 metadata 信息上报给消费端
• 消费端： 选择日志消费端
  • Kafka：
    • 访问地址： Kafka IP 和端口
    • 主题（Topic）： Kafka Topic 名
  • Elasticsearch：

    • Elasticsearch 地址： ES 地址，如：http://190.0.0.1:200

      注意：当前只支持未开启用户登录认证的 ES 集群

    • 索引： ES索引，最长60个字符，只能包含小写字母、数字及分隔符("-"、"_"、"+")，且必须以小写字母开头

• 单击【完成】按钮

平台管理侧

在平台管理侧也支持日志采集规则的创建，创建方式和业务管理处相同。详情可点击平台侧的日志采集。

指定容器运行后的日志目录

LogAgent 除了支持日志规则的创建，也支持指定容器运行后的日志目录，可实现日志文件展示和下载。

前提：需要在创建负载时挂载数据卷，并指定日志目录

创建负载以后，在容器内的/data/logdir目录下的所有文件可以展示并下载，例如我们在容器的/data/logdir下新建一个名为a.log的文件，如果有内容的话，也可以在这里展示与下载：

5 - GPUManager 介绍

GPUManager 介绍

GPUManager 提供一个 All-in-One 的 GPU 管理器, 基于 Kubernets Device Plugin 插件系统实现，该管理器提供了分配并共享 GPU，GPU 指标查询，容器运行前的 GPU 相关设备准备等功能，支持用户在 Kubernetes 集群中使用 GPU 设备。

GPU-Manager 包含如下功能:

• 拓扑分配：提供基于 GPU 拓扑分配功能，当用户分配超过1张 GPU 卡的应用，可以选择拓扑连接最快的方式分配GPU设备
• GPU 共享：允许用户提交小于1张卡资源的的任务，并提供 QoS 保证
• 应用 GPU 指标的查询：用户可以访问主机的端口(默认为5678)的/metrics 路径，可以为 Prometheus 提供 GPU 指标的收集功能，/usage 路径可以提供可读性的容器状况查询

GPU-Manager 使用场景

在 Kubernetes 集群中运行 GPU 应用时，可以解决 AI 训练等场景中申请独立卡造成资源浪费的情况，让计算资源得到充分利用。

GPU-Manager 限制条件

1. 该组件基于 Kubernetes DevicePlugin 实现，只能运行在支持 DevicePlugin 的 kubernetes版本（Kubernetes 1.10 之上的版本）

2. 使用 GPU-Manager 要求集群内包含 GPU 机型节点

3. TKEStack 的 GPU-Manager 将每张 GPU 卡视为一个有100个单位的资源

   特别注意：

   1. 当前仅支持 0-1 的小数张卡，如 20、35、50；以及正整数张卡，如200、500等；不支持类似150、250的资源请求
   2. 显存资源是以 256MiB 为最小的一个单位的分配显存

部署在集群内 kubernetes 对象

在集群内部署 GPU-Manager，将在集群内部署以下 kubernetes 对象：

GPU-Manager 使用方法

安装 GPU-Manager

集群部署阶段选择 vGPU，平台会为集群部署 GPU-Manager ，如下图新建独立集群所示，Global 集群的也是如此安装。

在节点安装 GPU 驱动

集群部署阶段添加 GPU 节点时有勾选 GPU 选项，平台会自动为节点安装 GPU 驱动，如下图所示：

注意：如果集群部署阶段节点没有勾选 GPU，需要自行在有 GPU 的节点上安装 GPU 驱动

工作负载使用 GPU

通过控制台使用

在安装了 GPU-Manager 的集群中，创建工作负载时可以设置 GPU 限制，如下图所示：

注意：

1. 卡数只能填写 0.1 到 1 之间的两位小数或者是所有自然数，例如：0、0.3、0.56、0.7、0.9、1、6、34，不支持 1.5、2.7、3.54
2. 显存只能填写自然数 n，负载使用的显存为 n*256MiB

通过 YAML 使用

如果使用 YAML 创建使用 GPU 的工作负载，提交的时候需要在 YAML 为容器设置 GPU 的使用资源。

• CPU 资源需要在 resource 上填写tencent.com/vcuda-core
• 显存资源需要在 resource 上填写tencent.com/vcuda-memory

例1：使用1张卡的 Pod

apiVersion: v1

kind: Pod

...

spec:

  containers:

    - name: gpu

      resources:
        limits: 
          tencent.com/vcuda-core: 100
        requests:
          tencent.com/vcuda-core: 100

例2，使用 0.3 张卡、5GiB 显存的应用（5GiB = 20*256MB）

apiVersion: v1

kind: Pod

...

spec:

  containers:

  - name: gpu

    resources:
      limits:
        tencent.com/vcuda-core: 30
        tencent.com/vcuda-memory: 20
      requests:
        tencent.com/vcuda-core: 30
        tencent.com/vcuda-memory: 20

GPU 监控数据查询

通过控制台查询

前提：在集群的【基本信息】页里打开“监控告警”

可以通过集群多个页面的监控按钮里查看到 GPU 的相关监控数据，下图以 集群管理 页对集群的监控为例：

通过后台手动查询

手动获取 GPU 监控数据方式（需要先安装 socat）：

kubectl port-forward svc/gpu-manager-metric -n kube-system 5678:5678 &
curl http://127.0.0.1:5678/metric

结果示例：

GPUManager 项目请参考：GPUManager Repository

6 - CSIOperator 介绍

CSIOperator

CSIOperator 介绍

Container Storage Interface Operator(CSIOperator)用于部署和更新 Kubernetes 集群中的 CSI 驱动和外部存储组件。

CSIOperator 使用场景

CSIOperator 用于支持集群方便的使用存储资源，当前支持的存储插件包括 RBD、CephFS、TencentCBS 和 TencentCFS（TencentCFS 正在测试中）

• 其中 RBD 和 CephFS 主要用于部署在 IDC 环境的集群
• TencentCBS 和 TencentCFS 用于部署在腾讯云环境的集群

部署在集群内 kubernetes 对象

在集群内部署 CSIOperator，将在集群内部署以下 kubernetes 对象

CSIOperator 使用方法

安装 CSIOperator

• 登录 TKEStack
• 切换至 【平台管理】控制台，选择 【扩展组件】 页面
• 选择需要安装组件的集群，点击【新建】按钮。如下图所示：

• 在弹出的扩展组件列表里，滑动列表窗口找到 CSIOperator
• 单击【完成】进行安装

通过 CSIOperator 使用腾讯云存储资源

• 登录 TKEStack
• 切换至 【平台管理】控制台，选择 【集群管理】 页面，如下图1所示：
• 点击安装了 CSIOperator 组件的【集群ID】，进入要管理的集群，如下图2所示：
• 点击【YAML创建资源】，如下图3所示：

• 文件中指定各自存储插件镜像的名称，这里以tencentcbs的 YAML 为例：（前提：需要拥有腾讯云账号）

  apiVersion: storage.tkestack.io/v1
  kind: CSI
  metadata:
    name: tencentcbsv1
    namespace: kube-system
  spec:
    driverName: com.tencent.cloud.csi.cbs
    version: "v1"
    parameters:
      secretID: "xxxxxx"
      secretKey: "xxxxxx"
  

  • secretID、secretKey 来源于 腾讯云控制台 -> 账号中心 -> 访问管理 -> 访问秘钥 -> API密钥管理

• 创建完 CSIOperator 的 CRD 对象，同时会为每个存储插件创建默认的 StorageClass 对象（tencentcbs 的 StorageClass 对象名为 cbs-basic-prepaid），如下图：

其 YAML 如下：

• tencentcbs 的 provisioner 名称指定为：com.tencent.cloud.csi.cbs

• tencentcfs 的 provisioner 名称指定为：com.tencent.cloud.csi.cfs，tencentcfs 仍在测试中，目前仅支持 tencentcbs

• 对于磁盘类型（在 StorageClass 的 diskType 中指定）和大小的限制：

  • 普通云硬（ CLOUD_BASIC ）盘提供最小 100 GB 到最大 16000 GB 的规格选择，支持 40-100MB/s 的 IO 吞吐性能和 数百-1000 的随机 IOPS 性能
  • 高性能云硬盘（CLOUD_PREMIUM）提供最小 50 GB 到最大 16000 GB 的规格选择
  • SSD 云硬盘（CLOUD_SSD）提供最小 100 GB 到最大 16000 GB 的规格选择，单块 SSD 云硬盘最高可提供 24000 随机读写IOPS、260MB/s吞吐量的存储性能

• 默认创建的磁盘类型为普通云硬盘，如果用户希望使用该 StorageClass，可以直接创建使用了该 StorageClass 的 PVC 对象：

  apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
    name: test-tencentcbs
    namespace: kube-system
  spec:
    accessModes:
      - ReadWriteOnce
    storageClassName: cbs-basic-prepaid
    resources:
      requests:
        storage: 10Gi
  

详情请见 CSIOperator Example