时间:2021-05-02
本文记录/分享 目前项目的 K8s 部署结构和请求追踪改造方案
这个图算是一个通用的前后端分离的 k8s 部署结构:
Nginx Ingress 负责暴露服务(nginx前端静态资源服务), 根据十二要素应用的原 则,将后端 api 作为 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注解。
答:以上面暴露的 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
熟悉我的朋友知道, 我写了《一套标准的ASP.NET Core容器化应用日志收集分析方案》,这里面主要是 BackEnd App 的日志,从我上面的结构图看,
Ingress-nginx----> Nginx FrontEnd App--->BackEnd App 需要一个串联的追踪 Id, 便于观察运维网络和业务应用。
幸好 Ingress-nginx, Nginx 强大的配置能力帮助我们做了很多事情:
这样跨越整个结构图的 request_id 思路已经清楚了,最后一步只需要我们在 Backend App 中提取请求中携带的X-Request-ID, 并作为日志的关键输出字段。
这就涉及到怎么自定义日志的LayoutRender。
下面为Asp.NETCore NLog 自定义名为x_request_id的 Render,该 Render 从请求的 X-Request-ID 标头中提取值。
① 定义 NLog Render
///<summary>
///RepresentauniqueidentifiertorepresentarequestfromtherequestHTTPheaderX-Request-Id.
///</summary>
[LayoutRenderer("x_request_id")]
publicclassXRequestIdLayoutRender:HttpContextLayoutRendererBase
{
protectedoverridevoidAppend(StringBuilderbuilder,LogEventInfologEvent)
{
varidentityName=HttpContextAccessor.HttpContext?.Request?.Headers?["X-Request-Id"].FirstOrDefault();
builder.Append(identityName);
}
}
///<summary>
///Representahttpcontextlayoutrenderertoaccessthecurrenthttpcontext.
///</summary>
publicabstractclassHttpContextLayoutRendererBase:LayoutRenderer
{
privateIHttpContextAccessor_httpContextAccessor;
///<summary>
///Getsthe<seecref="IHttpContextAccessor"/>.
///</summary>
protectedIHttpContextAccessorHttpContextAccessor{get{return_httpContextAccessor??(_httpContextAccessor=ServiceLocator.ServiceProvider.GetService<IHttpContextAccessor>());}}
}
internalsealedclassServiceLocator
{
publicstaticIServiceProviderServiceProvider{get;set;}
}
② 从请求中获取 X-Request-Id 依赖 IHttpContextAccessor 组件
这里使用依赖查找的方式获取该组件,故请在Startup ConfigureService 中生成服务
publicvoidConfigureServices(IServiceCollectionservices)
{
//......
ServiceLocator.ServiceProvider=services.BuildServiceProvider();
}
③ 最后在 Program 中注册这个NLog Render:
publicstaticvoidMain(string[]args)
{
LayoutRenderer.Register<XRequestIdLayoutRender>("x_request_id");
CreateHostBuilder(args).Build().Run();
}
这样从 Ingress-Nginx 产生的request_id,将会流转到 Backend App, 并在日志分析中起到巨大作用,也便于划清运维/开发的故障责任。
总结
1.了解了Ingress在应用层工作,根据Host和Path暴露k8s服务。
2.本文梳理了Ingress和常见的Ingress-nginx的关系。
3.对于应用了Ingress的应用,梳理了从Ingress-nginx到WebApp的日志追踪id, 便于排查网络/业务故障。
原文地址:https://mp.weixin.qq.com/s/o9mj8_4fUF7M__UeYbEA8g
声明:本页内容来源网络,仅供用户参考;我单位不保证亦不表示资料全面及准确无误,也不保证亦不表示这些资料为最新信息,如因任何原因,本网内容或者用户因倚赖本网内容造成任何损失或损害,我单位将不会负任何法律责任。如涉及版权问题,请提交至online#300.cn邮箱联系删除。
本文主要介绍一些Nginx做图片服务器的简单配置,但不包括Nginx的安装部署以及实现原理。配置步骤下载nginxWindowsnginx安装教程及简单实践配置
举个例子吧Django最佳实践与部署:Nginx+Gunicorn+Supervisor(Ubuntu和CentOS)http://sfdye.com/arti
偶尔听人说用nginx实现文件上传下载,之前看nginx实践大致看到过,没有细究。所以今天就想研究下nginx实现文件的上传下载,直接开搞,本地服务启起。这
本文会介绍一些Nginx与Libressl一起使用实践经验。本文所用软件的版本nginx1.6.0libressl2.0.0安装直接从源码编译LibreSSL,
WIKI:http://wiki.nginx.org/HttpLimitReqModule漏桶原理(leakybucket):http://en.wikiped