引言

Docker让容器化变得简单，而天翼云容器服务CTK让容器化变得省心。这句话听起来像是一句完美的升级宣言，但从Docker迁移到CTK的过程中，无数开发者踩过的坑告诉我们：简单和省心之间，隔着一道看不见的鸿沟。你以为把Docker Compose文件里的内容"搬"到CTK上就完事了，结果发现应用启动失败、网络不通、数据丢失、健康检查频繁误判……这些问题的根源，不在于CTK不好用，而在于Docker和Kubernetes（CTK的底层引擎）之间存在一系列深层差异，而这些差异在迁移过程中极易被忽略。本文将从五个最常见、最致命的迁移陷阱出发，逐一拆解其成因，并给出经过实战验证的规避方案。

陷阱一：镜像"能跑"不等于"能迁移"——镜像构建与运行时的隐性差异

这是迁移中最容易被忽视、却最容易翻车的陷阱。在本地Docker环境中运行完美的镜像，部署到CTK后可能出现各种诡异行为：应用启动后立即崩溃、端口监听失败、时区异常、时区配置丢失、文件权限错误……

问题的根源在于：Docker的运行时环境与CTK底层的Kubernetes运行时环境存在诸多隐性差异。Docker容器通常以root权限运行，而CTK基于Kubernetes的安全最佳实践，默认以非root用户运行容器。如果你的Dockerfile中没有显式指定运行用户，镜像在本地以root身份运行一切正常，但在CTK中会因权限不足而失败。此外，Docker默认不限制资源，而CTK对Pod的CPU和内存有明确的资源配额，如果应用在本地吃满了整机资源，到了CTK的资源限制下就会被OOM Kill（内存溢出杀掉）。

规避方案：

第一，在Dockerfile中显式指定非root用户，并确保该用户对所有工作目录有读写权限。第二，在迁移前对镜像进行资源适配测试，在本地用Docker运行时加上与CTK相同的资源限制参数，提前暴露资源不足的问题。第三，统一时区配置，不要依赖宿主机时区，而是在Dockerfile中通过环境变量显式设置时区。第四，镜像构建时明确声明暴露的端口，不要依赖Docker的隐式端口映射，因为CTK的Service机制需要精确的端口声明。

陷阱二：网络模型的"降维打击"——从桥接网络到Service网络

在Docker Compose中，服务之间通过服务名直接通信，Docker的内置DNS会自动解析。开发者习惯了"服务A访问服务B，直接用服务名拼端口"的简单模式。但到了CTK中，这套逻辑完全变了。

Kubernetes的网络模型与Docker存在本质差异。CTK中的Pod拥有独立的IP地址，但Pod是短暂的——重启后IP会变。因此，不能靠IP地址通信，而必须通过Service对象提供稳定的访问入口。更关键的是，Docker Compose中的depends_on只能控制启动顺序，不能保证依赖服务已经就绪；而CTK中的Service与Pod之间的通信需要额外配置就绪探针，否则可能出现"A已经启动但B还没准备好，A就开始调用B"的竞态问题。

规避方案：

迁移前，先梳理清楚应用内部的服务依赖关系，为每个服务创建对应的CTK Service，并确保Service的选择器能正确匹配Pod标签。不要依赖Pod IP进行服务间通信，所有跨服务调用必须走Service的ClusterIP或域名。对于有启动顺序要求的服务，不要仅依赖depends_on，而要配置就绪探针（Readiness Probe），确保依赖服务真正可用后再开始调用。同时，注意Docker Compose中的links和network_mode: host在CTK中没有直接等价物，需要重新设计网络拓扑。

陷阱三：数据持久化的"失忆症"——卷挂载到持久卷的认知断层

Docker中做数据持久化非常直观：一条卷挂载命令，数据就留在了宿主机上。但在CTK中，数据持久化的逻辑完全不同。CTK使用持久卷（PV）和持久卷声明（PVC）机制，数据不再绑定到某台具体的宿主机，而是由底层存储系统统一管理。

迁移中最常见的问题有三个：一是直接把Docker的绑定挂载（Bind Mount）逻辑搬过来，结果发现CTK不支持或不推荐这种方式；二是忽略了存储类（StorageClass）的选择，导致性能不达标或成本失控；三是多副本应用共享同一个PVC时，触发了读写冲突——因为大多数文件系统不支持多Pod同时读写同一个卷。

规避方案：

首先，迁移前明确数据的访问模式：是单Pod独享，还是多Pod共享？如果是独享，使用标准PVC即可；如果是共享，必须选择支持多读写的存储类型（如分布式文件系统），或者干脆将共享数据迁移到独立的数据服务中，不要让多个Pod直接竞争同一个文件卷。其次，根据业务对IO性能和数据可靠性的要求，选择合适的存储类。CTK提供了多种存储类型，从高性能SSD到大容量HDD，开发者需要根据实际场景做选择，而不是默认使用第一个选项。最后，务必在迁移前对数据做完整备份，PV的迁移不像Docker卷那么随意，一旦配置错误，数据恢复的成本极高。

陷阱四：环境变量与配置管理的"散装陷阱"——从docker-compose.yml到ConfigMap

在Docker Compose中，环境变量写在environment字段里，配置文件挂载在volumes里，一切都在一个文件中，清晰明了。但迁移到CTK后，很多开发者发现：环境变量不生效了，配置文件读取不到了，应用启动参数乱了。

原因在于：Docker Compose和Kubernetes对配置的管理方式完全不同。CTK中，环境变量通过ConfigMap或Secret注入，配置文件通过ConfigMap挂载为独立文件或环境变量。最容易踩的坑是：ConfigMap的更新不会自动触发Pod重启——你改了ConfigMap，Pod里的应用根本不知道，还在用旧配置跑。另外，Secret和ConfigMap虽然看起来相似，但Secret的数据是Base64编码的，不适合存储明文配置，很多开发者混用两者导致配置读取失败。

规避方案：

将所有环境变量和配置文件统一迁移到ConfigMap中，并通过环境变量引用或文件挂载两种方式注入Pod。关键原则：敏感信息（密码、密钥）放Secret，非敏感配置放ConfigMap，绝不混用。对于需要热更新的配置，不要指望改ConfigMap后应用自动感知，而要在Deployment中配置滚动更新策略，让Pod在配置变更后自动重启加载新配置。此外，建议使用Kustomize或Helm等配置管理工具，将环境差异化（开发、测试、生产）的配置抽离出来，避免硬编码。

陷阱五：健康检查的"误判风暴"——从Docker HEALTHCHECK到K8s探针

Docker的HEALTHCHECK机制相对简单：执行一条命令，根据退出码判断健康状态。很多开发者在Dockerfile中写好了健康检查，迁移到CTK后直接复用，结果发现CTK的探针频繁误判，导致Pod被反复重启，服务陷入"启动—崩溃—重启—崩溃"的死循环。

根本原因在于：Docker的HEALTHCHECK和Kubernetes的存活探针（Liveness Probe）、就绪探针（Readiness Probe）是两套完全不同的机制。Docker只有一种检查，而Kubernetes有两种，且触发逻辑不同。存活探针失败会导致容器重启，就绪探针失败会导致Pod从Service后端摘除。很多开发者把Docker的健康检查直接映射为存活探针，但实际上它更适合作为就绪探针——因为应用可能启动慢但最终能成功，不应该因此被重启。

更隐蔽的问题是初始延迟设置不当。Docker的健康检查通常在容器启动后立即开始，而Kubernetes探针有initialDelaySeconds参数控制首次检测的延迟时间。如果应用启动需要30秒，但探针在第5秒就开始检测，必然判定失败。

规避方案：

不要直接复用Docker的HEALTHCHECK，而是根据CTK的探针机制重新设计。原则是：用存活探针检测"应用是否彻底死了"（比如进程崩溃、死锁），用就绪探针检测"应用是否准备好接收流量"（比如依赖服务是否连通、缓存是否预热）。初始延迟时间必须大于应用的实际启动时间，建议设置为应用正常启动耗时的1.5倍。探测间隔不要太短，避免给应用造成额外负担。对于有状态服务，务必配置就绪探针，否则流量可能被转发到尚未初始化完成的Pod上。

结语

从Docker到CTK，不是一次简单的"搬家"，而是一次架构思维的升级。Docker解决的是"怎么把应用打包跑起来"，CTK解决的是"怎么让应用稳定、弹性、可观测地跑在生产环境"。五个陷阱的背后，是两种技术范式的根本差异：Docker是单机思维，CTK是集群思维。理解这个差异，才能在迁移中少走弯路。不要试图让CTK适应你在Docker中的习惯，而是让你的应用适配CTK的最佳实践——这才是迁移的正确姿态。