Nginx 入口控制器 - 调用 Webhook 失败答案

【问题标题】：Nginx Ingress Controller - Failed Calling WebhookNginx 入口控制器 - 调用 Webhook 失败
【发布时间】：2020-08-20 07:04:03
【问题描述】：

我在 Ubuntu 虚拟机上使用 kubeadm (v1.18) 建立了一个 k8s 集群。现在我需要添加一个入口控制器。我决定使用 nginx（但我对其他解决方案持开放态度）。我是按照docs，“bare-metal”部分安装的：

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-0.31.1/deploy/static/provider/baremetal/deploy.yaml

安装对我来说似乎很好：

kubectl get all -n ingress-nginx

NAME                                            READY   STATUS      RESTARTS   AGE
pod/ingress-nginx-admission-create-b8smg        0/1     Completed   0          8m21s
pod/ingress-nginx-admission-patch-6nbjb         0/1     Completed   1          8m21s
pod/ingress-nginx-controller-78f6c57f64-m89n8   1/1     Running     0          8m31s

NAME                                         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
service/ingress-nginx-controller             NodePort    10.107.152.204   <none>        80:32367/TCP,443:31480/TCP   8m31s
service/ingress-nginx-controller-admission   ClusterIP   10.110.191.169   <none>        443/TCP                      8m31s

NAME                                       READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/ingress-nginx-controller   1/1     1            1           8m31s

NAME                                                  DESIRED   CURRENT   READY   AGE
replicaset.apps/ingress-nginx-controller-78f6c57f64   1         1         1       8m31s

NAME                                       COMPLETIONS   DURATION   AGE
job.batch/ingress-nginx-admission-create   1/1           2s         8m31s
job.batch/ingress-nginx-admission-patch    1/1           3s         8m31s

但是，当尝试应用自定义 Ingress 时，我收到以下错误：

Error from server (InternalError): error when creating "yaml/xxx/xxx-ingress.yaml": Internal error occurred: failed calling webhook "validate.nginx.ingress.kubernetes.io": Post https://ingress-nginx-controller-admission.ingress-nginx.svc:443/extensions/v1beta1/ingresses?timeout=30s: Temporary Redirect

知道可能出了什么问题吗？

我怀疑 DNS，但其他 NodePort 服务正在按预期工作，并且 DNS 在集群内工作。

我唯一能看到的是我没有docs here 中提到的默认http 后端。但是，根据this thread，在我的情况下这似乎很正常。

最后但并非最不重要的一点是，我也尝试了installation with manifests（在从之前的安装中删除了 ingress-nginx 命名空间之后）和installation via Helm chart。结果是一样的。

我几乎是 k8s 的初学者，这是我的游乐场集群。所以我也愿意接受替代解决方案，只要我不需要从头开始设置整个集群。

更新： 对于“应用自定义入口”，我的意思是： kubectl apply -f <myIngress.yaml>

myIngress.yaml 的内容

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - http:
      paths:
      - path: /someroute/fittingmyneeds
        pathType: Prefix
        backend:
          serviceName: some-service
          servicePort: 5000

【问题讨论】：

when trying to apply a custom Ingress 是什么意思？您的自定义 Ingress 到底是什么？
@OhHiMark：我的意思是`kubectl apply -f 。我在原帖中添加了信息。
看起来您的 Ingress.yaml 配置错误。我看到您正在尝试使用重写注释，但没有定义捕获组。 Here 您将找到一个说明如何使用该注释的示例。请看一下，如果有帮助，请告诉我。
不删除ValidatingWebhookConfiguration的任何解决方案？

标签： kubernetes kubernetes-ingress nginx-ingress kubeadm

【解决方案1】：

最后，我通过改变安装方式成功地运行了 Ingress Nginx。我仍然不明白为什么以前的安装不起作用，但我会分享解决方案以及对原始问题的更多见解。

解决方案

卸载 ingress nginx：删除 ingress-nginx 命名空间。这不会删除验证 webhook 配置 - 手动删除此配置。然后安装 MetalLB 并再次安装 ingress nginx。我现在使用 Helm stable repo 中的版本。现在一切都按预期工作。感谢 kubernetes slack 频道的 Long！

对原始问题的更多见解

installation guide 提供的 yaml 包含一个 ValidatingWebHookConfiguration：

apiVersion: admissionregistration.k8s.io/v1beta1
kind: ValidatingWebhookConfiguration
metadata:
  labels:
    helm.sh/chart: ingress-nginx-2.0.3
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/version: 0.32.0
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/component: admission-webhook
  name: ingress-nginx-admission
  namespace: ingress-nginx
webhooks:
  - name: validate.nginx.ingress.kubernetes.io
    rules:
      - apiGroups:
          - extensions
          - networking.k8s.io
        apiVersions:
          - v1beta1
        operations:
          - CREATE
          - UPDATE
        resources:
          - ingresses
    failurePolicy: Fail
    clientConfig:
      service:
        namespace: ingress-nginx
        name: ingress-nginx-controller-admission
        path: /extensions/v1beta1/ingresses

每当我创建或更新入口时都会执行验证（我的 ingress.yaml 的内容无关紧要）。验证失败，因为调用服务时，响应是临时重定向。我不知道为什么。对应的服务是：

apiVersion: v1
kind: Service
metadata:
  labels:
    helm.sh/chart: ingress-nginx-2.0.3
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/version: 0.32.0
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/component: controller
  name: ingress-nginx-controller-admission
  namespace: ingress-nginx
spec:
  type: ClusterIP
  ports:
    - name: https-webhook
      port: 443
      targetPort: webhook
  selector:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/component: controller

与选择器匹配的 pod 来自此部署：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    helm.sh/chart: ingress-nginx-2.0.3
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/version: 0.32.0
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/component: controller
  name: ingress-nginx-controller
  namespace: ingress-nginx
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
      app.kubernetes.io/instance: ingress-nginx
      app.kubernetes.io/component: controller
  revisionHistoryLimit: 10
  minReadySeconds: 0
  template:
    metadata:
      labels:
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/instance: ingress-nginx
        app.kubernetes.io/component: controller
    spec:
      dnsPolicy: ClusterFirst
      containers:
        - name: controller
          image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.32.0
          imagePullPolicy: IfNotPresent
          lifecycle:
            preStop:
              exec:
                command:
                  - /wait-shutdown
          args:
            - /nginx-ingress-controller
            - --election-id=ingress-controller-leader
            - --ingress-class=nginx
            - --configmap=ingress-nginx/ingress-nginx-controller
            - --validating-webhook=:8443
            - --validating-webhook-certificate=/usr/local/certificates/cert
            - --validating-webhook-key=/usr/local/certificates/key
          securityContext:
            capabilities:
              drop:
                - ALL
              add:
                - NET_BIND_SERVICE
            runAsUser: 101
            allowPrivilegeEscalation: true
          env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          livenessProbe:
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 10
            timeoutSeconds: 1
            successThreshold: 1
            failureThreshold: 3
          readinessProbe:
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 10
            timeoutSeconds: 1
            successThreshold: 1
            failureThreshold: 3
          ports:
            - name: http
              containerPort: 80
              protocol: TCP
            - name: https
              containerPort: 443
              protocol: TCP
            - name: webhook
              containerPort: 8443
              protocol: TCP
          volumeMounts:
            - name: webhook-cert
              mountPath: /usr/local/certificates/
              readOnly: true
          resources:
            requests:
              cpu: 100m
              memory: 90Mi
      serviceAccountName: ingress-nginx
      terminationGracePeriodSeconds: 300
      volumes:
        - name: webhook-cert
          secret:
            secretName: ingress-nginx-admission

此验证链中出现问题。知道什么以及为什么会很有趣，但我可以继续使用我的 MetalLB 解决方案。请注意，此解决方案根本不包含验证网络钩子。

【讨论】：

【解决方案2】：

我已经解决了这个问题。问题是您使用的是 Kubernetes 版本 1.18，但当前 ingress-Nginx 中的 ValidatingWebhookConfiguration 使用的是最旧的 API；见文档： https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#prerequisites

确保 Kubernetes 集群至少与 v1.16（使用 admissionregistration.k8s.io/v1）或 v1.9（使用 admissionregistration.k8s.io/v1beta1）一样新。 em>

在当前的 yaml 中：

 # Source: ingress-nginx/templates/admission-webhooks/validating-webhook.yaml
    # before changing this value, check the required kubernetes version
    # https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#prerequisites
apiVersion: admissionregistration.k8s.io/v1beta1

在规则中：

apiVersions:
          - v1beta1

所以你需要在 v1 上更改它：

apiVersion: admissionregistration.k8s.io/v1

并添加规则 -v1 ：

apiVersions:
          - v1beta1
          - v1

更改并重新部署后 - 您的自定义入口服务将成功部署

【讨论】：

要了解admissionregistration.k8s.io 的哪个版本与您的设置兼容，请使用kubectl api-versions | grep admissionregistration
这太棒了，在尝试解决问题太久后拯救了我。谢谢奥列格。
这似乎解决了我的问题伙伴。谢谢！

【解决方案3】：

您的另一个选择是完全删除 Validating Webhook：

kubectl delete -A ValidatingWebhookConfiguration ingress-nginx-admission

我发现我必须在 another issue 上执行此操作，但解决方法/解决方案也适用于此。

这不是最好的答案；最好的答案是弄清楚为什么这不起作用。但在某些时候，你会接受变通办法。

我在 Docker for Mac 上安装，所以我使用 cloud 而不是 baremetal 版本：

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.34.1/deploy/static/provider/cloud/deploy.yaml

【讨论】：

kubectl delete -A ValidatingWebhookConfiguration ingress-nginx-admission 在 minikube 1.12 和 k8s 1.18 上为我解决了这个问题。
@Patrick Gardella 这似乎是许多人的实用解决方案，正如您在相关帖子stackoverflow.com/a/62044090/1549918 上的许多支持所证明的那样。我什至不确定这只是一种解决方法。
除了删除 Admission Webhook 之外，更实用的解决方案是允许防火墙中的所有节点与端口 8443 通信。kubernetes.github.io/ingress-nginx/deploy - "如果网络策略或附加防火墙，请允许访问端口8443。”

【解决方案4】：

在我的情况下，我将安装混合在一起。我通过执行以下步骤解决了这个问题：

$ kubectl get validatingwebhookconfigurations

我遍历了从上述步骤收到的配置列表，并使用删除了配置

$ `kubectl delete validatingwebhookconfigurations [configuration-name]`

【讨论】：

不删除ValidatingWebhookConfiguration的任何解决方案？

【解决方案5】：

就我而言，我不需要删除 ValidatingWebhookConfiguration。问题是我在 GCP 版本 1.17.14-gke.1600 上使用私有集群。如果我理解正确，在默认的 Kubernetes 安装中，valitaingwebhook API（当然是在主节点上运行）在端口 443 上公开。但是使用 GCP，由于安全原因，他们将端口更改为 8443，因为为了分配端口 443，服务需要对节点具有 root 访问权限。由于他们不希望那样，他们更改为 8443。现在，由于私有集群只有节点上的 Ingress 外部允许的端口 80/443（即所有节点将只接受请求到这些端口），当 Kubernetes 尝试根据 validatingwebhook-address:8443 验证您的 Ingress 时，它将失败 - 如果它在 443 上运行则不会失败。This thread 包含更多详细信息。

因此，当前的解决方法是，recommended by Google itself（但文档记录很差）在 GCP 上添加防火墙规则，这将允许在端口 8443 向您的主节点发出入站（入口）TCP 请求，以便其他节点集群内可以通过该端口到达主节点以验证在其上运行的 webhook API。

至于如何创建规则，我是这样做的：

转到Firewall Rules 并添加了一个新的。
在 Network 字段中，我选择了我的集群所在的 VPC。
交通方向我设置为Ingress
比赛行动到Allow
目标到Specified target tags
目标标签可以在名为网络标签的属性中的主节点详细信息中找到。为了找到它，我打开了一个新窗口，转到我的集群节点池，找到了主节点池。然后进入其中一个节点以查找虚拟机详细信息。在那里我找到了网络标签。复制其值并返回到防火墙规则表单。
将复制的网络标签粘贴到标签字段
在协议和端口，检查Specified protocols and ports
然后检查TCP并放置8443
保存规则并再次应用清单。

注意：大多数线程会说它是端口 9443。它可能会工作。但我首先尝试了 8443，因为据报道它可以在 this thread 上工作。它对我有用，所以我什至没有尝试 9443。

【讨论】：

感谢您的精彩解释！我在我们的私有产品 GKE 集群中遇到了这个问题。我应该注意到我只添加了端口 8443 以使其工作。
对我来说也一样。就我而言，我必须在 AWS 的自定义安装中打开一个安全组。
超级有帮助，谢谢！我也只添加了端口 8443 并且它有效。您可能想要添加一些关于在创建防火墙规则时选择什么源的信息（我在创建集群时使用了我也在 --master-ipv4-cidr= 中指定的整个块）。

【解决方案6】：

在裸机集群上，我在 Helm3 安装期间禁用了 admissionWebhooks：

kubectl create ns ingress-nginx

helm install [RELEASE_NAME] ingress-nginx/ingress-nginx -n ingress-nginx --set controller.admissionWebhooks.enabled=false

【讨论】：

【解决方案7】：

我不确定这是否有助于这么晚，但可能是您的集群在代理后面？因为在这种情况下，您必须正确配置 no_proxy。具体来说，它必须包含 .svc,.cluster.local 否则验证 webhook 请求（如 https://ingress-nginx-controller-admission.ingress-nginx.svc:443/extensions/v1beta1/ingresses?timeout=30s）将通过代理服务器路由（注意 URL 中的 .svc）。

我确实遇到了这个问题，将.svc 添加到 no_proxy 变量中有所帮助。您可以通过修改 /etc/kubernetes/manifests/kube-apiserver.yaml 文件来快速尝试一下，该文件会自动重新创建您的 kubernetes api 服务器 pod。

这不仅适用于入口验证，还适用于其他可能引用集群中以 .svc 或 .namespace.svc.cluster.local 结尾的 URL 的事物（即参见此 bug）

【讨论】：

顺便说一句 - 我不会为入口资源禁用验证 webhook。它们的存在是有原因的，并且可以防止您的控制器因应用损坏的入口而完全关闭（不是在语法方面，而是在运行时问题方面）。那么这个入口控制器后面的所有应用程序都将不可用。
确实，我在代理后面。您的解决方案看起来很干净并且有效。谢谢！

【解决方案8】：

对我有用的是在等待入口出现时增加超时。

【讨论】：