从Red Hat OpenShift集群迁移应用到Azure Kubernetes Service相关咨询

前置条件 #

• 完成OpenShift侧全量资产盘点：覆盖所有应用负载（Deployment、StatefulSet、DaemonSet等）、配置类资源（ConfigMap、Secret）、持久化存储（PVC/PV）、路由规则、服务账号与权限配置、自定义CRD、依赖的中间件服务、镜像仓库地址与全量应用镜像版本、网络策略
• 提前配置符合要求的AKS集群：节点计算/存储/网络规格匹配原应用资源需求、集群Kubernetes版本与OpenShift依赖的基础K8s版本兼容、存储类配置覆盖原应用持久化需求、CNI插件选型支持原应用的网络规则、RBAC权限体系提前完成映射规划
• 完成镜像资产预迁移：将OpenShift侧用到的所有镜像同步到AKS关联的Azure容器注册表（ACR），完成镜像漏洞扫描、签名校验，确保可正常拉取
• 完成试点预验证：在测试环境搭建同规格AKS集群，选择1-2个非核心应用做试点迁移，验证部署、访问、数据读写逻辑正常，排除基础适配问题

重点注意事项 #

• OpenShift专有资源适配：OpenShift特有的Route资源需转换为AKS的Ingress资源，Source-to-Image(S2I)构建配置需替换为AKS支持的镜像构建流水线，内置OAuth认证、Project资源（对应标准K8s的Namespace）、Security Context Constraints(SCC)需分别适配为AKS的RBAC规则、Pod安全标准/策略配置
• 持久化数据迁移：有状态应用迁移前需暂停OpenShift侧应用写入权限，通过存储快照、数据同步工具完成PV数据到AKS对应存储PV的迁移，迁移后必须做数据一致性校验，避免数据丢失
• 网络规则适配：原集群的网络策略、内部服务访问地址、对外暴露的域名配置需同步调整到AKS侧，若使用了OpenShift的Service Mesh能力，需对应迁移到AKS支持的Istio或Open Service Mesh配置
• 流量割接方案：建议采用灰度切流方案，先将小部分流量导到AKS侧的应用，观测运行指标（延迟、错误率、资源使用率）无异常后再逐步放大流量占比，预留回滚能力，避免一次性全量割接引发故障
• 可观测体系适配：OpenShift内置的监控、日志、告警规则需要对应适配AKS的Azure Monitor、容器Insights配置，确保迁移后应用运行状态可观测
• 权限体系映射：OpenShift的集群角色、项目级权限需要和AKS的Azure AD集成权限、K8s RBAC角色做一一映射，避免迁移后应用、运维人员出现权限不足或越权问题

参考学习资源 #

• 微软官方AKS异构集群迁移相关文档，包含标准迁移流程、适配工具说明
• Red Hat官方OpenShift与标准Kubernetes差异对照表，可快速掌握OpenShift专有能力和标准K8s资源的对应关系
• 技术社区同场景迁移实战案例，包含踩坑记录、适配脚本参考
• AKS官方最佳实践文档，可用于迁移后的集群运维、应用优化参考

内容的提问来源于stack exchange，提问作者Sarmad