Este artículo registra / comparte la estructura de implementación de K8 del proyecto actual y el plan de transformación de seguimiento de solicitudes
Este diagrama puede considerarse como una estructura de implementación general de k8s con separación de front-end y back-end:
Nginx Ingress es responsable de exponer los servicios (servicio de recursos estáticos de front-end nginx). De acuerdo con el principio de la aplicación de doce elementos
, la parte posterior -end api se utiliza como un recurso dinámico adicional para los servicios nginx.
Ingress vs Ingress-nginx
Sitio web del cupón https://www.fenfaw.net/Ingress es un método de exposición de servicios a clientes fuera del clúster K8S. Ingress trabaja en la capa de aplicación de la red de pila de protocolo ,
y determina el servicio al que la solicitud se reenvía basa en la solicitada anfitrión nombre de host y la ruta camino.
Antes de aplicar las funciones proporcionadas por el objeto Ingress, se debe enfatizar que el controlador Ingress existe en el clúster para que el recurso Ingress pueda funcionar con normalidad.
Mi proyecto web aquí usa el Ingress-nginx común (el Ingress oficial para otros propósitos). Ingress-nginx es un controlador de Ingress K8s que usa nginx como un proxy inverso y balanceador de carga. Se ejecuta como un Pod en el kube-systemespacio de nombres.
Comprender el principio de funcionamiento de Ingress es propicio para la forma en que tratamos con el personal de operación y mantenimiento.
A continuación, se expone el servicio Kibana a través de 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
Ingress-nginx me confundió más es que son Paths分流las rewrite-targetnotas.
- La derivación de rutas se
usa generalmente para reenviar solicitudes a un Pod de servicio de back-end específico de acuerdo con una Ruta específica, y el Pod de servicio de back-end puede recibir la información de Ruta.
Generalmente, el servicio de back-end se usa como una API. - Rewrite-target
redirige la solicitud al servicio de back-end. ¿Cuál es el uso?
Respuesta: Tome la kibana expuesta anteriormente como ejemplo. Ya podemos https://logging.internal.gridsum.com/acceder a la Kibana completa. ¿Qué pasa si quiero usar este nombre de dominio para exponer el sitio ElasticSearch?
Puedes usarlo rewrite-targeten este momento ,
---
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
En esta definición de Ingress, (.*)todos los caracteres capturados por él se asignarán al marcador de posición $ 2, que luego se usará como parámetro en la anotación de destino de reescritura. En este caso: https://logging.internal.gridsum.com/esserá redirigido al sitio de backend elasticsearch y se ignorará la ruta de es
Ingress-nginx al seguimiento de registros de aplicaciones web
Mis amigos que están familiarizados conmigo saben que escribí "Un programa estándar de análisis y recopilación de registros de aplicaciones en contenedores ASP.NET Core", que contiene principalmente registros de aplicaciones de backend. En el diagrama de estructura anterior,
Ingress-nginx ----> Aplicación Nginx FrontEnd ---> La aplicación BackEnd requiere una identificación de seguimiento en serie, que es conveniente para observar la red de operación y mantenimiento y las aplicaciones comerciales.
Afortunadamente, Ingress-nginx, las poderosas capacidades de configuración de Nginx nos han ayudado a hacer muchas cosas:
-
La solicitud del cliente llega al controlador Ingress-Nginx, el controlador Ingress-Nginx agregará automáticamente un
X-Request-IDencabezado de solicitud, un valor aleatorio; esta configuración es la predeterminada -
La solicitud llega a la aplicación Nginx FrontEnd, Nginx tiene una configuración predeterminada
proxy_pass_request_headers on;y automáticamente pasa todos los encabezados de solicitud a la aplicación backend ascendente
De esta manera, la idea de request_id en todo el diagrama de estructura es clara. El último paso solo requiere que extraigamos la información contenida en la solicitud en la aplicación Backend X-Request-IDy la usemos como el campo de salida clave del registro.
Esto implica cómo personalizar LayoutRender desde el registro .
A continuación, se muestra el x_request_idRender personalizado de NLog , que extrae el valor del encabezado X-Request-ID de la solicitud.
① Definir 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; }
}
② Obtener el X-Request-Id de la solicitud depende del componente IHttpContextAccessor.
Este componente se obtiene mediante la búsqueda de dependencias, así que genere el servicio en Startup ConfigureService
public void ConfigureServices(IServiceCollection services)
{
// ......
ServiceLocator.ServiceProvider = services.BuildServiceProvider();
}
③ Finalmente registre este NLog Render en el Programa:
public static void Main(string[] args)
{
LayoutRenderer.Register<XRequestIdLayoutRender>("x_request_id");
CreateHostBuilder(args).Build().Run();
}
De esta manera request_id, lo que se genera a partir de Ingress-Nginx fluirá a la aplicación Backend y desempeñará un papel muy importante en el análisis de registros, y también es conveniente distinguir la responsabilidad de falla de operación y mantenimiento / desarrollo.
- https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#generate-request-id
- http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass_request_headers
para resumir
- Comprender que Ingress funciona en la capa de la aplicación y expone los servicios de k8s basados en el host y la ruta.
- Este artículo analiza la relación entre Ingress y el Ingress-nginx común
- Para las aplicaciones que usan Ingress, se ha resuelto el ID de seguimiento de registros de Ingress-Nginx a WebApp, lo cual es conveniente para solucionar problemas de red / fallas comerciales