在云原生架构中，解耦是一件非常普遍却重要的事情，通过解耦功能，应用的职责变得单纯，更容易管理，也更容易水平扩展。

在由单体应用向分布式应用转换时，应用间通信就变得尤为重要且有难度。实例在变化，流量也在变化，当上游服务实例变化，或者性能波动时，很容易引起下游服务不稳定，同时下游服务流量的激增，也会给上游服务带去很大的压力甚至直接瘫痪上游服务。

请求驱动：

# A, B 下游服务（如登录系统）
# S 上游服务（如邮件发送服务）

# 如果 S1 出现区域性故障，会发生什么？

A1 ----|                   |---- S1
       |                   |
A2 ----| <--> 负载均衡 <--> |---- S2
       |                   |
B1 ----|                   |---- S3

事件驱动是解决上述问题的一种思路，通过事件驱动，将同步调用变为异步调用，不仅能够很好解决服务耦合的问题（虽然是两个服务，但上游服务出现任何异常下游服务就不可用，相当于还是耦合），还能够提高服务可扩展性和可观测性，在队列中的事件可以被有条不紊地消化，也可以方便地被系统的其它部分所使用。消息系统因此成为云原生架构中关键的中间件之一。

在 kubectl 的使用过程中我们经常需要在不同上下文之间切换，从而连接不同的集群，或者访问不同的 namespace，或者使用不同的用户身份。这种切换可以有很多种不同的方式实现，官方提供的途径包括使用 --kubeconfig 参数指定不同的 kubeconfig 文件，以及使用 kubectl config 子命令切换上下文 (context)，但这两种方式使用起来都不够方便，今天我给大家介绍 3 个 kubectl 插件：kubectl-cf, kubectx 和 kubens，实现优雅地切换 kubectl 上下文。☕️

如果你对 Kubernetes 的架构有一定的了解，那么你一定知道，Kubernetes 通过控制器 (controller) 来维护集群的状态，你还可能知道控制器的实现方式是 Informer，但是你对 Informer 了解多少？你有写过自己的控制器吗？🕵️‍♂️

如果你对 Kubernetes 的架构有一定的了解，那么你一定知道，Kubernetes 通过控制器 (controller) 来维护集群的状态，你还可能知道控制器的实现方式是 Informer，但是你对 Informer 了解多少？你有写过自己的控制器吗？🕵️‍♂️

如果你对 Kubernetes 的架构有一定的了解，那么你一定知道，Kubernetes 通过控制器 (controller) 来维护集群的状态，你还可能知道控制器的实现方式是 Informer，但是你对 Informer 了解多少？你有写过自己的控制器吗？🕵️‍♂️

如果你对 Kubernetes 的架构有一定的了解，那么你一定知道，Kubernetes 通过控制器 (controller) 来维护集群的状态，你还可能知道控制器的实现方式是 Informer，但是你对 Informer 了解多少？你有写过自己的控制器吗？🕵️‍♂️

A Docker + Kubernetes network trouble-shooting swiss-army container

Kubernetes runs a set of controllers to keep matching the current state of a resource with its desired state. It can be a Pod, Service or whatever is possible to control via Kubernetes. K8S has as core value extendibility to empower operators and applications to expand its set of capabilities. An event-based architecture where everything that matters get converted to an event that can be trigger custom code.