解析 Ingress-Nginx 故障：排查思路与方法

文章目录

一、什么是Ingress-Nginx
二、故障排除
- 1.1Ingress-Controller日志和事件
- - 检查 Ingress 资源事件
  - 检查 Nginx 配置
  - 检查使用的服务是否存在
  - 调试日志
- 1.2对 Kubernetes API 服务器的认证
- - 服务认证
  - 服务账户
  - Kube-Config
- 1.3使用GDB和Nginx
- 1.4在 Nginx 4.2.5 或其他版本（Helm 图表版本）上遇到的图像相关问题
- 1.5无法监听端口（80/443）
- - 创建一个测试pod
- 1.6使用root创建测试pod

一、什么是Ingress-Nginx

Ingress-nginx 是 Kubernetes 的一个 Ingress 控制器，它可以将外部的 HTTP 和 HTTPS 流量路由到集群内部的服务。Ingress 是 Kubernetes 中的一个 API 对象，它管理外部访问到集群服务的规则。Ingress 可以提供负载均衡、SSL 终结和基于名称的虚拟主机等功能。
Ingress-nginx 控制器是 Ingress 资源的一种实现，它根据定义在 Ingress 资源中的规则，动态地配置 Nginx 服务器，以路由流量。这使得你可以很方便地在 Kubernetes 集群中实现复杂的流量路由规则。

二、故障排除

1.1Ingress-Controller日志和事件

有许多方法可以对 ingress-controller 进行故障排除。以下是获取更多信息的基本故障排除方法。

检查 Ingress 资源事件

$ kubectl get ing -n <namespace-of-ingress-resource>
NAME           HOSTS      ADDRESS     PORTS     AGE
cafe-ingress   cafe.com   10.0.2.15   80        25s$ kubectl describe ing <ingress-resource-name> -n <namespace-of-ingress-resource>
Name:             cafe-ingress
Namespace:        default
Address:          10.0.2.15
Default backend:  default-http-backend:80 (172.17.0.5:8080)
Rules:Host      Path  Backends----      ----  --------cafe.com/tea      tea-svc:80 (<none>)/coffee   coffee-svc:80 (<none>)
Annotations:kubectl.kubernetes.io/last-applied-configuration:  {"apiVersion":"networking.k8s.io/v1","kind":"Ingress","metadata":{"annotations":{},"name":"cafe-ingress","namespace":"default","selfLink":"/apis/networking/v1/namespaces/default/ingresses/cafe-ingress"},"spec":{"rules":[{"host":"cafe.com","http":{"paths":[{"backend":{"serviceName":"tea-svc","servicePort":80},"path":"/tea"},{"backend":{"serviceName":"coffee-svc","servicePort":80},"path":"/coffee"}]}}]},"status":{"loadBalancer":{"ingress":[{"ip":"169.48.142.110"}]}}}Events:Type    Reason  Age   From                      Message----    ------  ----  ----                      -------Normal  CREATE  1m    ingress-nginx-controller  Ingress default/cafe-ingressNormal  UPDATE  58s   ingress-nginx-controller  Ingress default/cafe-ingress

检查 Nginx 配置

$ kubectl get pods -n <namespace-of-ingress-controller>
NAME                                        READY     STATUS    RESTARTS   AGE
ingress-nginx-controller-67956bf89d-fv58j   1/1       Running   0          1m$ kubectl exec -it -n <namespace-of-ingress-controller> ingress-nginx-controller-67956bf89d-fv58j -- cat /etc/nginx/nginx.conf
daemon off;
worker_processes 2;
pid /run/nginx.pid;
worker_rlimit_nofile 523264;
worker_shutdown_timeout 240s;
events {multi_accept        on;worker_connections  16384;use                 epoll;
}
http {
....

检查使用的服务是否存在

$ kubectl get svc --all-namespaces
NAMESPACE     NAME                   TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)         AGE
default       coffee-svc             ClusterIP   10.106.154.35    <none>        80/TCP          18m
default       kubernetes             ClusterIP   10.96.0.1        <none>        443/TCP         30m
default       tea-svc                ClusterIP   10.104.172.12    <none>        80/TCP          18m
kube-system   default-http-backend   NodePort    10.108.189.236   <none>        80:30001/TCP    30m
kube-system   kube-dns               ClusterIP   10.96.0.10       <none>        53/UDP,53/TCP   30m
kube-system   kubernetes-dashboard   NodePort    10.103.128.17    <none>        80:30000/TCP    30m

调试日志

通过使用标志 --v=XX，可以增加日志的级别。这是通过编辑部署来完成的。

$ kubectl get deploy -n <namespace-of-ingress-controller>
NAME                       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
default-http-backend       1         1         1            1           35m
ingress-nginx-controller   1         1         1            1           35m$ kubectl edit deploy -n <namespace-of-ingress-controller> ingress-nginx-controller
# Add --v=X to "- args", where X is an integer

–v=2 显示了关于 nginx 配置更改的详细信息，这些信息是通过 diff 显示的
–v=3 显示了关于服务、Ingress规则、端点更改的详细信息，并且它会以 JSON 格式输出 nginx 配置
–v=5 将 NGINX 配置为调试模式

1.2对 Kubernetes API 服务器的认证

许多组件参与了认证过程，第一步是确定问题的来源，即问题是出在服务认证上，还是出在 kubeconfig 文件上。
这两种认证都必须有效：
在这里插入图片描述

服务认证

Ingress 控制器需要从 apiserver 获取信息。因此，需要进行认证，这可以通过几种方式实现：

服务账户：这是推荐的方式，因为无需进行任何配置。Ingress 控制器将使用系统提供的信息与 API 服务器进行通信。详见 ‘服务账户’ 部分。
Kubeconfig 文件：在一些 Kubernetes 环境中，服务账户可能不可用。在这种情况下，需要手动配置。可以使用 --kubeconfig 标志启动 Ingress 控制器二进制文件。该标志的值是一个文件路径，该文件指定了如何连接到 API 服务器。使用 --kubeconfig 不需要 --apiserver-host 标志。文件的格式与 kubectl 用于连接 API 服务器的 ~/.kube/config 相同。详见 ‘kubeconfig’ 部分。
使用 --apiserver-host 标志：使用这个标志 --apiserver-host=http://localhost:8080 可以指定一个未加密的 API 服务器，或者使用 kubectl proxy 访问远程 Kubernetes 集群。请不要在生产环境中使用这种方法。
在下面的图表中，你可以看到所有选项的完整认证流程，从左下角的浏览器开始。

服务账户

如果使用服务账户连接 API 服务器，ingress-controller 期望文件 /var/run/secrets/kubernetes.io/serviceaccount/token 存在。它提供了一个秘密令牌，该令牌是与 API 服务器进行身份验证所必需的。
可以使用以下命令进行验证：

# start a container that contains curl
$ kubectl run -it --rm test --image=curlimages/curl --restart=Never -- /bin/sh# check if secret exists
/ $ ls /var/run/secrets/kubernetes.io/serviceaccount/
ca.crt     namespace  token
/ $# check base connectivity from cluster inside
/ $ curl -k https://kubernetes.default.svc.cluster.local
{"kind": "Status","apiVersion": "v1","metadata": {},"status": "Failure","message": "forbidden: User \"system:anonymous\" cannot get path \"/\"","reason": "Forbidden","details": {},"code": 403
}/ $# connect using tokens
}/ $ curl --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt -H  "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" https://kubernetes.default.svc.cluster.local
&& echo
{"paths": ["/api","/api/v1","/apis","/apis/",... TRUNCATED"/readyz/shutdown","/version"]
}
/ $# when you type `exit` or `^D` the test pod will be deleted.

如果它不起作用，可能有两个原因：
令牌的内容无效。使用 kubectl get secrets | grep service-account 找到秘密名称，并使用 kubectl delete secret 删除它。它将自动重新创建。
您的 Kubernetes 安装非标准，包含令牌的文件可能不存在。API 服务器将挂载包含此文件的卷，但前提是 API 服务器配置为使用 ServiceAccount 准入控制器。如果您遇到此错误，请验证您的 API 服务器是否正在使用 ServiceAccount 准入控制器。如果您手动配置 API 服务器，可以使用 --admission-control 参数设置此项。
请注意，您也应使用其他准入控制器。在配置此选项之前，您应阅读关于准入控制器的信息。

Kube-Config

如果你想使用 kubeconfig 文件进行认证，请遵循部署程序，并在部署的 args 部分添加标志 --kubeconfig=/etc/kubernetes/kubeconfig.yaml。

1.3使用GDB和Nginx

我们可以使用 gdb 和 nginx 一起执行配置的转储。这使我们能看到正在使用的配置以及旧的配置。
注意：以下内容基于 nginx 的文档。

SSH 连接到工作节点

$ ssh user@workerIP

获取运行nginx的Docker容器

$ docker ps | grep ingress-nginx-controller
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
d9e1d243156a        registry.k8s.io/ingress-nginx/controller   "/usr/bin/dumb-init …"   19 minutes ago      Up 19 minutes   k8s_ingress-nginx-controller_ingress-nginx-controller-67956bf89d-mqxzt_kube-system_079f31ec-aa37-11e8-ad39-080027a227db_0

执行进入容器

$ docker exec -it --user=0 --privileged d9e1d243156a bash

确保nginx在–with-debug模式下运行

$ nginx -V 2>&1 | grep -- '--with-debug'

获取容器上运行的进程列表

$ ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 20:23 ?        00:00:00 /usr/bin/dumb-init /nginx-ingres
root         5     1  0 20:23 ?        00:00:05 /ingress-nginx-controller --defa
root        21     5  0 20:23 ?        00:00:00 nginx: master process /usr/sbin/
nobody     106    21  0 20:23 ?        00:00:00 nginx: worker process
nobody     107    21  0 20:23 ?        00:00:00 nginx: worker process
root       172     0  0 20:43 pts/0    00:00:00 bash

将gdb附加到nginx主进程

$ gdb -p 21
....
Attaching to process 21
Reading symbols from /usr/sbin/nginx...done.
....
(gdb)

复制并粘贴以下内容

set $cd = ngx_cycle->config_dump
set $nelts = $cd.nelts
set $elts = (ngx_conf_dump_t*)($cd.elts)
while ($nelts-- > 0)
set $name = $elts[$nelts]->name.data
printf "Dumping %s to nginx_conf.txt\n", $name
append memory nginx_conf.txt \$elts[$nelts]->buffer.start $elts[$nelts]->buffer.end
end

通过按CTRL+D退出GDB
打开nginx_conf.txt

cat nginx_conf.txt

注意：从GitHub和BitBucket Server（源SCMs）迁移依赖于从GitLab（目标）发出的传入（Ingress）REST API连接。
"./congregate.sh list" 是一个命令，它从源系统收集元数据，为迁移的后续步骤做准备。列表操作会从这些系统中提取所有的元数据，通常需要管理员令牌或只读所有凭据才能成功。要设置这些，请运行 "./congregate.sh configure"，或者修改由客户提供的SCM和/或CI源主机名和凭据的data/congregate.conf。如果你直接编辑 .conf 文件，一定要参考 congregate 配置模板，以正确格式化它。
列表操作可能需要相当长的时间，这直接取决于源系统中的数据量。要调整列表的并发性，你可以在列表命令中添加 --processes=16（仅适用于GitHub）。如果不设置这个，它将使用基于硬件的进程数的 processes=nproc。当进程超过16个时要小心，因为这将增加对源系统造成不必要伤害的机会（如果他们的API速率限制没有设置，可能会导致稳定性问题）。
如果你需要重新列出并且不想覆盖之前列出的任何数据，可以使用 --partial 运行它。额外的 --skip-* 参数允许你跳过用户、组、项目和 ci。
如果你正在从带有SCM源的CI源迁移数据，列表操作也会执行一个映射功能，将CI任务映射到SCM仓库。这个功能将定位构建配置XML的迁移到仓库，以备将来转换为 gitlab-ci.yml。
为迁移准备数据的过程与使用基于git的工作流准备数据的过程相同。现在我们已经运行了"./congregate.sh list"命令，将所有数据获取到本地文件系统（本地MongoDB和.json文件的组合），我们需要选择要迁移的用户，项目和组。任何形式的stage命令的输出将会是data目录中的staged_groups.json，staged_projects.json和staged_users.json文件。
在shell中运行stage（无UI）时，我们需要确定当前迁移范围内的项目和组ID。我们可以通过几种不同的方式进行分阶段。
stage-projects
要从项目的名称（客户应该已经提供）获取项目ID，你可以运行 cat data/projects.json | grep <ProjectName> -A10 -B10 命令，其中ProjectName是要迁移的存储库（github和bitbucket）或项目（gitlab）的名称。从那里你将看到可以为以下命令记下的ID ./congregate.sh stage-projects 13 78 951 446。注意，你可以在stage-projects动词后面空格分隔地列出多个项目id。要强制此命令写入staged_projects.json和其他staged json文件，请使用–commit标志。
stage-groups
这个过程与stage-projects非常相似，但你需要在groups.json文件中搜索组id。运行 cat data/projects.json | grep <GroupName> -A10 -B10 命令。然后运行 ./congregate.sh stage-groups 78 651 997 --commit 来生成staged_*.json文件。

stage-wave
对于大型迁移，客户通常希望在电子表格中定义迁移波次，以便congregate可以读取并同时分阶段多个不同的组和项目，而无需进行项目和组id的初步调查。要设置这个，我们需要在data/congregate.conf中添加几行，看起来像模板中的那些。此配置模板引用waves.csv文件。关于此配置如何工作的更详细描述在下面的配置部分。
一旦我们有了这个，你可以运行 ./congregate.sh stage-wave <WaveName> --commit 来分阶段所有由电子表格定义的项目和组。
使用UI进行分阶段
如果你是在完整的桌面环境中运行congregate（没有SSH或BASH进入在集群上运行的容器），你可以使用UI在列出数据后进行分阶段，方法是使用 ./congregate.sh ui &。这将让你有能力选择你想要为迁移分阶段的特定组，项目和用户。一旦你选中了所有的框，你可以点击stage来生成迁移的最后一步所需的staged_*.json文件。

1.4在 Nginx 4.2.5 或其他版本（Helm 图表版本）上遇到的图像相关问题

如果你在使用 helm 图表安装 Nginx 时遇到以下错误（无论是通过 helm 命令或 helm_release terraform 提供程序）

Warning  Failed     5m5s (x4 over 6m34s)   kubelet            Failed to pull image "registry.k8s.io/ingress-nginx/kube-webhook-certgen:v1.3.0@sha256:549e71a6ca248c5abd51cdb73dbc3083df62cf92ed5e6147c780e30f7e007a47": rpc error: code = Unknown desc = failed to pull and unpack image "registry.k8s.io/ingress-nginx/kube-webhook-certgen@sha256:549e71a6ca248c5abd51cdb73dbc3083df62cf92ed5e6147c780e30f7e007a47": failed to resolve reference "registry.k8s.io/ingress-nginx/kube-webhook-certgen@sha256:549e71a6ca248c5abd51cdb73dbc3083df62cf92ed5e6147c780e30f7e007a47": failed to do request: Head "https://eu.gcr.io/v2/k8s-artifacts-prod/ingress-nginx/kube-webhook-certgen/manifests/sha256:549e71a6ca248c5abd51cdb73dbc3083df62cf92ed5e6147c780e30f7e007a47": EOF

请按照以下步骤操作。

在故障排查过程中，你也可以执行以下命令来测试你的本地机器与仓库详情的连通性。

curl registry.k8s.io/ingress-nginx/kube-webhook-certgen@sha256:549e71a6ca248c5abd51cdb73dbc3083df62cf92ed5e6147c780e30f7e007a47 > /dev/nullcurl -I https://eu.gcr.io/v2/k8s-artifacts-prod/ingress-nginx/kube-webhook-certgen/manifests/sha256:549e71a6ca248c5abd51cdb73dbc3083df62cf92ed5e6147c780e30f7e007a47

在代理中实现了重定向，以确保拉取图像。

这是建议将以下图像仓库列入白名单的解决方案：

*.appspot.com    
*.k8s.io        
*.pkg.dev
*.gcr.io

关于上述仓库的更多详细信息：a. *.k8s.io -> 为了确保你能从registry.k8s.io拉取任何图像 b. *.gcr.io -> GCP服务用于图像托管。这是GCP建议允许并确保用户可以从他们的容器注册服务拉取图像的域的一部分。c. *.appspot.com -> 这是Google的域，用于GCR的域的一部分。

1.5无法监听端口（80/443）

这个错误的一个可能原因是缺乏绑定到端口的权限。端口80，443和任何其他< 1024的端口是Linux特权端口，历史上只能由root绑定。ingress-nginx-controller使用CAP_NET_BIND_SERVICE linux能力来允许作为普通用户（www-data / 101）绑定这些端口。这涉及两个组件：1. 在镜像中，/nginx-ingress-controller文件添加了cap_net_bind_service能力（例如，通过setcap）2. 在部署的containerSecurityContext中，将NET_BIND_SERVICE能力添加到容器中。
个/某些节点上遇到这个问题，而其他节点没有，尝试在受影响的节点上清除并拉取镜像的新副本，以防底层层次的损坏导致可执行文件失去能力。

创建一个测试pod

当遇到这个错误时，/nginx-ingress-controller进程会退出/崩溃，这使得很难排查容器内部发生的情况。为了解决这个问题，启动一个运行"sleep 3600"的等效容器，并进入它进行进一步的排查。
例如：

apiVersion: v1
kind: Pod
metadata:name: ingress-nginx-sleepnamespace: defaultlabels:app: nginx
spec:containers:- name: nginximage: ##_CONTROLLER_IMAGE_##resources:requests:memory: "512Mi"cpu: "500m"limits:memory: "1Gi"cpu: "1"command: ["sleep"]args: ["3600"]ports:- containerPort: 80name: httpprotocol: TCP- containerPort: 443name: httpsprotocol: TCPsecurityContext:allowPrivilegeEscalation: truecapabilities:add:- NET_BIND_SERVICEdrop:- ALLrunAsUser: 101restartPolicy: NevernodeSelector:kubernetes.io/hostname: ##_NODE_NAME_##tolerations:- key: "node.kubernetes.io/unschedulable"operator: "Exists"effect: NoSchedule

如果适用/需要，请更新命名空间
将 ##NODE_NAME## 替换为有问题的节点（如果问题不仅限于一个节点，则删除 nodeSelector 部分）
将 ##CONTROLLER_IMAGE## 替换为您的 ingress-nginx 部署中使用的相同镜像
确认 securityContext 部分与您的集群中用于 ingress-nginx-controller pods 的设置匹配
应用这个 YAML 并打开一个连接到 pod 的 shell。尝试手动运行控制器进程：

$ /nginx-ingress-controller

你应该会从 ingress 控制器 pod 的日志中获取到相同的错误。
确认 capabilities 是否正确应用到 pod 中：

$ grep CapBnd /proc/1/status
CapBnd: 0000000000000400

上述值只启用了 net_bind_service（根据 YAML 中的 security context，它添加了该功能并丢弃了所有其他功能）。如果你得到一个不同的值，那么你可以在另一个 Linux 箱子上解码它（这个容器中没有 capsh），如下所示，然后找出为什么指定的 capabilities 没有传播到 pod/容器中。

$ capsh --decode=0000000000000400
0x0000000000000400=cap_net_bind_service

1.6使用root创建测试pod

（注意，这可能会受到 PodSecurityPolicy、PodSecurityAdmission/Standards、OPA Gatekeeper 等的限制，如果是这种情况，你将需要进行适当的测试工作，例如，在没有这些限制的新命名空间中部署。）为了进一步测试，你可能需要安装额外的工具等。通过以下方式修改 pod yaml：
将 runAsUser 从 101 改为 0
从 capabilities 中删除 “drop…ALL” 部分。
在进入此容器后尝试以下操作：
尝试以 www-data（101）用户身份运行控制器：

$ chmod 4755 /nginx-ingress-controller
$ /nginx-ingress-controller

检查错误，看看是否仍然存在在端口监听的问题，或者是否已经通过了这个问题，转而出现了由于运行上下文耗尽导致的其他预期错误。
安装 libcap 包并检查文件上的 capabilities：

$ apk add libcap
(1/1) Installing libcap (2.50-r0)
Executing busybox-1.33.1-r7.trigger
OK: 26 MiB in 41 packages
$ getcap /nginx-ingress-controller
/nginx-ingress-controller cap_net_bind_service=ep

（如果缺失，参见上文关于在服务器上清除图像并重新拉取的部分）
使用 strace 跟踪可执行文件，查看当它失败时正在执行的系统调用：

$ apk add strace
(1/1) Installing strace (5.12-r0)
Executing busybox-1.33.1-r7.trigger
OK: 28 MiB in 42 packages
$ strace /nginx-ingress-controller
execve("/nginx-ingress-controller", ["/nginx-ingress-controller"], 0x7ffeb9eb3240 /* 131 vars */) = 0
arch_prctl(ARCH_SET_FS, 0x29ea690)      = 0
...