共計 4414 個字符，預計需要花費 12 分鐘才能閱讀完成。

本篇內容介紹了“Ingress-Nginx 工作原理是什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓丸趣 TV 小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

這個圖算是一個通用的前后端分離的 k8s 部署結構:

Nginx Ingress 負責暴露服務(nginx 前端靜態資源服務)，根據十二要素應用的原 則，將后端 api 作為 nginx   服務的附加動態資源。

Ingress vs Ingress-nginx

Ingress 是一種向 k8s 集群外部的客戶端公開服務的方法，Ingress 在網絡協議棧的應用層工作,

根據請求的主機名 host 和路徑 path 決定請求轉發到的服務。

在應用 Ingress 對象提供的功能之前，必須強調集群中存在 Ingress Controller，Ingress 資源才能正常工作。

我這里 web 項目使用的是常見的 Ingress-nginx (官方還有其他用途的 Ingress)，Ingress-nginx 是使用 nginx   作為反向代理和負載均衡器的 K8s Ingress Controller，作為 Pod 運行在 kube-system 命名空間。

了解 Ingress 工作原理，有利于我們與運維人員打交道。

下面通過 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 到 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 工作原理是什么”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注丸趣 TV 網站，丸趣 TV 小編將為大家輸出更多高質量的實用文章！