见异思迁: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

原文地址:https://www.cnblogs.com/dudu/p/12334613.html

时间: 2024-10-10 20:38:46

见异思迁:K8s 部署 Nginx Ingress Controller 之 kubernetes/ingress-nginx的相关文章

NGINX Ingress Controller for Kubernetes(未完成)

Kubernetes的服务入口控制器 官方地址 https://github.com/nginxinc/kubernetes-ingress/blob/v1.5.3/docs/installation.md 安装清单位于Deployments文件夹中. # kubectl apply  -f   ns-and-sa.yaml    (为Ingress控制器创建名称空间和服务帐户) apiVersion: v1 kind: Namespace metadata: name: nginx-ingre

实操教程丨如何在K8S集群中部署Traefik Ingress Controller

注:本文使用的Traefik为1.x的版本 在生产环境中,我们常常需要控制来自互联网的外部进入集群中,而这恰巧是Ingress的职责. Ingress的主要目的是将HTTP和HTTPS从集群外部暴露给该集群中运行的服务.这与Ingress控制如何将外部流量路由到集群有异曲同工之妙.接下来,我们举一个实际的例子来更清楚的说明Ingress的概念. 首先,想象一下在你的Kubernetes集群中有若干个微服务(小型应用程序之间彼此通信).这些服务能够在集群内部被访问,但我们想让我们的用户从集群外部也

同一k8s集群中多nginx ingress controller

同一k8s集群中多nginx ingress controller同一k8s集群中,若有多个项目(对应多个namespace)共用一个nginx ingress controller,因此任意注册到ingress的服务有变更都会导致controller配置重载,当更新频率越来越高时,此controller压力会越来越大,理想的解决方案就是每个namespace对应一个nginx ingress controller,各司其职. NGINX ingress controller提供了ingress

11. Ingress及Ingress Controller(主nginx ingress controller)

11. Ingress,Ingress Controller拥有七层代理调度能力 什么是Ingress: Ingress是授权入站连接到达集群服务的规则集合 Ingress是一个Kubernetes资源,允许您为在Kubernetes上运行的应用程序配置HTTP负载均衡器,由一个或多个服务代表.这样的负载平衡器是将这些应用程序交付给Kubernetes集群之外的客户端所必需的. Ingress资源支持以下功能:1 基于内容的路由: 基于主机的路由.例如,将具有主机头的请求路由foo.exampl

Kubernetes学习之路(十五)之Ingress和Ingress Controller

1.部署Ingress controller (1)下载ingress相关的yaml [[email protected] ~]# mkdir ingress-nginx [[email protected] ~]# cd ingress-nginx/ [[email protected] ingress-nginx]# ll total 0 [[email protected] ingress-nginx]# for file in namespace.yaml configmap.yaml

kubernetes Ingress 之 Traefik

关于traefik 参考之前写的一篇文档:https://blog.51cto.com/michaelkang/1918192 版本介绍 traefik:v1.7 k8s:v1.15.1 Ingress Ingress是自kubernetes1.1版本后引入的资源类型.必须要部署Ingress controller才能创建Ingress资源,Ingress controller是以一种插件的形式提供. 使用 Ingress 时一般会有三个组件: 反向代理负载均衡器 Ingress Control

[转帖]K8s 工程师必懂的 10 种 Ingress 控制器

K8s 工程师必懂的 10 种 Ingress 控制器 https://www.kubernetes.org.cn/5948.html 控制器有好多啊. 2019-10-18 23:07 中文社区 分类:Kubernetes教程/入门教程 阅读(736) 评论(0) 今年 2 月,社区曾推送了一篇文章:<在 K8s 中,如何选择合适的 Ingress 控制器>.但当时只介绍了两种解决方案.为了帮助读者对 Ingress Controler 建立更完整的认识,今天,社区对现下流行的十种方案做了具

Kubernetes Ingress

Ingress 可以提供负载平衡,SSL 终端和基于名称的虚拟主机. Ingress 是什么 通常情况下,service和pod仅可在集群内部网络中通过IP地址访问.所有到达边界路由器的流量或被丢弃或被转发到其他地方. internet | ------------ [ Services ] Ingress是授权入站连接到达集群服务的规则集合. internet | [ Ingress ] --|-----|-- [ Services ] 可以给Ingress配置提供外部可访问的URL.负载均衡

(八)Kubernetes Ingress资源

前言 Kubernetes提供了两种内建的云端负载均衡机制(cloud load balancing)用于发布公共应用,一种是工作于传输层的Service资源,它实现的是“TCP负载均衡器”,另一种是Ingress资源,它实现的是“HTTP(S)负载均衡器”. TCP负载均衡器 无论是iptables还是ipvs模型的Service资源都配置于Linux内核中的Netfilter之上进行四层调度,是一种类型更为通用的调度器,支持调度HTTP.MySQL等应用层服务.不过,也正是由于工作于传输层从