故障排除

• 1: Workflow 故障排除
• 2: 使用 Kubectl 进行故障排除
• 3: 应用故障排除

1 - Workflow 故障排除

组件启动失败

有关故障排除失败组件的信息，请参见使用 Kubectl 进行故障排除。

应用启动失败

有关应用部署问题故障排除的信息，请参见应用故障排除。

权限被拒绝 (publickey)

此问题最常见的原因是用户忘记运行 drycc keys:add 或将他们的私钥添加到 SSH 代理。要这样做，请运行 ssh-add ~/.ssh/id_rsa，然后再次尝试运行 git push drycc master。

如果在尝试运行上述 ssh-add 命令后收到 Could not open a connection to your authentication agent 错误，您可能需要在运行 ssh-add 之前通过发出 eval "$(ssh-agent)" 命令来加载 SSH 代理环境变量。

其他问题

遇到这里没有详细说明的问题？请打开一个 issue 或加入 Slack 上的 #community 获取帮助！

2 - 使用 Kubectl 进行故障排除

本文档描述了如何使用 kubectl 来调试集群的任何问题。

深入了解组件

使用 kubectl，可以检查集群的当前状态。当使用 helm 安装 Workflow 时，Workflow 被安装到 drycc 命名空间中。要检查 Workflow 是否正在运行，请运行：

$ kubectl --namespace=drycc get pods
NAME                          READY     STATUS              RESTARTS   AGE
drycc-builder-gqum7            0/1       ContainerCreating   0          4s
drycc-controller-h6lk6         0/1       ContainerCreating   0          4s
drycc-controller-celery-cmxxn  0/3       ContainerCreating   0          4s
drycc-database-56v39           0/1       ContainerCreating   0          4s
drycc-fluentbit-xihr1          0/1       Pending             0          2s
drycc-storage-c2exb            0/1       Pending             0          3s
drycc-grafana-9ccur            0/1       Pending             0          3s
drycc-registry-5bor6           0/1       Pending             0          3s

要获取特定组件的日志，请使用 kubectl logs：

$ kubectl --namespace=drycc logs drycc-controller-h6lk6
system information:
Django Version: 1.9.6
Python 3.5.1
addgroup: gid '0' in use
Django checks:
System check identified no issues (2 silenced).
[...]

要深入运行中的容器来检查其环境，请使用 kubectl exec：

$ kubectl --namespace=drycc exec -it drycc-database-56v39 gosu postgres psql
psql (13.4 (Debian 13.4-1.pgdg100+1))
Type "help" for help.

postgres=# \l
                                                List of databases
     Name          |  Owner   | Encoding |  Collate   |   Ctype    |   Access privileges
-------------------+----------+----------+------------+------------+-----------------------
 drycc_controller  | postgres | UTF8     | en_US.utf8 | en_US.utf8 |
 drycc_passport    | postgres | UTF8     | en_US.utf8 | en_US.utf8 |
 postgres          | postgres | UTF8     | en_US.utf8 | en_US.utf8 |
 template0         | postgres | UTF8     | en_US.utf8 | en_US.utf8 | =c/postgres          +
                   |          |          |            |            | postgres=CTc/postgres
 template1         | postgres | UTF8     | en_US.utf8 | en_US.utf8 | =c/postgres          +
                   |          |          |            |            | postgres=CTc/postgres
(4 rows)
postgres=# \connect drycc_controller
You are now connected to database "drycc_controller" as user "postgres".
drycc_controller=# \dt
                                 List of relations
 Schema |              Name              | Type  |      Owner
--------+--------------------------------+-------+-------------------
 public | api_app                        | table | drycc_controller
 public | api_build                      | table | drycc_controller
 public | api_certificate                | table | drycc_controller
 public | api_config                     | table | drycc_controller
 public | api_domain                     | table | drycc_controller
 public | api_key                        | table | drycc_controller
 public | api_push                       | table | drycc_controller
 public | api_release                    | table | drycc_controller
 public | auth_group                     | table | drycc_controller
 --More--
 drycc_controller=# SELECT COUNT(*) from api_app;
 count
-------
     0
(1 row)

3 - 应用故障排除

应用有 Dockerfile，但发生了 Buildpack 部署

当您使用 git push drycc master 将应用部署到 Workflow 时，如果 Builder 尝试使用 Buildpack 工作流进行部署，请检查以下步骤：

1. 您是否在部署正确的项目？
2. 您是否在推送正确的 git 分支（git push drycc <branch>）？
3. Dockerfile 是否在项目的根目录中？
4. 您是否已将 Dockerfile 提交到项目中？

应用已部署，但无法启动

如果您部署了应用但它无法启动，您可以使用Drycc Grafana来检查应用无法启动的原因。有时，应用容器可能在没有记录任何错误信息的情况下启动失败。这通常发生在为应用配置的健康检查失败时。在这种情况下，您可以首先使用 kubectl 进行故障排除。您可以通过检查部署在应用命名空间中的 pod 来检查应用当前状态。为此，请运行

$ kubectl --namespace=myapp get pods
NAME                          READY     STATUS                RESTARTS   AGE
myapp-web-1585713350-3brbo    0/1       CrashLoopBackOff      2          43s

然后我们可以描述 pod 并确定它为什么无法启动：

Events:
  FirstSeen     LastSeen        Count   From                            SubobjectPath                           Type            Reason          Message
  ---------     --------        -----   ----                            -------------                           --------        ------          -------
  43s           43s             1       {default-scheduler }                                                    Normal          Scheduled       Successfully assigned myapp-web-1585713350-3brbo to kubernetes-node-1
  41s           41s             1       {kubelet kubernetes-node-1}     spec.containers{myapp-web}              Normal          Created         Created container with container id b86bd851a61f
  41s           41s             1       {kubelet kubernetes-node-1}     spec.containers{myapp-web}              Normal          Started         Started container with container id b86bd851a61f
  37s           35s             1       {kubelet kubernetes-node-1}     spec.containers{myapp-web}              Warning         Unhealthy       Liveness probe failed: Get http://10.246.39.13:8000/healthz: dial tcp 10.246.39.13:8000: getsockopt: connection refused

在这种情况下，我们将应用的健康检查初始延迟超时设置为 1 秒，这太激进了。应用在容器启动后需要一些时间来设置 API 服务器。通过将健康检查初始延迟超时增加到 10 秒，应用能够启动并正确响应。

有关如何自定义应用健康检查以更好地满足应用需求的更多信息，请参见自定义健康检查。