1. KubeCon CloudNativeCon China 2026一场值得提前做功课的云原生大会1.1 为什么每年都有人专程赶去KubeCon打个飞的KubeCon CloudNativeCon 是云原生计算基金会CNCF旗下规模最大、内容密度最高的年度技术峰会China场次每年在国内举办一次基本能代表接下来一年整个云原生技术圈的风向标。2026年这届虽然有华为云等大厂持续加码但并不是那种只适合“领导站台”的务虚会议——真正走进会场会发现Keynote、技术分论坛、动手实验室和厂商展区里全是能直接拿回生产环境用的东西。我自己参加过好几届KubeCon一个很直观的感受是如果你所在团队正在做Kubernetes容器化改造、微服务治理、可观测性平台建设或者已经在尝试把AI工作负载跑进容器集群那KubeCon的议题几乎就是为你量身定的。尤其像华为云这种头部云厂商往往会在大会上放出新版本、新工具链和真实落地案例信息量大到逛一天都消化不完必须提前做功课。这篇内容就是把“华为云亮相KubeCon CloudNativeCon China 2026”这件事拆开揉碎聊清楚三个层次华为云今年在云原生底层有什么新动作、基于DeepSeek搭建Agent智能助手这类热门实操到底怎么做、以及作为普通开发者在会前会中会后如何把产出最大化。不管你是搞基础设施的还是专注AI应用开发的都能从中找到参考路径。1.2 本届大会主题风向与华为云议题分布从公开预告来看KubeCon CloudNativeCon China 2026的核心主题仍然围绕“云原生化进入深水区”展开但和过去几年相比有几个明显变化值得提前划重点。第一是AI工作负载的云原生调度成为绝对主角。过去我们聊Kubernetes默认承载的是无状态微服务、中间件、大数据作业现在越来越多团队开始把大模型推理、Agent运行时、模型微调任务直接放进容器平台里。这带来一连串新问题GPU资源怎么动态分配、推理请求如何弹性伸缩、多个租户共享集群时怎么避免算力争抢。华为云这届的很多议题都往这个方向靠实际上是把Kubernetes从“应用编排平台”往“算力编排平台”推了一步。第二是云边端一体化的落地节奏明显加快。边缘计算讲了这么多年2026年已经进入规模化交付阶段。大会专门有贴近边缘场景的分论坛讨论弱网环境下的镜像分发、边缘节点自治、边云协同的流量治理等话题。华为云在边缘容器这一块有KubeEdge项目积累这次会怎么结合AI推理场景做演示是我个人比较期待的部分。第三是平台工程Platform Engineering逐渐从概念走向标准实践。开发者体验、内部开发者平台IDP、自动化运维策略这些话题不再是少数头部互联网公司的专利传统企业也在尝试搭建适合自己的平台工程体系。华为云的议题清单里不乏这类内容而且通常会配合具体的工具链demo来讲不是干巴巴的概念普及。华为云这次整体议程可以粗略分为三块云原生基础设施与容器产品演进、开源项目与生态治理经验、AI 云原生的融合实践。对应到参会者身上就是三条路搞平台基础设施的关注CCE、集群弹性、多云治理搞开源或者关注技术趋势的关注KubeEdge、Volcano等项目动态搞AI应用开发的重点盯ModelArts、云容器实例搭配DeepSeek这类模型服务的方案。1.3 参会前如何快速锁定有效议题我每年都会看到一种情况很多人在会场里跑来跑去看起来挺忙晚上回去却说不出来今天到底收获了什么。根本原因不是议题不好而是没有提前筛选。一个实用的方法是按“我的一个待解决问题”来找议题而不是按公司名或者演讲者Title来找。举例来说如果你最近正在头疼集群节点自动扩缩容不稳定就光搜“弹性”“HPA”“VPA”“cluster-autoscaler”这些关键词把相关议题全部标记出来如果你在折腾基于DeepSeek搭建Agent智能助手就把“Agent”“大模型推理”“function calling”“知识库”相关的场次优先排进去。KubeCon官方提供的日程系统可以手动收藏规划好一天最多听4到5场深度分享剩下的时间留给展区和动手实验室。别贪多一个议题听透比走马观花看八个议题有价值得多。2. 华为云在云原生底座的布局从容器引擎到开源生态2.1 华为云容器与云原生基础设施的演进逻辑很多人一提华为云第一反应还是“做政企市场的云厂商”但如果你仔细看它在容器和云原生方向的产品演进会发现其技术纵深被明显低估了。以华为云云容器引擎CCE为例早年版本解决的是“把Kubernetes集群在云上跑起来”的基本问题后来迭代出来的CCE Turbo则是从调度、网络、存储三个维度同步优化性能让容器实例的启动速度和单集群规模上了一个台阶。到了2026年这个阶段容器产品的比拼早就不是“能用Kubernetes”了而是拼大规模集群的稳定性、异构算力接入的灵活性以及和上层AI平台之间的配合深度。华为云CCE在这些方向上的思路可以简单概括为“一个底座多套场景”底座是统一的Kubernetes能力场景覆盖传统微服务、大数据作业、AI训练推理、边缘计算等。落到本届大会的议程上就是会有不少关于大规模集群性能调优、GPU虚拟化与共享调度、多集群联邦治理的session这些都是生产环境里实实在在的痛点。从实操角度来看如果你的团队还在用小集群跑业务可能感知不到这些增强点有什么了不起但当节点数超过几百个、每天有上万次Pod调度、还要混合调度CPU任务和GPU任务时控制面的性能瓶颈、调度器策略、网络插件的转发能力就会逐一暴露。华为云这届大会上关于容器底座的分享对正在做规模化的团队来说参考价值很高。2.2 开源项目与标准共建生态背后的底层逻辑国内云厂商对开源的态度这些年经历了明显变化早期更多是“用开源”后来是“贡献开源”现在华为云的姿态更接近“运营开源”。华为云在CNCF及开源社区的布局有几条线值得关注一是以KubeEdge为代表的边缘计算项目二是以Volcano为代表的批量调度与AI工作负载调度项目三是围绕Kubernetes原生生态做的增强组件。这里我特别想聊Volcano。很多做大模型训练的人可能没意识到Kubernetes原生的调度器在面对GPU训练任务时并不那么顺手尤其是在排队、抢占、binpack等策略上缺乏面向AI作业的语义。Volcano本质上是给Kubernetes加了一个能理解AI作业的调度层支持队列管理、优先级抢占、gang scheduling这些能力。华为云大规模AI训练集群背后离不开这类组件大会相关议题值得配置工程师、SRE这类角色重点关注。再看KubeEdge边缘侧和云端侧之间的网络经常是断断续续的KubeEdge通过把云边通信抽象成独立的消息通道让边缘节点可以离线自治、联网后再同步状态。这在车联网、工厂质检、智慧园区等场景里很实用。2026年边缘AI推理的需求越来越强KubeEdge加上轻量化运行时就可以在边缘设备上直接跑模型推理服务。这个方向华为云有很大优势毕竟边缘场景不光是软件问题还涉及硬件适配、平台对接这类know-how很难在短时间内复制。从企业选型的角度看关注华为云开源项目还有一个实际原因避免被单一厂商锁定。KubeEdge、Volcano这些项目都是CNCF体系内的开源项目代码和社区都是开放的即使你不在华为云上跑业务想在自己的机房或其它云环境里使用技术上也是可行的。这本质上是厂商用开源换生态信任我贡献底层基础设施你基于它构建自己的平台双方都能从中获益。2.3 产品配置不是开箱即用关键参数要提前吃透很多刚接触华为云的人容易有个误区以为在控制台点几个按钮CCE集群就能“一键生产可用”。实际用了之后才会发现开箱即用只是第一步真正影响稳定性和成本的全是细节参数。这里整理几个我在实际配置中觉得最值得提前确认的点给大家参考。节点规格与操作系统选型要匹配业务特征。如果你跑的是CPU密集型的微服务选通用计算型实例就好如果需要GPU跑推理就要确认所选实例能否绑定GPU驱动、是否支持MPS或者vGPU切分。华为云CCE在创建节点池时可以分批次配置不同规格的节点建议把在线业务和离线任务放在不同节点池里避免互相干扰。操作系统方面除非有明确的合规要求否则优先选云厂商提供的容器优化型镜像安全和性能都比通用镜像更贴合容器场景。集群版本不要追新但在官方支持周期内保持足够新。Kubernetes版本迭代很快但生产环境最忌讳的是一上来就冲到最新版因为配套的CNI、CSI、Ingress Controller未必全部兼容。比较稳妥的做法是选择华为云官方支持列表里处于稳定期的版本同时关注控制台是否提示“该版本即将停止维护”。一旦出现提示就要排期做版本升级避免后续安全漏洞补丁跟不上。网络模型选型决定了集群后续的扩展空间。VPC网络模式适合对网络性能要求高的生产业务容器和虚拟机在同一VPC内通信延迟更低容器隧道网络模式在集群内配置灵活适合快速搭建测试环境。如果你想跑的是大规模AI训练任务对网络带宽和延迟很敏感建议一开始就选VPC直通模式省得后面迁移网络架构。这个决定在创建集群时就要做落实后期想改非常麻烦。存储和服务发现也一样提前想清楚IO模型、是否跨AZ访问、是否需要StatefulSet持久化等等都关系到资源配置和成本。总之建议在大会动手实验区把CCE集群的完整配置流程亲手走一遍比自己回到公司踩一遍坑要划算得多。3. 现场最热实操基于DeepSeek搭建Agent智能助手的方法论3.1 AI Agent如何和云原生结合华为云相关热词里面“基于DeepSeek搭建Agent智能助手”是搜索热度特别高的一条。这并不意外DeepSeek作为开源大模型在中文理解、推理能力和成本控制上都很有优势很多人第一反应就是拿它做个Agent。但真正上手之后发现Agent不是简单调一个模型API就完事它涉及工具调用、外部知识、上下文管理、记忆机制、权限控制等一系列问题。为什么这件事会出现在KubeCon的语境里因为Agent一旦进入生产环境就天然是个云原生应用。它需要弹性伸缩来处理不确定的请求量需要配置中心来管理各种Prompt模板和工具定义需要可观测性来追踪每次决策链路可能还需要任务队列来异步处理耗时的工具调用。换句话说模型本身可以跑在DeepSeek这样的开源模型上但承载Agent的服务端架构必须用云原生的思路来设计否则只能停留在demo阶段。华为云生态里Agent通常不是“一个脚本”就能跑起来的而是会涉及函数工作流FunctionGraph、云容器实例CCI、ModelArts模型服务等多种云原生产品。KubeCon现场的动手环节一般会引导把Agent拆成若干容器化微服务再借助Kubernetes的调度和扩容能力跑起来。这种组合工具的用法和直接在本机起一个Python服务是完全不同的体验生产可行性也高得多。3.2 一步一步完成Agent搭建与华为云产品配置为了让你对“基于DeepSeek搭建Agent智能助手”这件事有个更清晰的感知我以一次在华为云上的典型配置过程为例把步骤拆开。这里不假设你有大量GPU资源直接使用DeepSeek相关API服务或开源的DeepSeek模型但在云端托管再搭配华为云的计算与集成产品来完成Agent的接入和发布。第一步规划Agent的核心功能。不要一上来就想着“做一个万能助手”先明确一个用户故事比如“帮我查天气并设置日程提醒”。这个Agent需要两个工具天气查询API、日历写入API。在代码层面可以理解为给模型提供两个function定义模型根据用户提问自动选择调用哪个。第二步准备运行环境。在华为云上创建弹性云服务器ECS或者直接用云容器实例CCI来跑Agent后端服务。考虑到后期扩展和演示效果我更推荐用CCE集群哪怕先建一个最小规格的单节点集群都行。创建集群时选择容器隧道网络模型节点规格用4C8G操作系统选华为云HCE容器优化型这样后续部署Agent服务不会有奇怪的兼容性问题。第三步集成DeepSeek模型调用。这部分有两种选择一种是直接调用DeepSeek开放平台的API不需要自建GPU推理服务成本低、落地快另一种是在华为云ModelArts上把开源的DeepSeek模型部署成在线服务。前者适合快速开发和验证后者适合数据敏感、需要私有化部署的场景。我建议初学阶段走前者先保证业务流程跑通再考虑模型私有化。# agent_demo.py # 一个极简的DeepSeek Agent骨架代码 # 使用OpenAI兼容接口调用DeepSeek并注册一个查询天气的工具 import json from openai import OpenAI client OpenAI( api_keyyour_deepseek_api_key, base_urlhttps://your_deepseek_endpoint/v1 ) def get_weather(city: str) - str: # 假设这里接入真实天气API return f{city}今天晴气温24℃ tools [ { type: function, function: { name: get_weather, description: 查询指定城市的天气, parameters: { type: object, properties: { city: {type: string, description: 城市名} }, required: [city] } } } ] def run_agent(user_message: str): messages [ {role: system, content: 你是一个智能助手使用工具回答用户问题}, {role: user, content: user_message} ] resp client.chat.completions.create( modeldeepseek-chat, messagesmessages, toolstools, tool_choiceauto ) choice resp.choices[0] if choice.finish_reason tool_calls: tool_call choice.message.tool_calls[0] args json.loads(tool_call.function.arguments) tool_result get_weather(args[city]) messages.append(choice.message) messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps({weather: tool_result}, ensure_asciiFalse) }) final_resp client.chat.completions.create( modeldeepseek-chat, messagesmessages ) return final_resp.choices[0].message.content return choice.message.content if __name__ __main__: print(run_agent(北京今天天气怎么样))第四步把Agent容器化并部署到CCE。写一个Dockerfile将上面的代码打包成镜像推送到华为云SWR镜像仓库再编写Deployment和Service的YAML完成部署。这里要注意环境变量管理API密钥不要直接写死在镜像里用ConfigMap或Secret保存Kubernetes会在Pod启动时注入。# agent-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: deepseek-agent spec: replicas: 2 selector: matchLabels: app: deepseek-agent template: metadata: labels: app: deepseek-agent spec: containers: - name: agent image: swr.cn-north-4.myhuaweicloud.com/your_namespace/deepseek-agent:latest ports: - containerPort: 8000 env: - name: DEEPSEEK_API_KEY valueFrom: secretKeyRef: name: deepseek-secret key: api_key - name: DEEPSEEK_BASE_URL value: https://your_deepseek_endpoint/v1 resources: requests: cpu: 500m memory: 512Mi limits: cpu: 1 memory: 1Gi第五步配置可观测性。生产环境的Agent必须能回答“用户上次问什么了、模型调了什么工具、哪一步报错了”这些问题。把Agent日志导入云日志服务LTS同时在代码里给每次会话生成一个trace_id在工具调用前后分别打印结构化日志。这样一来排查问题的时候就不是大海捞针直接按trace_id拉出整条链路就行。3.3 配置过程中最容易踩的坑第一类是API调用层的坑。DeepSeek的API如果按照OpenAI兼容格式调用最大的坑是工具调用function calling的返回格式解析。很多人发现模型已经返回了tool_calls但代码里忘记把上一轮的assistant消息追加到messages里导致下一轮对话丢失上下文。这个问题的表现很迷惑看起来是“模型变笨了”实际上是对话历史不完整。解决办法就是严格按第一节代码里的流程把assistant的消息原样放回messages数组再追加tool结果。第二类是容器配置的坑。CCI或者CCE部署Agent服务时如果只配置了requests没配置limits或者反过来都容易出问题。只配requests的Pod突发流量时可能把一个节点的CPU全部占满导致其他Pod卡死。另一方面requests和limits差距过大可能会触发节点资源碎片化明明总资源够用却调度不出新的Pod。一个相对保守的做法是让requests和limits保持一致或者使用华为云CCE的弹性资源能力来处理突发流量。第三类是关于密钥与权限的管理。很多人在本地调试时图省事直接给代码里塞明文API key。一旦推送镜像到仓库密钥就等于公开了。正确做法是代码里只从环境变量读取部署时用Secret对象管理。另外如果Agent需要访问华为云服务比如存储、消息队列强烈建议使用云服务自身的委托授权能力而不要创建永久AK/SK。因为你永远不知道日志系统会不会把环境变量打印出去。注意任何API密钥、访问凭据都不要以明文出现在代码、镜像、Git提交记录里。一旦泄露几分钟内就可能被自动化工具扫描到并滥用这是Agent生产化过程中最严重的安全隐患。4. 议程之外的实用经验参会前中后的完整操作清单4.1 展会动手实验室的正确打开方式KubeCon的动手实验室Hands-on Lab是最值得花时间的地方之一但也是很多人最容易浪费机会的地方。很多人走进实验室看到旁边有工作人员就开口问“这个怎么操作”工作人员虽然会耐心指导但你自己的收获会非常有限。更糟糕的是如果你只是跟着屏幕上的步骤一步步点点完就忘了那基本属于无效参与。我的习惯是进实验室之前先确定一个和自己工作强相关的目标。举个例子如果最近正在做基于DeepSeek搭建Agent智能助手就提前在本地写好一个最简单的调用Demo不追求功能完善但务必能运行。到了华为云展区或者实验室直接带着代码去问现场的解决方案架构师“这段代码我想放到CCE上跑需要怎么调整网络配置有没有推荐的GPU实例”这种具体的提问得到的答案往往比任何技术文档都值钱。另外一个容易忽略的层面是很多动手实验环境是有时间限制的通常一两个小时之后资源会被回收。你做完实验之后如果想保留配置结果最好在结束前把关键步骤截图、把YAML和代码存到笔记里。别想着“回公司再复现”现场实验环境的很多预置条件在自己账号里未必能完全复现趁环境还在赶紧沉淀才是正事。4.2 展区深度逛法从排队盖章到抓核心信息很多云厂商展区会设置互动打卡、盖章换礼物的环节参与一下没毛病但如果把半天时间全花在排队领周边上就有些本末倒置了。我的建议是展区分三圈看第一圈快速浏览花30分钟把所有展台过一遍记录下哪些展台在讲自己关心的技术方向第二圈定向深聊奔着第一圈标记出来的展台去找技术工程师问细节第三圈回到动手实验室或开放演讲区把深聊中遇到的疑问用实践验证一下。找华为云展台的技术人员聊天千万别只问“你们能做什么”这种问题他们每天要回答几百遍得到的回答大概率是标准宣传话术。更有效的问法是结合自己的场景比如“我们目前有一套自建的Kubernetes集群大概500个节点运行着在线推荐服务也在尝试接入大模型做智能客服想了解一下从自建集群迁移到CCE的大致路径和风险。”这种具体问题对应的往往是自家产品经理或者资深架构师他们给出的建议才有含金量。如果你对开源项目感兴趣直接在展区找到KubeEdge或Volcano相关的维护者聊几句比自己回家看半年Issue效率高。这类维护者通常很愿意分享规划中的Roadmap这些信息在官网和文档里是看不到的。4.3 会后复盘把会议价值带进代码里大会结束后的第一个星期是价值兑现的黄金时间。这时候很多记忆还新鲜但如果你不做任何沉淀最多两周那些精彩的分享就会变成“好像听说过”。我在每次KubeCon之后都会固定做三件事整理议题笔记、复现动手实验、写一篇内部技术分享。整理议题笔记不是把PPT截图贴一遍而是按“我遇到的问题、会上的解法、我打算怎么落地”这个结构来写。比如听到某个关于Volcano调度策略的分享笔记里就应该记下当前我们集群里GPU任务排队慢是因为默认调度器对AI作业不友好会上提到Volcano的queue和priorityClass可以解决回来后先在测试环境验证一下这两个配置对任务启动时间的影响。这样的笔记才是可行动的知识。动手实验的复现同样关键。很多实验虽然使用了预置环境但核心步骤里的代码和配置是通用的。我会把动手实验里用到的脚本、配置文件、命令保存到一个专门文件夹里然后标注“这个配置在华为云CCE 1.29版本验证过”方便以后查用。如果你在会场没有完成全部步骤也不用慌很多实验在会后会提供公开入口趁热打铁补完。关于内部技术分享哪怕只在团队群里发一篇几百字的收获总结也会逼迫你重新审视那些模棱两可的技术细节。写的过程中发现讲不清楚的地方正是需要进一步查证的地方。这个环节跑完会议的价值才算真正落回到团队内部。4.4 个人经验带一个“探索型问题”去参会最后再分享一个小技巧。每次我去KubeCon之前除了把自己负责的业务技术问题列出来还会额外准备一个“探索型问题”——这个问题不一定是当前项目需要的纯粹是技术兴趣。比如某一年我问自己“如果要在边缘设备上跑一个轻量级AI推理服务KubeEdge能不能在断网环境下完成模型热更新”带着这种问题逛展会给你带来完全不同的视角。很大概率这类问题没法和任何演讲完美匹配但在展区、在晚宴上、在茶歇排队时你可能会遇到做得正好的工程师那时候的交流完全没有KPI压力聊出来的是真正的实践细节而不是PPT结论。很多对我工作有帮助的灵感恰恰来自这种“超纲”的对话。从这个意义上说技术大会最不可替代的价值不是那些公开演讲而是人与人之间即兴碰撞出来的信息差。KubeCon CloudNativeCon China 2026也一样提前做足功课会上才有余力接受这种意外的惊喜。