zhaojiew的学习笔记

Replacing iptables with eBPF in Kubernetes with Cilium

k8s集群配置nfs存储卷

来看Cilium路由的几种核心模式。

Envoy，这个由Lyft开发并开源的代理，最初是为了应对分布式系统中那些棘手的网络难题而生。它用C++构建，目标明确：高性能、高稳定，尤其在高负载下也能保持确定性。这两大原则，是理解Envoy价值的关键。在深入Envoy之前，我们先快速明确一个概念：什么是代理？简单来说，代理就像一个中间人，它站在客户端和服务器之间，拦截流量。它。比如，你公司里的互联网代理，所有访问外网的请求都得先经过它，它会根据你的组织策略，过滤掉不允许访问的网站或协议，然后才把请求放出去。

看这个例子，当来自 coolstore-gateway 的流量，目标是 webapp.istioinaction.io 时，就把这些 HTTP 请求路由到名为 webapp 的服务的 80 端口。spec.gateways 字段指定了这个规则适用于哪个 Gateway，spec.hosts 指定了虚拟主机名，而 spec.http 部分则定义了具体的 HTTP 路由匹配和目标。

我们可以在 apigateway 的 VirtualService 中，设置一个规则，当 apigateway 收到请求时，它内部调用 catalog 时，也要根据请求头来决定是调用 v1 还是 v2。Istio 提供了 ServiceEntry 这个资源，可以把 ServiceEntry 理解为一个“通行证”，它允许我们把外部服务的信息，比如主机名、端口、协议，添加到 Istio 的内部服务注册表里。在发布新版本时，我们也可以选一小部分用户，比如内部员工，作为我们的金丝雀，让他们先体验新版本。

微服务将大系统拆解成一个个独立的、小型的服务单元。每个服务可以独立部署、快速迭代，团队可以自主决策，大大降低了变更风险。当然，微服务不是万能药，它需要强大的自动化和DevOps实践作为支撑。而Istio这样的工具，正是在微服务环境下，帮助我们实现流量控制、服务间韧性、指标收集等关键能力，让快速迭代变得可行且安全。学习和进步，离不开反馈。自动化测试就是我们获取反馈、加速迭代的利器。它能让我们在代码变更后，立刻知道是否引入了新的bug，或者功能是否按预期工作。

在分布式系统中，服务间的依赖关系就像一张错综复杂的网络，任何一个节点的抖动都可能引发连锁反应。这也是为什么我们需要强调弹性，因为在分布式系统中，服务之间通过网络进行通信，这本身就引入了无数个潜在的失败点。我们必须让服务从一开始就具备“容错”的意识，能够主动感知并尝试恢复，而不是被动等待。例如A服务访问B服务，可能的错误有在 Istio 这样的服务网格技术普及之前，我们通常需要在应用代码里自己写这些弹性逻辑。

更重要的是，这种动态加载的能力，使得我们可以将一些原本属于业务逻辑的东西，比如根据用户的订阅计划来限制请求速率，或者根据用户类型将请求路由到不同的服务集群，或者进行复杂的多变量测试，这些都可以通过编写WASM模块，动态地注入到数据平面中去执行。方法很多，比如你想记录更详细的访问日志，或者想用特定的指标插件，或者需要一套自定义的认证授权流程，甚至想用更高级的限流算法，都可以通过扩展Sidecar代理来实现。，它扮演了桥梁的角色，接收来自Istio控制平面的配置，然后翻译成NGINX能够理解和使用的配置格式。