大家好,今天小编来为大家解答以下的问题，关于Ingress-Nginx的工作原理和实践，这个很多人还不知道，现在让我们一起来看看吧！

[[388304]]

此图是一般的前后端分离的k8s部署结构：

Nginx Ingress负责暴露服务（nginx前端静态资源服务）。根据十二要素应用原则，将后端API作为nginx服务的附加动态资源。

Ingress vs Ingress-nginx

Ingress 是一种向k8s 集群外部的客户端公开服务的方法。 Ingress 工作在网络协议栈的应用层。

在应用Ingress对象提供的功能之前，必须强调集群中存在Ingress Controller，以便Ingress资源正常工作。

我这里的web项目使用的是常见的Ingress-nginx（官方还有其他Ingress用途）。 Ingress-nginx 是一个K8s Ingress 控制器，使用nginx 作为反向代理和负载均衡器。它作为kube-system 命名空间中的Pod 运行。

了解Ingress是如何工作的，有助于我们与运维人员打交道。

下面通过Ingress-nginx暴露Kibana服务：

apiVersion:networking.k8s.io/v1beta1kind:Ingressmetadata:name:kibanalabels:app:kibanaannotations:kubernetes.io/ingress.class:'nginx'nginx.ingress.kubernetes.io/proxy-connect-timeout:'30'nginx.ingress .kubernetes.io/proxy-read-timeout:'1800'nginx。 ingress.kubernetes.io/proxy-send-timeout:'1800'nginx.ingress.kubernetes.io/proxy-body-size:'8m'nginx.ingress.kubernetes.io/ssl-redirect:'true'spec:tls:-hosts:-'https://logging .internal.gridsum.com/'secretName:tls-certrules:-host:'https://logging.internal.gridsum.com'http:paths:-path:/backend:serviceName:kibanaservicePort:5601 最让我困惑的是它的Paths diversion 和rewrite-target 注释。

rewrite-target 将请求重定向到后端服务。那有什么用呢？答：以上面暴露的kibana为例，我们已经可以在https://logging.internal.gridsum.com/访问完整的Kibana。如果我想用这个域名暴露ElasticSearch站点。如何操作？然后你可以使用重写目标。

apiVersion:networking.k8s.io/v1beta1kind:Ingressmetadata:name:elasticsearchlabels:app:kibanaannotations:kubernetes.io/ingress.class:'nginx'nginx.ingress.kubernetes.io/proxy-connect-timeout:'30' nginx.ingress .kubernetes.io/proxy-read-timeout:'1800'nginx。 ingress.kubernetes.io/proxy-send-timeout:'1800'nginx.ingress.kubernetes.io/proxy-body-size:'8m'nginx.ingress.kubernetes.io/ssl-redirect:'true'nginx.ingress.kubernetes。 io/rewrite-target:'/$2'spec:tls:-hosts:-'logging.internal.gridsum.com'secretName:tls-certrules:-host:'logging.internal.gridsum.com'http:paths:-path:/es(/|$)(.*) backend:serviceName:elasticsearchservicePort:9200在此Ingress 定义中，(.*) 捕获的所有字符都将分配给占位符$2，然后将其用作重写目标注释中的参数。在这种情况下：https://logging.internal.gridsum.com/es将被重定向到后端elasticsearch站点，路径es将被忽略

Ingress-nginx 到 webapp 的日志追踪

熟悉我的朋友都知道，我写的是《一套标准的ASP.NET Core容器化应用日志收集分析方案》，主要是BackEnd App的日志。从上面的结构图来看，

Ingress-nginx----Nginx前端App---后端App需要一个序列化的跟踪ID，方便观察运维网络和业务应用。

幸运的是，Ingress-nginx，Nginx强大的配置能力帮助我们做了很多事情：

当客户端请求到达Ingress-Nginx Controller时，Ingress-Nginx Controller会自动添加一个X-Request-ID（随机值）的请求头----该配置是默认到达Nginx前端应用程序的请求。 Nginx 默认配置proxy_pass_request_headers on ;自动将所有请求头传递给上游Backend App，这样整个结构图中的request_id 就已经清晰了。最后一步只需要我们在Backend App中提取出请求中携带的X-Request-ID，并将其作为日志输出字段的key即可。

这里涉及到如何自定义日志的LayoutRender。

下面是一个名为x_request_id 的Asp.NETCore NLog 自定义渲染，它从请求的X-Request-ID 标头中提取值。

定义 NLog Render//////RepresentauniqueidentifiertorepresentarequestfromrequestHTTPheaderX-Request-Id.///[LayoutRenderer('x_request_id')]publicclassXRequestIdLayoutRender:HttpContextLayoutRendererBase{protectedoverridevoidAppend(StringBuilderbuilder,LogEventInfologEvent){varident ityName=HttpContextAccessor.HttpContext?Request?Headers?[' X -Request-Id'].FirstOrDefault();builder.Append(identityName);}}//////代表一个httpcontextlayoutrenderer来访问当前的httpcontext.///publicabstractclassHttpContextLayoutRendererBase:LayoutRenderer{privateIHttpContextAccessor_httpContextAccessor;//////获取'IHt tpContextAccessor'/.///protectedIHttpContextAccessorHttpContextAccessor{get{return_httpContextAccessor?(_httpContextAccessor=ServiceLocator.ServiceProvider.GetService());}}}internalsealedclassServiceLocator{publicstaticIServiceProviderServiceProvider{get;set;}}

从请求中获取X-Request-Id并依赖IHttpContextAccessor组件

这里使用依赖搜索来获取组件，所以请在StartupConfigureService中生成服务。

publicvoidConfigureServices(IServiceCollectionservices){//.ServiceLocator.ServiceProvider=services.BuildServiceProvider();}最后在程序中注册这个NLog Render：

publicstaticvoidMain(string[]args){LayoutRenderer.Register('x_request_id');CreateHostBuilder(args).Build().Run();} 这样Ingress-Nginx生成的request_id就会流向Backend App并被记录日志中起到了巨大的分析作用，有利于运维/开发的故障责任认定。

https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#generate-request-idhttp://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass_request_headers

总结

1.了解Ingress的应用分层工作，根据Host 和Path 公开k8s 服务。

3. 对于使用Ingress的应用，整理出Ingress-nginx到WebApp的日志跟踪ID，方便排查网络/业务故障。

好了，本文到此结束，如果可以帮助到大家，还望关注本站哦！