集群技术

作者 | 贤维 阿里巴巴高级技术专家 导读 ：Serverless Kubernetes 是阿里云容器服务团队对未来 Kubernetes 演进方向的一种探索，通过对 Kubernetes 做减法，降低运维管理负担，简化集群管理，让 Kubernetes 从复杂到简单。 背景 Kubernetes 作为通用的容器编排系统，承载了广泛的应用和场景，包括 CI／CD，数据计算，在线应用，AI 等，然而由于其通用性和复杂性，管理一个 Kubernetes 集群对于很多用户而言还是充满挑战的，主要体现在： 学习成本高； 集群运维管理成本高，包括节点管理、容量规划，以及各种节点异常问题的定位； 计算成本在很多场景中没有达到最优，比如对于一个定时运行 Jobs 的集群，长期持有资源池对于用户来说是浪费的行为，资源利用率不高。 对 Kubernetes 集群做减法 无节点管理 我们相信未来用户会更加关注应用的开发，而不是基础设施的维护。体现在 Kubernetes 集群中，我们希望用户能够关注在 pod/service/ingress/job 等应用编排语义上，对底层 node 则可以减少关注。 无需管理节点也可以显著降低集群的运维管理成本，经统计 Kubernetes 常见的异常问题中大多数与节点相关，比如 Node NotReady 问题，也无需担忧 Node 的安全问题

目录 node_exporter监控集群节点 1.node-exporter.yaml 2.查看DaemonSet字段 3.启动 prometheus.yaml文件说明 1.Pod的安全策略 2.监控master节点 3.启动参数 4.映射端口 5.服务发现 热更新: prometheu_configmap 配置文件 容器监控 Api-Service 监控 Service 监控 1.添加service监控 2.service添加prometheus标签 3.kube-state-metrics node_exporter监控集群节点 通过prometheus来采集节点的监控指标，可以通过node_exporter获取，node_exporter就是抓取用于采集服务器节点的各种运行指标，目前node_exporter几乎支持所有常见的监控点，比如cpu、distats、loadavg、meminfo、netstat等，详细的监控列表可以参考github repo 这里使用DeamonSet控制器来部署该服务，这样每一个节点都会运行一个Pod，如果我们从集群中删除或添加节点后，也会进行自动扩展 1.node-exporter.yaml # cat >>prometheus-node-exporter.yaml apiVersion: apps/v1 kind: DaemonSet

作者 | 贤维 阿里巴巴高级技术专家 导读 ：Serverless Kubernetes 是阿里云容器服务团队对未来 Kubernetes 演进方向的一种探索，通过对 Kubernetes 做减法，降低运维管理负担，简化集群管理，让 Kubernetes 从复杂到简单。 背景 Kubernetes 作为通用的容器编排系统，承载了广泛的应用和场景，包括 CI／CD，数据计算，在线应用，AI 等，然而由于其通用性和复杂性，管理一个 Kubernetes 集群对于很多用户而言还是充满挑战的，主要体现在： 学习成本高； 集群运维管理成本高，包括节点管理、容量规划，以及各种节点异常问题的定位； 计算成本在很多场景中没有达到最优，比如对于一个定时运行 Jobs 的集群，长期持有资源池对于用户来说是浪费的行为，资源利用率不高。 对 Kubernetes 集群做减法 无节点管理 我们相信未来用户会更加关注应用的开发，而不是基础设施的维护。体现在 Kubernetes 集群中，我们希望用户能够关注在 pod/service/ingress/job 等应用编排语义上，对底层 node 则可以减少关注。 无需管理节点也可以显著降低集群的运维管理成本，经统计 Kubernetes 常见的异常问题中大多数与节点相关，比如 Node NotReady 问题，也无需担忧 Node 的安全问题

写在前面 在当今信息爆炸的时代，单台计算机已经无法负载日益增长的业务发展，虽然也有性能强大的超级计算机，但是这种高端机不仅费用高昂，也不灵活，一般的企业是负担不起的，而且也损失不起，那么将一群廉价的普通计算机组合起来，让它们协同工作就像一台超级计算机一样地对外提供服务，就成了顺其自然的设想，但是这又增加了软件的复杂度，要求开发的软件需要具备横向扩展能力，比如：Kafka、Elasticsearch、Zookeeper等就属于这一类软件，它们天生都是"分布式的"，即可以通过添加机器节点来共同地分摊数据存储和负载压力。 为什么需要集群？ 分布在不同区域的计算机，彼此之间通过网络建立通信，相互协作作为一个整体对外提供服务，这就是集群，如果我们开发的系统具备这样的能力，那么理论上就具备无限横向扩容的能力，系统的吞吐量就会随着机器数增加而增长，那么未来当系统出现高负载的时候，就可以很好地应对这种情况。 为什么CAP不能同时满足？ 通过上面分析，我们知道实现集群，其实就是采用多台计算机来共同承担和负载系统压力，那么就涉及到多台计算机需要参与一起处理数据，为了保证可用性，一般都会在每台计算机上备份一份数据，这样只要有一个节点保持同步状态，那么数据就不会丢失，比如kafka分区多副本、Elasticsearch的副本分片，由于同一数据块及其副本位于不用的机器，随着时间的推移，再加上不可靠的网络通信

本文面向的读者 如果您是一个Kubernetes的初学者，本文可以帮助你快速在云上搭建一个可实际使用的集群环境，并发布自己的第一个应用。你无须提前准备任何的硬件资源或者下载任何的软件包。 如果您已经有一个自建的Kubernetes集群，想要尝试阿里云上的托管集群，本文可以帮助你快速完成上手操作，而无需详细阅读阿里云的帮助文档，从而节省您的时间。您可以在有了端到端的初体验之后，再有选择的阅读容器服务和容器镜像服务的帮助文档。 如果你已经有一个传统的部署在云上的Web应用（比如部署在云上的ECS里），想要进行容器化的改造，本文同样可以帮助到您，您甚至无需深入学习Kubernetes，只需了解基本概念即可。 准备代码 本文的操作全部基于阿里云控制台，因此您只需要一个阿里云控制台的登录账号即可。 我们先把应用的代码准备好。请登录 https://code.aliyun.com/ ，登录完成后，访问 https://code.aliyun.com/shengbo.tsb/yunputest ，点击派生项目(fork)的图标。 在随后弹出的确认框里，点击头像确认，完成派生。 备选方案：如果您派生遇到了困难，可以直接从 https://github.com/docker-training/webapp clone这个项目，然后自己通过git push到code.aliyun.com上。

转眼已经2020，距离微服务这个词落地已经过去好多年！（我记得2017年就听过这个词）。然而今天我想想什么是微服务，其实并没有一个很好的定义。为什么这样说，按照微服务的定义： 微服务架构就是将一个庞大的业务系统按照业务模块拆分成若干个独立的子系统，每个子系统都是一个独立的应用，它是一种将应用构建成一系列按业务领域划分模块的，小的自治服务的软件架构方式，倡导将复杂的单体应用拆分成若干个功能单一、松偶合的服务，这样可以降低开发难度、增强扩展性、便于敏捷开发，及持续集成与交付活动。 根据这个定义，不难看出其实就是对复杂的业务系统统一做逻辑拆分，保持逻辑上的独立。那么逻辑上独立就是一个服务这样做真的是好吗，如何界定：小、独，还有要做一个事情，完成单一的业务，单一的功能要拆分出来，为了独立而独立会不会导致拆的过细？不同人有不同的见解，我们今天一起探讨微服务的过去和未来。 微服务缘起 在没有微服务之前，我们最早的架构模式就是 MVC 模式，把业务逻辑分为：表示层，业务逻辑层，数据访问层。MVC模式随着大前端的发展，从一开始的前后端不分离，到现在的前后端分离逐渐演进。这种演进好的一点是剥离了不同开发语言的开发环境和部署环境，使得开发较为便利，部署更直接。然而问题是：这种模式仍然是单体应用模式，如果有一个改动需要上线，你不得不因为这个改动去考虑更多

单点数据库 数据库往往是系统中的性能瓶颈，所以通常在系统设计中会引入各种各样的缓存机制，以避免频繁访问数据库。另外，数据库由于其重要性，高可用要求也是避免不了的，因为一旦数据库挂了基本上整个系统也就不能使用了。 而以上这些常见问题都是单点数据库带来的限制，为了解决这些问题，达到高性能、高可用的目的，我们就需要在系统架构设计中采用数据库集群方案。 性能测试 既然单点数据库存在性能问题，那么有没有实际数据呢？下面我们就来对单点数据库进行一个性能测试，看看其并发极限大概是多少。我这里使用了一台2核2G的云服务，mysql版本为8.0.18。 mysql自带了一个性能测试工具：mysqlslap，我们可以使用该工具进行测试，具体的测试参数如下： [root@localhost ~]# mysqlslap -hlocalhost -uroot -pyour_password -P3306 --concurrency=500 --iterations=1 --auto-generate-sql --auto-generate-sql-load-type=mixed --auto-generate-sql-add-autoincrement --engine=innodb --number-of-queries=500 主要参数说明： 参数 说明 --concurrency 并发数量

　CDN技术详解 一本好的入门书是带你进入陌生领域的明灯，《CDN技术详解》绝对是带你进入CDN行业的那盏最亮的明灯。因此，虽然只是纯粹的重点抄录，我也要把《CDN技术详解》的精华放上网。公诸同好。 第一章 引言 “第一公里”是指万维网流量向用户传送的第一个出口，是网站服务器接入互联网的链路所能提供的带宽。这个带宽决定了一个 网站能为用户提供的访问速度和并发访问量。如果业务繁忙，用户的访问数越多，拥塞越严重，网站会在最需要向用户提供服务时失去用户。（还有“中间一公里” 和“最后一公里”分别代表互联网传输传输和万维网流量向用户传送的最后一段接入链路） 从互联网的架构来看，不同网络之间的互联互通带宽，对任何一个运营商网络的流量来说，占比都比较小，收敛比是非常高的，因此这里通常都是互联网传输中的拥堵点（运营商互联互通的问题） 其次是骨干网堵塞问题，由于互联网上的绝大部分流量都要通过骨干网络进行传输，这就要求骨干网络的承载能力必须与互联网 的应用同步发展，但实际上两者并不是同步的，当骨干网络的升级和扩容滞后于互联网之上的应用的发展时，就会阶段性地使得大型骨干网的承载能力成为影响互联 网性能的瓶颈（区域互联互通问题，骨干网带宽瓶颈） 在互联网领域有一个“8秒定律”，用户访问一个网站时，如果等待网页打开的时间超过8秒，会有超过30%的用户放弃等待 使用CDN会极大简化网站的系统维护工作量

每年双十一，对于买家来说是一年一度的购物狂欢，可是对于电商公司的技术人员来说，却是一年一次的大考。如何用更少的预算完成指定当前业务规模的流量高峰，是技术的永恒主题。 有赞在双十一之前完成了全链路压测方案，并把它用于大促的扩容和容量验证，取得了不错的成果。 在电商公司待过的技术同学都知道，在大促来临时，整个集群的最高峰压力将是正常时间的几十倍，最高峰持续的时间会特别短，然后回落到正常水平的几倍。所以，我们可能会自然而然地想到，把整个集群扩容几十倍的机器，在双十一当天应对几十倍的流量，然后第二天减至正常量，就可以完成大促的考验。事实情况是否真的这么简单？ 大促保障的困难 用户购买商品的链路是一条很长很复杂的系统集群，中间会涉及到店铺、商品、会员、营销、交易、支付等 6 大核心模块，每个模块又会涉及到多个不同的服务化系统单元，我们把这一条骨干的链路就叫做核心链路。 大家都知道，双十一当天，真正爆增的其实是买家的购买量，像开店 / 商品上架等功能，其实并发量没什么变化。也就是说，真正的压力其实是在核心链路上面，如果把所有的系统都扩容几十倍，本身就是一个很大的浪费。正常来说，一个稍有规模的电商公司，日常有几千台机器维持正常的运转，本身就是一个较大的开销，如果突增几十倍的系统开销，对于公司的财务也是很大的压力。所以，一个较理想的方法，是只把核心链路的系统扩大几十倍的系统吞吐量，就可以达到目标。

一. Kubernetes 系统简介 首先，他是一个全新的基于容器技术的分布式架构领先方案。Kubernetes(k8s)是Google开源的容器集群管理系统（内部:Borg）。在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。 　　Kubernetes是一个完备的分布式系统支撑平台，具有完备的集群管理能力，多扩多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、內建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力。同时Kubernetes提供完善的管理工具，涵盖了包括开发、部署测试、运维监控在内的各个环节。 Kubernetes中，Service是分布式集群架构的核心，一个Service对象拥有如下关键特征： 拥有一个唯一指定的名字 拥有一个虚拟IP（Cluster IP、Service IP、或VIP）和端口号 能够体统某种远程服务能力 被映射到了提供这种服务能力的一组容器应用上 Service的服务进程目前都是基于Socket通信方式对外提供服务，比如Redis、Memcache、MySQL、Web Server，或者是实现了某个具体业务的一个特定的TCP Server进程