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

See how a minor change to your commit message style can make you a better programmer.

feat: add hat wobble

^--^ ^------------^
| |
| +-> Summary in present tense.
|
+-------> Type: chore, docs, feat, fix, refactor, style, or test.

Examples:

chore: add Oyster build script
docs: explain hat wobble
feat: add beta sequence
fix: remove broken confirmation message
refactor: share logic between 4d3d3d3 and flarhgunnstow
style: convert tabs to spaces
test: ensure Tayne retains clothing

如果你对 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?

Every feature that is added to an application adds a certain amount of risk to the overall application. The aim for secure development is to reduce the overall risk by reducing the attack surface area.

Shift + Function + Delete is what I need.

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

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

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

请求驱动：

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

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

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

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