Shulou(Shulou.com)05/31 Report--

This article introduces the relevant knowledge of "what is the working principle of Ingress-Nginx". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

This figure is a general-purpose front-end separate k8s deployment structure

Nginx Ingress is responsible for exposing the service (nginx front-end static resource service). According to the original principle of the 12-element application, the back-end api is regarded as the additional dynamic resource of the nginx service.

Ingress vs Ingress-nginx

Ingress is a way to expose services to clients outside the K8s cluster, and Ingress works at the application layer of the network protocol stack

The service to which the request is forwarded is determined based on the hostname host and path path of the request.

Before applying the functionality provided by the Ingress object, it is important to emphasize the existence of Ingress Controller in the cluster for Ingress resources to work properly.

My web project uses the common Ingress-nginx (officially there are other uses of Ingress). Ingress-nginx is a K8s Ingress Controller that uses nginx as a reverse proxy and load balancer and runs in the kube-system namespace as Pod.

Understanding how Ingress works is helpful for us to deal with operation and maintenance personnel.

The following exposes the Kibana service through Ingress-nginx:

-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

What puzzles me most about ☹️ Ingress-nginx is its Paths shunting and rewrite-target annotations.

Paths streaming is generally used to forward requests to a specific backend service Pod according to a specific Path, and the backend service Pod can receive the information of Path. The general back-end service is used as an api.

What is the use of redirecting requests to back-end services by rewrite-target?

A: taking the kibana exposed above as an example, we can already access the complete Kibana in https://logging.internal.gridsum.com/. What if I want to use this domain name to expose the ElasticSearch site? At this point, you can use 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

In this Ingress definition, all characters captured by (. *) are assigned to the placeholder $2, which is then used as a parameter in the override target annotation. In this way: https://logging.internal.gridsum.com/es will redirect to the back-end elasticsearch site and ignore the path of es

Log tracking from Ingress-nginx to webapp

Friends who are familiar with me know that I wrote "a set of standard ASP.NET Core containerized application log collection and analysis scheme", which is mainly BackEnd App logs, from my above structure diagram.

Ingress-nginx---- > Nginx FrontEnd App--- > BackEnd App requires a serial tracking Id to facilitate the observation of operation and maintenance networks and business applications.

Fortunately, the powerful configuration capabilities of Ingress-nginx and Nginx have helped us do a lot of things:

Client request arrives at Ingress-Nginx Controllerr,Ingress-Nginx Controller will automatically add a X-Request-ID request Header (random value)-this configuration is the default

Request reaches Nginx FrontEnd App. Nginx has default configuration proxy_pass_request_headers on;, automatically passes request headers to upstream Backend App

So the idea of request_id across the entire structure diagram is clear, and the final step is that we only need to extract the X-Request-ID carried in the request in Backend App and use it as the key output field of the log.

☺️ this involves how to customize the LayoutRender of the log.

The following is a Render customized by Asp.NETCore NLog named x_request_id, which extracts the value from the requested X-Request-ID header.

① defines NLog Render

/ Represent a unique identifier to represent a request from the request HTTP header X-Request-Id. / / [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);}} / Represent a http context layout renderer to access the current http context. / public abstract class HttpContextLayoutRendererBase: LayoutRenderer {private IHttpContextAccessor _ httpContextAccessor; / Gets the. / / protected IHttpContextAccessor HttpContextAccessor {get {return _ httpContextAccessor? (_ httpContextAccessor = ServiceLocator.ServiceProvider.GetService ());} internal sealed class ServiceLocator {public static IServiceProvider ServiceProvider {get; set;}}

② gets the X-Request-Id dependent IHttpContextAccessor component from the request

Dependency lookup is used to get the component here, so please generate the service in Startup ConfigureService

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

③ finally registers the NLog Render with Program:

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

In this way, the request_id generated from Ingress-Nginx will be transferred to Backend App and play a huge role in log analysis, and it is also easy to clarify the fault responsibility of operation and maintenance / development.

This is the end of the content of "how Ingress-Nginx works". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.