在 上篇文章 用了整篇的内容来描述网络数据包在 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。
近日 Google 开源了一个名为 Service Weaver 的开源框架，它可以帮助开发者构建和部署分布式应用程序。Service Weaver 的特点是，它允许开发者以模块化单体的方式编写应用程序，然后使用自定义部署器将其部署为一组微服务。这样，开发者可以在不改变代码的情况下，灵活地调整应用程序的架构和性能。
这篇文章介绍了如何编写云原生网络功能（CNF），即在电信领域的网络应用，它们与大多数云原生企业应用有不同的非功能性需求。CNF 需要满足高性能、高可靠性、高安全性和低延迟等指标。文章提出了一个基本的设计原则：每个容器只负责一个关注点，即一个单一的网络功能或子功能。
随着越来越多的企业将应用程序迁移到 Kubernetes 平台，它逐渐成为了资源编排和调度的重要入口。众所周知，Kubernetes 会按照应用程序申请的资源配额进行调度，因此如何合理的配置应用资源规格就成为提升集群利用率的关键。这篇文章将会分享如何基于 FinOps 开源项目 Crane 正确的配置应用资源，以及如何在企业内推进资源优化的实践。
