检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
使用Kubeflow和Volcano实现典型AI训练任务 Kubernetes已经成为云原生应用编排、管理的事实标准, 越来越多的应用选择向Kubernetes迁移。人工智能和机器学习领域天然的包含大量的计算密集型任务,开发者非常愿意基于Kubernetes构建AI平台,充分利用Kubernetes提供的资源管理、应用编排、运维监控能力。
CCE AI套件(Ascend NPU) 插件介绍 CCE AI套件(Ascend NPU)是支持容器里使用NPU设备的管理插件。 安装本插件后,可创建“AI加速型”节点,实现快速高效地处理推理和图像识别等工作。 字段说明 表1 参数描述 参数 是否必选 参数类型 描述 basic
CCE AI套件(Ascend NPU) 插件简介 CCE AI套件(Ascend NPU)是支持容器里使用huawei NPU设备的管理插件。 安装本插件后,可创建“AI加速型”节点,实现快速高效地处理推理和图像识别等工作。 约束与限制 集群中使用“AI加速型”节点时必须安装CCE
Bool 默认值:false XGPU虚拟化模式的开关 gpu_driver_config 否 Map 针对单个节点池的GPU驱动的相关配置 默认值:{} health_check_xids_v2 否 String 插件健康检查的GPU错误的范围 默认值:"74,79" inject_ld_Library_path
Kubeflow的诞生背景 基于Kubernetes构建一个端到端的AI计算平台是非常复杂和繁琐的过程,它需要处理很多个环节。如图1所示,除了熟知的模型训练环节之外还包括数据收集、预处理、资源管理、特性提取、数据验证、模型的管理、模型发布、监控等环节。对于一个AI算法工程师来讲,
插件仅提供驱动的下载及安装脚本执行功能,插件的状态仅代表插件本身功能正常,与驱动是否安装成功无关。 对于GPU驱动版本与您业务应用的兼容性(GPU驱动版本与CUDA库版本的兼容性),CCE不做保证,请您自行验证。 对于已经安装GPU驱动的自定义操作系统镜像,CCE无法保证其提供的GPU驱
AI任务性能增强调度 公平调度(DRF) 组调度(Gang) 父主题: Volcano调度
CCE AI套件(NVIDIA GPU)版本发布记录 表1 CCE AI套件(NVIDIA GPU)版本记录 插件版本 支持的集群版本 更新特性 2.7.42 v1.28 v1.29 v1.30 v1.31 新增NVIDIA 535.216.03驱动,支持XGPU特性 2.7.41
CCE AI套件(Ascend NPU)版本发布记录 表1 CCE AI套件(Ascend NPU)插件版本记录 插件版本 支持的集群版本 更新特性 2.1.46 v1.21 v1.23 v1.25 v1.27 v1.28 v1.29 v1.30 v1.31 支持CCE v1.31集群
在NVIDIA Container Toolkit v1.16.1及更早版本的环境中,攻击者通过运行一个恶意镜像,可能实现容器逃逸,从而获得主机系统的访问权限。成功利用此漏洞可能会导致代码执行、拒绝服务、权限提升、信息泄露和数据篡改。 判断方法 如果集群未安装CCE AI套件(NVIDIA
- 指示容器是否准备好为请求提供服务。如果就绪态探测失败, 端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。 初始延迟之前的就绪态的状态值默认为 Failure。 如果容器不提供就绪态探针,则默认状态为 Success。 启动探针 参数名 取值范围
Gang调度策略是volcano-scheduler的核心调度算法之一,它满足了调度过程中的“All or nothing”的调度需求,避免Pod的任意调度导致集群资源的浪费。具体算法是,观察Job下的Pod已调度数量是否满足了最小运行数量,当Job的最小运行数量得到满足时,为Job下的所有Pod执行调度动作,否则,不执行。
Inheritable 集合上,这会导致在容器内的进程在以 Non-Root 用户 execve() 执行可执行文件时Inheritable和文件的Inheritable集合的交集被添加到执行完execve后的进程的Permited集合中,出现非预期的“越权“行为。需要说明的是,这个越权并没有突破 execve
Containerd Pod重启风险检查异常处理 检查项内容 检查当前集群内使用containerd的节点在升级containerd组件时,节点上运行的业务容器是否可能发生重启,造成业务影响。 解决方案 检测到您的节点上的containerd服务存在重启风险;请确保在业务影响可控
<none> 驱逐该节点上的所有Pod。 kubectl drain 192.168.0.160 如果节点上存在绑定了本地存储的Pod或是一些守护进程集管理的Pod,将提示“error: unable to drain node "192.168.0.160" due
推荐使用滚动的方式迁移,即扩容部分Containerd节点,再删除部分Docker节点,直至新的Containerd节点池中节点数量和原Docker节点池中节点数量一致。 若您在原有Docker节点或节点池上部署的负载设置了对应的节点亲和性,则需要将负载的节点亲和性策略配置为的新Containerd节点或节点池。
用户在使用了恶意构造的镜像时,会导致容器内可获取主机上的任意文件的只读副本,从而泄露敏感信息。 该漏洞影响范围如下: 使用containerd作为Kubernetes CRI运行时,且使用了未知来源的恶意镜像。使用docker作为CRI时不涉及该漏洞。 containerd版本号小于1
Apache containerd安全漏洞公告(CVE-2020-15257) 漏洞详情 CVE-2020-15257是containerd官方发布的一处Docker容器逃逸漏洞。containerd是一个支持Docker和常见Kubernetes配置的容器运行时管理组件,它处理
节点干扰ContainerdSock检查异常处理 检查项内容 检查节点上是否存在干扰的Containerd.Sock文件。该文件影响Euler操作系统下的容器运行时启动。 解决方案 问题场景:节点使用的docker为定制的Euler-docker而非社区的docker 登录相关节点。
在实际业务中,经常会遇到将集群稀缺资源分配给多个用户的情况,每个用户获得资源的权利都相同,但是需求数却可能不同,如何公平的将资源分配给每个用户是一项非常有意义的事情。调度层面有一种常用的方法为最大最小化公平分配算法(max-min fairness share),尽量满足用户中的最小的需求,然后将剩余的资源公平分配给剩下的用户。形式化定义如下: