Ingress、Istio 和 APISIX 都是与云原生环境紧密相关的技术,在现代应用部署中扮演着重要角色,尤其是在微服务架构中。今天这篇文章内容,先弄明白他们都是干嘛的,然后有什么区别,后面的文章再分别深入展开实例了解。
官方文档:
Ingress:https://kubernetes.io/docs/concepts/services-networking/ingress/
lstio:https://istio.io/latest/zh/
Apisix: https://apisix.apache.org/docs/
总之最详细的内容还是在官网,只是有些内容官网说的比较晦涩,所以常看官网的同时再借助他人的讲解一定会事半功倍。加油!
先说说 ingress,Ingress 是 Kubernetes 的一个组件,Ingress 主要作为一个 API 对象,它处理外部访问集群内服务的请求,提供 HTTP 和 HTTPS 路由。Ingress 允许用户通过定义规则来指定外部请求如何路由到服务,这样用户就可以通过一个入口点访问多个服务。Ingress 作为单一的入口点简化了复杂的路由规则,并且可以与 Let's Encrypt 等服务集成以自动管理 SSL/TLS 证书。
通过简短的特性看一下:
假如给一个零售店服务配置ingress,看yaml注释就明白了。
apiVersion: networking.k8s.io/v1 # 使用的 Kubernetes API 版本
kind: Ingress # 资源类型是 Ingress
metadata:
name: e-commerce-ingress # Ingress 资源的名称
annotations: # 使用注解来定义 Ingress 控制器相关的配置
kubernetes.io/ingress.class: "nginx" # 指定 Ingress 控制器的类型
nginx.ingress.kubernetes.io/rewrite-target: / # 重写目标路径
spec:
tls: # TLS 配置部分
- hosts:
- shop.example.com # 指定域名
secretName: shop-tls # 指定存有 TLS 证书的 Kubernetes Secret
rules: # 定义路由规则
- host: shop.example.com # 对应的域名
http:
paths:
- path: / # 对应前端 UI 的路径
pathType: Prefix # 路径类型是前缀匹配
backend:
service:
name: frontend-service # 前端服务的名称
port:
number: 80 # 服务的端口
- path: /products # 对应商品服务的路径
pathType: Prefix
backend:
service:
name: products-service # 商品服务的名称
port:
number: 80
- path: /orders # 对应订单服务的路径
pathType: Prefix
backend:
service:
name: orders-service # 订单服务的名称
port:
number: 80
lstio是一个开源的服务网格,它提供了一种方式来控制、管理和监视在多个微服务之间的网络通信。服务网格是在应用程序之上,但在网络层之下的一个基础设施层。lstio 提供了负载均衡、服务到服务的认证、流量转移规则、故障注入、金丝雀发布、分布式踪等功能,无需更改服务代码。
如果你有一个微服务架构的在线交易处理平台,lstio可以用来:
相比 Ingress,Istio 提供更为复杂和全面的功能集合,对于大型分布式应用是非常有用的,但也带来了更高的学习曲线和资源消耗。
apiVersion: networking.istio.io/v1beta1 # Istio 网络 API 版本
kind: VirtualService # 资源类型为 VirtualService
metadata:
name: backend-virtualservice # VirtualService 的名称
spec:
hosts:
- backend-service # 服务主机名
http:
- match:
- uri:
prefix: /api/v1/ # 匹配的 URI 前缀
route:
- destination:
host: backend-service
subset: v1 # 路由到的目标子集
weight: 90 # 流量权重
- destination:
host: backend-service
subset: v2
weight: 10 # 较小的权重,用于金丝雀发布
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule # 资源类型为 DestinationRule
metadata:
name: backend-destinationrule # DestinationRule 的名称
spec:
host: backend-service
subsets: # 定义子集
- name: v1
labels:
version: v1 # 子集标签
- name: v2
labels:
version: v2 # 用于金丝雀发布的子集标签
这个简单的介绍可以看我之前这篇文章的介绍:Ingress-Nginx已经淘汰了?还是Apisix太强大!
从几个方面看:
{
"uri": "/backend/*", // 定义请求路径匹配规则
"name": "backend-route", // 路由规则名称
"methods": ["GET", "POST", "PUT"], // 允许的请求方法
"hosts": ["api.store.example.com"], // 请求匹配的主机名
"upstream": {
"nodes": {
"backend-service:80": 1 // 后端服务的地址和权重
},
"type": "roundrobin" // 后端服务的负载均衡策略,此处为轮询
},
"plugins": {
"jwt-auth": { // 启用 JWT 认证插件
"key": "your-jwt-key", // JWT Key
"secret": "your-jwt-secret" // JWT Secret
},
"rate-limiting": { // 启用请求速率限制插件
"rate": 1000, // 每秒请求数量限制
"burst": 2000, // 请求突发数量限制
"key": "remote_addr" // 限制的依据,此处为客户端 IP 地址
}
}
}
Ingress是Kubernetes的标配,适合基本的HTTP路由需求,它集成了负载均衡和SSL终端,但在性能和定制方面就显得有点儿力不从心。更适合中小型企业希望将他们的几个服务部署在 Kubernetes 上,而这些服务需要通过互联网暴露给客户端的情况。
Istio是服务网格领导者,它不仅能路由流量,还能提供丰富的流量管理策略、服务监控和安全保障,但是复杂性和资源消耗可能会让人望而却步。更适合类似金融公司拥有多个微服务,这些服务需要细致的流量控制、加密的服务间通信、以及全面的监控这样的场景。
APISIX作为API网关,性能出众,可扩展性强,拥有灵活的插件机制,非常适合现代化的微服务架构,但与K8s的集成和Ingress相比稍微复杂一些。适合类似大型在线零售平台,它需要处理成千上万的客户端 API 请求,并对这些请求进行身份验证、速率限制和其他安全检查。APISIX 能够以高性能的方式处理这些请求,同时提供了丰富的插件来满足业务需求。
嗯,通过以上介绍,各位读者应该有所了解了吧,后期我也会不断实践总结,分享给大家,记得关注呀!