Ingress-Nginx工作原理是什么

本篇内容介绍了“Ingress-Nginx工作原理是什么”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!

成都创新互联公司专注为客户提供全方位的互联网综合服务,包含不限于成都做网站、网站建设、外贸星空体育app最新版本(2024已更新)建设、互助网络推广、微信平台小程序开发、互助网络营销、互助企业策划、互助品牌公关、搜索引擎seo、人物专访、企业宣传片、企业代运营等,从售前售中售后,我们都将竭诚为您服务,您的肯定,是我们最大的嘉奖;成都创新互联公司为所有大学生创业者提供互助建站搭建服务,24小时服务热线:028-86922220,官方网址:www.executivehouseboatcharters.com

Ingress-Nginx工作原理是什么

这个图算是一个通用的前后端分离的 k8s 部署结构:

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

Ingress vs Ingress-nginx

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

根据请求的主机名 host 和路径 path 决定请求转发到的服务。

Ingress-Nginx工作原理是什么

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

我这里web项目使用的是常见的Ingress-nginx (官方还有其他用途的 Ingress),Ingress-nginx 是使用nginx  作为反向代理和负载均衡器的 K8s Ingress Controller, 作为Pod运行在kube-system 命名空间。

了解 Ingress 工作原理,有利于我们与运维人员打交道。

Ingress-Nginx工作原理是什么

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

--- apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata:   name: kibana   labels:     app: kibana   annotations:     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-cert   rules:     - host: 'https://logging.internal.gridsum.com'       http:         paths:           - path: /             backend:               serviceName: kibana               servicePort: 5601

☹️ Ingress-nginx 中最让我困惑的是它的Paths分流与rewrite-target注解。

  • Paths 分流 一般用于 根据特定的 Path,将请求转发到特定的后端服务 Pod,后端服务 Pod 能接收到 Path 这个信息。一般后端服务是作为  api。

  • rewrite-target 将请求重定向到后端服务, 那有什么用处呢?

答:以上面暴露的 kibana 为例, 我们已经可以在https://logging.internal.gridsum.com/ 访问完整的  Kibana, 如果我想利用这个域名暴露 ElasticSearch 站点,怎么操作?这时就可以利用rewrite-target,

--- apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata:   name: elasticsearch   labels:     app: kibana   annotations:     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-cert   rules:     - host: 'logging.internal.gridsum.com'       http:         paths:           - path: /es(/|$)(.*)             backend:               serviceName: elasticsearch               servicePort: 9200

在此 Ingress  定义中,由(.*)捕获的所有字符都将分配给占位符$2,然后将其用作重写目标注解中的参数。这样的话:https://logging.internal.gridsum.com/es  将会重定向到后端 elasticsearch 站点,并且忽略了 es 这个 path

Ingress-Nginx工作原理是什么

Ingress-nginx 到 webapp 的日志追踪

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

Ingress-nginx----> Nginx FrontEnd App--->BackEnd App 需要一个串联的追踪 Id,  便于观察运维网络和业务应用。

幸好 Ingress-nginx, Nginx 强大的配置能力帮助我们做了很多事情:

  • 客户端请求到达 Ingress-Nginx Controllerr,Ingress-Nginx Controller  会自动添加一个X-Request-ID的请求 Header (随机值)---- 这个配置是默认的

  • 请求达到 Nginx FrontEnd App, Nginx 有默认配置proxy_pass_request_headers on;,  自动将请求头都传递到上游的 Backend App

这样跨越整个结构图的 request_id 思路已经清楚了,最后一步只需要我们在 Backend App 中提取请求中携带的X-Request-ID,  并作为日志的关键输出字段。

☺️ 这就涉及到怎么自定义日志的LayoutRender。

下面为Asp.NETCore NLog 自定义名为x_request_id的 Render,该 Render 从请求的 X-Request-ID  标头中提取值。

① 定义 NLog Render

/// <summary>     /// Represent a unique identifier to represent a request from the request HTTP header X-Request-Id.     /// </summary>     [LayoutRenderer("x_request_id")]     public class XRequestIdLayoutRender : HttpContextLayoutRendererBase     {         protected override void Append(StringBuilder builder, LogEventInfo logEvent)         {             var identityName = HttpContextAccessor.HttpContext?.Request?.Headers?["X-Request-Id"].FirstOrDefault();             builder.Append(identityName);         }     }     /// <summary>     /// Represent a http context layout renderer to access the current http context.     /// </summary>     public abstract class HttpContextLayoutRendererBase : LayoutRenderer     {         private IHttpContextAccessor _httpContextAccessor;         /// <summary>         /// Gets the <see cref="IHttpContextAccessor"/>.         /// </summary>         protected IHttpContextAccessor HttpContextAccessor { get { return _httpContextAccessor ?? (_httpContextAccessor = ServiceLocator.ServiceProvider.GetService<IHttpContextAccessor>()); } }     }     internal sealed class ServiceLocator     {         public static IServiceProvider ServiceProvider { get; set; }     }

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

这里使用依赖查找的方式获取该组件,故请在Startup ConfigureService 中生成服务

public void ConfigureServices(IServiceCollection services)  {      // ......      ServiceLocator.ServiceProvider = services.BuildServiceProvider();  }

③ 最后在 Program 中注册这个NLog Render:

 public static void Main(string[] args) {      LayoutRenderer.Register<XRequestIdLayoutRender>("x_request_id");      CreateHostBuilder(args).Build().Run(); }

这样从 Ingress-Nginx 产生的request_id,将会流转到 Backend App,  并在日志分析中起到巨大作用,也便于划清运维/开发的故障责任。

“Ingress-Nginx工作原理是什么”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站,小编将为大家输出更多高质量的实用文章!

当前名称:Ingress-Nginx工作原理是什么
当前网址:/article8/jhgdip.html

成都网站建设公司_创新互联,为您提供全网营销推广网站设计公司企业网站制作App设计自适应网站定制网站

广告

声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联

h5响应式网站建设