Istio - 标签 - 研发日志 · R&D Loghttps://rd163.visword.com/tags/istio/Istio - 标签 - 研发日志 · R&D LogHugo -- gohugo.iozh-CNwhutluohui@gmail.com (小智晖)whutluohui@gmail.com (小智晖)本作品采用知识共享署名-非商业性使用 4.0 国际许可协议进行许可。Mon, 24 Mar 2025 00:00:00 +0800Envoy xDS 协议介绍https://rd163.visword.com/posts/xds-for-envoy/Mon, 24 Mar 2025 00:00:00 +0800小智晖https://rd163.visword.com/posts/xds-for-envoy/xDS（Extensible Discovery Service，可扩展发现服务）是 Envoy 代理用来从控制面（Control Plane）获取动态配置的一组 gRPC/REST API 的统称。这里的 “x” 代表具体的资源类型，例如 Listener、Route、Cluster、Endpoint，分别对应 LDS、RDS、CDS、EDS。借助 xDS，Envoy 能够在不停机、不 reload 的情况下热更新监听器、路由表、上游集群、证书等几乎所有运行期配置，这正是 Istio、Higress 等服务网格与云原生网关实现毫秒级配置生效的底层基础。

]]>K8s 服务网格配置发现协议https://rd163.visword.com/posts/k8s-service-mesh-config-proto/Sun, 12 Jan 2025 00:00:00 +0800小智晖https://rd163.visword.com/posts/k8s-service-mesh-config-proto/在服务网格场景下，控制面需要把监听器、路由、集群、端点、证书等配置高效、一致地下发到数据面（每个 sidecar 代理）。本文梳理 Istio 历史上使用过的两类配置分发协议：基于订阅的 MCP 与 Envoy 原生的 xDS。

]]>K8s 服务治理https://rd163.visword.com/posts/k8s-service-governance/Sun, 12 Jan 2025 00:00:00 +0800小智晖https://rd163.visword.com/posts/k8s-service-governance/<p>微服务架构将单体应用拆分为众多独立部署的服务，服务间的依赖与通信变得极其复杂。如何对这些分布式服务进行<strong>注册发现、流量调度、故障容错、统一配置和可观测</strong>,就是「服务治理（Service Governance）」要解决的核心问题。在 Kubernetes 已成为事实标准的今天，服务治理方案大致沿着「SDK/胖客户端库」到「Service Mesh 服务网格」两条路线演进。</p>Kmesh：基于 eBPF 的内核原生服务网格数据平面https://rd163.visword.com/posts/k8s-service-mesh-kmesh/Sun, 12 Jan 2025 00:00:00 +0800小智晖https://rd163.visword.com/posts/k8s-service-mesh-kmesh/ 背景

像 Istio 这样的服务网格（Service Mesh）已经成为管理复杂微服务架构的核心手段，提供流量管理、安全（mTLS）和可观测性等能力。Sidecar 模型——在每个业务 Pod 旁注入一个 Envoy 代理——是过去几年最主流的数据平面实现。它功能完备、对应用透明，但在性能与资源开销上代价不菲。

]]>云原生 API 网关https://rd163.visword.com/posts/cloud-native-api-gateway/Sun, 12 Jan 2025 00:00:00 +0800小智晖https://rd163.visword.com/posts/cloud-native-api-gateway/在 Kubernetes 与微服务架构中，API 网关（API Gateway）是南北向流量的统一入口，承担路由、认证、限流、可观测、协议转换等职责。与 Kubernetes 原生的 Ingress 相比，API 网关通常提供更丰富的流量治理能力;而随着 Gateway API 成为 Ingress 的继任者，网关也越来越多地以 GatewayClass 实现的身份接入集群。

]]>