您可通过本文了解应用配置迁移过程中的常见问题及解决方法。

文件版本不正确

异常输出
FATA Version 2.1 of Docker Compose is not supported. Please use version 1, 2 or 3

异常原因

kompose工具只支持V1、V2、V3版本的compose格式,不支持V2.X版本;导致整个转换中断。

解决方案

将version: '2.X' 修改为version: '2',重新转换。

标签解析异常

  • 异常输出
    ERRO Could not parse config for project source : Unsupported config option for account-db service: 'external'

    异常原因

    kompose 工具无法解析external标签,导致转换中断。

    解决方案

    出现 ERROFATA 级别的错误,修改原编排文件,移除配置,后续手动迁移配置,迁移方式参见附录 :标签映射列表

  • 异常输出
    ERRO Could not parse config for project source : Unsupported config option for gateway service: 'net'

    异常原因

    kompose 工具无法解析 net 标签,导致转换中断。

    解决方案

    修改原编排文件,移除配置,后续手动迁移配置,迁移方式参见附录 :标签映射列表

标签值格式不正确

  • 异常输出
    ERRO Could not parse config for project source : Service 'auth-service' configuration key 'labels' contains an invalid type, it should be an array or object Unsupported config option for auth-service service: 'latest_image'

    异常原因

    根据提示是latest_image配置值格式无效,kompose 工具无法转换。

    解决方案

    修改原编排文件,修复值配置; 将bool 值修改成字符串形式,true 修改成'true'。

    说明 以下标签列表均有此问题:
    • aliyun.latest_image: true
    • aliyun.global: true
  • 异常输出
    ERRO Could not parse config for project source : Cannot unmarshal '30' of type int into a string value

    异常原因

    值类型不对,查看下compose文件aliyun.log_*标签值是否为30,但未带单引号'',因为其对应结构体应该是string不是int所以得加引号。

    解决方案

    修改原编排文件,修复值配置,然后重新转换; 将30修改成'30'。

标签不支持提醒

  • 异常输出
    WARN Unsupported hostname key - ignoring

    异常原因

    Swarm里面,支持 hostName 作为域名来访问服务,而在compose文件里面并没有声明对应的容器端口,使得kompose工具无法自动创建对应的Kubernetes 服务,导致在Kubernetes里面无法通过hostName来访问应用。

    解决方案

    先部署资源文件,然后在Kubernetes控制台手动创建Kubernetes 服务,其中服务名称即为 hostName;服务端口与容器端口号一致。

  • 异常输出
    WARN Unsupported links key - ignoring

    异常原因

    links 底层跟 hostName 一样,支持通过links名称或别名访问服务;而在 compose 文件里面并没有声明对应的容器端口,使得 kompose 工具无法自动创建对应的 Kubernetes 服务,导致在 Kubernetes 里面无法通过links名称或别名来访问应用。

    解决方案

    先部署资源文件,然后在Kubernetes控制台手动创建Kubernetes Service,其中Service名称即为links名称或别名;服务端口与容器端口号一致。

标签转换有缺陷

  • 异常输出
    WARN Handling aliyun routings label: [{rabbitmq.your-cluster-id.alicontainer.com  http 15672}]

    异常原因

    swarm简单路由里面配置了测试域名(swarm容器服务提供的域名);其跟集群标识cluster-id有关。因为不知道Kubernetes新集群id,kompose无法自动完成新测试域名的转换,需要手动手动对应的ingress文件,更新域名。

    解决方案

    找到各ingress文件*-ingress.yaml,将其中的host: your-cluster-id.alicontainer.com修改成对应Kubernetes集群的测试域名,您可以通过以下操作查看测试域名 :
    1. 登录容器服务管理控制台,在左侧导航栏选择集群 > 集群,在目标集群 Kubernetes-piggymetrics-cluster 右侧单击管理
    2. 基本信息页面,可以看到测试域名的值为*.c7f537c92438f415b943e7c2f8ca30b3b.cn-zhangjiakou.alicontainer.com,将其替换到各个ingress文件的.your-cluster-id.alicontainer.com字符串。
  • 异常输出
    WARN Handling aliyun routings label: [{gateway.your-cluster-id.alicontainer.com  http 4000} {gateway.swarm.piggymetrics.com  http 4000}]

    异常原因

    Swarm 里面简单路由配置多域名,但 kompose 工具转换时只支持单域名转名,后续域名需要自己添加 ingress 规则

    解决方案

    修改转换后的 Kubernetes 资源文件,修复方式参见附录 :标签映射列表

部署应用时报错

  • 异常输出
    error: error validating "logtail2-daemonset.yaml": error validating data: ValidationError(DaemonSet.status): missing required field "numberReady" in io.Kubernetes.api.extensions.v1beta1.DaemonSetStatus; if you choose to ignore these errors, turn validation off with --validate=false

    异常原因

    针对 Swarm 里面的aliyun.global: true 这类服务,kompose 工具会转成 Kubernetes 里面的DaemonSet,但自动转换后的资源文件里面会有status信息,用来记录中间状态;进而导致部署失败。

    status:
    • currentNumberScheduled: 0
    • desiredNumberScheduled: 0
    • numberMisscheduled: 0

    解决方案

    在转换后的 Kubernetes 资源文件*-daemonset.yaml里面,删除 status 信息,再部署应用。

  • 异常输出
    error: error parsing auth-service-deployment.yaml: error converting YAML to JSON: yaml: line 26: did not find expected key

    异常原因

    对应 Kubernetes 资源文件对应行的标签定义不符合要求,解析失败。最常见的是缩进问题,将当前标签误以为上一个标签的子标签,其实应该是兄弟标签等。

    解决方案

    按照标签列表和 Kubernetes 官方文档,确认当前行的正确配置,并修改 Kubernetes 资源文件。

  • 异常输出
    error: error parsing auth-service-deployment.yaml: error converting YAML to JSON: yaml: line 34: found character that cannot start any token

    异常原因

    对应 Kubernetes 资源文件对应行上存在非 token 字符,最常见是tab 按键。

    解决方案

    在转换后的 Kubernetes 资源文件*-daemonset.yaml里面,对应行 tab 修改成空格键。

启动失败

  • 异常输出

    Pod容器一直在重启,并显示健康检查失败。
    Initialized: True
    Ready: False
    ContainersReady: False
    PodScheduled: True

    异常原因

    在 Kubernetes 里面会通过 liveness probe 和 readiness probe 来验证业务容器是否存活或就绪;类似于Swarm里面的 aliyun.probe.url、aliyun.probe.cmd。但 aliyun.probe.url、aliyun.probe.cmd 如果有问题只会标注容器的健康状态,kompose 工具会将其转换为 liveness probe;而在Kubernetes中,如果liveness probe设置有问题,检查失败,则会自动触发重启容器,强制中断原有容器业务的初始化。

    解决方案
    1. 先验证是否为探针设置问题。

      先去掉 liveness probe 或 readiness probe探针,如果应用能启动成功,则说明是探针时间设置有问题。

    2. 修复问题。

      根据业务需要,确认容器真正启动完成耗时,到 Kubernetes 对应应用配置里合理设置 liveness probe 的配置,尤其是其中的延迟探测时间执行探测频率超时时间等字段,具体参见镜像创建无状态Deployment应用

  • 异常输出

    Pod容器一直在重启,并显示健康检查失败。
    Initialized: True
    Ready: False
    ContainersReady: False
    PodScheduled: True
    进入容器查看日志如下:
    2019-05-22 06:42:09.245  INFO [gateway,,,] 1 --- [           main] c.c.c.ConfigServicePropertySourceLocator : Connect Timeout Exception on Url - http://config:8888. Will be trying the next url if available

    异常原因

    在这里请求 config:8888 超时,之前是因为该 Pod 的网络模型设置出错,设置了hostNetwork: true,通过ECS 网络栈导致解析不了 Kubernetes service 名称。

    但我们已经修复gateway-deployment.yaml里面的配置,并通过kubectl apply重新部署,但还是一直报错。

    解决方案

    这种情况下,有时是因各种原因导致新配置*-deployment.yaml没有真正生效。

    可以在保存配置后,登录容器服务管理控制台,删除对应的应用,再通过 kubectl 重新部署。