容器化部署在阿里云上的完整实践
去年我们团队将一个传统Java单体应用迁移到Docker+K8s架构，部署在阿里云ACK上。整个过程踩了不少坑，今天把经验整理出来分享给大家。文章涵盖环境准备、镜像构建、K8s配置、CI/CD流水线、监控告警等完整链路，希望能帮到正在做容器化迁移的团队。
在讨论「Docker+K8s在阿里云上的部署实践」时，真正决定成败的往往不是某个单点配置，而是把容器与 Kubernetes 编排放进整体架构之后的一致性设计。资源规格、网络边界、弹性策略与故障域需要放在一起权衡，任何一环脱节，都会在流量高峰或故障切换时被成倍放大。
环境准备
首先在阿里云控制台创建一个ACK托管版集群。建议选择专有版而非Serverless版，因为专有版可以自定义节点规格和网络配置，更适合生产环境。节点推荐选择4核16G的通用型g7实例，至少3个节点分布在不同可用区保证高可用。网络插件选择Terway（支持ENI模式，Pod可直接使用VPC网络），Service CIDR建议用 172.21.0.0/20，避免和VPC网段冲突。
集群创建后，别忘了配置以下关键项：开启日志采集（SLS）、开启ARMS应用监控、配置Pod安全策略（禁止root运行）、设置资源配额（ResourceQuota）和限制范围（LimitRange）。
Docker镜像构建
我们使用多阶段构建来减小镜像体积。基础镜像选择 alibaba-cloud-linux-3，JDK使用 dragonwell-11（阿里开源的JDK，针对阿里云有优化）。最终镜像控制在200MB以内。
Dockerfile关键优化：将依赖下载层和代码编译层分离，利用Docker缓存加速构建。使用 .dockerignore 排除不必要的文件。设置非root用户运行应用。健康检查用 HEALTHCHECK 指令配置。
K8s部署配置要点
Deployment中务必设置 resources.limits，防止单个Pod占用过多资源导致节点不稳定。Liveness和Readiness探针必须配置，否则K8s无法正确判断容器健康状态，可能导致流量打到未就绪的Pod上。Service使用ClusterIP类型，通过Ingress暴露外部访问，Ingress Controller选择Nginx Ingress或ALB Ingress。
ConfigMap和Secret要分开管理，敏感信息（数据库密码、API Key）用Secret存储，并开启KMS加密。HPA（水平自动伸缩）建议配置，根据CPU利用率或自定义指标自动调整Pod副本数。
CI/CD流水线
我们使用阿里云效（Flow）构建CI/CD流水线：代码提交 → 代码扫描（SonarQube） → 镜像构建（ACR） → 部署到测试环境 → 自动化测试 → 审批 → 部署到生产环境。整个流程全自动化，发布频率从原来的每月1次提升到每周3次。
踩过的坑
镜像拉取失败：需要在ACK节点上配置容器镜像服务企业版的地域，或者将镜像推到阿里云ACR公共版。跨地域拉取镜像会很慢，建议在每个地域都创建ACR命名空间并开启同步。
Pod调度不均：开启Pod拓扑分布约束（TopologySpreadConstraints），确保Pod均匀分布在不同可用区，避免单点故障。
OOM Killed：Java应用在容器中容易触发OOM，因为JVM默认使用容器的memory limit作为堆上限。需要设置 -XX:MaxRAMPercentage=75.0，给非堆内存留出空间。
日志丢失：容器重启后日志丢失，必须使用Sidecar模式或Volume挂载将日志持久化。推荐直接用Logtail DaemonSet采集容器日志到SLS。
把容器与 Kubernetes 编排放回架构全局来看
单点的最优解，叠加起来未必是全局最优。评估容器与 Kubernetes 编排时，建议先明确业务的峰值模型与故障容忍度，再倒推资源与网络该怎么设计：哪些负载是稳定基线、哪些是突发流量、哪些可以容忍短暂中断，答案不同，架构取向也完全不同。
在此基础上再谈规格与参数，才有意义。否则很容易陷入「先买资源、再找用途」的被动局面，成本与复杂度都会随之上升。
与安徽卓牛一起推进容器与 Kubernetes 编排
安徽卓牛作为阿里云一级代理商，长期服务企业客户的上云与用云全过程，能够围绕容器与 Kubernetes 编排提供架构评审、产品选型、迁移实施与运维托管等一站式支持，帮助团队把精力集中在业务本身。
如果你正在评估「Docker+K8s在阿里云上的部署实践」相关方案，或希望对现有架构做一次体检，欢迎通过官网在线客服联系安徽卓牛，获取贴合自身业务的建议。