• 见异思迁:K8s 部署 Nginx Ingress Controller 之 kubernetes/ingress-nginx


    前天才发现,区区一个 nginx ingress controller 竟然2个不同的实现。一个叫 kubernetes/ingress-nginx ,是由 kubernetes 社区维护的,对应的容器镜像是 quay.io/kubernetes-ingress-controller/nginx-ingress-controller ,namespace 是 ingress-nginx ;一个叫 nginxinc/kubernetes-ingress ,是由 nginx 公司与社区共同维护的,对应的容器镜像是 nginx/nginx-ingress ,namespace 是 nginx-ingress

    之前我们用的是 nginxinc/kubernetes-ingress (详见之前的博文), 不知道有2个不同的实现,在排查问题时有时查的是 kubernetes/ingress-nginx 的资料,南辕北辙,当时还纳闷明明按照文档进行了设置,为什么不起作用呢?

    由于使用 nginxinc/kubernetes-ingress 后遭遇 K8s 中 ASP.NET Core 应用获取不到客户端真实 IP 地址 的问题(X-Forwarded-For转发问题),于是被迫见异思迁试试换成 kubernetes/ingress-nginx 作为 nginx ingress controller 。

    接下来是 kubernetes/ingress-nginx 的部署步骤。

    首先删除之前的 nginxinc/kubernetes-ingress 部署。

    kubectl delete all --all -n nginx-ingress
    kubectl delete namespace nginx-ingress
    

    接着从 github 上签出 kubernetes/ingress-nginx 仓库,用其中的 mandatory.yaml 配置文件进行部署。

    git clone https://github.com/kubernetes/ingress-nginx
    cd deploy/static
    kubectl apply -f mandatory.yaml
    

    部署完成后,查看已部署的资源:

    $ kubectl get all -n ingress-nginx
    NAME                                            READY   STATUS    RESTARTS   AGE
    pod/nginx-ingress-controller-6885bc7778-m62kv   1/1     Running   0          37m
    
    NAME                                       READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/nginx-ingress-controller   1/1     1            1           37m
    
    NAME                                                  DESIRED   CURRENT   READY   AGE
    replicaset.apps/nginx-ingress-controller-6885bc7778   1         1         1       37m
    

    还少个 service ,我们这里用 nodePort 的方式部署 service ,于是选用 deploy/static/provider/baremetal/service-nodeport.yaml 部署文件,在其中添加 nodePort: 31080 指定端口。

    kind: Service
    metadata:
      name: ingress-nginx
      namespace: ingress-nginx
      labels:
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
    spec:
      type: NodePort
      ports:
        - name: http
          nodePort: 31080
          port: 80
          targetPort: 80
          protocol: TCP
      # ....
    

    部署 service

    kubectl apply -f service-nodeport.yaml
    

    查看部署结果

    $ kubectl get svc -n ingress-nginx      
    NAME            TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
    ingress-nginx   NodePort   10.96.151.144   <none>        80:31080/TCP,443:32428/TCP   9
    

    登录 worker 节点用 curl 命令验证 nginx 是否正常工作

    $ curl -i localhost:31080/healthz
    HTTP/1.1 200 OK
    Server: nginx/1.17.8
    

    返回 200 ,说明 nginx OK。

    注:kubernetes/ingress-nginx 默认实现了健康检查地址 /healthznginxinc/kubernetes-ingress 没有实现,需要自己实现(详见博问)。

    登录 nginx-ingress-controller pod ,查看 nginx 配置。

    kubectl exec -it deployment/nginx-ingress-controller -n ingress-nginx /bin/bash
    

    发现 kubernetes/ingress-nginx 中基于 ingress 规则生成的 nginx 配置全都放在 /etc/nginx/nginx.conf 中,而 nginxinc/kubernetes-ingress 是在 /etc/nginx/conf.d/ 目录中用一个专门的配置文件存放,文件名以 ingress 所在的命名空间名称开头。

    最后是最关键的时刻,验证 kubernetes/ingress-nginx 是否也存在 X-Forwarded-For 转发问题。

    在 ConfigMap 中添加启用 use-forwarded-headers 。

    data:
      use-forwarded-headers: "true"
    

    kubernetes/ingress-nginx 不负众望!没有 X-Forwarded-For 转发问题,应用中可以正常获取到客户端真实 IP 地址。

    对比一下两者处理 X-Forwarded-For 的区别。

    1)nginxinc/kubernetes-ingress 生成的 nginx 配置是

    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    

    X-Forwarded-For 的值是 "116.62.124.68, 192.168.107.192"

    2)kubernetes/ingress-nginx 生成的 nginx 配置是

    proxy_set_header X-Forwarded-For $remote_addr;
    

    X-Forwarded-For 的值是 "116.62.124.68"kubernetes/ingress-nginx 收到的请求是通过阿里云负载均衡转发过来的,客户端真实 IP 地址也是藏在 X-Forwarded-For 中,但它足智多谋,会将 X-Forwarded-For 中的 IP 地址传给 $remote_addr

    如果在 ConfigMap 中添加下面的配置,kubernetes/ingress-nginx 的表现就和 nginxinc/kubernetes-ingress 一样了。

    data: 
      compute-full-forwarded-for: "true"
    

    一次成功的见异思迁,情定 kubernetes/ingress-nginx

  • 相关阅读:
    20169220 2016-2017-2 <网络攻防实践> 课程总结
    20169220 <网络攻防实践> 第十四周实验—免杀
    20169220 <网络攻防实践> 第十二周实验—SQL注入
    20169220 <网络攻防实践> 第十一周实验—SQL注入+TCP/IP攻击
    20169220 <网络攻防实践> 第十周实验—Nmap+Wireshark+缓冲区溢出漏洞
    20169220 <网络攻防实践> 第九周实验——Nmap
    20169220 <网络攻防实践> 第八周实验——网络攻防虚拟机环境搭建
    20169220 <网络攻防实践> 第七周学习总结
    20169220 <网络攻防实践> 第六周学习总结
    20169220 <网络攻防实践> 第五周学习总结
  • 原文地址:https://www.cnblogs.com/dudu/p/12334613.html
Copyright © 2020-2023  润新知