超级会员免费看
其他服务网格技术介绍
1. Gloo Mesh 简介
Gloo Mesh 是 Solo.io 推出的一款服务网格产品，有开源版本（Gloo Mesh）和企业版本（Gloo Mesh Enterprise）。这两个版本都基于 Istio 服务网格，宣称在开源 Istio 的基础上拥有更好的控制平面和额外功能。Solo.io 在其官网（https://www.solo.io/products/gloo - mesh/）提供了 Gloo Mesh Enterprise、Gloo Mesh 开源版和 Istio 的功能对比。
Gloo Mesh 主要专注于提供一个 Kubernetes 原生管理平面，用户可以通过它跨多个集群配置和操作多个异构服务网格实例。它带有一个 API，能抽象管理和操作多个网格的复杂性，用户无需了解底层多个服务网格带来的复杂细节。关于 Gloo Mesh 的详细信息可查看：https://docs.solo.io/gloo - mesh - open - source/latest/getting_started/ 。
Solo.io 还有一款名为 Gloo Edge 的产品，它既可以作为 Kubernetes Ingress 控制器，也可以作为 API 网关。Gloo Mesh Enterprise 与 Gloo Edge 一起部署，提供了许多全面的 API 管理和 Ingress 功能。
2. Gloo Mesh Enterprise 特性
- 外部认证支持 ：Gloo Mesh Enterprise 增加了对使用 OIDC、OAuth、API 密钥、LDAP 和 OPA 进行外部认证的支持。这些策略通过一个名为 ExtAuthPolicy 的自定义 CRD 实现，当路由和目标匹配特定条件时可以应用这些认证。
- WAF 策略和数据防泄漏 ：提供 WAF 策略来监控、过滤和阻止任何有害的 HTTP 流量。还通过对 Envoy 记录的响应体和内容进行一系列正则表达式替换来支持数据防泄漏。DLP 过滤器可以在监听器、虚拟服务和路由上进行配置。
- 与遗留应用集成 ：支持通过 SOAP 消息格式连接到遗留应用。可以构建数据转换策略，对 SOAP/XML 端点应用 XSLT 转换以实现现代化。数据转换策略可用于转换请求或响应负载，还支持通过 Inja 模板进行特殊转换。
- WASM 过滤器支持 ：对 WASM 过滤器有广泛支持。Solo.io 提供了自定义工具来加速 Web 程序集的开发和部署。为存储 WASM 文件，Solo.io 提供了 WebAssembly Hub（https://webassemblyhub.io/）和一个名为 wasme 的开源 CLI 工具。更多使用信息可查看：https://docs.solo.io/web - assembly - hub/latest/tutorial_code/getting_started/ 。
- 全局 API 门户 ：Gloo Mesh 和 Solo.io 的其他产品与企业服务网格紧密集成，提供了如全局 API 门户这样的功能。API 门户是一个自发现门户，用于发布、共享和监控 API 使用情况，以实现内部和外部货币化。使用多异构网格时，用户无需为每个网格管理可观测性工具，Gloo Mesh Enterprise 提供跨所有网格的聚合指标，提供无缝的多网格管理和观测体验。
3. Gloo Mesh 的多租户和集成特性
在企业环境中，多个团队和用户需要在不相互干扰的情况下访问和部署服务网格中的服务。Gloo Mesh 使用工作区的概念，工作区是团队的逻辑边界，将团队的服务网格操作限制在工作区内，多个团队可以同时使用网格。工作区为每个团队发布的配置提供安全隔离，解决了企业环境中多租户的复杂性问题，使多个团队能够更简单地采用服务网格，实现配置隔离和严格的访问控制。
Gloo Mesh 还与基于不同架构的 Istio Ambient Mesh 集成。Istio Ambient Mesh 不是为每个工作负载添加边车代理，而是在每个节点级别添加代理。用户可以同时运行基于边车代理的网格和基于每个节点代理的 Istio Ambient Mesh。
Gloo Enterprise Mesh 与 Solo.io 的产品（如 Gloo Edge）集成，使其在服务网格产品中具有很强的竞争力。它支持多集群和多网格部署、通过工作区实现多租户、强大的认证支持、零信任网络以及通过 Gloo Edge 实现成熟的 Ingress 管理，是一个全面的服务网格解决方案。
4. Kuma 简介
Kuma 是 Kong Inc. 捐赠给 CNCF 的一个开源 CNCF 沙盒项目。和 Istio 一样，Kuma 也使用 Envoy 作为数据平面。它支持多集群和多网格部署，提供一个全局控制平面来管理所有这些。在撰写本文时，Kuma 是一个用 GoLang 编写的单一可执行文件，可以部署在 Kubernetes 和 VM 上。在非 Kubernetes 环境中部署时，需要一个 PostgreSQL 数据库来存储其配置。
5. Kuma 的安装和使用
- 下载 Kuma ：
% curl -L https://kuma.io/installer.sh | VERSION=2.0.2 sh
- 在 minikube 上安装 Kuma ：解压下载文件，在解压文件夹的 bin 目录中，运行以下命令在 Kubernetes 上安装 Kuma：
% kumactl install control - plane | kubectl apply -f -
这将创建一个名为 kuma - system 的命名空间，并在该命名空间中安装 Kuma 控制平面，同时配置各种 CRD 和准入控制器。
-
访问 Kuma 的 GUI
：
% kubectl port - forward svc/kuma - control - plane - n kuma - system 5681:5681
在浏览器中打开 localhost:5681/gui 即可看到 Kuma 仪表盘。Kuma GUI 提供了关于网格的全面详细信息，可用于检查配置。在 GUI 的主页上，会看到一个名为 default 的网格。Kuma 中的网格是一个逻辑上与其他 Kuma 服务网格隔离的服务网格。可以在一个 Kubernetes 集群中安装一个 Kuma，然后管理多个服务网格，也许每个团队或部门可以在该 Kubernetes 集群中部署他们的应用。
6. 在 Kuma 网格中部署应用
部署文件位于 AppendixA/Kuma/envoy - proxy - 01.yaml。与 Istio 相比，部署文件中明显的区别是添加了以下标签，指示 Kuma 将其边车代理注入到 envoydummy：
kuma.io/sidecar - injection: enabled
使用以下命令部署 envoydummy 和 curl 应用：
% kubectl create ns appendix - kuma
% kubectl apply -f AppendixA/Kuma/envoy - proxy - 01.yaml
几秒钟后，使用以下命令检查 Pod 是否已部署且边车是否已注入：
% kubectl get po -n appendix - kuma
边车也称为数据平面代理（DPPs），它们与网格中的每个工作负载一起运行。DPP 由定义 DPP 配置的数据平面实体和 kuma - dp 二进制文件组成。在启动时，kuma - dp 从 Kuma 控制平面（kuma - cp）检索 Envoy 的启动配置，并使用该配置启动 Envoy 进程。Envoy 启动后，使用 XDS 连接到 kuma - cp。kuma - dp 在启动时还会启动一个 core - dns 进程。
7. Kuma 策略实践
- 访问 envoydummy 服务 ：
% kubectl exec -it pod/curl -n appendix - kuma -- curl http://envoydummy:80
默认情况下，Kuma 允许流量进出网格，且所有流量在网格中都是未加密的。接下来将启用 mTLS 并拒绝网格中的所有流量以建立零信任网络。
-
删除允许所有流量的策略
：
% kubectl delete trafficpermissions/allow - all - traffic
- 启用 mTLS ：使用以下配置启用 mTLS：
apiVersion: kuma.io/v1alpha1
kind: Mesh
metadata:
name: default
spec:
mtls:
enabledBackend: ca - 1
backends:
- name: ca - 1
type: builtin
配置文件位于 AppendixA/Kuma/enablemutualTLS.yaml，使用以下命令应用配置：
% kubectl apply -f AppendixA/Kuma/enablemutualTLS.yaml
启用 mTLS 后，再次尝试访问 envoydummy 服务：
% kubectl exec -it pod/curl -n appendix - kuma -- curl http://envoydummy:80
由于启用了 mTLS 且没有允许 curl 和 envoydummy 之间流量的 TrafficPermission 策略，此时会得到空响应。
-
创建允许流量的策略
：创建以下 TrafficPermission 策略：
apiVersion: kuma.io/v1alpha1
kind: TrafficPermission
mesh: default
metadata:
name: allow - all - traffic - from - curl - to - envoyv1
spec:
sources:
- match:
kuma.io/service: 'curl_appendix - kuma_svc'
destinations:
- match:
kuma.io/service: 'envoydummy_appendix - kuma_svc_80'
配置文件位于 AppendixA/Kuma/allow - traffic - curl - to - envoyv1.yaml，使用以下命令应用配置：
% kubectl apply -f AppendixA/Kuma/allow - traffic - curl - to - envoyv1.yaml
再次尝试访问 envoydummy 服务，应该可以正常访问。
8. Kuma 流量管理和路由
- 部署 envoydummy v2 并测试访问 ：部署 envoydummy v2 版本，并定义允许 curl Pod 和 envoydummy v2 Pod 之间流量的权限。相关文件位于 AppendixA/Kuma/envoy - proxy - 02.yaml 和 AppendixA/Kuma/allow - traffic - curl - to - envoyv2.yaml。应用配置后，使用以下命令测试 curl 是否能够访问 envoydummy 的 v1 和 v2 版本：
% for ((i = 0; i < 2; i++)); do kubectl exec -it pod/curl -n appendix - kuma -- curl http://envoydummy ;done
-
配置流量路由
：使用 Kuma 的 TrafficRoute 策略配置路由。该策略可分为四个部分：
- 声明 TrafficRoute 策略：
apiVersion: kuma.io/v1alpha1
kind: TrafficRoute
mesh: default
metadata:
name: trafficroutingforlatest
spec:
sources:
- match:
kuma.io/service: curl_appendix - kuma_svc
destinations:
- match:
kuma.io/service: envoydummy_appendix - kuma_svc_80
2. 配置前缀为 '/latest' 的请求路由到 v2 版本：
conf:
http:
- match:
path:
prefix: "/latest"
destination:
kuma.io/service: envoydummy_appendix - kuma_svc_80
version: 'v2'
3. 配置前缀为 '/old' 的请求路由到 v1 版本：
- match:
path:
prefix: "/old"
destination:
kuma.io/service: envoydummy_appendix - kuma_svc_80
version: 'v1'
4. 声明不匹配上述路径的请求的默认目标：
destination:
kuma.io/service: envoydummy_appendix - kuma_svc_80
配置文件位于 AppendixA/Kuma/trafficRouting01.yaml，应用配置后，测试以下场景：
- 所有 ‘/latest’ 请求应路由到 v2 版本：
% for ((i = 0; i < 4; i++)); do kubectl exec -it pod/curl -n appendix - kuma -- curl http://envoydummy/latest ;done
- 所有 '/old' 请求应路由到 v1 版本：
% for ((i = 0; i < 4; i++)); do kubectl exec -it pod/curl -n appendix - kuma -- curl http://envoydummy/old ;done
- 所有其他请求应遵循默认行为：
% for ((i = 0; i < 4; i++)); do kubectl exec -it pod/curl -n appendix - kuma -- curl http://envoydummy/xyz ;done
- 加权路由配置 ：构建另一个流量路由策略进行加权路由，配置片段如下：
conf:
split:
- weight: 10
destination:
kuma.io/service: envoydummy_appendix - kuma_svc_80
version: 'v1'
- weight: 90
destination:
kuma.io/service: envoydummy_appendix - kuma_svc_80
version: 'v2'
配置文件位于 AppendixA/Kuma/trafficRouting02.yaml，应用配置后，使用以下命令测试流量分布：
% for ((i = 0; i < 10; i++)); do kubectl exec -it pod/curl -n appendix - kuma -- curl http://envoydummy/xyz ;done
流量应大致以 1:9 的比例分布在两个版本之间。可以使用 TrafficRoute 策略执行流量路由、流量修改、流量拆分、负载均衡、金丝雀部署和感知本地性的负载均衡。更多关于 TrafficRoute 的信息可查看：https://kuma.io/docs/2.0.x/policies/traffic - route 。
9. Kuma 创建新网格和网关
- 创建新网格 ：可以使用以下配置创建一个新的网格：
apiVersion: kuma.io/v1alpha1
kind: Mesh
metadata:
name: team - digital
配置文件位于 AppendixA/Kuma/team - digital - mesh.yaml，使用以下命令应用配置：
% kubectl apply -f AppendixA/Kuma/team - digital - mesh.yaml
创建网格后，在工作负载部署配置中添加以下注释来在该网格中创建所有资源：
kuma.io/mesh: team - digital
并在 Kuma 策略中添加：
mesh: team - digital
-
创建内置网关
：
- 定义 MeshGatewayInstance：
apiVersion: kuma.io/v1alpha1
kind: MeshGatewayInstance
metadata:
name: envoydummy - gateway - instance
namespace: appendix - kuma
spec:
replicas: 1
serviceType: LoadBalancer
tags:
kuma.io/service: envoydummy - edge - gateway
配置文件位于 AppendixA/Kuma/envoydummyGatewayInstance01.yaml。
2. 创建 MeshGateway：
apiVersion: kuma.io/v1alpha1
kind: MeshGateway
mesh: default
metadata:
name: envoydummy - edge - gateway
namespace: appendix - kuma
spec:
selectors:
- match:
kuma.io/service: envoydummy - edge - gateway
conf:
listeners:
- port: 80
protocol: HTTP
hostname: mockshop.com
tags:
port: http/80
配置文件位于 AppendixA/Kuma/envoydummyGateway01.yaml。
3. 定义 MeshGatewayRoute：示例配置可查看 AppendixA/Kuma/envoydummyGatewayRoute01.yaml。
4. 创建 TrafficPermission：配置文件位于 AppendixA/Kuma/allow - traffic - edgegateway - to - envoy.yaml。
使用以下命令应用配置：
% kubectl apply -f AppendixA/Kuma/envoydummyGatewayInstance01.yaml
% kubectl apply -f AppendixA/Kuma/envoydummyGateway01.yaml
% kubectl apply -f AppendixA/Kuma/envoydummyGatewayRoute01.yaml
% kubectl apply -f AppendixA/Kuma/allow - traffic - edgegateway - to - envoy.yaml
验证 Kuma 是否创建了网关实例：
% kubectl get po -n appendix - kuma
% kubectl get svc -n appendix - kuma
找到访问 Ingress 网关服务的 IP 地址：
% minikube service envoydummy - gateway - instance --url - n appendix - kuma
使用该 IP 地址访问 envoydummy 服务：
% curl -H "host:mockshop.com" http://127.0.0.1:52346/latest
10. Kuma 的其他特性和卸载
Kuma 还提供使用外部网关作为 Ingress 的选项，也称为委托网关。在委托网关中，Kuma 支持与各种 API 网关集成，但 Kong Gateway 是首选且文档最完善的选项。更多关于委托网关的信息可查看：https://kuma.io/docs/2.0.x/explore/gateway/#delegated 。
Kuma 与 Istio 一样，为基于 Kubernetes 和 VM 的工作负载提供原生支持。它支持跨多个 Kubernetes 集群、数据中心和云提供商运行高级服务网格配置。Kuma 有区域的概念，区域是可以相互通信的 DPP 的逻辑聚合。Kuma 支持在多个区域运行服务网格，并在多区域部署中分离控制平面。每个区域都有自己的水平可扩展控制平面，提供每个区域之间的完全隔离。所有区域还由一个集中的全局控制平面管理，该全局控制平面管理应用于 DPP 的策略的创建和更改，并将特定区域的策略和配置传输到各个底层区域的控制平面。全局控制平面是一个单一的操作界面，提供所有区域中所有 DPP 的清单。
Kong 还提供 Kong Mesh，它是基于 Kuma 构建的企业版，扩展了 Kuma 以包括运行企业工作负载关键功能所需的能力。Kong Mesh 提供了一个交钥匙服务网格解决方案，具有与 OPA 集成、FIPS 140 - 2 合规性和基于角色的访问控制等功能。结合 Kong Gateway 作为 Ingress 网关、基于 Kuma 的服务网格、额外的企业级附加组件和可靠的企业支持，使 Kong Mesh 成为一个交钥匙服务网格技术。
卸载 Kuma Mesh 可以使用以下命令：
% kumactl install control - plane | kubectl delete -f -
综上所述，Gloo Mesh 和 Kuma 都为服务网格领域提供了独特的解决方案，各自具有不同的特点和优势，用户可以根据自己的需求和场景选择合适的服务网格产品。
其他服务网格技术介绍（续）
11. Gloo Mesh 与 Kuma 的功能对比
为了更清晰地了解 Gloo Mesh 和 Kuma 这两种服务网格技术，下面通过表格对它们的一些关键功能进行对比：
| 功能特性 | Gloo Mesh | Kuma |
| — | — | — |
| 多集群和多网格支持 | 支持，可通过 Kubernetes 原生管理平面管理多个异构服务网格实例 | 支持，提供一个全局控制平面管理多集群和多网格部署 |
| 多租户支持 | 通过工作区实现多租户，提供配置隔离和严格访问控制 | 可创建不同的隔离网格，为团队提供隔离的网格环境 |
| 认证支持 | Gloo Mesh Enterprise 支持 OIDC、OAuth、API 密钥、LDAP 和 OPA 等外部认证 | 支持 mTLS 认证，可配置外部 CA |
| 数据安全 | 提供 WAF 策略和数据防泄漏功能 | 可通过 mTLS 实现安全通信，阻止敏感数据记录 |
| 与遗留应用集成 | 支持通过 SOAP 消息格式连接遗留应用 | 未提及明显的与遗留应用集成特性 |
| 网关支持 | 与 Gloo Edge 集成，提供成熟的 Ingress 管理 | 提供内置网关和支持委托网关（如 Kong Gateway） |
| 流量管理 | 未详细提及特殊流量管理策略 | 提供 TrafficRoute 策略进行流量路由、拆分、负载均衡等操作 |
从这个对比表格可以看出，Gloo Mesh 和 Kuma 在多集群和多网格支持方面都表现出色，但在其他功能上各有侧重。Gloo Mesh 在认证和与 Solo.io 产品集成方面有优势，而 Kuma 在流量管理和多网格隔离方面特色明显。
12. 服务网格选择决策流程
在选择 Gloo Mesh 还是 Kuma 作为服务网格解决方案时，可以参考以下 mermaid 流程图：
graph TD;
A[是否需要与 Solo.io 其他产品集成] -->|是| B[考虑 Gloo Mesh];
A -->|否| C[是否强调多网格隔离和流量管理];
C -->|是| D[考虑 Kuma];
C -->|否| E[是否需要强大的外部认证功能];
E -->|是| B;
E -->|否| F[是否需要与 Kong Gateway 集成];
F -->|是| D;
F -->|否| G[综合评估其他因素选择];
这个流程图展示了一个简单的决策过程。首先考虑是否需要与 Solo.io 其他产品集成，如果是则优先考虑 Gloo Mesh。如果不需要，接着看是否强调多网格隔离和流量管理，若是则考虑 Kuma。若不强调这一点，再看是否需要强大的外部认证功能，需要则选择 Gloo Mesh。若也不需要，再看是否需要与 Kong Gateway 集成，需要则选择 Kuma，否则就需要综合其他因素进行选择。
13. Gloo Mesh 和 Kuma 的应用场景分析
-
Gloo Mesh 应用场景
- 企业级多产品集成 ：当企业已经在使用 Solo.io 的其他产品（如 Gloo Edge），并且希望实现统一的服务网格管理时，Gloo Mesh 是一个很好的选择。它可以与 Gloo Edge 紧密集成，提供全面的 API 管理和 Ingress 功能。
- 复杂认证需求 ：对于有复杂外部认证需求的企业，如需要支持 OIDC、OAuth、API 密钥、LDAP 和 OPA 等多种认证方式，Gloo Mesh Enterprise 能够满足这些需求，提供强大的安全保障。
- 跨多个异构网格管理 ：如果企业的服务网格环境包含多个异构的服务网格实例，Gloo Mesh 的 Kubernetes 原生管理平面可以帮助用户更轻松地配置和操作这些网格，无需了解底层复杂细节。
-
Kuma 应用场景
- 多团队隔离部署 ：在企业中，不同团队需要在同一个 Kubernetes 集群中部署各自的应用，并且希望有隔离的网格环境。Kuma 可以创建多个隔离的网格，为每个团队提供独立的服务网格配置，实现安全隔离。
- 灵活的流量管理 ：对于需要进行精细流量管理的场景，如流量路由、流量拆分、负载均衡等，Kuma 的 TrafficRoute 策略提供了丰富的配置选项，可以满足各种复杂的流量管理需求。
- 与 Kong 生态集成 ：如果企业已经在使用 Kong Gateway，并且希望将其与服务网格集成，Kuma 支持与 Kong Gateway 集成，提供委托网关功能，实现更高效的流量入口管理。
14. 未来服务网格技术的发展趋势
随着云计算、微服务架构的不断发展，服务网格技术也在不断演进。以下是一些可能的发展趋势：
-
更强大的安全功能
：随着企业对数据安全和隐私的关注度不断提高，服务网格将提供更强大的安全功能，如更精细的访问控制、更高级的加密算法和零信任网络架构的进一步完善。
-
智能化的流量管理
：借助人工智能和机器学习技术，服务网格将实现更智能化的流量管理，如自动根据流量特征进行路由决策、预测性的负载均衡等。
-
与云原生生态的深度融合
：服务网格将与云原生生态系统（如 Kubernetes、容器编排工具等）进行更深度的融合，提供更无缝的集成和更好的用户体验。
-
简化的操作和管理
：为了降低使用门槛，服务网格技术将朝着简化操作和管理的方向发展，提供更直观的用户界面和更自动化的配置工具。
15. 总结与建议
Gloo Mesh 和 Kuma 都是优秀的服务网格技术，它们在不同的场景下各有优势。如果你正在考虑引入服务网格到你的项目中，可以按照以下步骤进行决策：
1.
明确需求
：仔细分析你的项目需求，包括是否需要与现有产品集成、对安全和流量管理的要求、是否需要多租户支持等。
2.
评估功能
：根据前面的功能对比和应用场景分析，评估 Gloo Mesh 和 Kuma 的功能是否满足你的需求。
3.
进行测试
：在测试环境中分别部署 Gloo Mesh 和 Kuma，进行功能测试和性能测试，亲身体验它们的特点和优势。
4.
综合决策
：结合测试结果和项目的长期规划，综合考虑选择最适合你的服务网格技术。
希望通过本文的介绍，你对 Gloo Mesh 和 Kuma 有了更深入的了解，能够在服务网格技术的选择上做出更明智的决策。在未来的服务网格应用中，不断关注技术的发展趋势，及时调整和优化你的服务网格架构，以适应不断变化的业务需求。
扫一扫
44
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
