nginx-ingress设置日志格式-配置转发真实ip-超时参数配置-会话保持参数

nginx-ingress设置日志格式-配置转发真实ip-白名单限制

参考官方文档
nginx-ingress官方文档
修改nginx-ingrss的configmap配置文件

apiVersion: v1
data:compute-full-forwarded-for: "true"forwarded-for-header: X-Forwarded-Forlog-format-upstream: '{"time": "$time_iso8601", "proxy_protocol_addr": "$proxy_protocol_addr","proxy_add_x_forwarded_for": "$proxy_add_x_forwarded_for", "request_id": "$req_id",   "remote_user":"$remote_user", "bytes_sent": $bytes_sent, "request_time": $request_time, "status":$status, "vhost": "$host", "request_proto": "$server_protocol",   "path": "$uri","request_query": "$args", "request_length": $request_length, "duration": $request_time,"method": "$request_method", "http_referrer": "$http_referer",   "http_user_agent":"$http_user_agent", "remote_addr":"$remote_addr", "remote_port": "$remote_port","x_forwarded_for": "$http_x_forwarded_for" }'real_ip_header: X-Forwarded-For  #将客户端真实ip替换为请求头的值real_ip_recursive: "on"  #递归排除IP地址,ip串从右到左开始排除set_real_ip_from里面出现的IP,如果出现了未出现这些ip段的IP，那么这个IP将被认为是用户的IPset_real_ip_from: 100.125.0.0/16  #可信任的ip，真实服务器上一级代理的IP地址或者IP段,可以写多行use-forwarded-headers: "true"  #如果Nginx在其他7层代理或负载均衡后面，当期望Nginx将X-Forwarded-*的头信息传递给后端服务时，则需要将此参数设为true，如果设为false（默认为false），Nginx会忽略掉X-Forwarded-*的头信息。false设置适用于Nginx直接对外或前面只有3层负载均衡的场景
kind: ConfigMap
metadata:creationTimestamp: "2021-12-02T02:04:31Z"labels:app: nginx-ingresschart: nginx-ingress-1.2.6component: controllerheritage: Tillerrelease: cceaddon-nginx-ingressname: cceaddon-nginx-ingress-controllernamespace: kube-systemresourceVersion: "4738338"selfLink: /api/v1/namespaces/kube-system/configmaps/cceaddon-nginx-ingress-controlleruid: 38ee4b63-4fcb-43c8-8ed1-1258f28ab13c

nginx-ingress配置域名转发时参数注释添加

上述配置需要配置nginx-ingress的本身的配置文件，下边是给ingress转发创建资源时添加的注释
上传一些大文件参数时需要配置的大小限制和超时时间限制参数

nginx.ingress.kubernetes.io/proxy-body-size=200m
#指定请求大小限制
nginx.ingress.kubernetes.io/proxy-read-timeout=600
#连接成功后_等候后端服务器响应时间_其实已经进入后端的排队之中等候处理
nginx.ingress.kubernetes.io/proxy-send-timeout=600
#后端服务器数据回传时间_就是在规定时间之内后端服务器必须传完所有的数据
#我们这是转发到后端需要在后端上传到oss，所以需要等待后端给响应

如果后端还有nginx，nginx也需要调整时间

client_max_body_size 200M;
#请求主体大小
client_header_buffer_size 32k;
#标准请求头大小
large_client_header_buffers 4 1024k;
#最大请求头大小
#先根据client_header_buffer_size配置的值分配一个buffer，如果分配的buffer无法容纳 request_line/request_header，那么就会再次根据large_client_header_buffers配置的参数分配large_buffer，如果large_buffer还是无法容纳，那么就会返回414（处理request_line）/400（处理request_header）错误。
proxy_send_timeout  600s;
#后端服务器数据回传时间_就是在规定时间之内后端服务器必须传完所有的数据
proxy_read_timeout  600s;
#连接成功后_等候后端服务器响应时间_其实已经进入后端的排队之中等候处理

nginx-ingress限制白名单访问
在ingress资源配置上添加参数

nginx.ingress.kubernetes.io/whitelist-source-range: 127.0.0.1,192.168.8.0/24

nginx-ingress会话保持设置

## 前提

基于kubernetes部署Java项目，发现在多pod模式下，会出现登录成功但是页面无法跳转的问题，在单一pod时却可以成功登录并页面正常跳转，于是推测是cookie的问题。

网上的大部分文章提供的解决方案都是在service的配置文件中加入sessionAffinity: ClientIP，功能是选择与请求来源ip更接近的pod，这样就会固定同一个session，但是好像并不适用于我这个项目。

最终的解决当然还是要靠自己读官方的文档，ingress-nginx有大量的注释配置，官方针对这种情况已经做了说明，需要细细阅读，详见Cookie affinity。

## 解决方案

注释nginx.ingress.kubernetes.io/affinity在Ingress的所有上游中启用和设置相似性类型。这样，请求将始终定向到同一上游服务器。Nginx唯一可用的相似性类型是cookie。

如果为一个主机定义了多个Ingress nginx.ingress.kubernetes.io/affinity: cookie，并且至少一个Ingress使用，则只有Ingress使用的路径nginx.ingress.kubernetes.io/affinity将使用会话Cookie相似性。通过随机选择后端服务器，可以在主机的其他入口定义的所有路径进行负载均衡。

如果您使用Cookie affinity，则还可以使用注释nginx.ingress.kubernetes.io/session-cookie-name来指定将用于路由请求的cookie名称。默认是创建一个名为INGRESSCOOKIE的cookie。

注释nginx.ingress.kubernetes.io/affinity-mode定义了会话的粘性。如果将部署规模扩大，balance则将此选项设置为（默认）将重新分配一些会话，从而重新平衡服务器上的负载。将此设置为persistent不会重新平衡与新服务器的会话，因此提供了最大的粘性。

以上是官方文档的直译。

简而言之，在ingress-nginx配置中应做以下操作：

设置nginx.ingress.kubernetes.io/affinity属性，启用会话保持。设置nginx.ingress.kubernetes.io/affinity-mode属性，设置为balance在集群扩大pod时，会自动分配一些会话到新创建的pod上，用于平衡服务器的负载；设置为persistent则永远保证用户访问pod的一致性，不会访问到其他pod。设置nginx.ingress.kubernetes.io/session-cookie-name属性，自定义cookie名称。

对我用到了其中的三个属性进行描述：

## 配置文件

使用session会话保持可以用于解决多tomcat的pod下，登录由于session问题导致页面无法跳转的问题。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:name: ingress-tomcatnamespace: defaultannotations:kubernetes.io/ingress.class: "nginx"nginx.ingress.kubernetes.io/affinity: "cookie"nginx.ingress.kubernetes.io/affinity-mode: "persistent"nginx.ingress.kubernetes.io/session-cookie-name: "route"
spec:tls:- hosts:- your.host.cnsecretName: https-secretrules:                                                          - host: your.host.cn                                            http:                                                        paths:                                                       - path:backend:serviceName: your service nameservicePort: 8280

以下为其他网友提供的解决方案：

在service的配置文件中加入sessionAffinity: ClientIP，功能是选择与请求来源ip更接近的pod，这样就会固定同一个session。

apiVersion: v1
kind: Service
metadata:name: tomcatnamespace: default
spec:selector:app: tomcatrelease: canaryports:- name: httptargetPort: 8280port: 8280sessionAffinity: ClientIP