关于 ingress、lstio、apisix
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，Ingress 是 Kubernetes 的一个组件，Ingress 主要作为一个 API 对象，它处理外部访问集群内服务的请求，提供 HTTP 和 HTTPS 路由。Ingress 允许用户通过定义规则来指定外部请求如何路由到服务，这样用户就可以通过一个入口点访问多个服务。Ingress 作为单一的入口点简化了复杂的路由规则，并且可以与 Let's Encrypt 等服务集成以自动管理 SSL/TLS 证书。
通过简短的特性看一下：
- 主要用途：Kubernetes 集群中的 HTTP/HTTPS 路由。
- 工作层级：作用于 OSI 模型的第七层（应用层），主要管理基于域名或路径的路由。
- 功能限制：主要负责流量的入口管理，对于出口和服务间通信不提供直接支持。
- 部署简易性：比 Istio 和 APISIX 更为简单，易于设置和维护，适合小型或中等规模的应用。
- 插件性质：需要一个 Ingress 控制器来实现这些规则，如 Nginx Ingress 控制器或 Traefik。
通用配置
假如给一个零售店服务配置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 提供了负载均衡、服务到服务的认证、流量转移规则、故障注入、金丝雀发布、分布式踪等功能，无需更改服务代码。
如果你有一个微服务架构的在线交易处理平台，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 # 用于金丝雀发布的子集标签
apisix
这个简单的介绍可以看我之前这篇文章的介绍：Ingress-Nginx已经淘汰了？还是Apisix太强大！
从几个方面看：
- 管理和优化路由，实现请求的负载均衡和故障转移。
- 通过限制速率、熔断、重试机制等，保护后端服务不被过载。
- 支持多种认证机制，例如 Key Auth、JWT、OAuth等，保障API的安全性。
- 提供高度可观测性，集成如 Prometheus 和 Grafana 等工具来监控和分析API使用情况。
- 提供丰富的插件， 具有强大的插件系统，允许用户根据需要启用或禁用功能，如限流、熔断、监控、认证等。apisix聚焦于API管理，提供了访问控制、流量控制、日志记录、监控和各种身份验证机制等功能。相较于Ingress，APISIX 优化了其代理性能，适用于高吞吐量及低延迟的场景。主要是第七层（应用层），但可以支持四层的 TCP/UDP 流量管理。
通用配置实例
{
"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 能够以高性能的方式处理这些请求，同时提供了丰富的插件来满足业务需求。
嗯，通过以上介绍，各位读者应该有所了解了吧，后期我也会不断实践总结，分享给大家，记得关注呀！
