Envoy Gateway 是由 EnvoyProxy 社区发起的，联合 Contour、Emissary 等基于 Envoy 的 API 网关开源项目及社区，共同参与并维护的 API 网关项目。 从项目发起到现在，已经有了很多开源贡献者参与到了其中，现在 Issues 和 PRs 总数已经达到 1200 +，GitHub Stars 已经接近 1000，是 EnvoyProxy 社区中发展最快，重视度很高的项目。 很多朋友也私下联系过我，向我询问如何参与到 Envoy Gateway 的贡献之中，所以本文从整体来详细梳理和讲解一下，如何参与到项目贡献之中。 本文的目的是想通过介绍 EG 设计与架构，讲解贡献者如何参与到开源贡献之中。
今天读到这篇文章，觉得不错就翻译一下。文章是翻译自 Steef-Jan Wiggers The Commoditization of the Software Stack:How Application-first Cloud Services are Changing the Game[1]，内容来自 Bilgin Ibryam 在 QCon London 上的演讲。Ibryam 在分享中从应用开发和运维两个不同的维度来讨论架构的演进：内部架构和外部架构。二者从单体应用时期的明显的界限，到如今界限愈来愈模糊。 我认为随着架构的演进，应用程序发生着巨大的变化，能力从应用中分离出来，下沉到基础设施中，甚至变成新的基础设施。基础设施，也从狭义上的物理设施、计算资源演变为软件定义的能力，这些能力不断地被产品化、商品化。新生代的基础设施，以各种运行时的方式游离在应用程序之外，二者仍保持着一定的联系：API。
在不久前发布的 Flomesh 服务网格 1.3.3[1] 我们引入了 eBPF 功能，用以替代流量拦截方面的实现 iptables。由于 eBPF 对较新内核的依赖，iptables 的实现仍继续提供。同时，得益于 eBPF 网络方面的能力，我们也实现了同节点网络通信的加速。
在 上篇文章 用了整篇的内容来描述网络数据包在 Kubernetes 网络中的轨迹，文章末尾，我们提出了一种假设：同一个内核空间中的两个 socket 可以直接传输数据，是不是就可以省掉内核网络协议栈处理带来的延迟？ 不论是同 pod 中的两个不同容器，或者同节点的两个 pod 间的网络通信，实际上都发生在同一个内核空间中，互为对端的两个 socket 也都位于同一个内存中。而在上篇文章的开头也总结了数据包的传输轨迹实际上是 socket 的寻址过程，可以进一步将问题展开：同一节点上的两个 socket 间的通信，如果可以 快速定位到对端的 socket -- 找到其在内存中的地址，我们就可以省掉网络协议栈处理带来的延迟。
Apache SkyWalking[1] 是一个开源应用性能管理系统，帮助用户收集和聚合日志、追踪、指标和事件，并在 UI 上显示。从 OAP 9.4.0 开始，SkyWalking 新增了 AWS Firehose receiver[2]，用来接收，计算 CloudWatch metrics 的数据。本文将以 DynamoDB 为例，展示如何使用 SkyWalking 接收并计算 CloudWatch metrics 数据，以监控 Amazon Web Services。
本文介绍了云绑定应用程序的概念，并探讨了在使用云绑定应用程序时需要考虑的几个关键因素。首先，作者解释了云绑定应用程序是指在构建应用程序时使用云提供的服务和资源。作者强调了使用云绑定应用程序可以带来很多好处，例如降低成本和提高可靠性。然而，作者也指出了在使用云绑定应用程序时需要考虑的几个关键因素，包括云供应商锁定、数据隐私和网络连接可靠性等。最后，作者提供了一些建议，帮助企业在使用云绑定应用程序时避免潜在的风险。例如，选择具有高可用性的云服务提供商，并在使用云绑定应用程序时加强数据安全措施。原文地址：https://www.infoq.com/articles/cloud-bound-applications/
SKyWalking OAP 现有的 OpenTelemetry receiver[1] 可以通过OTLP[2]协议接收指标(metrics)，并且使用MAL[3]实时分析相关指标。从OAP 9.4.0开始，SkyWalking 新增了AWS Firehose receiver[4]，用来接收，分析CloudWatch metrics数据。本文将以EKS和S3为例介绍SkyWalking OAP 接收，分析 AWS 服务的指标数据的过程
过去几年，公有云凭借着更高扩展性、灵活性、可靠性和安全性，吸引了大量的企业将应用程序部署到公有云上。随着业务规模的不断扩张，企业出于某些原因，如避免厂商锁定、追求更低的延迟、更高的可靠性等，选择将应用部署在更多的公有云上；也有些企业出于数据敏感性等原因，选择将部分应用部署有私有环境中。后者也更像是将上云的过程拉长。不管是多云还是混合云，基础设施都不可避免的存在着差异，企业不得不在适配底层设施上投入了大量的人力物力。 Kubernetes 的出现，完美地解决了这一问题。除了屏蔽基础设施层的差异解决了跨平台的问题，还提供自动化的容器编排、更高的扩展性、弹性和高可用性，其背后更是有着庞大的社区的支持。Kubernetes 的风靡，得到了大量企业的青睐。随着时间的推移，企业使用多个 Kubernetes 集群管理应用的情况越来越普遍。 如何在跨越多个集群、甚至是混合多云的环境下来管理应用成了新的难题。Karmada[1] 的出现正是要解决这一问题。
本文译自 Istio 官方博客，这篇文章介绍了 Istio 的 Rust-Based Ztunnel，它是一种基于 Rust 语言的轻量级代理，用于 Istio 的 ambient mesh。在文章中，作者解释了为什么需要一种新的代理，以及 Rust 语言是如何成为最佳选择的。文章还讨论了如何使用 workload xDS 配置来管理工作负载，以及如何查看 ztunnel 日志和 L4 指标。作者表示，Rust-Based Ztunnel 显著简化了 Istio 的 ambient mesh，并提高了性能。此外，Istio ambient mesh 已经合并到了上游主干，可以通过遵循入门指南来尝试 Rust-Based Ztunnel。
