在 Kubernetes (k8s) 中,Ingress 是一个 API 对象,它管理着集群中服务的外部访问,通常是 HTTP/HTTPS 流量。Ingress 可以提供路由规则,定义如何将外部请求路由到集群中的不同服务。
Kubernetes Ingress 的含义
- 服务入口点:
Ingress为 Kubernetes 集群提供了一个入口点,使得外部流量能够访问集群内部的服务。 - 路由规则:它定义了一系列规则,用于将进入集群的请求映射到不同的服务。
- 负载均衡:
Ingress可以配置为执行简单的负载均衡,将流量分发到多个后端服务。
Kubernetes Ingress 的实现
Kubernetes 本身不直接处理 Ingress 资源,而是依赖于 Ingress Controller 来实现具体的路由规则。以下是一些流行的 Ingress Controller 实现:
-
Ingress n ginx Controller: 它是由Kubernetes社区基于Nginx Web服务器开发的,并补充了一组用于实现额外功能的Lua插件,作为“官方”默认控制器支持。
Github: github.com/kubernetes/…
-
Nginx Ingress Controller:
这是Nginx官方社区开发产品,Nginx ingress具有很高的稳定性,持续的向后兼容性,没有任何第三方模块,并且由于消除了Lua代码而保证了较高的速度。
-
-
使用 Nginx 作为反向代理和负载均衡器。
-
它是最流行的
Ingress Controller之一,功能丰富且配置灵活。Github: github.com/nginxinc/ku…
-
-
Traefik:
-
- 一个开源的反向代理和负载均衡器,专为微服务架构设计。
- 它自动发现 Kubernetes 集群中的服务,并配置路由规则。
-
HAProxy Ingress Controller:
-
- 基于高性能的 HAProxy 负载均衡器。
- 提供丰富的配置选项和强大的性能。
-
Istio Ingress Gateway:
-
- 作为服务网格 Istio 的一部分,它提供了更高级的特性,如流量管理、安全性和监控。
- 它通常与 Kubernetes 一起使用,以提供更细粒度的控制。
-
Kong Ingress Controller:
-
- 基于 Kong API 网关,提供 API 管理功能。
- 适用于需要 API 管理和微服务架构的场景。
-
Contour:
-
- 使用 Envoy 作为其数据平面,提供高性能的 HTTP 反向代理功能。
-
AWS Load Balancer Controller:
-
- 适用于 AWS 环境,可以管理 AWS Load Balancers,并与 Kubernetes Ingress 资源集成。
-
GCE Ingress Controller:
-
- 为 Google Kubernetes Engine (GKE) 提供了集成的负载均衡器。
每种 Ingress Controller 都有其独特的特性和配置选项,选择哪种实现取决于具体的需求和偏好。安装和使用 Ingress Controller 后,你可以通过定义 Ingress 资源来指定如何将外部请求路由到 Kubernetes 集群中的服务。
这里我们选择k8s官方提供的Ingress n ginx Controller进行改造,它是基于Nginx的扩展版OpenResty及诸多第三方模块构建的,其基于OpenResty的Lua嵌入式编程能力,扩展了 Nginx的功能,并基于balancer_by_lua 模块实现了Pod变化的动态变更功能
OpenResty处理流程
Directives - OpenResty Reference (openresty-reference.readthedocs.io)
从图中可知OpenResty 处理请求大致分为4个大阶段,11个小阶段
四个大阶段
- 初始化阶段(Initialization Phase):master进程启动预加载/生成worker进程预加载
- 重写、转发、访问阶段(Rewrite / Access Phase):URL转发、权限判断
- 内容处理/生成阶段(Content Phase):内容生成
- 日志阶段(Log Phase):日志记录
七个小阶段
- init_by_lua_file:master-initing 阶段,初始化全局配置或模块
- init_worker_by_lua_file:worker-initing 阶段,初始化进程专用功能
- ssl_certificate_by_lua_file:ssl 阶段,在握手时设置安全证书
- set_by_lua_file:rewrite 阶段,改写 Nginx 变量
- rewrite_by_lua_file:rewrite 阶段,改写 URI ,实现跳转或重定向
- access_by_lua_file:access 阶段,访问控制或限速
- content_by_lua_file:content 阶段,产生响应内容
- balancer_by_lua_file:content 阶段,反向代理时选择后端服务器
- header_filter_by_lua_file:filter 阶段,加工处理响应头
- body_filter_by_lua_file:filter 阶段,加工处理响应体
- log_by_lua_file:log 阶段,记录日志或其他的收尾工作
我们可以在balancer_by_lua_file中处理环境路由,在access_by_lua_file中设置路由开关
开启路由功能
环境路由代码逻辑
1、支持从branch、User-agent、Cookie等多种header头获取环境路由染色标识,以方便支持PC、H5、App、webview等多种场景
2、当同时配置时,进行优先级判断:优先branch>User-Agent>Cookie
3、根据获取到的目标环境标识,判断相应的k8s service是否存在(调用dns_lookup),若存在,则从中随机选择一个endpoints赋值给自定义变量ngx.var.branchEnv_endpoint
4、为了限制环境标识的复杂性,这里做了限制,此处只支持主环境,但会把标记往下透传。
**负载均衡逻辑增强
**
在负载均衡阶段,其主要逻辑就是设置目标服务器端点(IP:Port)。如果ngx.var.branchEnv_endpoint变量存在,则赋值给目标端点,否则走以前的逻辑。
至此,入口层的环境路由功能就构建好了!!!
敬请期待下一篇,聊一聊RPC层的处理方式!!!
如果你觉得这篇文章对你有帮助,请不要吝惜你的“关注”、“点赞”、“评价”,我们可以进一步讨论实现方案和细节。你的支持永远是我前进的动力~~~