Browsed by
标签：k8s

Kubernetes Informer 机制源码解析

Kubernetes Informer 机制源码解析

Comments 0 Comment  16 Views

閱讀本文約花費: 14 (分鐘)这篇文章来源于云原生社区组织的 Kubernetes 源码研习社的作业，是个人学习Informer机制、理解Informer各个组件的设计的总结。 背景 为什么Kubernetes需要Informer机制？我们知道Kubernetes各个组件都是通过REST API跟API Server交互通信的，而如果每次每一个组件都直接跟API Server交互去读取/写入到后端的etcd的话，会对API Server以及etcd造成非常大的负担。而Informer机制是为了保证各个组件之间通信的实时性、可靠，并且减缓对API Server和etcd的负担。 Informer 流程 这个流程，建议先看看《From Controller Study Informer》 这里我们以CoreV1. Pod资源为例子： 第一次启动Informer的时候，Reflector 会使用 List从API Server主动获取CoreV1. Pod的所有资源对象信息，通过 resync将资源存放在 Store中 持续使用 Reflector建立长连接，去 Watch API Server发来的资源变更事件 当2 监控到CoreV1.Pod的资源对象有增加删除修改之后，就把资源对象存放在 DeltaFIFO中，…

Read More Read More

消息疯狂堆积！RocketMQ 出 Bug 了?

消息疯狂堆积！RocketMQ 出 Bug 了?

Comments 0 Comment  57 Views

閱讀本文約花費: 21 (分鐘)前言 用过 MQ 的同学，可能会遇到过消息堆积的问题。而肥壕最近也踩上了这个坑，但是发现结果竟然是这么一个意料之外的原因而导致的。 正文 那一晚月黑风高，肥壕正准备踏上回家的路，突然收到告警短信轰炸！“MQ 消息堆积告警 [TOPIC: XXX] ” 肥壕心里“万只草泥马崩腾~” 第一反应是：“怎么肥事？刚下班就来搞事情？？？” 于是乎赶回公司赶紧打开电脑，登上 RocketMQ 后台查看（公司自己搭建的开源版RocketMQ） 握草 (ｷ｀ﾟДﾟ´)!!! 竟然堆积了3亿多条消息了？？？ 要知道出现消息堆积无在乎这个问题： 生产者的生产速度 >> 消费者的处理速度  1. 生产者的生产速度骤增，比如生产者的流量突然骤增 2. 消费速度变慢，比如消费者实例 IO 阻塞严重或者宕机 擦了一下头上的冷汗😓…赶紧登上消费者服务器瞧瞧。 应用运行正常！服务器磁盘IO 正常！网络正常！ 再去上去生产者的服务器，咦…流量也很正常！ 什么？？？佛了😨 …生产者和消费者的应用都很正常，但是为什么消息会堆积怎么多呢？看着这堆积的数量越堆越多（要是这是我头发的数量那该多好啊），越发着急。 虽然说 RocketMQ 版能支持 10 亿级别的消息堆积，不会因为消息堆积导致性能明显下降，&#x1…

Read More Read More

上 Kubernetes 到底有什么业务价值？

上 Kubernetes 到底有什么业务价值？

Comments 0 Comment  48 Views

閱讀本文約花費: 13 (分鐘)开篇，我们先思考这样一个问题：“为什么要基于 Kubernetes 去构建一个应用管理平台？” 上图是一个本质的问题，我们在落地 K8s 经常遇到的一个问题。尤其是我们的业务方会问到这么一个问题，我们上 Kubernetes 有什么业务价值？这时候作为我们 K8s 工程师往往是很难回答的。原因在哪里呢？实际上这跟 K8s 的定位是相关的。K8s 这个项目呢，如果去做一个分析的话，我们会发现 K8s 不是一个 PaaS 或者应用管理的平台。实际上它是一个标准化的能力接入层。什么是能力接入层呢？大家可以看一下下图。 实际上通过 Kubernetes 对用户暴露出来的是一组声明式 API，这些声明式 API 无论是 Pod 还是 Service 都是对底层基础设施的一个抽象。比如 Pod 是对一组容器的抽象，而 Deployment 是对一组 pod 的抽象。而 Service 作为 Pod 的访问入口，实际上是对集群基础设施：网络、网关、iptables 的一个抽象。Node 是对宿主机的抽象。Kubernetes 还提供了我们叫做 CRD（也就是 Custom Resource）的自定义对象。让你自己能够自定义底层基础设施的一个抽象。 而这些抽象本身或者是 API 本身，是通过另外一个模式叫做控制器 (Controller) 去实现的。通过控制器去驱动…

Read More Read More

如何构建以应用为中心的“Kubernetes”?

如何构建以应用为中心的“Kubernetes”?

Comments 0 Comment  61 Views

閱讀本文約花費: 23 (分鐘)在上篇文章《上 Kubernetes 到底有什么业务价值？》，主要和大家介绍了上 Kubernetes 有什么业务价值，以及什么是“以应用为中心”的 Kubernetes。本文将跟大家具体分享如何构建“以应用为中心”的 Kubernetes。 如何构建“以应用为中心”的 Kubernetes？ 构建这么一个以用户为中心的 Kubernetes，需要做几个层级的事情。 1. 应用层驱动 首先来看最核心的部分，上图中蓝色部分，也就是 Kubernetes。可以在 Kubernetes 之上定义一组 CRD 和 Controller。可以在 CRD 来做用户这一侧的 API，比如说 pipeline 就是一个 API，应用也是一个 API。像运维侧的扩容策略这些都是可以通过 CRD 的方式安装起来。 2. 应用层抽象 所以我们的需要解决第一个问题是应用抽象。如果在 Kubernetes 去做应用层抽象，就等同于定义 CRD 和 Controller，所以 Controller 可以叫做应用层的抽象。本身可以是社区里的，比如 Tekton，istio 这些，可以作为你的应用驱动层。这是第一个问题，解决的是抽象的问题。不是特别难。 3. 插件能力管理 很多功能不是 K8s 提供的，内置的 Controller 还是有限的，大部分能力来自于社区或者是自己开发的 …

Read More Read More

云原生：「落地」最重要

云原生：「落地」最重要

Comments 0 Comment  54 Views

閱讀本文約花費: 17 (分鐘)1 云原生这个话题虽然我们谈了很多年了，但到底怎么去理解它，还是需要一段过程。提到云原生，很多人会联想到另一个词：「互联网原住民」，这个词代表了一群出生在互联网时代的人，他们看待世界和思考问题的方式从一开始就和互联网时代以前的人不同。 云原生也是如此。未来我们构建任何系统，不再是原来的那套思考方式，不是把云当成一个工具来使用，而是系统本身就生长于云，并在云上爆发，因此需要我们从根本上转换思考方式，重新定义业务系统。云原生和云计算也不一样，云计算的主角是计算、机器、资源，而云原生的主角是云上延伸出来的应用。 阿里云智能事业群总裁行癫曾经写过一个故事： 在 2004 年那个缺电的夏天，淘宝网全都挤在华星二楼：正是在那里，开始了我的淘宝生涯。我的位置在一个角落里，边上是一堆开着的服务器，吹出的风比七月烈阳下的风更热：因为限电，空调基本上只能看。刚到一个新环境，不知道该做什么，眼睁睁地看着一大群人忙忙碌碌。那时淘宝的节奏是非常快的，我记得小宝有一次说，当时网站如果要改点什么，只要跑到多隆那儿说一下，等他接杯水回到座位打开页面时，需求就已经上线了。 那是 2004 年，基于当时的技术架构，任何需求只要改一下代码，就能够立刻交付。而在现在这样复杂的技术架构下，很难通过简单修改代码实现需求迭代。 但是随着云原生时代的到来，我们又看到了新的机会。为了再现“当年的传说…

Read More Read More

上 Kubernetes 到底有什么业务价值？

上 Kubernetes 到底有什么业务价值？

Comments 0 Comment  34 Views

閱讀本文約花費: 13 (分鐘)开篇，我们先思考这样一个问题：“为什么要基于 Kubernetes 去构建一个应用管理平台？” 上图是一个本质的问题，我们在落地 K8s 经常遇到的一个问题。尤其是我们的业务方会问到这么一个问题，我们上 Kubernetes 有什么业务价值？这时候作为我们 K8s 工程师往往是很难回答的。原因在哪里呢？实际上这跟 K8s 的定位是相关的。K8s 这个项目呢，如果去做一个分析的话，我们会发现 K8s 不是一个 PaaS 或者应用管理的平台。实际上它是一个标准化的能力接入层。什么是能力接入层呢？大家可以看一下下图。 实际上通过 Kubernetes 对用户暴露出来的是一组声明式 API，这些声明式 API 无论是 Pod 还是 Service 都是对底层基础设施的一个抽象。比如 Pod 是对一组容器的抽象，而 Deployment 是对一组 pod 的抽象。而 Service 作为 Pod 的访问入口，实际上是对集群基础设施：网络、网关、iptables 的一个抽象。Node 是对宿主机的抽象。Kubernetes 还提供了我们叫做 CRD（也就是 Custom Resource）的自定义对象。让你自己能够自定义底层基础设施的一个抽象。 而这些抽象本身或者是 API 本身，是通过另外一个模式叫做控制器 (Controller) 去实现的。通过控制器去驱动…

Read More Read More

让开发部署提速8倍，我参与这款的插件的全过程

让开发部署提速8倍，我参与这款的插件的全过程

Comments 0 Comment  52 Views

閱讀本文約花費: 20 (分鐘)如何像参与开源那样，去参与一款 IDE 插件的设计？ 作为一款 IDE 插件的使用者，我是否能决定下一个版本的功能？ 自从产品经理银时小伙和他的开发小哥们在去年12月发布 Cloud Toolkit（一款 IDE 插件）以来，已帮助数以万计的开发者们提高了业务的部署效率。期间，开发者们不仅是 Cloud Toolkit 的使用者，同时也作为设计者参与了插件的更新迭代。 本文来自开发者徐靖峰，分享了他和 Cloud Toolkit 的故事 遇见 Cloud Toolkit 在与中间件小姐姐的一次聊天中，偶然间了解到这款插件，小姐姐跟我提到自己正在运营一款 IDE 开发者工具，能够使开发部署效率提高 8 倍，出于好奇心，我就上手体验了一下，看看究竟是一个什么样的产品。使用了一段时间之后，便迫不及待地向小姐姐分享了我作为开发者对插件的一些看法。 我对这款产品最直观的感受：这是一款发布工具，帮助用户在 IDE 中直接打包应用并部署到各种终端。一开始看到这款产品位于阿里云的页面中，原本以为是一款和阿里云服务强绑定的产品，但试用过后才发现，即使对于普通的云主机，也非常适用，还可以解决很多开发运维的痛点，非阿里云用户可以放心使用。 在 Cloud Toolkit 出现之前 作为一个 Java 程序员，我们大多数会在 Intellij IDEA 中基于 S…

Read More Read More

Kubernetes(k8s)容器运行时(CRI)简介

Kubernetes(k8s)容器运行时(CRI)简介

Comments 0 Comment  89 Views

閱讀本文約花費: 11 (分鐘)Kubernetes节点的底层由一个叫做“容器运行时”的软件进行支撑，它负责比如启停容器这样的事情。最广为人知的容器运行时当属Docker，但它不是唯一的。事实上，容器运行时这个领域发展迅速。为了使Kubernetes的扩展变得更容易，我们一直在打磨支持容器运行时的K8s插件API：容器运行时接口(Container Runtime Interface, CRI)。 CRI是什么？ 每种容器运行时各有所长，许多用户都希望Kubernetes支持更多的运行时。在Kubernetes 1.5发布版里，我们引入了CRI–一个能让kubelet无需编译就可以支持多种容器运行时的插件接口。CRI包含了一组protocol buffers，gRPC API，相关的库，以及在活跃开发下的额外规范和工具。CRI目前是Alpha版本。 支持可替换的容器运行时在Kubernetes中概念中并非首次。在1.3发布版里，我们介绍了rktnetes项目，它可以让rkt容器引擎作为Docker容器运行时的一个备选。然而，不管是Docker还是Rkt都需要通过内部、不太稳定的接口直接集成到kubelet的源码中。这样的集成过程要求十分熟悉kubelet内部原理，并且还会在Kubernetes社区引发巨大的维护反响。这些因素都在为容器运行时的初期造成了巨大的困难。我们通过提供一个清…

Read More Read More

Scroll Up