Ingress-Nginx工作原理与实践

本文转载自微信公众号《全栈码农画像》，作者小马甲。转载本文请联系全栈码农画像公众号。本文记录/分享当前项目的K8s部署架构和请求跟踪改造方案。这张图是一个通用的前后端分离的k8s部署结构：NginxIngress负责暴露服务（nginx前端静态资源服务）。根据十二要素应用原则，使用后端api作为nginx服务的附加动态资源。IngressvsIngress-nginxIngress是一种向k8s集群外的客户端暴露服务的方法。Ingress工作在网络协议栈的应用层，根据请求的主机名host和路径path来确定将请求转发到哪个服务。在应用Ingress对象提供的功能之前，必须强调集群中存在IngressController，Ingress资源才能正常工作。我这里的web项目使用了常见的Ingress-nginx（官方的Ingress也有其他用途），Ingress-nginx是一个K8sIngressController，使用nginx作为反向代理和负载均衡器，作为Pod运行在kube-system命名空间.了解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.库伯内特斯。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??在Ingress-nginx中最让我困惑的是它的Pathsshuntwithrewrite-目标注释。Paths分发一般用于将请求按照特定的Path转发到特定的后端服务Pod，后端服务Pod可以接收到Path信息。一般后端服务作为api。rewrite-target将请求重定向到后端服务，那有什么用呢？答：以上面暴露的kibana为例，我们已经可以在https://logging.internal.gridsum.com/访问到完整的Kibana，如果我想用这个域名暴露ElasticSearch站点，怎么办它？这时候我可以使用rewrite-target，---apiVersion:networking.k8s.io/v1beta1kind:Ingressmetadata:name:elasticsearchlabels:app:kibanaannotations:kubernetes.io/ingress。类：“nginx”nginx.ingress.kubernetes.io/proxy-connect-timeout：“30”nginx.ingress.kubernetes.io/proxy-read-timeout：“1800”nginx.ingress.kubernetes.io/proxy-send-超时：“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，然后将其用作overridetargetannotation中的参数。这种情况下：https://logging.internal.gridsum.com/es会被重定向到后端elasticsearch站点，而忽略es路径Ingress-nginxtowebapplogtracking熟悉我的朋友都知道，我写的《一套标准的ASP.NET Core容器化应用日志收集分析方案》，主要是BackEndApp的日志。从上面的结构图看，Ingress-nginx---->NginxFrontEndApp--->BackEndApp需要一个串口的trackingId，方便观察运维网络和业务应用。幸运的是，Ingress-nginx，Nginx强大的配置能力帮我们做了很多事情：当客户端请求到达Ingress-NginxControllerr时，Ingress-NginxController会自动添加一个X-Request-ID请求Header（随机值）----这个配置是默认请求到达NginxFrontEndApp。Nginx默认有一个配置proxy_pass_request_headerson;，自动将requestheaders传递给上游BackendApp，这样request_id横跨整个结构图的思路就一目了然了。最后一步只需要在BackendApp中提取出request中携带的X-Request-ID作为日志的关键输出字段即可。??这里涉及到如何自定义日志的LayoutRender。下面是一个名为x_request_id的自定义Render，用于Asp.NETCoreNLog，它从请求的X-Request-ID标头中提取值。①定义NLogRender///

///RepresentauniqueidentifiertorepresentarequestfromtherequestHTTPheaderX-Request-Id.///

[LayoutRenderer("x_request_id")]publicclassXRequestIdLayoutRender:HttpContextLayoutRendererBase{protectedoverridevoidAppend(StringBuilderbuilder,LogEventInfologAttextHtContorEvent=){varidentity?.Request?.Headers?["X-Request-Id"].FirstOrDefault();builder.Append(identityName);}}///

///代表httpcontextlayoutrenderer访问当前httpcontext.///

publicabstractclassHttpContextLayoutRendererBase:LayoutRenderer{privateIHttpContextAccessor_httpContextAccessor;///

///Getsthe.///

protectedIHttpContextAccessorHttpContextAccessor{get{return_httpContextAccessor??(_httpContextAccessor=ServicepContextAccessor.ServiceHccessor.ServiceProvider.);}}}内海ledclassServiceLocator{publicstaticIServiceProviderServiceProvider{get;set;}}②从请求中获取X-Request-Id，依赖IHttpContextAccessor组件。这里依赖lookup方法获取组件，所以请在StartupConfigureService中生成服务publicvoidConfigureServices(IServiceCollectionservices){//......ServiceLocator.ServiceProvider=services.BuildServiceProvider();}③最后注册这个NLog在程序中呈现：publicstaticvoidMain(string[]args){LayoutRenderer.Register("x_request_id");CreateHostBuilder(args)。Build().Run();}这样Ingress-Nginx产生的request_id会流向BackendApp，对日志分析起到巨大的作用，也便于区分运维故障责任/开发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服务。2.本文梳理了Ingress与常见Ingress-nginx的关系。3、对于使用Ingress的应用，整理出Ingress-nginx到WebApp的logtrackingid，方便排查网络/业务故障。