2025-03-27 14:57:27
过去一年中，我一直享有 GitHub Copilot 的免费使用资格，但是由于种种原因，我并没有深入地使用它。最近看到了 GitHub 官方发布的一篇关于 Copilot 的博客《Mastering GitHub Copilot: When to use AI agent mode》，让我对如何更好地使用 Copilot 有了新的灵感和思考。
在这篇文章里，我想和大家分享一下我对 Copilot 强大功能的理解，尤其是 Copilot Edits 和 Agent Mode 这两个模式之间的差异和使用场景。最后，我还想呼吁所有开源项目的贡献者：如果你符合条件，一定要去积极申请 Copilot 免费使用资格，让自己的开发效率更上一个台阶！
大多数开发者在接触 AI 辅助编码工具（比如 GitHub Copilot）时，都会或多或少地遇到一些状况，比如：
其实，这些小挫折往往不在于工具本身，而在于你是否找对了使用方式。GitHub Copilot 内部包含多个侧重点各不相同的功能，它们各自适合在不同的情景下使用。正确地选择合适的功能，就是解锁 Copilot 真正实力的关键。
Copilot Edits 的功能就像是给你配备了一个能读懂上下文的“超级编辑器”。你可以快速发出命令，让它在有限范围内对现有代码进行改动，并在提交前查看 diff，随时保持对改动的掌控。
与 Copilot Edits 相比，Agent Mode 更像是一个能够宏观统筹全局的 AI 助手。它不只是在一个文件里给你提建议，更可以去你的整个项目里做深度搜索、自动找出依赖关系、创建或修改多个文件，甚至可以帮你在终端里运行命令、编译、测试项目等。
UserService 写测试并确保全部通过”。博主（也就是我）在给个人网站的 GitHub Action 中增加一个更新索引文件的工作，可以告诉 Copilot Agent：
“给我的 GitHub Action 中增加一个更新 search index 的任务并在本地测试”
然后 Copilot Agent 会扫描我的代码库，聪明地在我的 GitHub Action 配置文件中帮我插入相应的任务，并会自动的安装依赖软件并运行测试。
这就是 Agent Mode 的强大之处，它可以一次性处理全局级别的改动，真正让 AI 成为你的“对等”开发伙伴。
无论你是想使用 Copilot Edits 还是 Agent Mode，你都会用到 VS Code 里的 Copilot Chat 窗口：
/explain 理解复杂代码片段。/fix 让 Copilot 帮你调试。/tests 为给定代码自动生成测试用例。记住：你提供的上下文信息越完整，Copilot 生成的回答就越准确。请不要吝啬给它多一些提示！
原文中强调了一点：Copilot Edits 和 Agent Mode 并不是二选一的对立关系，而是相辅相成。
AI 只是辅助，我们才是项目的主导者，无论在任何模式下，你都随时拥有最终的决定权。与 AI 协作的关键是：在发起需求时确保“意图”足够清晰，并在生成代码后自行进行必要的审查和测试。
verifyUserToken”。diff，确认无误后再点「接受更改」。在国内外，你的个人和团队如果对开源社区有贡献——比如在 GitHub 上维护或积极参与开源项目，就有机会免费申请 GitHub Copilot，这对提高工作效率、让团队更专注于关键业务逻辑而言非常有帮助。
建议把你的 GitHub Profile、开源项目链接、贡献度、Stars 等信息准备好，申请通过后就可以体验到 Copilot 的强大功能。
别担心！ 只要你确实为开源生态做出过贡献，GitHub 官方是很鼓励你去申请 Copilot 的免费使用资格的。需要注意的是该免费资格是按月赋予的！
从最初的 GitHub Copilot 到如今逐渐涌现的各种 AI 编程工具，比如 Cursor、Amazon CodeWhisperer、Google Gemini Code Assist、以及基于大语言模型的各种插件等等，AI 编程助手已经不再是新鲜事。Cursor 的特点在于提供类似 IDE 的环境，可直接在其编辑器里集成对话式的 AI 辅助；Replit 的 Ghostwriter 则充分利用 Replit 在线编程环境的优势，为多人协作和实时预览提供极大方便。和 Copilot 相比，这些工具可能在对话交互深度、代码质量、或对特定语言和生态的支持范围上各有所长。但总体而言，它们都在让开发者摆脱那些冗杂、重复、机械的编程工作，从而腾出更多时间和精力进行架构和创新。
“AI 不会取代程序员，但会取代那些拒绝与 AI 合作的程序员。”
如果你正在或即将投入开源项目的开发，或者在商业项目中想要挖掘更多高阶生产力，都推荐你去尝试并深入学习这些 AI 编程工具。在 GitHub 官方文档 中，你还可以找到一份从入门到进阶的 Copilot 教程系列——从最初的安装到高级用法，让你快速掌握 Copilot 的精髓。也欢迎试用其他同类工具，对比各种功能优缺点，探索适合自己团队的工作流。
让我们一起拥抱 AI，做更高效的开发者吧！
如果你对 AI 编程、云原生和开源技术感兴趣，也欢迎访问我的个人博客 jimmysong.io，一起交流讨论。祝大家编码愉快，效率倍增！
2025-03-22 14:45:55
欢迎阅读我的这篇博客——“超越 Sidecar：深入解析 Istio Ambient Mode 的流量机制与成本效益”。本文内容源自我在 KCD 北京的一次演讲。主要探讨的是 Istio 全新推出的一种数据面模式 —— Ambient Mode。它的核心理念是去除 Sidecar，减少资源开销与运维复杂度。本文将带大家了解 Ambient Mode 的出现背景、核心组件、流量路径机制以及与现有 Sidecar 模式的对比，从而帮助你快速评估并上手这项新特性。
首先，我们来思考一个问题：为什么要关注、甚至尝试这种新模式？Sidecar 在服务网格里一直都用得好好的，为什么要“去 Sidecar”呢？
让我们看看当前服务网格面临的一些问题和挑战。
思考：有没有一种方式在保留服务网格核心能力（安全、可观测、流量控制）的同时，减少对每个 Pod 的侵入和额外资源消耗？
服务网格架构一直在探索代理部署位置的多种可能性。例如：
这些模式在功能、安全、性能和管理复杂度上都有不同的侧重。Istio Ambient Mode 则是针对 Sidecar 带来的高资源消耗和运维成本，而提出的新尝试。
以下表格是对比常见服务网格部署模式的一些简要特点：
| 模式 | 安全性 | 效率 | 可管理性 | 性能 |
|---|---|---|---|---|
| Sidecar 模式 | 高安全性，隔离的代理 | 资源使用率高 | 集中化管理但较为复杂 | 增加一定延迟 |
| Ambient 模式 | 通过 ztunnel 提供安全性，仍在发展中 | 更高效，共享代理 | 管理更简单但功能在完善中 | 良好；跨可用区时需注意网络开销 |
| Cilium mesh | 中等安全性，基于 eBPF | 内核级效率 | 配置复杂 | 可视场景不同而异 |
| gRPC | 应用集成安全，依赖应用自身 | 高效 | 更新管理复杂 | 低延迟，适用于实时场景 |
接下来我们正式进入第二部分，深入看看 Ambient Mode 的具体组件，包括 ztunnel、Waypoint Proxy 以及 Istio CNI 在其中扮演的角色。
istio-init 容器，负责流量劫持
在 Ambient 模式下，Istio 数据面可分为两层：
Control Plane 依然由 Istiod 提供，主要负责给 ztunnel、Waypoint 下发配置和证书。
istio-init 容器，使安装更加清晰简洁。iptables REDIRECT 规则。这张图简单示意了 Istio CNI 如何与 Kubernetes 本身的网络插件（如 Calico、Cilium 等）组合在一起。它修改了本机的 CNI 配置，增加了 CNI 链，在 Kubernetes 分配完 Pod IP 后，紧接着就会执行 Istio CNI 的拦截逻辑，把网络流量规则注入到 Pod netns。并且为不同模式中 Pod 配置不同的 iptables 规则。 这样就与原本的 CNI 配置（包括网络策略）形成一个链式流程，不会相互冲突。
这张图详细描绘了当 Pod 启动时，Istio CNI 会怎么做：
介绍完组件之后，我们来看看最核心的“流量路径”。zTunnel 和 Waypoint 究竟是怎么拦截并转发流量的？我们会从透明流量拦截、HBONE 协议等角度进行解析。
在 Ambient 模式中，Istio CNI 会在 Pod 网络命名空间中注入 iptables 规则，将出站流量透明拦截到所在节点的 ztunnel 进程。之后由 ztunnel 决定是直接进行 L4 转发，还是将流量转发至 Waypoint Proxy 做进一步的 L7 处理。
如图所示，Kubelet 在节点上启动了一个 Pod，这个事件被 Istio CNI Agent 监听到，Istio CNI Agent 进入 Pod 的网络空间，设置 iptables 规则将流量重定向到本地 socket，并将 Pod 的文件描述符（FD）发送为 ztunnel。ztunnel 获取到 FD 之后就可以在 Pod 的网络空间中创建 socket。
Pod 在发送流量时，本该直连目标地址，但是 iptables 规则会把它拦截到本节点的 ztunnel 进程里，然后 ztunnel 决定这条流量需不需要交给 Waypoint 做 L7 代理。 如果不需要，就直接在 L4 层把它加密转发到目标 Pod；如果要 L7，例如鉴权，就再把流量隧道给 Waypoint。
Ambient 模式中，zTunnel 与 Waypoint 之间使用 HBONE (HTTP/2 + CONNECT) 协议来建立安全隧道，实现 mTLS 加密 和多路复用，减少额外的连接开销，简化代理转发流程。
下面是一个简化的 HBONE CONNECT 请求示例，利用 x-envoy-original-dst-host、x-istio-auth-userinfo 等头信息来传递路由和身份认证所需上下文。
:method: CONNECT
:scheme: https
:authority: Pod_B_IP:9080
:path: /api/v1/users?id=123
x-envoy-original-dst-host: Pod_B_IP:9080
x-forwarded-proto: hbone
x-istio-attributes: ...
...
在这个示例里，假设 ztunnel A 需要把流量发送给 目标节点 B，我们可以看到外层的 TCP 连接其实是从 ztunnel_A_IP:52368 连到 Node_B_IP:15008。这是 ztunnel A 和 ztunnel B 之间的隧道端口，15008 就是 HBONE 监听端口。
进入到 HTTP/2 层后，就会有一个 CONNECT 请求，里面的 :authority 显示的是 Pod_B_IP:9080，表示实际上要连到 Pod B 的 9080 端口。x-envoy-original-dst-host 里也能看出相同信息。
同时我们看到了一些自定义头，比如 x-forwarded-proto、x-istio-attributes 等，用来给目标 ztunnel 或后续代理带去更多上下文和安全验证信息。
可以把这个理解为：在 HTTP/2 CONNECT 之上，流量就像加了一个“内层”隧道，把应用层的请求（例如 /api/v1/users?id=123）封装在这里面，然后在 ztunnel B 端解封装并转发到真实的 Pod B。
整个过程对应用来说是透明的，但对我们来说，通过查看这种 CONNECT 请求头，可以了解 Ambient 模式如何在 HTTP/2 层做流量路由和身份认证。这就是为什么说 HBONE 比传统的 Sidecar-to-Sidecar通信更加灵活，也更便于做 mTLS 以及 L7 扩展。
如果源 Pod 和目标 Pod 恰好在同一个节点上，流量会走 ztunnel 的 L4 加密流程。 这里显示，ztunnel 是使用 DaemonSet 部署在每个节点上的，并且使用了host Network，共享主机的网络。Istio CNI 将 Pod 的出站流量拦截到 ztunnel的15001端口，如果源和目的 pod 在同一个节点上，ztunnel 直接在内部完成加解密后将流量发送到目的地 pod。
如果需要 L7 的流量处理，比如鉴权，ztunnel 就会与 Waypoint 代理建立 HBONE 隧道，经过 Waypoint 代理的转发到目的 Pod。
这是跨节点的情况，也就是最常见的场景：
源节点的 ztunnel 把流量通过 HBONE 隧道加密后发给目标节点的 ztunnel；目标节点 ztunnel 解封装，再把明文流量递给目标 Pod。只要是纯 L4 无需 L7，就不必加一层 Waypoint，减少了代理链路。
当我们需要 L7 处理时，流量就会多经过一下 Waypoint。也就是：
这个流程比 L4 多了一次代理，但好处是只有特定流量才会被 L7 代理解析，减少不必要的开销。
对于非 Istio网格内部的流量，通过 Pod IP和端口直接访问 Pod时，为了防止这些流量逃出 ztunnel的掌控，也需要拦截这些流量。如果流量是访问的应用端口，通过判断数据包上是否带有 0x539 标记，如果没有，则将其转发到 ztunnel 监听的 15006 明文端口，经 ztunnel 处理后会带上 0x539 标记，然后就可以访问应用的目标端口了；如果流量的目的端口是 15008，那么实际上就会被 ztunnel 监听和处理，判断 HBONE 协议。
| 流量类型 | 处理位置 | 示例场景 |
|---|---|---|
| L4 | ztunnel（透明转发） | TCP 级别流量，不需应用层策略 |
| L7 | ztunnel → Waypoint Proxy | HTTP/gRPC 需要鉴权、熔断、路由、可观测等高级功能 |
对于大部分只需 TCP 层加密和转发的流量，Ambient Mode 仅通过 ztunnel 即可；只有在需要 HTTP 层策略时才会额外经过 Waypoint。
有了对 Ambient 的了解后，我们还是得和原有的 Sidecar 模式做对比，来看看哪些功能还不完善，哪些场景更适合 Ambient。
与传统 Sidecar 模式相比，Ambient 目前仍有一些不完善之处：
| 指标 | Sidecar 模式 | Ambient 模式 |
|---|---|---|
| 代理位置 | 每个 Pod 都运行 Envoy Sidecar | Node 级 ztunnel + 可选的 Waypoint Proxy |
| 资源开销 | 在大规模场景下 CPU/内存消耗相对更高 | 相对更低：代理共享在节点/命名空间级 |
| 运维复杂度 | 升级 Sidecar 需滚动更新所有关联 Pod，操作较繁琐 | 部署/升级集中在少数组件（ztunnel / Waypoint），运维更简单 |
| 性能 | 每个 Pod 都有 Envoy，使得隔离性更强，但整体有额外代理开销 | L4 性能较好，L7 场景需要多经过一次 Waypoint 转发 |
| 功能完整度 | 成熟稳定，支持多集群、VM、混合网络 | 尚在演进，多网络、VM 等高级场景支持仍在完善 |
| 典型使用场景 | 注重严格隔离或依赖特定的 EnvoyFilter、WASM 插件等深度定制 | 大规模集群、需要轻量化管理且大部分流量以 L4 为主的场景 |
好的，最后我们来总结一下 Ambient Mode 的优缺点，以及当前适合哪些场景。
你也可以通过 jimmysong.io 网站找到更多云原生相关的文章和实践分享。如果对此文或 Istio 有任何疑问，欢迎给我留言或在社区中交流。谢谢！
2025-02-27 13:47:35
随着 Istio 版本迭代，其的安装方式和工具链也在不断演进。从 istioctl 到 Helm，再到曾经的 Istio Operator，用户常常会面临选择困境：到底哪种方式最适合我的场景？在最近的交流中，我经常遇到关于 Istio 安装方式选择的问题，特别是围绕 IstioOperator API 和已废弃的 Istio Operator 组件的区别。今天，我将以技术实践者的视角，带你梳理 Istio 的安装之道，拆解关键问题，并给出生产级建议。
Istio 提供了多种安装路径，每种方式都有其设计初衷和适用场景。以下是当前主流选项：
istioctl：官方推荐的安装工具，集验证、定制和运维于一体，几乎是生产环境的标配。接下来，我们逐一剖析这些方式的核心特点，以及背后的取舍逻辑。
istioctl：生产环境的不二之选在 Istio 中，istioctl 被官方定位为首选安装工具。它的优势显而易见：
istioctl 会对配置进行静态检查，避免潜在问题。比如，使用 istioctl analyze 可以快速定位配置文件中的错误。IstioOperator API，你可以精确控制安装细节，比如只启用 Pilot 或调整网关配置。istioctl verify-install）到增量升级，istioctl 提供了全生命周期支持。istioctl 在本地运行，避免了高权限组件带来的安全隐患。实践中的一个简单例子：
istioctl install --set profile=default -y
这会快速部署默认配置。如果需要更细粒度的控制，可以搭配 YAML 文件（后文详解）。
适用场景：生产环境、新用户、需要高度定制的场景。
Helm 是 Kubernetes 生态的老朋友，Istio 也提供了官方 Helm chart。它的亮点在于：
但 Helm 并非没有短板：
istioctl，Helm 的配置检查较弱，错误往往在运行时暴露。适用场景：已有 Helm 工作流、CI/CD 驱动的项目。
如果你接触过早期 Istio，可能会对 Istio Operator 有所耳闻。这是一个运行在集群内的控制器，负责根据配置管理 Istio 安装。然而，从 1.23 版本起，它已被官方废弃。原因何在？
istioctl 已能完全覆盖其功能（参考 GitHub Discussion #166）。现有用户可以继续运行旧版本，但无法升级到 1.24+。对于新项目，我的建议是直接跳过这一选项。
讨论中常出现的一个困惑是：IstioOperator API 和 Istio Operator 有什么区别？让我们一次性讲清楚：
IstioOperator API：一个声明式的配置接口，用于定义 Istio 安装的期望状态。它并未废弃，而是 istioctl 的核心依赖。类比一下：API 是设计图纸，Operator 是施工队。现在，istioctl 取代了施工队，效率更高，风险更低。
IstioOperator API？IstioOperator API 是 Istio 安装的灵魂，允许你通过 YAML 文件灵活定制配置。以下是一个典型流程：
编写配置文件：
假设我们要启用 Egress Gateway：
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
profile: default
components:
egressGateways:
- name: istio-egressgateway
enabled: true
部署配置：
执行：
istioctl install -f istio-config.yaml
这种方式的好处在于声明式管理，修改后重新运行即可实现增量更新。比如，要调整资源限制，只需更新 YAML 并再次应用。
安装完成后，如何添加或更新组件（如 Egress Gateway）？istioctl 的答案简单直接：
编辑 YAML，添加新配置。
运行：
istioctl install -f updated-config.yaml
istioctl 会自动计算差异，完成增量部署。
Helm 更新则稍显繁琐，可能涉及 chart 调整或手动干预，尤其在非常规组件上。
通过这次深入剖析，我们可以得出以下结论：
istioctl 是王道：它兼具安全性、灵活性和生产就绪特性，适合绝大多数场景。作为一个在开源领域摸爬滚打的实践者，我建议从 istioctl 入手，结合 IstioOperator API，既能快速上手，又能满足复杂需求。Istio 的安装看似复杂，但掌握核心逻辑后，你会发现它其实很有条理。
有任何疑问，欢迎留言交流，一起解锁服务网格的更多玩法！
2025-02-13 18:20:14
Istio 的 Ambient 模式是一种创新的、无 Sidecar 的服务网格部署方式，通过 ztunnel 和 waypoint proxy 分离数据平面功能，简化了操作并降低了资源消耗。本篇博客将通过一份详细的术语表，帮助你更好地理解 Istio Ambient 模式中的关键概念及其背后的技术实现。
istiod）负责管理集群内 ztunnel 和 waypoint proxy 的配置和策略，而数据平面由 ztunnel 和 waypoint proxy 组成，负责处理实际的网络流量。istiod 获取配置并执行策略，管理 Pod 之间的 L4 和 L7 流量。istiod)istiod 使用 xDS APIs 进行配置推送，动态管理 Ambient 模式中的流量策略、证书分发以及与 Kubernetes 集群的交互。
istiod) 获取 mTLS 证书，并负责证书的管理和轮换。pistioin 和 pistioout：用于与节点上的 istioin 和 istioout 接口通过 GENEVE 隧道连接。
istioin 和 istioout）与 ztunnel 内的接口（pistioin 和 pistioout）。
istioin 处理进入节点的流量，istioout 处理离开节点的流量。两者通过 GENEVE 隧道连接到 ztunnel 中相应的接口。istioin 或 istioout，然后通过 GENEVE 隧道传递给 ztunnel。
Istio 服务网格中所有工作负载将根据其服务账户注册 SPIFFE 标准的服务身份格式：spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>。
ztunnel-pods-ips 是每个节点上用于存储 Ambient 网格 Pod IP 的集合。ztunnel-pods-ips 中，以确保这些 Pod 的流量可以被 iptables 规则识别和处理。istioin 和 istioout），从而将流量引导至 ztunnel 进行处理。
Istio Ambient 模式通过将数据平面功能分为 L4 和 L7 层的独立组件，为用户提供了更轻量且灵活的服务网格解决方案。这种方式不仅简化了服务的部署，还大幅降低了资源开销。通过术语表的方式，我们探讨了 Ambient 模式中的各种核心概念，从 ztunnel 到 waypoint proxy，再到 iptables 和 eBPF 的使用，帮助你全面了解 Istio Ambient 模式的架构和运行机制。如果你对服务网格感兴趣或正在考虑如何优化微服务通信，希望这篇文章对你有所帮助。
2025-01-21 10:02:05
在如今各种 AI 工具层出不穷的时代，找到一个好用又免费的绘图工具真的不容易。而 Raphael.app 就是一款非常值得一试的 AI 绘图工具。它简单易用，而且用英文提示词就能生成效果不错的图片。
这款以文艺复兴三杰之一拉斐尔（Raphael，全名：Raffaello Sanzio da Urbino，1483 年 4 月 6 日－1520 年 4 月 6 日）命名的工具，有以下特点：
操作非常简单：
Raphael 是一个用起来特别方便的 AI 绘图工具，既免费又能生成效果不错的图片。不管你是想找灵感还是单纯玩玩 AI，都非常值得一试。
2025-01-20 16:50:25
最近读了 TheNewStack 发布的电子书《Cloud Native Observability for DevOps Teams》，虽然这本书是 2022 年出品的，但给我了很大的启发。它不仅讨论了技术工具，还深入探讨了团队协作、文化建设和未来趋势的结合点。在这本书里，“观察”不仅仅是看到数据，而是看清背后的意义。可以说，它从根本上改变了我对可观测性的理解。
本书从基础定义到实际操作，系统地阐述了云原生可观测性的重要性及其实现方式。通过具体的工具和策略，它帮助读者理解如何整合指标、日志、追踪和混沌工程等维度，全面掌控分布式系统的健康状况，为 DevOps 团队提供高效的决策支持。
书中开篇就点明：可观测性是通过系统的外部信号推断内部状态的能力。不仅是传统的指标（Metrics）、日志（Logs）、追踪（Tracing）三根支柱的组合，而是一种综合性、全局化的分析方法。正如作者所说：
“Observability isn’t just the ability to see each piece at a time; it’s also the ability to understand the broader picture and how these pieces combine.”
书中特别强调了 Kubernetes 环境中日志和监控的复杂性。Kubernetes 没有内置的完整可观测性解决方案，只提供了基础功能，比如 kubectl 查看对象状态，而更高级的功能需要依赖第三方工具如 Fluentd 和 Prometheus。
书中在实践部分提到了多种实现可观测性的具体策略和工具：
kubectl get events 快速了解集群中资源的状态变化。这些实践指南强调了工具与策略的结合，从而实现全面的可观测性。
书中强调，单纯收集数据并不能解决问题，关键在于跨维度数据的整合与分析。例如，在性能问题排查时，指标和追踪往往无法直接关联，而这正是现有工具的短板。未来，统一数据存储和分析视角的工具，比如 OpenTelemetry 提倡的标准化方法，可能是突破口。
随着 AI 技术的发展，可观测性工具也可以更智能化。例如，通过机器学习预测异常，或是自动推荐优化策略。这不仅能减少人为干预，还能提升故障响应速度。正如作者在混沌工程部分提到的：
“Instead of waiting for something to happen and finding out how your application fares, you put it through duress under controlled conditions to identify weaknesses and fix them.”
书中提到“DevOps 的终极目标是跨团队的协作与同理心”，这点深有共鸣。尤其是在复杂分布式系统中，开发和运维团队往往各自为战，导致沟通断层。跨团队协作的关键在于工具提供的透明性与共享视角，而不仅仅是技术能力。
这本书的独到之处在于它从技术和人文两个角度同时切入，它让我意识到，可观测性不仅是一组工具的集合，而是一种文化、一种能力，帮助我们更深刻地理解系统，推动团队协作，并在复杂的云原生环境中建立起真正的“透明化”。
最后，我想引用书中一段非常打动我的话来结尾：
“Observability lets you see the beautiful and complete picture that is your production software systems.”
