在 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 了解多少？你有写过自己的控制器吗？🕵️‍♂️

When it comes to building Docker containers, you should always strive for smaller images. Images that share layers and are smaller in size are quicker to transfer and deploy.

But how do you keep the size under control when every RUN statement creates a new layer, and you need intermediate artefacts before the image is ready?

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

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

请求驱动：

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

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

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

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

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.

Reference meterials.

Cgroups, namespaces, 以及其他: 容器是由什么构成的?

DockerCon EU 的一场分享.

准确来说 "容器 (container)" 这个词并不代表任何含义. 它基本上只是 Linux 内核提供的一些新特性 ("namespaces" 和 "cgroups"), 它们使你得以将进程互相隔离. 当你在使用这些特性的时候, 你可以把它们称为 "容器". 这些特性好像让你觉得你创建了一些虚拟机, 虽然它们实际上根本不是虚拟机, 它们只是同一个 Linux 内核中运行的一些进程而已. 让我们仔细看看!