主要负责阿里云容器服务产品的底层服务发现系统、集群管理系统的研发,从事容器的持续交付、持续集成的方案的设计与实现。在云计算、分布式系统、图像识别与虚拟现实方向有多年的开发经验。个人博客:abandonzoo.com
当游戏服完成云原生化改造,进行模拟时间设置的时候,就会遇到一些问题。因为默认情况下Pod的时间是继承ECS的时间设置的。如果直接修改ECS的时间,会影响该节点所有的Pod,这对于测试环境而言是不可接受的,需要不影响其他节点的Pod时间修改方式。fake-time-injector是阿里云与莉莉丝游戏通过CloudNativeGame社区一起开源的用于云原生场景下修改模拟时间的组件,协助游戏运维人员简单快速完成开服模拟时间测试。
为了解决企业内部落地AIGC引擎的通用性问题,阿里云与行者AI通过CloudNativeGame社区一起开源了AIGC-Gateway项目,降低企业内部AIGC落地的难度与费用,真正做到开箱即用,即开即用。
## 前言 定时伸缩(cronhpa)是很多开发者在解决负载周期性时最常用的方法,通过类似crontab的语法可以在一个时间点定时触发伸缩活动。crontab的语义表达是很强大的,但是也存在语法复杂,执行计划容易被打断等问题。为了解决上述的问题,定时伸缩(cronhpa)提供了运维模式,支持通过运维页面来查看底层排队的定时任务,同时也提供了API接口用于开发者自研的平台接入与集成。 #
在之前的文章中,我们介绍了kubernetes-cronhpa-controller是如何通过设置定时的方式触发容器的水平副本伸缩,但是在实际的场景下,虽然定时伸缩对于负载有规律的应用比较友好,但是应用为了防止突发的流量冲击,还是会配置HPA来做最后的保障的。
kube-eventer是Kubernetes社区中针对事件监控、报警、chatOps场景的开源组件,新版本的kube-eventer支持了泛化Webhook的支持,更多信息请点击详情。
kubernetes-cronhpa-controller是容器服务开源的一款面向Pod水平定时伸缩场景的CRD controller。在本系列的之前文章中已经向大家介绍了kubernetes-cronhpa-controller的基本用法了,今天我们来看下近期kubernetes-cronhpa-controller又增加了哪些新的功能。
监控是保障系统稳定性的重要组成部分,在Kubernetes开源生态中,资源类的监控工具与组件百花齐放。除了社区自己孵化的metrics-server,到从CNCF毕业的Prometheus,开发者可选的方案有很多。
容器技术的发展让软件交付和运维变得更加标准化、轻量化、自动化。这使得动态调整负载的容量变成一件非常简单的事情,在kubernetes中,通常只需要调整对应的replicas数目即可完成。当负载的容量调整变得如何简单后,我们再回过头来看下应用的资源画像。
在上篇文章中,我们分析了Spark Operator内部的机制,今天我们会讨论一个在大数据领域中最重要的话题 - 存储。大数据已经无声无息的融入了每个人的生活中。大到旅游买房,小到外卖打车,都可以看到通过大数据提供数据分析、数据推荐、数据决策的使用场景。
在上篇文章中,向大家介绍了如何使用Spark Operator在kubernetes集群上面提交一个计算作业。今天我们会继续使用上篇文章中搭建的Playgroud进行调试与解析,帮助大家更深入的理解Spark Operator的工作原理。
### 前言 Spark是非常流行的大数据处理引擎,数据科学家们使用Spark以及相关生态的大数据套件完成了大量又丰富场景的数据分析与挖掘。Spark目前已经逐渐成为了业界在数据处理领域的行业标准。但是Spark本身的设计更偏向使用静态的资源管理,虽然Spark也支持了类似Yarn等动态的资源管理器,但是这些资源管理并不是面向动态的云基础设施而设计的,在速度、成本、效率等领域缺乏解决方案
#### 前言 在本系列的前三篇中,我们介绍了弹性伸缩的整体布局以及HPA的一些原理,HPA的部分还遗留了一些内容需要进行详细解析。在准备这部分内容的期间,会穿插几篇弹性伸缩组件的最佳实践。今天我们要讲解的是 **cluster-proportional-autoscaler** 。
#### 前言 在上一篇文章中,给大家介绍和剖析了HPA的实现原理以及演进的思路与历程。在本文中,我们会为大家讲解如何使用HPA以及一些需要注意的细节。 #### `autoscaling/v1`实践 v1的模板可能是大家平时见到最多的也是最简单的,v1版本的HPA只支持一种指标 —— CPU。传统意义上,弹性伸缩最少也会支持CPU与Memory两种指标,为什么在Ku
#### 前言 在上一篇文章中,我们介绍了在Kubernetes在处理弹性伸缩时的设计理念以及相关组件的布局,在今天这篇文章中,会为大家介绍在Kubernetes中弹性伸缩最常用的组件HPA(Horizontal Pod Autoscaler)。HPA是通过计算Pod的实际工作负载进行重新容量规划的组件,在资源池符合满足条件的前提下,HPA可以很好的实现弹性伸缩的模型。HPA到目前为止,
### 传统弹性伸缩的困境 弹性伸缩是Kubernetes中被大家关注的一大亮点,在讨论相关的组件和实现方案之前。首先想先给大家扩充下弹性伸缩的边界与定义,传统意义上来讲,弹性伸缩主要解决的问题是容量规划与实际负载的矛盾。 如上图所示,蓝色的水位线表示集群的容量随着负载的提高不断的增长,红色的曲线表示集群的实际的负载真实的变化。而弹性伸缩要解决的就是当实际负载出现激增,而容量规
前言 随着容器技术的兴起,越来越多不同类型的应用开始使用容器的方式进行交付。Golang作为服务器端非常热门的一门语言同时也是容器技术的主要编写语言备受关注。那么将一个Golang应用进行容器化的时候,需要注意哪些事情,在出现问题时该如何进行调优和诊断呢? 先谈谈Golang本身的设计 Golang是谷歌发布的第二款开源编程语言。
前言 Prometheus是一款面向云原生应用程序的开源监控工具,作为第一个从CNCF毕业的监控工具而言,开发者对于Prometheus寄予了巨大的希望。在Kubernetes社区中,很多人认为Prometheus是容器场景中监控的第一方案,成为容器监控标准的制定者。
前言 在开始给大家讲解如何通过eventer与npd来实现节点异常告警之前,要稍微给大家解释一下为什么用三篇的篇幅来介绍eventer。在kubernetes中,会将交付场景中的大部分实体都抽象为一个逻辑的概念,例如:接入层抽象为Service,存储层抽象为PV/PVC,不同种类的应用抽象为Deployment、StatefulSet等等。
前言 在上一篇文章中,向大家介绍了如何通过eventer将Kubernetes中的事件告警到钉钉群中,那么如何将这些非常有价值的事件进行离线存储与归档呢? 目前eventer支持elasticsearch、influxdb、kafka、sls四种离线存储的链路。
竞价实例优化运营成本 竞价实例(Spot Instance)也叫抢占式实例是一种按需实例,旨在降低部分场景下使用ECS的成本,创建竞价实例时,必须为指定的实例规格设置一个价格上限,当指定的实例规格的当前市场价格低于出价时,就能成功创建竞价实例,并按当前市场价格计费。
前言 cluster-autoscaler是Kubernetes中非常受大家关注的功能特性,可以通过cluster-autoscaler实现节点级别的动态添加与删除,动态调整容器资源池,应对峰值流量。
前言 容器应用的监控和传统应用的监控有很大的不同,在本系列的前面几篇文章中提到了关于自顶向下的传统监控策略以及在容器中常用的自底向上的反向监控策略与问题以及阿里云是如何通过数据链路与逻辑链路分离的方式解决上述问题的,文章直达连接。
前言 Kubernetes作为非常流行的容器编排引擎已经逐渐成为容器交付的标准,为了解决标准化交付的问题,Kubernetes抽象了多种概念来代表不同的交付内容。 例如,不同应用场景的服务载体可以通过Deployment、DaemonSet、StatefulSet、CronJob来抽象;网络接入层可以通过Service进行抽象;服务配置可以通过ConfigMap或者Secret进行抽象等等。
前言 弹性伸缩是开发者使用容器过程中非常关注的特性,如果从资源类型的角度来讲,可以分为物理资源的弹性伸缩与容器资源的弹性伸缩。在本篇中,主要向大家介绍的是容器资源的弹性伸缩,在Kubernetes中,HPA(Horizontal Pod Autoscaling)是用来抽象容器水平弹性伸缩的概念。
简介 监控是运维Kubernetes中非常重要的一环,在kubernetes的生态内,有非常多可选的方案,场景的方案包括内置的Heapster、CNCF的亲儿子Prometheus、Influxdb的采集方案Telegraf等等,当然传统的监控运维工具例如zabbix也对容器的场景进行了适配。
简介 在kubernetes的监控方案中,Heapster+Influxdb+Grafana的组合相比prometheus等开源方案而言更为简单直接。而且Heapster在kubernetes中承担的责任远不止监控数据的采集,还包括控制台的监控接口、HPA的POD弹性伸缩等都依赖于Heapster的功能。
简介 容器通过集装箱式的编译、打包、部署,大大提高了应用的迭代速度。对于架构师而言,容器带来的是分钟级的部署、秒级的伸缩与恢复、一个量级的迭代速度提升、50%左右的基础成本节省。但是对于落地实施容器的开发者而言。
前言 性能调优是一个老生常谈的话题,通常情况下,一个应用在上线之前会进行容量规划、压力测试并进行验证,而性能调优则是在容量规划与验证结果之间出现差异时会进行的必然手段。从某种角度来讲,性能调优是一个非常需要经验的领域,需要调优人员对应用的架构、调用的链路、使用的语言、操作系统的差异、内核的参数表现等等都有完整的了解。
2017年是容器领域交战非常激烈的一年,容器编排领域逐渐形成一超多强的局面,各种容器解决方案变得越来越成熟,传统的中间件(监控、日志、报警)对容器化场景支持逐渐完善。到了今年,如果一家公司还没有开始对Docker进行关注,真的不好意思说是在互联网的圈子里了。
一篇文章来看Jenkins的存储模型并讨论高可用的可行性。
前言 哲学有各种各样的流派,百家争鸣,但是只有一个哲学问题是严肃的,那就是生与死。而云端交付过程中也只有三个问题是严肃的。 如何重建你的系统 How to recreate your system? 如何安全地部署你的系统 How to safely change your system? 部署后的问题监控与解决 When something has gone wrong? 在前面的文章中,我们讲述了什么是云端交付,如何搭建从零搭建一个持续交付系统,而今天我们要谈的是如何安全的部署你的系统,部署这个名词包含了很多的含义,最简单的解释就是如何让你的程序运行在最终的环境上。
前言 随着微服务架构与容器虚拟化技术的发展,持续集成与持续交付的概念又重新回到了大家的视野,越来越多的公司开始使用持续集成的系统来解决频繁发布带来的质量问题;使用持续交付的工具来实现代码在不同环境上的自动部署。
3月28日云栖大会开源专场,阿里云高级开发工程师莫源给大家带来了“Dev Oops ? No , DevOps!”的演讲。本文主要介绍DevOps的相关知识,以及Jenkins2.0的高级特性,以及阿里云对Jenkins的增强。
## 前言 在上篇文章中,我们讨论了如何调试Jenkins的页面。今天我们将开始研究研究Jenkins的页面与路由机制。因为Stapler与Jelly的内容比较繁琐和复杂,暂定通过两篇文章来探讨。
## 写在开头 Jenkins是非常流行的开源的持续交付平台,拥有丰富的插件、文档与良好的社区。是国内大多数公司私有持续集成方案CI/CD服务器的选型。开发者可以快速的通过Jenkins搭架符合自己业务场景的pipeline,结合大量的开源插件,可以轻松的满足不同语言、不同平台、不同框架的持续集成场景。
## 前言 在上一篇文章中,总结了Jenkins的罪与罚。从本文开始,我们将迈入Jenkins的源码学习部分。学习源码的方式有很多种,对于Jenkins而言,网上关于源码的学习非常有限,比较建议大家先阅读官方关于如何成为contributor的文档,了解大体的结构后再逐步深入。
在上一篇文章中,我们演示了如何使用蓝绿发布来实现热部署,但是在实际生产的场景中,应用的拓扑结构会复杂很多。在本篇文章中我们将会讨论下复杂应用拓扑中的蓝绿发布方案以及蓝绿发布适用的场景。
## 初识slack 几年前开始创业,组建团队的第一天,我们首先讨论和考虑的不是高屋建瓴的业务场景和目标,而是整个团队的协同和沟通的问题。选择使用什么作为团队的IM,选择什么作为BUG的记录,选择什么作为需求的跟踪,这些基础设施的存在无形中提高了整个团队的生产力,保证了协作的顺畅和流程。由于团队的成员有些是外国人,而在国外GEEK圈中风光无限的SLACK也就顺理成章的被老外们安利到了团队中。