天道酬勤,学无止境

容器

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 | 韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号​ 前言 台湾作家林清玄在接受记者采访的时候,如此评价自己 30 多年写作生涯:“第一个十年我才华横溢,‘贼光闪现’,令周边黯然失色;第二个十年,我终于‘宝光现形’,不再去抢风头,反而与身边的美丽相得益彰;进入第三个十年,繁华落尽见真醇,我进入了‘醇光初现’的阶段,真正体味到了境界之美”。​长夜有穷,真水无香。领略过了 K8s“身在江湖”的那种惊心动魄以及它那生态系统的繁花似锦,该是回过头来体味高可用体系境界之美的时候了。毕竟仅能经得起敲打还是不能独步武林的!​在 K8s 高可用领域有一个问题被大家所熟知,那就是 K8s 单集群规模带来的 SLO 问题,如何持续保障?今天就以单集群的规模增长带来的高可用挑战来作为引子来给大家一个体感。​ASI 单集群规模支撑超过社区的 5000 台,这是个非常有意思且具备极大挑战的事情,对需要进行 K8s 生产化的同学,甚至具备 K8s 生产化经验的同学来说,一定会是个感兴趣的话题。回看 ASI 单集群规模从 100 到 10000 的发展之路,伴随着业务的增长和创新带来的每一次集群规模增长,都在逐步使我们的压力和挑战发生质变。​ ASI:Alibaba Serverless infrastructure,阿里巴巴针对云原生应用设计的统一基础设施,ASI 是阿里公共云服务 ACK

2021-06-02 12:24:35    分类:博客    云原生   开发者   容器

业界率先支持 MCP-OVER-XDS 协议,Nacos 2.0.1 + 1.4.2 Release

来源 | 阿里巴巴云原生公众号​Nacos 是阿里巴巴开源的服务发现与配置管理项目,本次同时发布两个版本:​ 发布 2.0.1 版本,主要致力于支持 MCP-OVER-XDS 协议,解决 Nacos 与 Istio 数据服务同步问题。 发布 1.4.2 版本,极大增强 K8s 环境中 JRaft 集群 Leader 选举的稳定性。 Nacos 2.0.1 2.0.1 主要变更为:​ 在 nacos-istio 插件及模块中,支持 MCP-OVER-XDS 协议,解决 Nacos 与 Istio 数据服务同步问题。 增强了 Jraft 协议在 K8s 环境中的 Leader 选举的稳定性。 修复了频繁抛出 Server is Down 错误的问题。 具体变更为:​ [#3484] Support ldap login. [#4856] Support mcp over xds. [#5137] Support service list add view subscriber. [#5367] Support client encryption plugin for nacos 2.0. [#5307] Push support config some parameters [#5334] Fix Server is Down problem in k8s environment. [

2021-06-02 12:24:27    分类:博客    云原生   微服务   容器

KubeVela + KEDA:为应用带来“与生俱来”的弹性伸缩能力

联合作者 | Yan Xun,阿里云 EDAS 团队高级工程师Andy Shi,阿里云开发者倡导者Tom Kerkhove,Codit 容器化业务负责人兼 Azure 架构师、KEDA 维护者、CNCF 大使来源 | 阿里巴巴云原生公众号​当你在伸缩 Kubernetes 时,你会想到一些领域,但是如果你是 Kubernetes 的新手,你可能会觉得有些难以应付。​在这篇博文中,我们将简要解释需要考虑的领域,KEDA 如何使应用自动伸缩变得简单,以及为什么阿里云企业分布式应用服务(EDAS)​在 KEDA 上完全标准化。​ 伸缩 Kubernetes 当管理 Kubernetes 集群和应用程序时,你需要仔细监视各种事情,比如:​ 集群容量——我们是否有足够的可用资源来运行我们的工作负载? 应用程序工作负载——应用程序有足够的可用资源吗?它能跟上待完成的工作吗?(像队列深度) 为了实现自动化,你通常会设置警报以获得通知,甚至使用自动伸缩。Kubernetes 是一个很好的平台,它可以帮助你实现这个即时可用的功能。​通过使用 Cluster Autoscaler 组件可以轻松地伸缩集群,该组件将监视集群,以发现由于资源短缺而无法调度的 pod,并开始相应地添加/删除节点。​因为 Cluster Autoscaler 只在 pod 调度过度时才会启动,所以你可能会有一段时间间隔

2021-06-02 05:40:08    分类:博客    云原生   监控   容器

Ceph数据恢复初探

大家好,我是焱融云存储系统的研发猿小焱,本文由我和大家一起探讨下Ceph数据恢复相关的知识。众所周知,Ceph是近年来最为炙手可热的开源分布式存储系统。跟其他分布式存储系统不一样的是,Ceph在称之为RADOS的核心对象存储架构之上,提供了块存储、文件存储以及对象存储的接口,因此Ceph可以称之为统一存储(Unified Storage)。而本文我们将讨论的是Ceph RADOS核心层面的数据恢复逻辑。不过和一般分布式系统一样的是,Ceph同样使用多副本机制来保证数据的高可靠性(注:EC在实现层面可以理解为副本机制的一种),给定一份数据,Ceph在后台自动存储多份副本(一般使用3个副本),从而使得在硬盘损毁、服务器故障、机柜停电等故障情况下,不会出现数据丢失,甚至数据仍能保持在线。不过在故障发生后,Ceph需要及时做故障恢复,将丢失的数据副本补全,以维系持续的数据高可靠性。因此多副本机制是分布式存储系统的核心机制之一,它带来了数据高可靠性,也提高了数据可用性。然而事情是没有十全十美的,多副本机制同时带来了分布式系统的最大问题之一:数据一致性。不过Ceph数据一致性并非本文的主题,以后有机会小焱再跟大家一起分享,本文仅会聊到数据恢复相关的数据一致性。综上,我们讨论了为什么Ceph采用多副本机制,以及需要通过数据恢复及时补全故障带来的副本缺失

2021-06-02 04:36:16    分类:博客    分布式   云存储   容器

工商银行分布式服务 C10K 场景解决方案

作者 | 颜高飞来源 | 阿里巴巴云原生公众号 Dubbo 是一款轻量级的开源 Java 服务框架,是众多企业在建设分布式服务架构时的首选。中国工商银行自 2014 年开始探索分布式架构转型工作,基于开源 Dubbo 自主研发了分布式服务平台。 Dubbo 框架在提供方消费方数量较小的服务规模下,运行稳定、性能良好。随着银行业务线上化、多样化、智能化的需求越来越旺盛,在可预见的未来,会出现一个提供方为数千个、甚至上万个消费方提供服务的场景。 在如此高负载量下,若服务端程序设计不够良好,网络服务在处理数以万计的客户端连接时、可能会出现效率低下甚至完全瘫痪的情况,即为 C10K 问题。那么,基于 Dubbo 的分布式服务平台能否应对复杂的 C10K 场景?为此,我们搭建了大规模连接环境、模拟服务调用进行了一系列探索和验证。 C10K 场景下 Dubbo 服务调用出现大量交易失败 1. 准备环境 使用 Dubbo2.5.9(默认 netty 版本为 3.2.5.Final)版本编写服务提供方和对应的服务消费方。提供方服务方法中无实际业务逻辑、仅 sleep 100ms;消费方侧配置服务超时时间为 5s,每个消费方启动后每分钟调用1次服务。 准备 1 台 8C16G 服务器以容器化方式部署一个服务提供方,准备数百台 8C16G 服务器以容器化方式部署 7000 个服务消费方。 启动

2021-06-02 02:54:41    分类:博客    云原生   微服务   容器

云原生下的灰度体系建设

作者 | 墨封来源 | 阿里巴巴云原生公众号 一周前,我们介绍了《面对大规模 K8s 集群,如何先于用户发现问题》。 本篇文章,我们将继续为大家介绍 ASI SRE(ASI,Alibaba Serverless infrastructure,阿里巴巴针对云原生应用设计的统一基础设施) 是如何探索在 Kubernetes 体系下,建设 ASI 自身基础设施在大规模集群场景下的变更灰度能力的。 我们面临着什么 ASI 诞生于阿里巴巴集团全面上云之际,承载着集团大量基础设施全面云原生化的同时,自身的架构、形态也在不断地演进。 ASI 整体上主要采用 Kube-on-Kube 的架构,底层维护了一个核心的 Kubernetes 元集群,并在该集群部署各个租户集群的 master 管控组件:apiserver、controller-manager、scheduler,以及 etcd。而在每个业务集群中,则部署着各类 controller、webhook 等 addon 组件,共同支撑 ASI 的各项能力。而在数据面组件层面,部分 ASI 组件以 DaemonSet 的形式部署在节点上,也有另一部分采用 RPM 包的部署形式。 同时,ASI 承载了集团、售卖区场景下数百个集群,几十万的节点。即便在 ASI 建设初期,其管辖的节点也达到了数万的级别。在 ASI 自身架构快速发展的过程中

2021-06-02 02:31:46    分类:博客    云原生   容器   监控

Docker之容器技术概述

Docker之容器技术概述容器概述:容器是一种基础工具,泛指任何可以用于容纳其他物品的工具,可以部分或完全封闭,被用于容纳,存储,运输物品。物体可以被放置在容器中,而容器则可以保护内容物。我们的期望:我们希望不同的环境跑在不同的环境中,对其中的资源,内存等进行隔离,因为经常因为复杂的环境冲突问题,导致我们的工作不顺等问题VM:虚拟化技术VM虚拟化技术的出现解决了这一问题,隔离开了不同的服务器中的环境,这也是最早的容器技术,但是他存在一个问题,虽然隔离性好,但是对于开销来说就非常的大,因为我可能只跑一个程序,只是想把环境隔离开来,却要为他单独分配一个操作系统,这显然是资源的浪费,所以泛生出来容器技术,如果采用物理机上装VM,会跑一层Hypervisor 容器技术:其中的Docker Engine可以通过其他容器技术取代,通过容器技术的出现,我们解决了要为每个程序安装新的操作系统的问题,容器技术只是将二进制,类库和应用隔离开来,并没有操作系统层,所以他的开销大大减小了,但是相对的因为采用同一台操作系统,应用隔离性大幅度下降,但是也能满足使用隔离层次:   前几天一直没有写文章,是一直在看腾讯云大学的DevOps,其中里面的概念性东西比较多,没有实际操作,所以就没有写成文章,而且我觉得这个DevOps要落地的话,完全看公司的理念制度等相关的,如果有兴趣的可以去看一看

2021-06-02 02:26:02    分类:博客    docker   容器

Docker容器引擎介绍及其安装部署

Docker容器引擎介绍概述:Docker引擎可以从Docker网站下载,也可以基于GitHub上的源码进行构建,无论是开源版本还是商业版本,都有Linux和Windows版本Docker引擎主要有两个版本:企业版(EE)和社区版(CE)每个季度,企业版和社区版都会发布一个稳定版本,社区版本会提供4个月的支持,而企业版会提供12个月的支持从2017年第一季度开始,Docker版本号遵循YY.MM-xx格式,类似于Ubuntu等项目,泪如2018年6月第一次发布的社区版本18.06.0-ce注:2017年第一季度之前,Docker版本号遵循大版本号.小版本号的格式,采用新格式的最后一个版本是Docker1.13Docker安装前的环境检查:执行 uname -a,要求内核3.8以上,我的是3.10符合 执行 cat /etc/redhat-release 查看版本,版本要求 Centos7以上 Centos 7配置Base源和epel源将 /etc/yum.repos.d的文件夹中的所有文件,新建一个文件夹放入里面cd /etc/yum.repos.d/mkdir bak mv * bak/获取阿里的base源和epel源wget -O CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repowget -O /etc

2021-06-02 02:25:58    分类:博客    docker   容器

在Docker中创建Mongo容器的后续设置

后续设置包括设置数据库管理员账号密码、创建业务数据库以及设置账户密码需要注意的是,在创建Mongo容器后,需要映射到本机以管理员身份打开powershell先切换到mongdo bash# `docker exec -it mongo bash`中的`mongo`是容器名 docker exec -it mongo bash mongo切换到admin数据库use admin创建admin用户db.createUser({user: "mongo-admin",pwd: "passw0rd",roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]}) db.createUser({user: "mongo-root",pwd: "passw0rd",roles: [ { role: "root", db: "admin" } ]})使用Navicat创建一个数据库db为指定数据库db创建用户use db db.createUser({user: "my-user",pwd: "passw0rd",roles: [ { role: "readWrite", db: "db" } ]})结果如下参考资料MongoDB: Create User – For Database, Admin, Root来源:https://blog

2021-05-18 15:04:29    分类:博客    docker   容器

面对大规模 K8s 集群,如何先于用户发现问题?

作者 | 彭南光(光南)来源 | 阿里巴巴云原生公众号 千里之堤,溃于蚁穴。 绪论 不知道大家是否经历过这样的情景:突然被用户告知系统出现问题,然后一脸懵地惶惶然排查修复;或是等到自己发现系统出现故障时,实际已经对用户造成了严重的恶劣影响。 所谓千里之堤,溃于蚁穴。用户信任的建立是长期而艰难的,然而要摧毁这种信任却很简单。一旦出现上述问题,不仅极大影响用户使用体验,同时会给用户留下一个这个产品/团队不可靠的印象,丧失用户对产品/团队长期好不容易积累下来的信用资本,未来再想建立这样的信任关系就很难了。 这也是为什么我们说快速发现问题的能力如此重要的原因,只有先做到快速发现问题,才能谈怎样排查问题、如何解决问题。 那么怎样才能在复杂的大规模场景中,做到真正先于用户发现问题呢?下面我会带来我们在管理大规模 ASI 集群过程中对于快速发现问题的一些经验和实践,希望能对大家有所启发。 注:ASI 是 Alibaba Serverless infrastructure 的缩写,是阿里巴巴针对云原生应用设计的统一基础设施。有兴趣可以阅读:《揭开阿里巴巴复杂任务资源混合调度技术面纱》。 背景 1. 复杂的场景和曾面临的困境 我们所管理的大规模 ASI 集群场景非常复杂,这为我们的工作带来了极大挑战,任何一个场景处理不慎就有可能导致意料之外的伤害扩大化。 从组件维度看,我们目前有几百个组件

2021-05-18 12:50:51    分类:博客    云原生   容器   k8s