背景信息

当您在容器服务中架设了一个 web 类型的容器,并通过 routing 将请求转发到这个服务器时,请求的链路是 client > DNS 域名解析 > 负载均衡 VIP > 负载均衡到集群中某一台 acsrouting 容器 > 转发到 web 容器,如下图所示。



在这整个链路过程中,任何一个环节发生问题,用户的请求可能都不能正确地到达 web 容器。下面,我们从最容易发生问题的环节开发者的 web 容器的健康检查开始,来排查访问链路的问题。

操作步骤

  1. 查看容器是否处于运行状态。

    登录 容器服务管理控制台,单击左侧导航栏中的 应用,选择目标应用所在的集群并单击应用的名称,本示例中为 wordpress-test,如下图所示。



  2. 单击应用 wordpress-test 下提供 web 容器的服务的名称,本示例中为 web,如下图所示。


  3. 查看提供 web 服务的容器的健康检查状态。

    容器 选项卡中,检查所有容器在 健康检测 这一列是否均为 正常。如果不正常,请查看相应的 日志 报错信息以及该页面的 事件 选项卡,查看部署是否发生异常。如设置了应用的 健康检查,需要确定健康检查页面返回 200,来确保健康检查的状态是正常的。如下图所示。



  4. 检查 web 容器页面响应是否正常。

    如果容器的健康检查状态没有问题,需要绕过 routing 直接检查 web 容器的可访问性。如上图所示,可以查看到某个 web 容器的容器 IP,登录集群中某台机器的 routing 容器,通过容器 IP 请求 web 容器的页面,如果返回的 HTTP 状态码小于 400,则 web 容器的页面正常。如下所示,docker exec -it f171110f2fe2 shf171110f2fe2 是容器 acsrouting_routing_1 的容器 ID,curl -v 172.19.0.7 中的 IP 地址 172.19.0.7 是某个 web 服务的容器 IP 地址。如下所示,请求返回了状态码 302,说明 web 容器访问是正常的。

     root@c68a460635b8c405e83c052b7c2057c7b-node2:~# docker ps
     CONTAINER ID        IMAGE                                                 COMMAND                  CREATED              STATUS              PORTS                                            NAMES
     b403ea045fa1        registry.aliyuncs.com/acs-sample/wordpress:4.5        "/entrypoint.sh apach"   13 seconds ago       Up 11 seconds       0.0.0.0:32768->80/tcp                            w_web_2
     025f7967cec3        registry.aliyuncs.com/acs-sample/mysql:5.7            "/entrypoint.sh mysql"   About a minute ago   Up About a minute   3306/tcp                                         w_db_1
     2f247b8a76e5        registry.aliyuncs.com/acs/ilogtail:0.9.9              "/bin/sh -c 'sh /usr/"   31 minutes ago       Up 31 minutes                                                        acslogging_logtail_1
     42b75bee6cd8        registry.aliyuncs.com/acs/monitoring-agent:latest     "acs-mon-run.sh --hel"   31 minutes ago       Up 31 minutes                                                        acsmonitoring_acs-monitoring-agent_2
     0a9afa527f03        registry.aliyuncs.com/acs/volume-driver:0.7-252cb09   "acs-agent volume_exe"   31 minutes ago       Up 31 minutes                                                        acsvolumedriver_volumedriver_2
     3c1440fd114c        registry.aliyuncs.com/acs/logspout:0.1-41e0e21        "/bin/logspout"          32 minutes ago       Up 32 minutes                                                        acslogging_logspout_1
     f171110f2fe2        registry.aliyuncs.com/acs/routing:0.7-staging         "/opt/run.sh"            32 minutes ago       Up 32 minutes       127.0.0.1:1936->1936/tcp, 0.0.0.0:9080->80/tcp   acsrouting_routing_1
     0bdeb8464c14        registry.aliyuncs.com/acs/agent:0.7-bfe8bdf           "acs-agent join --nod"   33 minutes ago       Up 33 minutes                                                        acs-agent
     ba32a0e9e7fe        registry.aliyuncs.com/acs/tunnel-agent:0.21           "/acs/agent -config=c"   33 minutes ago       Up 33 minutes                                                        tunnel-agent
     root@c68a460635b8c405e83c052b7c2057c7b-node2:~# docker exec -it f171110f2fe2 sh
     / # curl -v 172.19.0.7
     * Rebuilt URL to: 172.19.0.7/
     *   Trying 172.19.0.7...
     * Connected to 172.19.0.7 (172.19.0.7) port 80 (#0)
       > GET / HTTP/1.1
       > Host: 172.19.0.7
       > User-Agent: curl/7.47.0
       > Accept: */*
       >
       < HTTP/1.1 302 Found
       < Date: Mon, 09 May 2016 03:19:47 GMT
       < Server: Apache/2.4.10 (Debian) PHP/5.6.21
       < X-Powered-By: PHP/5.6.21
       < Expires: Wed, 11 Jan 1984 05:00:00 GMT
       < Cache-Control: no-cache, must-revalidate, max-age=0
       < Pragma: no-cache
       < Location: http://172.19.0.7/wp-admin/install.php
       < Content-Length: 0
       < Content-Type: text/html; charset=UTF-8
       <
     * Connection #0 to host 172.19.0.7 left intact
       / #
  5. 验证 acsrouting 的正确性。

    升级 routing 到最新版本,登录到集群的每一台机器(每一台机器都可能接收请求,不管应用容器在哪台机器上面),请求 routing 健康检查页面,如下所示。

    root@c68a460635b8c405e83c052b7c2057c7b-node2:~# curl -Ss -u admin:admin 'http://127.0.0.1:1936/haproxy?stats' &> test.html

    将页面 test.html 拷贝到有浏览器的机器,用浏览器打开本地文件 test.html,如下图所示。查看相应的 web 服务和容器后端,第一部分为 stats 信息,为 routing 的统计信息,第二部分为 frontend 的统计信息,我们主要观察第三部分 backend 的信息,w_web_80_servers 表示名为 w 的应用下服务 web 的 80 端口的后端 servers 的信息。总共有三个 backend server,即后端有三个容器提供 web 服务,显示为绿色,表示 routing 容器到这三个容器的网络是连通的,在正常工作,显示为其他颜色则为异常。



  6. 查看负载均衡 VIP 的转发是否正确,并查看健康检查的状态。
    1. 如下图所示,找到集群的负载均衡 VIP。单击 容器服务管理控制台 左侧导航栏中的 集群,选择相应的集群,本示例中为 test-swarm。


    2. 单击该集群对应的 管理,进入集群详情页面。单击左侧导航栏中的 负载均衡,查看并复制负载均衡 ID,然后进入 SLB控制台,搜索该负载均衡 ID,找到该负载均衡实例,然后单击该负载均衡实例右侧的 管理,进入负载均衡实例详情页面。


    3. 查看负载均衡实例的服务地址。


    4. 查看负载均衡的端口健康状态。单击左侧导航栏中的 监听状态 显示为 运行中 则表示端口正常。


    5. 查看负载均衡后端挂载的服务器的状态。单击左侧导航栏中的 服务器 > 后端服务器,确保 健康检查状态正常


  7. 查看域名是否正确解析到了负载均衡的 VIP。例如,使用 ping 命令或者 dig 命令查看解析结果。域名解析的结果必须指向前面步骤查找到的负载均衡的 VIP 地址。如下所示。
    $ ping www.example-domain.com
    $ dig www.example-domain.com