根据Kubernetes的网络模型，集群中的所有pod都可以直接相互通信，不管它们存在于哪个节点上，或存在于哪个命名空间中，通信过程不需要NAT。从可用性的角度来看，这是非常便捷的，但从安全性来看，这貌似有一点问题。假设攻击者侵入了一个不受网络限制地pod，他就可以连接到同一集群中的任何一个pod，甚至是有权限访问敏感信息的pod。
使用NetworkPolicy，可以在IP地址或端口级别上限制Kubernetes集群中pod之间的网络流量。
在Kubernetes集群中，该如何设置CPU的requests和limits呢？
可供选择的策略包含：
- 只使用limits
- 从来不用limits，只是设置requests
- 或者，两者哪一个都不用。
该作何选择呢？
介绍
eBPF（extended Berkeley Packet Filter）是一种Linux内核中的虚拟机技术，它允许用户在内核中运行自定义的代码，从而实现更高级别的网络过滤、监控和安全功能等。eBPF最初是由Linux内核开发者Brendan Gregg和Others在2014年提出的，它是传统BPF（Berkeley Packet Filter）的增强版，支持更多的指令和数据结构，使得用户可以编写更加复杂和高级的代码。
eBPF技术的核心是一个虚拟机，该虚拟机运行在内核中，具有JIT（即时编译）功能，可以将用户编写的eBPF代码编译成本地代码，从而获得接近本地代码的执行效率。eBPF代码可以在运行时动态注入到内核中，而不需要重新编译或重新启动内核，从而使得它在运行时可以快速适应不同的场景和需求。
2月14日，Istio社区发布了1.17的发布通告。1.17版本添加了一些重要的新功能，并将一些现有的功能成熟度标记为Beta，表明它们已经准备好生产使用。以下是一些亮点：
金丝雀升级和修订标签升级为Beta版本
Istio 1.6在版本中引入了对使用修订版按照金丝雀模式升级服务网格的基本支持。使用这种方法，您可以并排运行多个控制平面，而不会影响现有的部署，并缓慢地将工作负载从旧的控制平面迁移到新的控制平面。在Istio 1.10中，引入修订标签作为金丝雀升级的改进，以帮助减少操作员使用修改时必须做的更改数量，并安全升级Istio控制平面。这是我们的用户在生产过程中被广泛采用和使用的一个特性。所有这些特性的集成测试和端到端测试都已完成，已经升级为Beta版本。
在云原生生态愈加成熟的加持下，微服务架构体系服务治理能力下沉，基础设施的服务能力和计算能力进一步抽象，以达到进一步实现应用程序和基础服务更加细化的垂直分工和运行时解耦，已经成为越来越容易被大家 所追求的新趋势。
而被社区广泛使用的Sidecar模式，通过部署独立进程的Sidecar实现与应用程序松耦合，大大降低了构建高可用、高度弹性和高度可扩展微服务架构体系的复杂度。
Kubernetes从1.8版本起就声称单集群最多可支持5000个节点和15万个Pod，这个规模对于腰部以下团队来讲已经足够应对业务膨胀。但是总会出于混合云、可扩展性、降低网络延迟或者跨可用区故障隔离等各种各样因素考量去部署多集群。Kubernetes Cluster Federation 又名 KubeFed 或 Federation v2，Federation将使管理多个集群变得简单，打破各个集群边界，使之不再是一个个孤岛。
我们在探讨微服务时，通常避不开服务的颗粒度和服务之间的松耦合。也就是说服务应该是能够自治的，能够掌控服务所有的依赖，并且尽量降低同步通信的频率。今天我们来探讨一下实现分布式服务松耦合的事件驱动架构模式，以及异构语言系统如何实现事件驱动架构设计。