标签: Kubernetes
29 May 21 13:35 +0000

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


09 May 21 16:22 +0000

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


07 May 21 17:25 +0000

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


06 May 21 16:28 +0000

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


03 May 21 05:21 +0000

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


08 Sep 20 08:56 +0000

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

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

请求驱动:

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

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

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

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


⬅️ ➡️