Ack

前文回顾： 本系列将介绍如何基于 ACK Fluid 反对和优化混合云的数据拜访场景，相干文章请参考： 《基于 ACK Fluid 的混合云优化数据拜访（一）：场景与架构》 《基于 ACK Fluid 的混合云优化数据拜访（二）：搭建弹性计算实例与第三方存储的桥梁》 《基于 ACK Fluid 的混合云优化数据拜访（三）：减速第三方存储的读拜访，降本增效并行》 在前一篇文章《基于 ACK Fluid 的混合云优化数据拜访（三）：减速第三方存储的读拜访，降本增效并行》中，介绍如何减速第三方存储拜访，实现更好的性能，更低的老本同时升高对专线稳定性的依赖。 还有一些客户的场景下，出于历史起因和容器存储接口开发保护的老本，并没有抉择应用规范的 CSI 接口，而是应用非容器化的伎俩，比方自动化脚本。然而一旦拥抱云，就须要思考如何和基于标准接口的云服务对接的问题。 而本文将重点介绍如何通过 ACK Fluid 实现第三方存储主机目录挂载 Kubernetes 化，更加规范并减速提效。 概述有许多企业因为历史起因和技术云下存储抉择没有反对 CSI 协定，只反对以主机目录的形式通过 ansible 等运维工具挂载，一方面存在与 Kubernetes 标准化平台的对接的挑战，另一方面也须要应答与上篇文章相似的性能和老本的问题： 短少标准化，上云艰难：主机目录挂载的模式因为无奈被 Kubernetes 感知和调度，很难被容器化工作负载应用和治理。短少数据隔离性：因为整个目录都被挂载到主机上，并被所有的工作负载拜访，导致数据全局可见。数据拜访在老本，性能和可用性上有何场景 2 雷同的需要，因而不再赘述。ACK Fluid 提供了基于 JindoRuntime 的 PV 主机目录通用减速能力[1]，间接反对主机目录挂载能够原生，简略，疾速，平安的取得通过分布式缓存实现数据拜访减速能力。 将传统架构迁徙到云原生适配架构：将主机目录挂载模式变动为 Kubernetes 能够治理的 CSI 协定下的 PV 存储卷，不便通过标准化协定与公共云相结合。传统架构迁徙低成本：只须要实现主机目录挂载能够立刻应用，无需额定开发；只须要在部署时刻将 Hostpath 协定转换成 PV 存储卷。数据可隔离：通过 Fluid 的子数据集模式能够隔离不同用户对于线下存储不同目录的可见性。能够提供和《基于 ACK Fluid 的混合云优化数据拜访（三）：减速第三方存储的读拜访，降本增效并行》一样的性能，老本，自动化和无缓存数据落盘的长处。总结：ACK Fluid 为云上计算拜访第三方存储的主机目录挂载形式提供了开箱即用，高性能，低成本，自动化和无数据落盘的收益。 演示1.前提条件已创立 ACK Pro 版集群，且集群版本为 1.18 及以上。具体操作，请参见创立 ACK Pro 版集群[2]。已装置云原生 AI 套件并部署 ack-fluid 组件。重要：若您已装置开源 Fluid，请卸载后再部署 ack-fluid 组件。未装置云原生 AI 套件：装置时开启 Fluid 数据减速。具体操作，请参见装置云原生 AI 套件[3]。已装置云原生 AI 套件：在容器服务治理控制台的云原生 AI 套件页面部署 ack-fluid。已通过 kubectl 连贯 ACK 集群。具体操作，请参见通过 kubectl 工具连贯集群[4]。已创立须要拜访存储系统对应的 PV 存储卷和 PVC 存储卷申明。在 Kubernetes 环境中，不同的存储系统有不同的存储卷创立形式，为保障存储系统与 Kubernetes 集群的连贯稳固，请依据对应存储系统的官网文档进行筹备。2.筹备主机目录挂载点本示例中通过 sshfs 模仿第三方存储通过 fluid 转化为数据卷申明，并且对其实现拜访减速。 ...

前文回顾： 本系列将介绍如何基于 ACK Fluid 反对和优化混合云的数据拜访场景，相干文章请参考： 《基于 ACK Fluid 的混合云优化数据拜访（一）：场景与架构》 《基于 ACK Fluid 的混合云优化数据拜访（二）：搭建弹性计算实例与第三方存储的桥梁》 在前一篇文章《基于 ACK Fluid 的混合云优化数据拜访（二）：搭建弹性计算实例与第三方存储的桥梁》中，介绍如何通过 ACK Fluid 接入第三方分布式存储，能够实现弹性计算实例 ECI 和 ECS 与云下存储系统之间的拜访和数据传输，这实际上解决上云的第一阶段问题：连通性。 而对于生产环境来说，如果云上计算拜访云下存储系统变成一种常态，就须要思考性能、老本和稳定性。比方每年的云上拜访线下数据的专线老本是多少？云上计算工作耗时和原有 IDC 计算工作相比是否有显著的落差？以及一旦专线出了问题，如何升高云上计算工作的损失？ 在本文中将重点介绍如何减速第三方存储拜访，实现更好的性能，更低的老本以及升高对专线稳定性的依赖。 概述即使云上计算可能以 Kubernetes 的标准化协定 PV 存储卷拜访企业的线下存储，也无奈防止在性能，老本上的挑战和需要： 数据拜访带宽无限和高延时：云上计算拜访云下存储带来的数据拜访延时和带宽无限，导致高性能计算耗时长，计算资源利用率低数据冗余读取，网络费用低廉：深度学习模型的超参调优、主动调参深度学习工作等运行期间会一直反复拜访同一数据。然而因为 Kubernetes 原生调度器无奈感知数据缓存状态，导致利用调度的后果不佳，缓存无奈重用，导致数据反复拉取引入更多外网和专线费用。线下分布式存储是数据并发拜访的瓶颈，而且面临着性能和稳定性方面的挑战：当大规模算力并发拜访线下存储且深度学习训练的 IO 压力增大，线下分布式存储很容易成为性能瓶颈。这会对计算工作造成影响，甚至会导致整个计算集群生效。受网络稳定性影响重大：一旦公共云和数据中心之间网络不够稳固，会导致数据同步出错，利用处于不可用的状态。数据安全需要：元数据和数据须要爱护，不容许够长久化到云盘上。ACK Fluid 提供了基于 JindoRuntime 的 PV 存储卷通用减速能力，能够反对满足 PVC 的第三方存储简略，疾速，平安的取得通过分布式缓存实现数据拜访减速能力，能够带来如下益处： 零适配老本：只须要实现 CSI 协定中 PVC 的第三方存储即能够立刻应用，无需额定开发。数据拜访性能大幅晋升，晋升工程效率：a. 通过基于拜访和策略数据预热等伎俩实现拜访云下数据性能等同于数据位于云上计算集群 b. 弹性数据拜访带宽应答高并发，数据拜访吞吐晋升到数百 Gbps，也能够缩容到 0，实现低成本和高吞吐的动态平衡。 c. 数据缓存亲和感知调度防止跨网络数据拜访升高提早 防止热点数据的重复读取，节约网络老本：通过分布式缓存将热点数据长久到云上，缩小数据读取，升高网络流量。以数据为核心的自动化运维实现高效的数据拜访，晋升运维效率：包含自动化和定时的数据缓存预热，防止重复拉取数据数据。还反对数据缓存扩容，缩容和清理，实现数据缓存的自动化治理。通过分布式内存缓存防止元数据和数据落盘，更加平安：对于数据安全敏感用户，ACK-Fluid 提供分布式内存缓存一方面性能好，另一方面也防止用户对于数据落盘的担心。总结：ACK Fluid 为云上计算拜访第三方存储 PVC 提供了开箱即用，高性能，低成本，自动化和无数据落盘的收益。 演示1.前提条件已创立 ACK Pro 版集群，且集群版本为 1.18 及以上。具体操作，请参见创立 ACK Pro 版集群[1]。已装置云原生 AI 套件并部署 ack-fluid 组件。重要：若您已装置开源 Fluid，请卸载后再部署 ack-fluid 组件。未装置云原生 AI 套件：装置时开启 Fluid 数据减速。具体操作，请参见装置云原生 AI 套件[2]。已装置云原生 AI 套件：在容器服务治理控制台的云原生 AI 套件页面部署 ack-fluid。已通过 kubectl 连贯 ACK 集群。具体操作，请参见通过 kubectl 工具连贯集群[3]。已创立须要拜访存储系统对应的 PV 存储卷和 PVC 存储卷申明。在 Kubernetes 环境中，不同的存储系统有不同的存储卷创立形式，为保障存储系统与 Kubernetes 集群的连贯稳固，请依据对应存储系统的官网文档进行筹备。留神：对于混合云场景，为了数据的安全性和性能，建议您将数据拜访模式配置为只读。2.查问 PV 存储卷和 PVC 存储卷申明的信息执行如下命令，查问 Kubernetes 中 PV 存储卷和 PVC 存储卷申明的信息。 ...

前文回顾： 本系列将介绍如何基于 ACK Fluid 反对和优化混合云的数据拜访场景，相干文章请参考：《基于 ACK Fluid 的混合云优化数据拜访（一）：场景与架构》 在前文《基于 ACK Fluid 的混合云优化数据拜访（一）：场景与架构》中，重点介绍 ACK Fluid 反对混合云数据拜访实用的不同利用场景和架构实现。在本文中会重点介绍如何通过 ACK Fluid 实现公共云的弹性计算实例拜访云下存储系统的能力。 概述ACK（阿里云容器服务 Kubernetes）即开即用的弹性能力能够很好做自建IDC的弹性能力补充。特地是随着 AIGC 的风行，算力推动翻新的理念深入人心，许多本来抵制计算上云的客户也开始在评估公共云。他们通常会抉择应用 ECI（弹性计算实例）作为技术验证的第一步。然而，如何将自建存储与云上弹性资源对接，特地是 ECI 资源对接，就成了混合云客户应用阿里云的门槛。比方，用户想疾速比拟通过云上 ASK 和云下自建机房运行训练任务的老本，传统的做法须要把数据搬到云上，这就会波及数据隐衷问题，还有迁徙的工夫和金钱老本，无奈做疾速验证。甚至有些客户短期内无奈通过外部平安评审，导致整个翻新节奏受到重大的影响。 能够看到许多企业的数据都是存在线下，并且应用的存储类型多样，包含各种开源存储（Ceph，lustrure，JuiceFS，CubeFS）和自建存储。在应用公共云计算资源的时候，也存在挑战： 数据迁云安全性和老本评估工夫长：对于数据迁徙到云存储上，须要平安和存储团队的长时间评估，这会延缓整个上云过程。数据拜访适配性差：比方公共云对于弹性计算实例（ECI）反对的分布式存储类型无限（比方 NAS，OSS，CPFS），然而对于第三方存储不足反对。接入云平台周期长和难度高：须要开发和保护云原生兼容的 CSI 插件，一方面须要相干的专家和开发适配工程量，同时要保护版本的降级，同时反对的场景无限。比方自建 CSI 无奈适配弹性计算实例（ECI）。不足可信通明的数据接入形式：如何在 Serverless 容器的黑盒零碎拜访数据过程中躲避泄露，如何确保数据在传输、拜访过程中平安，通明，牢靠。防止业务批改的需要：如何确保业务用户不感知基础设施层面的差别，防止对现有利用自身进行任何批改。ACK Fluid 通过提供 ThinRuntime 扩大机制反对将基于 FUSE 实现第三方存储客户端以容器化的形式接入 Kubernetes 中，能够反对阿里云上规范 Kubernetes，边缘 Kubernetes，Serverless Kubernetes 多种状态。 简略的开发接入模式，易扩大： 基于 ThinRuntime 计划，只须要理解 Dockerfile 构建就能够实现，个别开发工作 2-3 小时左右，从而显著升高了接入第三方存储的工作老本。同时基于开源 Fluid 规范对于 ThinRuntime 提供了残缺的反对，只有满足开源要求就能够适配。平安可控的数据拜访：以容器化的形式反对自定义形式实现数据拜访。整个数据拜访过程云平台无侵入，无需提供实现细节。无升高革新适配的老本：只须要在 PVC 中增加特定 label 即可，满足了业务用户无需感知基础设施层面的差别的需要，能将存储适配工夫缩短为原打算的十分之一。存储客户端的自适应部署：Fluid 同时反对 CSI 和 FUSE Sidecar 两种客户端部署模式，依据所在运行平台抉择适合的部署模式，将 PVC 协定转换成 Sidecar 模式，无需最终用户感知。加强可观测性和可控制性：第三方存储客户端只须要实现本身的容器化，就能够转化为 Fluid 治理的 Pod，无缝接入 Kubernetes 体系，并取得可观测性和计算资源可控制性。总结：ACK Fluid 为云上计算拜访云下数据提供了扩展性好，平安可控，低适配老本和与云平台实现无关的益处，利用案例参见小米[1]。 ...

随着容器和 Kubernetes 技术的衰亡，集群入口流量治理形式逐步被 Ingress 通用化和标准化。入口网关的标准化制订将入口流量治理与网关的实现解耦，不仅促成了各种 Ingress Controller 的倒退，而且打消了开发者存在的与厂商绑定的顾虑，日后也能够依据本身业务理论场景切换到不同 Ingress Controller。目前，越来越多的开发者开始关注并思考将业务网关切换为 Ingress 网关，有的企业甚至曾经落地了 Ingress 网关。 本文次要介绍 Ingress Controller 新抉择——MSE Ingress 是什么，分享 MSE Ingress 最佳实际来帮忙开发者从用 Ingress、到用好 Ingress。 什么是 Ingress简略回顾一下之前咱们在应用一些传统网关遇到的问题。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1178466?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

三年前的云栖大会上，LifseaOS 正式公布，这是一款专为云原生场景而垂直优化的操作系统发行版，即业界统称的 ContainerOS。初始公布时，它提供了如下几个突出的个性：轻量（Lightweight）、疾速（Fast）、平安（Secure）、镜像原子治理（Atomic）。 现在 LifseaOS 已在阿里云容器服务 ACK Pro 的托管节点池取得宽泛应用，通过一年多的打磨优化，它在基于 Kubernetes 的云原生集群中正展现出越来越多的独特劣势，本次所介绍的即为 LifseaOS 在扩容弹性上所展现出的极速劣势。 两秒启动 OS，分钟级千节点扩容在 ACK 集群中实现弹性扩容，是一项根底、要害且被重度依赖的能力。尤其是在集群资源池缓和或者有余时，如何疾速扩容节点、复原资源水位对用户业务至关重要。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1189868 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

本文介绍如何在阿里云容器平台 ACK 上疾速搭建一套可对外提供服务的 Stable Diffusion。 CPU 版本前提条件已创立 Kubernetes 托管版集群。具体操作，请参见创立 Kubernetes 托管版集群[1]。无需 GPU，节点须要 8c16g 以上 已通过 kubectl 连贯 kubernetes 集群。具体操作，请参见通过 Kubectl 连贯 Kubernetes 集群[2]。应用控制台创立登录容器服务治理控制台[3]，在左侧导航栏抉择集群。在集群列表页面中，单击指标集群名称或者指标集群右侧操作列下的详情。在集群治理页左侧导航栏中，抉择工作负载 > 无状态。在无状态页面中，单击应用镜像创立。在利用根本信息配置向导页面中，设置利用的根本信息。 zibai-registry.cn-hangzhou.cr.aliyuncs.com/gpt/stable-diffusion:v1.cpu ["python3", "launch.py"]["--listen", "--skip-torch-cuda-test", "--no-half"]期待 pod ready 镜像大小为 12.7GB，内网下载约 10min 在集群治理页左侧导航栏中，选择网络 > 服务。 新建服务，抉择负载平衡类型。 期待约 1min 后，刷新页面能够看到 External IP 列有具体 IP 在浏览器中拜访上一步获取到的 http://xxx.xxx.xxx.xxx:7860，即可看到如下页面。 Prompt：Black and white photo of a beautiful city Sampling method：DPM++ SDE 应用 kubectl 创立stable-diffusion.yaml apiVersion: apps/v1kind: Deploymentmetadata: labels: app: stable-diffusion name: stable-diffusion namespace: defaultspec: replicas: 1 selector: matchLabels: app: stable-diffusion template: metadata: labels: app: stable-diffusion spec: containers: - args: - --listen - --skip-torch-cuda-test - --no-half command: - python3 - launch.py image: zibai-registry.cn-hangzhou.cr.aliyuncs.com/gpt/stable-diffusion:v1.cpu imagePullPolicy: IfNotPresent name: stable-diffusion resources: requests: cpu: "2" memory: 2Gi---apiVersion: v1kind: Servicemetadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: internet service.beta.kubernetes.io/alibaba-cloud-loadbalancer-instance-charge-type: PayByCLCU name: stable-diffusion namespace: defaultspec: externalTrafficPolicy: Local ports: - port: 7860 protocol: TCP targetPort: 7860 selector: app: stable-diffusion type: LoadBalancer期待 pod ready ...

三年前的云栖大会上，LifseaOS 正式公布，这是一款专为云原生场景而垂直优化的操作系统发行版，即业界统称的 ContainerOS。初始公布时，它提供了如下几个突出的个性：轻量（Lightweight）、疾速（Fast）、平安（Secure）、镜像原子治理（Atomic）。 现在 LifseaOS 已在阿里云容器服务 ACK Pro 的托管节点池取得宽泛应用，通过一年多的打磨优化，它在基于 Kubernetes 的云原生集群中正展现出越来越多的独特劣势，本次所介绍的即为 LifseaOS 在扩容弹性上所展现出的极速劣势。 两秒启动 OS，分钟级千节点扩容在 ACK 集群中实现弹性扩容，是一项根底、要害且被重度依赖的能力。尤其是在集群资源池缓和或者有余时，如何疾速扩容节点、复原资源水位对用户业务至关重要。 在节点主动伸缩场景，ACK 通过组件轮询判断集群内资源是否短缺，一旦呈现有余则主动触发扩容节点。如果在这种状况下，节点扩容速度慢，则会重大影响主动伸缩成果，甚至因为资源水位长期有余而影响用户业务。目前的节点扩容速度在 ACK 节点主动伸缩端到端耗时中占比超过 90%，能够说节点扩容速度的优化的水平决定了主动伸缩的体验。 以某量化公司的扩容场景为例，在其长期提供服务的过程中，通过了上千次百节点级别的扩容流动，均匀每次扩容 P90 节点就绪耗时（即单次扩容流动开始至 90% 的节点处于就绪状态）为 162s，耗时较长。若能将扩容流动耗时压缩至 1min 以内，将大幅提高用户在节点扩容场景中的体验。 基于此，LifseaOS 针对 ACK 集群节点池的弹性扩容场景，实现了极速扩容的个性。 一方面，LifseaOS 通过简化 OS 自身的启动流程大大提高了 OS 启动速度。它裁剪掉了大量云上场景无需的硬件驱动，必要的内核驱动模块批改为 built-in 模式，去除了 initramfs，udev 规定也被大大简化，OS 首次启动工夫从传统 OS 的 1min 以上降落到了 2s 左右。 另一方面，LifseaOS 联合 ACK 场景进行了定制优化。它通过预置集群管控必备组件的容器镜像以缩小节点启动过程中因镜像拉取而带来的耗时，并联合 ACK 管控链路优化（例如调节要害逻辑的检测频率、调整高负载下零碎瓶颈中的限流值等），极大地提高了节点扩容速度。 LifseaOS 在节点弹性扩容场景上，相比于传统 OS 计划有十分大的劣势，且并发启动的节点数目越多，LifseaOS 的劣势越显著！如下图所示，并发启动 1000 个节点时，P90 节点就绪工夫 CentOS 为 380s，而 LifseaOS 仅需 53s，实现了分钟级别的千节点扩容体验！！！ ...

随着容器和 Kubernetes 技术的衰亡，集群入口流量治理形式逐步被 Ingress 通用化和标准化。入口网关的标准化制订将入口流量治理与网关的实现解耦，不仅促成了各种 Ingress Controller 的倒退，而且打消了开发者存在的与厂商绑定的顾虑，日后也能够依据本身业务理论场景切换到不同 Ingress Controller。目前，越来越多的开发者开始关注并思考将业务网关切换为 Ingress 网关，有的企业甚至曾经落地了 Ingress 网关。 本文次要介绍 Ingress Controller 新抉择——MSE Ingress 是什么，分享 MSE Ingress 最佳实际来帮忙开发者从用 Ingress、到用好 Ingress。 什么是 Ingress简略回顾一下之前咱们在应用一些传统网关遇到的问题。 人力老本：常见的网关（Nginx、Spring Cloud Gateway、Zuul等）的路由配置以及策略配置格局均不同，开发者在选用网关之前须要相熟对应网关的配置文件的应用办法，企业在招聘人员也要思考是否具备所用网关的技术栈。迁徙老本：业务因为本身起因须要切换网关类型，开发者须要相熟指标网关的配置文件，开发迁徙工具，测试迁徙工具的完整性，演练迁徙计划，最终能力实现迁徙。在 Kubernetes 平台中，形象、规范是第一要义。有了规范，能力更好适配各类不同实现的组件，能力一直蓬勃、可继续的倒退。Kubernetes 通过对立形象定义的 Ingress 资源来治理内部拜访集群外部服务的形式，将入口网关的性能与实现解耦。应用 Ingress 来治理集群入口流量有3大劣势： 规范：遵循入口流量治理的规范模式，开发者只需相熟 Ingress 配置即可，并且能够十分不便的切换业务网关的实现。简略：Ingress 的定义格局简略，易于学习。通过简略配置 Host、Path 和指标服务即可疾速实现集群外部服务的对外公布。可扩大：Ingress 的规范定义仅仅蕴含了 HTTP 流量的路由匹配规定以及 HTTPS 流量所需的证书配置。开发者能够通过 Ingress Annotation 的模式进一步拓展 Ingress 的 API，实现流量分流、跨域、Header管制等治理策略。 Ingress 实现现状Ingress 是形象接口，具体的实现依然由各类网关实现。目前，Ingress 的实现有两大阵营：Nginx 和 Envoy。Nginx 存量大，然而因为架构设计的问题，随着用户规模变大逐渐裸露平安和稳定性危险，目前社区发表进行 6 个月新需要开发， 集中解决平安和稳定性问题；Envoy + Istio 作为后起之秀，采纳数据面和管制面拆散架构，有更好的平安和稳定性保障，并且反对多语言扩大，热更新劣势，Envoy 社区也推出 Gateway 产品减速 Gateway API 落地。 ...

Koordinator 是什么Koordinator 是一个开源我的项目，基于阿里巴巴在容器调度畛域多年累积的教训孵化诞生，能够晋升容器性能，升高集群资源老本。通过混部、资源画像、调度优化等技术能力，可能进步提早敏感的工作负载和批处理作业的运行效率和可靠性，优化集群资源应用效率。 Koordinator 的技术计划源自阿里巴巴在混部、资源优化等畛域多年的技术积攒。早在 2011 年，阿里巴巴就开始在容器调度领进行相干的技术摸索，并于 2016 年启动研发面向混部场景的容器调度技术，通过了多轮技术迭代降级后，最终演进到明天的云原生零碎架构。目前，阿里巴巴曾经实现了全业务规模超千万核的云原生混部，混部天均匀 CPU 利用率超 50%，间断通过了多年“双十一”的考验，帮忙阿里巴巴节俭了大量的资源老本。 随着企业数字化转型工作深刻推动，为了帮忙宽广企业客户播种云原生场景下的技术红利，阿里云于 2022 年 4 月正式开源 Koordinator 我的项目，提供云原生场景下接入老本最低、混部效率最佳的解决方案，升高零碎运维老本，放弃长期可继续倒退的衰弱状态。自开源以来，Koordinator 失去来自业界十几个企业优良工程师的奉献，已在多个企业的生产零碎中失去利用。 Koordinator 助力 ACK 容器调度为了帮忙 ACK 用户晋升容器性能，优化资源效率，阿里云 ACK 在 2021 年推出了 ack-slo-manager 套件，提供了包含 CPU Burst 性能优化、负载感知调度、差异化 SLO 精细化调度、资源画像等一系列性能。这些性能帮忙 ACK 用户无效晋升了容器的性能体现和集群利用率，升高了资源老本。 随着 Koordinator 社区的逐步成熟，技术上也实现了对 ack-slo-manager 套件的反哺。为了让广大客户取得统一的技术体验，ACK 在原组件的根底上进行了全面降级，日前最新公布的 v1.1.1-ack.1 版本，在标准化、通用化上做出了更多的冲破，对相干性能进行了整合，兼容适配了所有原协定和性能，用户能够在利用齐全无感的状况下实现从 ack-slo-manager 到 ack-koordinator 的一键降级。 目前，Koordinator 曾经全面接入阿里云容器服务 ACK，用户能够间接在控制台装置应用。本文将为您介绍相干技术的外围原理。 核心技术能力零碎架构ACK Koordinator 提供的性能次要蕴含三个局部：QoS 感知调度、重调度，资源画像，以及差异化 SLO 混部。组件由核心侧组件和单机侧组件两大部分组成，具体包含以下模块。 Koordinator Manager：以 Deployment 的模式部署的核心组件，其中有两局部性能：SLO Controller：用于资源超卖治理，依据节点混部时的运行状态，动静调整集群的超卖资源量，同时为治理各节点的差异化 SLO 策略。Recommender：提供资源画像性能，预估工作负载的峰值资源需要，简化您的配置容器资源规格的复杂度。Koordinator Descheduler：以 Deployment 的模式部署的核心组件，提供重调度性能。Koordlet：以 DaemonSet 的模式部署的单机组件，用于反对混部场景下的资源超卖、单机精细化调度，以及容器 QoS 保障等。 ...

ACK One 是阿里云面向混合云、多集群、分布式计算等场景推出的分布式云容器平台，可能对立治理阿里云上、边缘、部署在客户数据中心以及其余云上的 Kubernetes 集群，并简化集群治理界面。通过 ACK One 多集群治理，能够关联并治理各种状态的 Kubernetes 集群，提供对立的集群管制面，实现多集群对立的利用散发，流量治理，运维治理，平安治理，GitOps 能力。本文介绍如何应用 ACK One GitOps 能力在多集群公布利用，以及版本治理，自动更新，权限管制，CI 流水线集成等，帮忙您疾速上手 GitOps。 GitOps 概述 利用散发 GitOps 的外围是应用 Git 仓库来治理利用的部署模版，将利用继续部署到指定 Kubernetes 集群中，并以 Git 仓库作为利用部署的惟一起源，一直调整 Kubernetes 集群上利用状态，最终与 Git 仓库中的期待状态统一。 GitOps 的劣势： 简略易学Git 易于被承受开发者承受，易于集成，无额定学习老本。 可靠性强Git 仓库作为利用部署的惟一起源，提供版本控制，疾速回滚和审计能力。 安全性高开发者应用 GitOps 不须要任何 Kubernetes 集群权限，只须要 Git 仓库权限。 利用继续部署Kubernetes 集群和 Git 仓库中的利用状态主动同步，保持一致。 CNCF 在对2023 Cloud Native 的预测中指出 Gitops 曾经成熟并进入生产力稳定期，CNCF Gitops 开源我的项目 Argo 曾经在 2022 年 12 月正式成为 CNCF 毕业我的项目[1]，标记着 Argo 我的项目的稳定性和成熟度，以及越来越多的用户应用 Argo 我的项目实现 GitOps 利用散发。 ...

主动驾驶被认为是推动智能汽车倒退的里程碑式技术。数智化大潮下，公众对汽车的定义和需要都产生了巨大变化，汽车的性能已不再是简略的交通工具，而是逐步演变为一个个“超级智能终端”。 然而，老本和效率始终是制约主动驾驶大规模商用的重要因素。得益于 Kubernetes 和云原生技术在边缘场景的拓展和利用，主动驾驶企业可能以更加高效率、低成本的形式解决数据、训练算法，将研发人员从硬件装备和日常运维治理等繁琐事务中解脱进去，把更多精力投入主动驾驶外围算法的研发及业务的增长中。 本文将通过介绍元戎启行应用阿里云边缘容器服务 ACK@Edge 的实际，分享在主动驾驶网约车场景下，如何将云边一体的云原生能力疾速笼罩到泛滥智能车载设施，无效升高主动驾驶车辆管理老本。 为什么说“云边协同”是主动驾驶倒退的加速器？元戎启行科技有限公司是一家专一于研发和利用 L4 级主动驾驶技术的科技公司，领有主动驾驶乘用车“元启行”和主动驾驶轻卡“元启运”两大产品，次要是为车企、Tier1、出行公司等提供定制化的主动驾驶解决方案。其中，Robotaxi 出行搭载元戎启行自研 L4 级主动驾驶解决方案，通过自营车队和单干经营的模式落地。元戎启行 L4 级主动驾驶前装计划车队已投入经营，为乘客提供城市出行服务。 在业务快速增长的迫切需要下，车载设施在高并发场景下的性能要求与计算资源受限的矛盾、车载环境云边网络不牢靠与车载业务谋求可靠性的矛盾、企业迅速响应需要变动的诉求与传统运维伎俩低下的矛盾、云端管控车载设施以及车载设施对安全性高要求的矛盾等，都会为元戎启行进入高阶主动驾驶量产过程中的老本和效率带来挑战。 面临的挑战零碎可扩展性差，车载应用环境依赖抵触：在主动驾驶畛域，车载业务的传统的交付模式大多数以 deb/rpm 包的形式部署，对车载运行环境的依赖性比拟强，不同业务对系统库的依赖版本可能会抵触；此外，因为算法模块的数量一直增多，单个模块又须要依赖更多的模块，因而不能疾速搭建与复现 bug 产生时的运行零碎环境，给研发调试带来许多困扰。这些都可能给车载线上业务、路上车辆的失常运行带来隐患。环境不统一导致研发运维效率低：理论业务中仿真与车上环境不统一，仿真环境始终放弃容器环境运行，然而车上保留的则为 deb 的部署形式；此外，以 deb/rpm 包等传统的部署形式须要较多的人工干预，容易造成车辆业务部署和运行时测试及研发迭代效率低的问题。短少全局管控能力：对于路测车辆，许多研发人员须要在车端调试需要，因为车载运维条件无限，影响调试工作的效率；此外，线下经营的车辆越来越多，车载业务的降级、运维、监控等都面临较大挑战，须要一个从全局视角对线下经营车辆业务的对立治理和部署的能力。短少云端一体化交付能力：现阶段云原生在云上曾经成为事实标准，主动驾驶车企能够在云上应用云原生+ AI 的能力，进行大量的AI模型训练和仿真业务的运行。然而当AI模型和仿真业务训练好后， 如何将这些制品疾速高效的交付到车端，也是车企所面临的问题。若独自开发一套平台来专门保护车端利用，不仅带来额定开发和保护老本，而且和云端业务的 CI/CD 流程呈现割裂，因而车企也心愿通过云原生的能力治理边缘侧的车载业务，进行云端一体化交付。车载网络安全问题：网络安全对于主动驾驶的重要性曾经毋庸置疑，通常状况下车端利用始终要和云端放弃通信，以监听云端下发的工作，而车端又是一个很容易和内部人员产生物理接触的环境，尤其是网约车经营模式的主动驾驶场景。如果车端被歹意侵入，入侵者有可能通过这条链路侵入云端，甚至进一步影响和云端有连贯的所有车辆，这就对车端利用提出了十分高的平安诉求，显然，这会大大减轻利用开发人员的累赘。弱网/断网环境下的车载业务自治能力：在以网约车经营模式的主动驾驶车辆，在线下运行时，因为车辆所处的地位的不同，很可能处于弱网或者断网的状况，在这种状况下，如何能保障车载业务在极其重启状况下稳固运行，这也是车企所急须要解决的问题。车辆监控/日志采集：大量的经营车辆在行驶过程中，须要监控车辆的硬件温度、CPU、 内存等控件的使用率，时刻在云端监控大屏上显示，另外云端须要车辆上零碎和利用的要害日志采集，用来日志剖析，以后并没有通用且无效的办法去解决。ACK@Edge 助力元戎启行车云一体化协同ACK@Edge 云边端一体化利用劣势主动驾驶场景是云原生在云边协同场景下的很好用例：车载设施能够作为云边协同的计算节点，对立接入到云端，由云端对立管控，同时应用云原生的能力，能很好保障车载上业务之间的环境隔离问题，能够对于主动驾驶车载利用零碎在云上进行对立降级更新、资源调度、运维管控，实现云端一体化交付。 阿里云边缘容器服务（简称 ACK@Edge）是一款提供规范 Kubernetes 集群云端托管，反对边缘计算资源、业务疾速接入、对立治理、对立运维的云原生利用平台，可能帮忙用户轻松实现云边一体化协同。用户利用 ACK@Edge 通过纳管边缘节点将云上利用延长到边缘，联动边缘和云端的数据，使得边缘节点领有云端雷同能力。在云端提供对边缘设施、边缘利用的对立 Ops 能力，保障边缘设施及边缘智能利用少运维、高可用。 目前 ACK@Edge 曾经全面降级为基于云原生的云边一体和云端一体架构，可能适配更多的垂直畛域的边缘计算场景，另外在云端协同场景，车载设施、交通、桥梁等小终端设备的轻量化接入，减速您容器化利用的散发、运维，升高您自建运维的老本。除主动驾驶外，已宽泛用于 CDN、IDC、IoT、智慧物流、工业大脑、新批发等诸多场景。 ACK@Edge 主动驾驶解决方案助力元戎启行云边协同基于 ACK@Edge 云边一体、云端一体，Kubernetes 容器编排调度的能力，以及 ACK@Edge 在 Kubernetes 之上针对边缘场景叠加的如轻量化、OTA，边缘侧 POD 离线启停，边缘自治、边缘单元化、单元化部署、Tunnel 通道的能力，切实解决了元戎启行智能在主动驾驶畛域的相干痛点，最终承载了元戎启行主动驾驶线上经营车辆，为乘客提供城市智能出行服务。 ACK@Edge 在原生 Kubernetes 的根底上针对主动驾驶场景提供了独有的增强型性能： 云端运维，近程调试：ACK@Edge 提供的 Tunnel 通道， 能够让业务人员疾速查看容器日志和进入容器调试。同时利用 tunnel 通道能够将车载设施的监控信息（硬件温度，CPU/内存使用率等）对立收编到云上，为元戎云端平台提供监控和告警服务。边缘自治：ACK@Edge 的边缘自治能力，能够在经营车辆离线、或者车辆重启这种极其状况下， 还能保障车载上的的业务能失常运行。期间，ACK@Edge 团队与元戎零碎团队做了大量的断网、重启操作，最终在证实经营车辆上的业务可能失常运行。轻量化接入：ACK@Edge 在云端场景下，提供轻量化接入的能力，边侧组件具备更少的资源占用率。更少的资源占用率能够为业务腾挪出更多的资源，进步了车载利用对摄像头视频流的解决能力，进一步提高主动驾驶车辆的反应速度。车载利用的 OTA：因为主动驾驶场景对于车辆运行平安要求十分刻薄，对车辆上的利用降级有着十分高的要求，原生的 Kubernetes workload 的降级回滚形式还是显得比拟暴力， 针对这些非凡场景，ACK@Edge 创新性的提出了针对于 POD 的 OTA，以及在离线场景下 POD 的启停治理能力，此性能能够很好的满足经营车辆的依据过后的状况按需降级，以及在极其状况下管理人员人工接入运维的需要。 ...

前言我的阿里云ACK 也就是k8s之前是2021年创立的，过后的版本是1.18，两头也降级过一次到1.22，然而最近k8s的1.24版本公布之后从docker runtime变到了containerd，所以打算再降级一下，之前的镜像制作和镜像公布包含编写dockerfile等等操作不变。 问题1、NAT网关IP和Nginx SLB ip问题NAT网关是ECS外面的Pod是否拜访外网的配置，如果没有NAT网关则你不能通过pod拜访外网，比如说你的服务外面有个网络爬虫，这时候就须要配置NAT网关 Nginx SLB是你的服务通过ingress让外界可能拜访外部资源的配置，也就是说你的利用对应的域名及ip是指向Nginx SLB公网对内拜访的资源。 2、Pod拉取集体或者企业公有镜像问题这个问题也是我降级过程中遇到最大的问题，依据阿里工程师提供的应用免密组件拉取容器镜像文档即可解决。 步骤：(留神：先在控制台看看本人是否装置了aliyun-acr-credential-helper组件)通过控制台形式设置acr-configuration配置项。 登录容器服务治理控制台。 在控制台左侧导航栏中，单击集群。 在集群列表页面，单击指标集群下的详情。 在集群信息页面左侧导航栏，抉择配置管理 > 配置项。 在配置项页面的上方命名空间下拉框中，抉择kube-system，而后找到配置项acr-configuration，而后通过以下两种形式配置acr-configuration。 集体： acr-registry-info: |- - instanceId: "" regionId: "cn-hangzhou"企业： acr-registry-info: |- - instanceId: "cri-xxx" regionId: "cn-hangzhou"残缺的配置，如下： apiVersion: v1data: acr-api-version: "2018-12-01" acr-registry-info: |- - instanceId: "" regionId: "cn-hangzhou" expiring-threshold: 15m service-account: default watch-namespace: allkind: ConfigMapmetadata: name: acr-configuration namespace: kube-system selfLink: /api/v1/namespaces/kube-system/configmaps/acr-configuration3、Https证书cert-manager是一个云原生证书治理开源工具，用于在Kubernetes集群中提供HTTPS证书并主动续期。以下示例介绍了如何应用cert-manager申请收费证书并主动续期。应用cert-manager申请收费的HTTPS证书 4、nacos新版本mysql字段缺失问题Nacos v2.0.4降级到v2.1.0后mysql数据库字段缺失了，加上即可。 Nacos v2.0.4降级到v2.1.0后启动报如下谬误 Unknown column ‘encrypted_data_key‘ in ‘field list‘ 总结降级ACK过程中总会遇到各种各样的问题，还好都解决了，心愿对大家有所帮忙。

作者｜刘东阳、吴梓洋 2018 年底，vivo AI 研究院为了解决对立高性能训练环境、大规模分布式训练、计算资源的高效利用调度等痛点，着手建设 AI 计算平台。通过两年多的继续迭代，平台建设和落地获得了很大停顿，成为 vivo AI 畛域的外围根底平台。平台从当初服务深度学习训练为主，到当初演进成蕴含 VTraining、VServing、VContainer 三大模块，对外提供模型训练、模型推理和容器化能力。平台的容器集群有数千个节点，领有超过数百 PFLOPS 的 GPU 算力。集群里同时运行着数千个训练任务和数百个在线服务。本文是vivo AI 计算平台实战系列文章之一，次要分享了平台在混合云建设方面的实际。 背景混合云是近年来云原生畛域关注的新方向之一，它是指将公有云和私有云服务联合起来应用的解决方案。目前几大公有云厂商都提供了各自的混合云计划，如 AWS 的AWS Outpost、谷歌的 GEC Anthos 和阿里的 ACK 混合云。大部分厂商都是通过应用 Kubernetes 和容器来屏蔽底层基础设施的差别，对上提供对立的服务。AI 计算平台抉择建设混合云，次要是基于以下两点起因。 私有云的弹性资源平台的集群应用公司自建机房内的裸金属服务器，新增资源的洽购流程简单、周期长，无奈及时响应业务长期的大量的算力需要，如大规模参数模型的训练和在线服务的节假日流动扩容。同时因为往年服务器供应链形势严峻，网卡、硬盘、GPU 卡等硬件设施都缺货，服务器洽购交付存在较大危险。私有云的资源能够按需申请和开释，通过混合云应用私有云资源，可能满足业务的长期算力需要，又能无效降低成本。 私有云的高级个性私有云有一些高级的个性，比方 AI 高性能存储 CPFS、高性能网络 RDMA、深度学习减速引擎 AIACC，这些计划或个性目前公司公有云尚不具备，而私有化落地的工夫和金钱老本都很高，通过混合云能够疾速和低成本的应用这些个性。 计划计划选型通过后期调研，以下三种计划能够实现混合云的需要： 计划一的实现成本低、不扭转以后资源申请流程，可疾速落地。业务能够承受小时级的扩容。因而咱们抉择了计划一。 整体架构混合云的整体架构如下图所示。K8s 集群的治理立体部署在公司自建机房，工作立体蕴含了机房的物理机和阿里云的云主机。机房和阿里云间通过专线买通了网络，物理机和云主机能够互相拜访。计划对下层平台通明，比方 VTraining 训练平台不须要改变即可应用云主机的算力。 落地实际注册集群首先须要将自建的集群注册到阿里云。留神应用的 VPC 的网段不能和集群的 Service CIDR 抵触，否则无奈注册。VPC 的虚构交换机和 Pod 虚构交换机的 CIDR 也不能和机房内应用的网段重合，否则会有路由抵触。注册胜利后，须要部署 ACK Agent。它的作用是被动建设从机房到阿里云的长链接，接管控制台的申请并转发给 apiserver。对于没有专线的环境，此机制能够防止将 apiserver 裸露在公网。控制台到 apiserver 的链路如下： 阿里云 ACK 控制台 <<-->> ACK Stub（部署在阿里云） <<-->> ACK Agent（部署在 K8s） <<-->> K8s apiserver ...