禁止同ip网站查询,网站开发看谁的教程,黄冈十大软件推荐,网站建设课程设计实训心得本文记录/分享 目前项目的 K8s 部署结构和请求追踪改造方案这个图算是一个通用的前后端分离的 k8s 部署结构:Nginx Ingress 负责暴露服务(nginx前端静态资源服务)#xff0c; 根据十二要素应用的原 则#xff0c;将后端 api 作为 nginx 服务的附加动态资源。Ingress vs Ingre… 本文记录/分享 目前项目的 K8s 部署结构和请求追踪改造方案这个图算是一个通用的前后端分离的 k8s 部署结构:Nginx Ingress 负责暴露服务(nginx前端静态资源服务) 根据十二要素应用的原 则将后端 api 作为 nginx 服务的附加动态资源。Ingress vs Ingress-nginxIngress 是一种向 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: kibanalabels:app: kibanaannotations:kubernetes.io/ingress.class: nginxnginx.ingress.kubernetes.io/proxy-connect-timeout: 30nginx.ingress.kubernetes.io/proxy-read-timeout: 1800nginx.ingress.kubernetes.io/proxy-send-timeout: 1800nginx.ingress.kubernetes.io/proxy-body-size: 8mnginx.ingress.kubernetes.io/ssl-redirect: true
spec:tls:- hosts:- https://logging.internal.gridsum.com/secretName: tls-certrules:- host: https://logging.internal.gridsum.comhttp:paths:- path: /backend:serviceName: kibanaservicePort: 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: elasticsearchlabels:app: kibanaannotations:kubernetes.io/ingress.class: nginxnginx.ingress.kubernetes.io/proxy-connect-timeout: 30nginx.ingress.kubernetes.io/proxy-read-timeout: 1800nginx.ingress.kubernetes.io/proxy-send-timeout: 1800nginx.ingress.kubernetes.io/proxy-body-size: 8mnginx.ingress.kubernetes.io/ssl-redirect: truenginx.ingress.kubernetes.io/rewrite-target: /$2
spec:tls:- hosts:- logging.internal.gridsum.comsecretName: tls-certrules:- host: logging.internal.gridsum.comhttp:paths:- path: /es(/|$)(.*)backend:serviceName: elasticsearchservicePort: 9200
在此 Ingress 定义中由(.*)捕获的所有字符都将分配给占位符$2然后将其用作重写目标注解中的参数。这样的话https://logging.internal.gridsum.com/es 将会重定向到后端 elasticsearch 站点并且忽略了 es 这个 pathIngress-nginx 到 webapp 的日志追踪熟悉我的朋友知道 我写了《一套标准的ASP.NET Core容器化应用日志收集分析方案》这里面主要是 BackEnd App 的日志从我上面的结构图看Ingress-nginx---- Nginx FrontEnd App---BackEnd App 需要一个串联的追踪 Id 便于观察运维网络和业务应用。幸好 Ingress-nginx Nginx 强大的配置能力帮助我们做了很多事情•客户端请求到达 Ingress-Nginx ControllerrIngress-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./// /summarypublic abstract class HttpContextLayoutRendererBase : LayoutRenderer{private IHttpContextAccessor _httpContextAccessor;/// summary/// Gets the see crefIHttpContextAccessor/./// /summaryprotected IHttpContextAccessor HttpContextAccessor { get { return _httpContextAccessor ?? (_httpContextAccessor ServiceLocator.ServiceProvider.GetServiceIHttpContextAccessor()); } }}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.RegisterXRequestIdLayoutRender(x_request_id);CreateHostBuilder(args).Build().Run();
}
这样从 Ingress-Nginx 产生的request_id将会流转到 Backend App 并在日志分析中起到巨大作用也便于划清运维/开发的故障责任。•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总结1.了解了Ingress在应用层工作根据Host和Path暴露k8s服务。2.本文梳理了Ingress和常见的Ingress-nginx的关系。3.对于应用了Ingress的应用梳理了从Ingress-nginx到WebApp的日志追踪id 便于排查网络/业务故障。
