云原生技术
如果你正在系统了解云原生技术,可以从 Kubernetes 与容器、微服务架构、DevOps 与平台工程、云原生安全几个主方向进入。这个入口适合先建立全局认知,再按具体技术方向继续深入。
-
AI智能体搭建教程:工具链与上线步骤
第一次搭 AI 智能体时,最容易卡在“先选框架还是先接业务系统”。这篇教程用路线图方式拆开最小原型、工具链取舍、示例工作流和部署门禁,帮助你从可跑 Demo 走向可交付版本。
-
Agent大语言模型是什么?架构与边界
当团队讨论 Agent、大模型和智能体平台时,最容易混淆的是“模型能力”和“任务执行系统”。本文用架构拆解 Agent大语言模型的组成、工作流和限制,帮助你判断哪些场景适合做 Agent,哪些只需要普通 LLM 应用。
-
Agent智能体搭建步骤:从规划到验证
当 Agent 原型准备进入项目评审时,团队需要的不再是工具链总览,而是每一步谁签字、看什么证据、哪些权限不能越过。本文提供 Agent智能体搭建步骤清单,适合启动会、评审会和上线前验收使用。
-
Velero恢复演练-Kubernetes备份可用性验证
备份任务 Completed 不等于业务可恢复。本文围绕 Velero 恢复演练,把误删恢复、应用级恢复和跨集群恢复拆成不同验收目标,帮助团队发现备份盲区。
-
OpenTelemetry Collector管道部署-采样路由与故障降级
可观测数据进后端之前,最容易出问题的是采样口径、字段脱敏和导出失败。本文围绕 OpenTelemetry Collector 管道部署,拆解如何设计可降级的 Telemetry Pipeline。
-
Kyverno vs OPA Gatekeeper-策略引擎怎么选
同样能做准入控制,Kyverno 和 OPA Gatekeeper 的分歧在于谁来写策略、规则是否跨系统复用、例外如何审批。本文用团队协作视角比较两类策略引擎。
-
Kueue ClusterQueue配额借用-优先级与等待原因诊断
当训练任务一直等待、借用资源后又被抢占时,问题通常不在 Kueue 基础对象,而在 ClusterQueue 配额模型。本文用等待原因、借用边界和优先级规则拆解排查路径。
-
KEDA事件驱动扩缩容-队列积压与冷启动验证
队列长度上涨时,副本数没有跟上;副本扩起来后,任务仍然堆积。本文从事件源、ScaledObject、HPA 时间线和冷启动成本切入,梳理 KEDA 事件驱动扩缩容的验证方法。
-
Istio mTLS排障-STRICT切换与证书链路检查
STRICT 一开就 503,问题可能是未注入调用方、客户端 TLS 模式、SDS 证书或端口命名。本文围绕 Istio mTLS 排障,把策略、证书和路由层分开验证。
-
External Secrets Operator密钥同步治理实践
密钥同步成功,只代表 Secret 被写入集群;更关键的是谁能同步、同步哪些路径、应用是否重载、失败是否告警。本文用权限边界和轮换链路拆解 ESO 落地治理。
-
Cilium网络策略排障-身份标签与丢包路径诊断
同一条访问有时通、有时被拒,往往不是单个 NetworkPolicy 能解释。本文围绕 Cilium 网络策略排障,把身份标签、策略选择器、Hubble verdict 和节点路径拆成分支。
-
cert-manager证书自动续期排查-断点定位与入口验证
浏览器提示证书过期时,真正的问题可能不在 cert-manager。本文围绕 cert-manager 证书自动续期,把资源状态、ACME Challenge、Secret 更新和入口返回证书拆成可复核证据链。
-
Argo Rollouts灰度发布-指标闸门与回滚决策
灰度失败时,团队真正要判断的是继续放量、暂停观察、回滚还是切换到人工处理。本文围绕 Argo Rollouts 灰度发布,把指标闸门和回滚证据串成一条决策链。
-
Karpenter vs Cluster Autoscaler:节点自动扩缩容怎么选
节点自动扩缩容选错,常见后果不是少省几台机器,而是 Pending 等待、节点碎片和容量策略长期失控。本文把 Karpenter vs Cluster Autoscaler 放到真实平台场景中比较,给出可执行的选型与迁移判断。
-
Falco运行时安全怎么做:Kubernetes威胁检测与告警实践
镜像扫描和准入控制只能覆盖上线前风险,运行中的异常命令、敏感文件访问和容器逃逸迹象仍需要持续观察。本文从 Falco 运行时安全入手,梳理 Kubernetes 威胁检测与告警落地路径。
-
Argo CD ApplicationSet怎么用:多集群GitOps应用分发实践
多集群环境中,应用分发容易从“多写几份 Application”演变成环境漂移和权限混乱。围绕 Argo CD ApplicationSet,本文拆解生成策略、目录组织、集群标签和变更验证,让 GitOps 分发更可控。
-
万卡集群算力评审清单-资源池网络与调度联审
万卡集群算力评审不应只汇报 GPU 数量和预算。本文把规划材料拆成资源池、网络、存储、调度和验收证据,帮助多团队在扩容前对失败信号、责任边界和复盘口径达成一致。
-
PaaS平台边界怎么划?IDP、容器平台与云管理平台分工
当应用交付链路越来越长,PaaS、IDP、容器平台和云管理平台容易被混用。本文用责任分工矩阵拆清每类平台的边界,帮助团队决定哪些能力放在 PaaS,哪些交给 IDP、容器底座或云资源治理。
-
大模型平台有哪些类型?生命周期能力地图与建设顺序
大模型平台建设常卡在“先买一套平台还是复用现有系统”。本文按模型生命周期梳理底座能力、上层治理和复用边界,帮助团队判断当前阶段先补训练、推理、注册还是 LLMOps。
-
GPU集群管理软件选型矩阵-5类方案与PoC清单
GPU集群管理软件选型不能只看控制台功能。本文把五类方案放到同一张矩阵中,帮助团队按任务规模、既有技术栈、集成成本和受控失败 PoC 判断哪类方案更适合当前阶段。
云原生技术常见问题
云原生技术主要包括哪些方向?
云原生技术通常包括容器、Kubernetes、微服务、服务治理、DevOps、可观测性、云原生安全和平台工程。它不是单一工具,而是一套围绕弹性、自动化、可扩展和持续交付构建的技术体系。
规划学习或建设路径时,可以先按“运行底座、应用架构、交付流程、稳定性治理、安全合规”五个层次拆开。这样更容易判断当前团队缺的是 Kubernetes 能力、微服务治理能力,还是 DevOps 和平台工程能力。
企业为什么要做云原生转型?
云原生转型的目标通常是提升交付效率、资源利用率、系统弹性和运维自动化水平。对于业务变化快、应用数量多、团队协作复杂的企业,云原生可以帮助基础设施和应用交付更加标准化。
转型前需要先明确目标指标,例如交付频率、环境交付时长、资源利用率、故障恢复时间和发布失败率。没有这些指标,云原生很容易变成技术替换,而不是业务和工程效率提升。
云原生和 Kubernetes 是什么关系?
Kubernetes 是云原生体系中的核心基础设施技术,但云原生不等于 Kubernetes。企业还需要补齐微服务治理、DevOps 流程、可观测性、安全合规和平台工程能力。
Kubernetes 是重要底座,但它不能替代架构治理、研发流程和安全体系。企业在建设时应避免把所有问题都归结为“上 K8s”,而是同步规划镜像、流水线、可观测性和权限治理。
云原生适合所有应用吗?
不是。无状态服务、新建应用、接口服务和弹性需求明显的应用更适合优先云原生化;强依赖本地状态、老旧架构或改造成本过高的系统,需要先做评估。
适配应用时,应区分无状态服务、有状态服务、批处理任务和遗留系统。不同类型的应用对存储、网络、扩缩容和发布策略的要求不同,不能用同一套迁移模板处理所有系统。
显示更多
云原生平台建设从哪里开始?
建议从容器平台和 CI/CD 流程开始,先解决标准运行环境和自动化交付问题,再逐步补齐可观测性、安全治理、多租户和开发者自服务。
平台建设可以从最小闭环开始:镜像构建、环境申请、应用部署、日志查看、监控告警和回滚。这个闭环稳定后,再扩展多租户、多集群、成本治理和开发者门户。
云原生安全需要提前规划吗?
需要。云原生环境的资源变化快、发布频率高,安全能力必须进入镜像、流水线、集群、运行时和访问控制环节,不能等系统上线后再补。
安全能力最好从第一天进入设计,包括镜像准入、RBAC、网络策略、Secret 管理、审计日志和运行时告警。后期再补安全,往往会遇到大量历史配置和流程改造成本。
云原生和平台工程有什么关系?
云原生提供技术底座,平台工程把这些底座能力封装成开发者可自助使用的平台服务,例如应用模板、环境申请、发布流程、日志查询和资源治理。
平台工程的价值在于把底层复杂能力转化为开发者可消费的服务。判断平台是否有效,要看业务团队是否减少等待、减少重复操作,并能在标准边界内自助完成交付。
云原生转型如何衡量效果?
可以从交付频率、变更失败率、恢复时间、资源利用率、环境交付时长、平台自服务使用率和运维成本等指标评估,而不只是看是否使用了 Kubernetes。
效果评估建议结合技术指标和体验指标:既看资源和稳定性,也看开发者等待时间、发布自助率和平台支持工单量。只有两类指标一起改善,才说明云原生建设真正进入可持续阶段。