标签 集群 下的文章

使用minio搭建高性能对象存储-第一部分:原型

近期参与了一个项目,该项目有存储大量图片、短视频、音频等非结构化数据的需求。于是我优先在Go社区寻找能满足这类需求的开源项目,minio就这样进入了我的视野。

img{512x368}

图:minio logo

其实三年前我就知道了minio,并还下载玩(研)耍(究)了一番,但那时minio的成熟程度与今天相比还是相差较远的(当时需求简单,于是选择了较为熟悉的weedfs)。而如今的minio在github上收获了广泛的关注,小星星也是蛮多的(20k+ star)。它不仅被Go社区使用,在其他语言社区也有着广泛应用。我可以不负责任的说:在对象存储领域,minio大有kafka(java技术栈)在消息队列领域舍我其谁的气概:)。

2019年gopherchina大会上,探探工程师分享了“基于MINIO的对象存储方案在探探的实践”。虽然探探目前是否在生产中使用minio暂不得而知,但这又一次证明了minio在对象存储领域的强大影响力。

img{512x368}

图:探探工程师在gopherchina2019大会上分享minio实践

minio出品自一个有着多年网络文件系统开发经验的团队,其初始创始团队都来自于原Glusterfs团队,该团队二次创业的产品minio的设计广泛吸取了glusterfs的经验和教训:

  • 部署简单:一个single二进制文件即是一切,还可支持各种平台。(托了go语言的福)

  • minio支持海量存储,可按zone扩展(原zone不受任何影响),支持单个对象最大5TB;

  • 兼容Amazon S3接口,充分考虑开发人员的需求和体验;

  • 低冗余且磁盘损坏高容忍,标准且最高的数据冗余系数为2(即存储一个1M的数据对象,实际占用磁盘空间为2M)。但在任意n/2块disk损坏的情况下依然可以读出数据(n为一个纠删码集合(Erasure Coding Set)中的disk数量)。并且这种损坏恢复是基于单个对象的,而不是基于整个存储卷的。

  • 读写性能优异

img{512x368}

图:来自minio技术白皮书中的benchmark数据

鉴于上述minio的“优点”,我打算在这个项目中基于minio实现非结构化数据的对象存储方案。本篇文章将介绍方案的原型设计与初始minio验证环境搭建。

一. 原型方案

基于minio的非结构化数据对象存储方案都大同小异,下面的图示就是根据我们的需求简单设计的原型方案:

img{512x368}

图:原型方案

  • 我们基于minio提供的distributed mode,将位于多个host上的多块磁盘组成一个逻辑存储池,通过运行于不同host上的minio server实现一个高可用的对象存储方案;

  • 数据通过一个独立的上传服务(基于minio提供的sdk与minio集群通信)写入minio;

  • 通过minio的mc工具创建bucket,并将bucket的policy设置为”download”,以允许外部用户直接与minio通信,获取对象数据。中间不再设置除lb之外的中间层;

  • 通过job或定时任务利用mc工具统一对minio中的数据进行维护,比如定期删除7天前的数据(如果数据默认过期时间设定为7天)。

二. minio server启动模式

minio支持多种server启动模式:

img{512x368}

图:minio server启动模式

minio server的standalone模式,即要管理的磁盘都在host本地。该启动模式一般仅用于实验环境、测试环境的验证和学习使用。在standalone模式下,还可以分为non-erasure code modeerasure code mode

所谓non-erasure code mode,即minio server启动时仅传入一个本地磁盘目录参数:比如:

$minio server data

Endpoint:  http://10.10.126.88:9000  http://127.0.0.1:9000
AccessKey: minioadmin
SecretKey: minioadmin

Browser Access:
   http://10.10.126.88:9000  http://127.0.0.1:9000           

Command-line Access: https://docs.min.io/docs/minio-client-quickstart-guide
   $ mc config host add myminio http://10.10.126.88:9000 minioadmin minioadmin

... ...

在这样的启动模式下,对于每一份对象数据,minio直接在data下面存储这份数据,不会建立副本,也不会启用纠删码机制。因此,这种模式无论是服务实例还是磁盘都是“单点”,无任何高可用保障,磁盘损坏就表示数据丢失。

同样在单minio server的情况下,erasure code mode即为minio server实例传入多个本地磁盘参数。一旦遇到多于一个磁盘参数,minio server会自动启用erasure code modeerasure code对磁盘的个数是有要求的,如不满足要求,实例启动将失败:

$minio server data1 data2
ERROR Invalid command line arguments: Incorrect number of endpoints provided [data1 data2]
      > Please provide an even number of endpoints greater or equal to 4
      HINT:
        For more information, please refer to https://docs.min.io/docs/minio-erasure-code-quickstart-guide

erasure code启用后,要求传给minio server的endpoint(standalone模式下,即本地磁盘上的目录)至少为4个。minio server启用纠删码机制后,会自动将传入的disk drive划分为多个erasure coding set,每个erasure coding set中的disk drive的数量可以是:4, 6, 8, 10, 12, 14 和16。minio server会根据传入disk drive的数量自动计算set个数和每个set中的disk drive数量。比如下面例子中,我们传入四个endpoint(disk drive)给minio server:

$minio server data1 data2 data3 data4

Formatting 1 zone, 1 set(s), 4 drives per set.
WARNING: Host local has more than 2 drives of set. A host failure will result in data becoming unavailable.
Status:         4 Online, 0 Offline.
Endpoint:  http://10.10.126.88:9000  http://127.0.0.1:9000
AccessKey: minioadmin
SecretKey: minioadmin

Browser Access:
   http://10.10.126.88:9000  http://127.0.0.1:9000           

Command-line Access: https://docs.min.io/docs/minio-client-quickstart-guide
   $ mc config host add myminio http://10.10.126.88:9000 minioadmin minioadmin

... ...

从minio server的输出日志来看,minio server将这些drive放入了一个erasure coding set了。在输出日志中,我们还看到一行WARNING: Host local has more than 2 drives of set. A host failure will result in data becoming unavailable.,即minio server警告我们:这个erasure coding set中有多于两个的drive都在local host上,这样一旦host宕机,那么数据将无法获取。(每个set 有4个drive,根据纠删码的机制,这个set的最大允许失效的disk数量为4/2=2)。

我们再来看minio server启动的一个“语法糖” – “省略号”语法:

$minio server data{1...18}

Formatting 1 zone, 3 set(s), 6 drives per set.
WARNING: Host local has more than 3 drives of set. A host failure will result in data becoming unavailable.
WARNING: Host local has more than 3 drives of set. A host failure will result in data becoming unavailable.
WARNING: Host local has more than 3 drives of set. A host failure will result in data becoming unavailable.
Status:         18 Online, 0 Offline.
Endpoint:  http://10.10.126.88:9000  http://127.0.0.1:9000
AccessKey: minioadmin
SecretKey: minioadmin

Browser Access:
   http://10.10.126.88:9000  http://127.0.0.1:9000           

Command-line Access: https://docs.min.io/docs/minio-client-quickstart-guide
   $ mc config host add myminio http://10.10.126.88:9000 minioadmin minioadmin

... ...

minio server data{1...18}等价于minio server data1 data2 data3 data4 data5 data6 data7 data8 data9 data10 data11 data 12 data13 data14 data15 data16 data17 data18。minio server会自行扩展省略号代表的内容。我们看到:当我们传入18个disk drive后,minio server创建了3个erasure coding set,每个set中有6个disk drive。同样,minio server还针对每个set输出了一行WARNING:每个Set中有三个以上的disk drive都位于同一台host上。

这些WARNING我们可以通过distributed mode来解决。顾名思义,distributed mode下,minio server实例和其管理的disk drive分布在多台host上,这种模式可以避免minio server实例单点,数据也将分布在不同host上的不同disk中,实现了高可用,提升了整体的容灾能力。由于处理多个host上的disk,distribute mode默认就会启动erasure coding set机制。

在distributed mode下,minio server后面的远程的endpoint采用http url编码格式:

export MINIO_ACCESS_KEY=<ACCESS_KEY>
export MINIO_SECRET_KEY=<SECRET_KEY>
$minio server http://host{1...4}:9000/minio/data{1...4}

上面例子中的minio server命令相当于4个host,每个host上启动一个minio server实例,每个实例都管理16的disk drive(包括本地和远程的)。上述命令等价于:

$minio server http://host1:9000/minio/data1 http://host1:9000/minio/data2 http://host1:9000/minio/data3 http://host1:9000/minio/data4 http://host2:9000/minio/data1 http://host2:9000/minio/data2 http://host2:9000/minio/data3 http://host2:9000/minio/data4 http://host3:9000/minio/data1 http://host3:9000/minio/data2 http://host3:9000/minio/data3 http://host3:9000/minio/data4 http://host4:9000/minio/data1 http://host4:9000/minio/data2 http://host4:9000/minio/data3 http://host4:9000/minio/data4

minio同样会自动将这些disk drive划分为若干个erasure coding set。每个endpoint用http://address/disk-drive-path的形式编码。注意:这条命令在host1、host2、host3和host4上都要执行

minio有一个zone的概念,比如下面这个例子:

$minio server data{1...8} data{9...16}

Formatting 1 zone, 1 set(s), 8 drives per set.
WARNING: Host local has more than 4 drives of set. A host failure will result in data becoming unavailable.
Formatting 2 zone, 1 set(s), 8 drives per set.
WARNING: Host local has more than 4 drives of set. A host failure will result in data becoming unavailable.
Status:         16 Online, 0 Offline.
Endpoint:  http://10.10.126.88:9000  http://127.0.0.1:9000
AccessKey: minioadmin
SecretKey: minioadmin

Browser Access:
   http://10.10.126.88:9000  http://127.0.0.1:9000           

Command-line Access: https://docs.min.io/docs/minio-client-quickstart-guide
   $ mc config host add myminio http://10.10.126.88:9000 minioadmin minioadmin

... ...

我们在命令行中给minio server传入两组采用“省略号”语法的参数,minio认为每组就是一个“zone”,这里有两组,因此minio创建了两个zone。在每个zone内,minio创建了一个erasure coding set,每个set中有8个disk drive。对于外部的写数据请求,minio server会首先查找可用空间多的zone,然后再在zone内选择set和disk drive。

如果不用“省略号”语法,那么minio server会将后面传入的所有disk drive放入一个zone中。

三. 原型验证环境搭建与配置

1. 单机上部署distributed minio集群

我们的验证环境采用最小的distributed minio模式:单机、one zone, one erasure coding set, 4 disk drive。下面是部署的示意图:

img{512x368}

图:单机上部署distributed minio集群

我们没有使用“省略号”语法,在单机上不是很好模拟。我们通过下面脚本来启动该minio集群:

# cat startup_minio.sh
#!/bin/bash

export MINIO_ACCESS_KEY="minio"
export MINIO_SECRET_KEY="minio123"

for i in {01..04}; do
    nohup minio server --address ":90${i}" http://127.0.0.1:9001/root/minio-install/data1 http://127.0.0.1:9002/root/minio-install/data2  http://127.0.0.1:9003/root/minio-install/data3 http://127.0.0.1:9004/root/minio-install/data4 > "/root/minio-install/90${i}.log"& 2>&1
done

启动该minio集群,并查看启动状态:

# bash startup_minio.sh

# ps -ef|grep minio

root      1218     1 11 21:58 pts/5    00:00:01 minio server --address :9001 http://127.0.0.1:9001/root/minio-install/data1 http://127.0.0.1:9002/root/minio-install/data2 http://127.0.0.1:9003/root/minio-install/data3 http://127.0.0.1:9004/root/minio-install/data4
root      1219     1 11 21:58 pts/5    00:00:01 minio server --address :9002 http://127.0.0.1:9001/root/minio-install/data1 http://127.0.0.1:9002/root/minio-install/data2 http://127.0.0.1:9003/root/minio-install/data3 http://127.0.0.1:9004/root/minio-install/data4
root      1220     1  3 21:58 pts/5    00:00:00 minio server --address :9003 http://127.0.0.1:9001/root/minio-install/data1 http://127.0.0.1:9002/root/minio-install/data2 http://127.0.0.1:9003/root/minio-install/data3 http://127.0.0.1:9004/root/minio-install/data4
root      1221     1 11 21:58 pts/5    00:00:01 minio server --address :9004 http://127.0.0.1:9001/root/minio-install/data1 http://127.0.0.1:9002/root/minio-install/data2 http://127.0.0.1:9003/root/minio-install/data3 http://127.0.0.1:9004/root/minio-install/data4

root@instance-cspzrq3u:~/minio-install# ls
9001.log  9002.log  9003.log  9004.log  data1  data2  data3  data4  startup_minio.sh
root@instance-cspzrq3u:~/minio-install# tail -100f 9001.log

Formatting 1 zone, 1 set(s), 4 drives per set.
Attempting encryption of all config, IAM users and policies on MinIO backend
Status:         4 Online, 0 Offline.
Endpoint:  http://192.168.16.4:9001  http://172.17.0.1:9001  http://172.18.0.1:9001  http://127.0.0.1:9001       

Browser Access:
   http://192.168.16.4:9001  http://172.17.0.1:9001  http://172.18.0.1:9001  http://127.0.0.1:9001       

.... ...

2. mc配置与管理

minio官方提供了mc命令行工具,用于对minio server进行管理。我们首先要为mc创建一个管理本地minio server(:9001)的配置:

# mc config host add myminio http://localhost:9001 minio minio123
Added `myminio` successfully.

这里我们使用mc添加了一个所谓”host”,指向上面创建的minio server(:9001)。上面的命令实质上是在~/.mc/config.json中写入了如下配置:

# cat ~/.mc/config.json
{
    "version": "9",
    "hosts": {
        "myminio": {
            "url": "http://localhost:9001",
            "accessKey": "minio",
            "secretKey": "minio123",
            "api": "s3v4",
            "lookup": "auto"
        }
    }
}

接下来,我们通过mc命令在minio集群中添加三个bucket:

root@instance-cspzrq3u:~# mc mb myminio/image
Bucket created successfully `myminio/image`.
root@instance-cspzrq3u:~# mc mb myminio/video
Bucket created successfully `myminio/video`.
root@instance-cspzrq3u:~# mc mb myminio/audio
Bucket created successfully `myminio/audio`.
root@instance-cspzrq3u:~# mc ls myminio
[2020-03-16 15:19:55 CST]      0B audio/
[2020-03-16 15:19:48 CST]      0B image/
[2020-03-16 15:19:52 CST]      0B video/

新创建的bucket默认的访问policy是none,即外部无访问权限:

root@instance-cspzrq3u:~# mc policy get myminio/image
Access permission for `myminio/image` is `none`

根据我们的设计,我们需要给这三个bucket添加外部可读取权限,以image这个bucket为例:

root@instance-cspzrq3u:~# mc policy set download myminio/image
Access permission for `myminio/image` is set to `download`
root@instance-cspzrq3u:~# mc policy get myminio/image
Access permission for `myminio/image` is `download`

3. load balancer设置

这里我们使用一个nginx前置在minio集群外部,下面是为minio创建的nginx配置文件(/etc/nginx/conf.d/minio.conf):

// /etc/nginx/conf.d/minio.conf

 upstream minio_cluster {
    server localhost:9001;
    server localhost:9002;
    server localhost:9003;
    server localhost:9004;
 }

server {
 listen 9000;
 server_name myminio.tonybai.com;

 # To allow special characters in headers
 ignore_invalid_headers off;
 # Allow any size file to be uploaded.
 # Set to a value such as 1000m; to restrict file size to a specific value
 client_max_body_size 0;
 # To disable buffering
 proxy_buffering off;

location / {

   proxy_set_header X-Real-IP $remote_addr;
   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
   proxy_set_header X-Forwarded-Proto $scheme;
   proxy_set_header Host $http_host;

   proxy_connect_timeout 300;
   # Default is HTTP/1, keepalive is only enabled in HTTP/1.1
   proxy_http_version 1.1;
   proxy_set_header Connection "";
   chunked_transfer_encoding off;

   proxy_pass http://minio_cluster;
}

location /image/ {
   proxy_set_header X-Real-IP $remote_addr;
   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
   proxy_set_header X-Forwarded-Proto $scheme;
   proxy_set_header Host $http_host;

   proxy_connect_timeout 300;
   # Default is HTTP/1, keepalive is only enabled in HTTP/1.1
   proxy_http_version 1.1;
   proxy_set_header Connection "";
   chunked_transfer_encoding off;
   client_max_body_size 1000m;
   proxy_buffering off;

   proxy_pass http://minio_cluster;
 }
}

重启nginx(nginx -s reload)。

我们使用浏览器访问一下http://myminio.tonybai.com:9000/,登录后,你将看到如下页面:

img{512x368}

图:浏览器访问minio web

选择左侧的”image” bucket,点击右下角的”+”号,我们可以上传一张图片:gopher-daily-logo.png,上传后,我们退出登录。然后通过地址http://myminio.tonybai.com:9000/image/gopher-daily-logo.png访问该图片。你也可以通过wget命令下载该图片:

$wget -c http://myminio.tonybai.com:9000/image/gopher-daily-logo.png
--2020-03-16 15:40:20--  http://myminio.tonybai.com:9000/image/gopher-daily-logo.png
正在解析主机 myminio.tonybai.com (myminio.tonybai.com)... 106.12.69.83
正在连接 myminio.tonybai.com (myminio.tonybai.com)|106.12.69.83|:9000... 已连接。
已发出 HTTP 请求,正在等待回应... 200 OK
长度:59736 (58K) [image/png]
正在保存至: “gopher-daily-logo.png”

gopher-daily-logo.png        100%[============================================>]  58.34K   253KB/s  用时 0.2s   

2020-03-16 15:40:20 (253 KB/s) - 已保存 “gopher-daily-logo.png” [59736/59736])

4. 对象清除

我们的需求中,bucket中的数据对象的生命周期是7天,我们可以使用定时工具或一个job通过mc工具对这些过期对象进行清除,比如我们每隔5分钟执行一次下面的命令:

$mc rm --recursive --force --newer-than 7d myminio/image/

该命令将递归删除image bucket下早于7天前创建的数据对象。rm命令支持各种条件组合,具体可参考一下mc rm的manual。

四. 小结

至此,使用minio搭建高性能对象存储的第一步:原型算是顺利搭建ok了。相信在后续对minio的深入使用和了解后,会有更多关于minio的内容和大家分享。


我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://tonybai.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

构建Kubernetes集群 – 选择工作节点大小

近期learnk8s网站上发布了一些关于k8s的好文章,这里搬运并翻译了一些,供大家参考。

本文翻译自《Architecting Kubernetes clusters — choosing a worker node size》

img{512x368}

当您创建Kubernetes集群时,冒出的第一个问题之一是:“我应该使用哪种类型的工作节点以及需要多少个这样的节点”。

如果您正在构建在内部部署的k8s集群,是应该订购一些最近一代的新服务器,还是使用数据中心内的十几台旧机器?

或者,如果您使用Google Kubernetes Engine(GKE)等托管Kubernetes服务,您是否应该使用八个n1-standard-1或两个n1-standard-4实例来实现所需的计算能力呢?

集群容量

通常,Kubernetes集群可以被视为将一组单个节点抽象为一个大的“超级节点”。

该超级节点的总计算容量(就CPU和内存而言)是所有组成节点容量的总和。

有多种方法可以实现集群的所需目标容量。

例如,假设您需要一个总容量为8个CPU内核和32 GB RAM的集群。

例如,因为要在集群上运行的应用程序集需要如此数量的资源。

以下是设计集群的两种可能方法:

img{512x368}

这两个选项都会产生具有相同容量的集群 – 但左侧选项使用4个较小的节点,而右侧选项使用2个较大的节点。

哪个更好?

为了解决这个问题,让我们来看看“少数大节点”和“许多小节点”这两个相反方向思路的优缺点。

请注意,本文中的“节点”始终指的是工作节点(worker node)。master节点的数量和大小的选择是完全不同的话题。

使用少量大节点

这方面最极端的情况是仅使用一个可以提供整个所需集群容量的工作节点。

如果要满足上面的示例中容量的需求,这将是一个具有16个CPU内核和16 GB RAM的单个工作节点。

让我们来看看这种方法可能具有的优势。

1. 减少管理成本

简单地说,管理少量机器比管理大量机器要更省力。

更新和补丁可以更快地应用,机器可以更容易保持同步。

此外,对于机器数量少而言,预期故障的绝对数量要小于机器数量多的情况。

但请注意,这主要适用于裸机服务器而不适用于云实例。

如果您使用云实例(作为托管Kubernetes服务的一部分或您在云基础架构上安装的Kubernetes),则将底层机器的管理外包给云提供商。

因此,管理云中的10个节点并不比管理云中的单个节点成本多得多。

2. 每个节点的成本更低

虽然更强大的机器比低端机器更昂贵,但价格上涨不一定是线性的。

换句话说,具有10个CPU内核和10 GB RAM的单台机器可能比具有1个CPU内核和1 GB RAM的10台机器便宜。

但请注意,如果您使用云实例,这可能同样不适用。

在主要云提供商Amazon Web Services,Google Cloud Platform和Microsoft Azure的当前定价方案中,实例价格是随容量线性增加的。

例如,在Google Cloud Platform上,64个n1-standard-1实例的成本与单个n1-standard-64实例完全相同- 两个选项都为您提供64个CPU内核和240 GB内存。

因此,在云中,您通常无法通过使用更大的机器来节省成本。

3. 允许运行资源消耗较大的应用程序

拥有大型节点可能只是您要在集群中运行一类应用程序的要求。

例如,如果您有一台需要8 GB内存的机器学习应用程序,你无法在仅具有1 GB内存的节点的集群上运行它。

但是,您可以在具有10 GB内存节点的群集上运行它。

看过优势后,让我们再来看看其弊端又是什么。

1. 每个节点有大量的pod

在较少的节点上运行相同的工作负载自然意味着在每个节点上运行更多的pod。

这可能成为一个问题。

原因是每个pod都会在节点上运行的Kubernetes代理上引入一些开销 – 例如容器运行时(例如Docker),kubelet和cAdvisor。

例如,kubelet对节点上的每个容器执行常规活动和就绪探测 – 更多容器意味着在每次迭代中kubelet需要做更多的工作。

cAdvisor收集节点上所有容器的资源使用统计信息,并且kubelet定期查询此信息并通过其API发布它 – 再次,这意味着每次迭代中cAdvisor和kubelet的工作量都会增加。

如果pod的数量变大,这些东西可能会开始减慢系统速度,甚至使系统变得不可靠。

img{512x368}

issue称节点因常规的kubelet运行状况检查花费了太长时间来迭代节点上的所有容器而导致节点处于非就绪状态。

出于这些原因,Kubernetes 建议每个节点最多110个pod

针对这个数字,Kubernetes已经做过测试,结果证明是可以在通常节点类型上可靠地工作的。

根据节点的性能,您可能能够成功地为每个节点运行更多的pod – 但这依然很难预测事情是否会顺利运行,又或您将遇到问题。

大多数托管Kubernetes服务甚至对每个节点的pod数量施加了严格的限制:

  • 在Amazon Elastic Kubernetes Service(EKS)上,每个节点的最大pod数取决于节点类型,范围从4到737。
  • 在Google Kubernetes Engine(GKE)上,无论节点类型如何,每个节点的限制为100个pod。
  • 在Azure Kubernetes服务(AKS)上,默认限制是每个节点30个pod,但最多可以增加到250个。

因此,如果您计划为每个节点运行大量pod,则应该事先测试事情是否能按预期工作。

2. 有限的复制

少量节点可能会限制应用程序的有效复制程度。

例如,如果您有一个由5个副本组成的高可用性应用程序,但您只有2个节点,那么应用程序的有效复制程度将减少到2。

这是因为5个副本只能分布在2个节点上,如果其中一个失败,它可能会同时删除多个副本。

另一方面,如果您有至少5个节点,则理想情况下每个副本可以在单独的节点上运行,并且单个节点的故障最多只会删除一个副本。

因此,如果您具有高可用性要求,则可能需要对集群中的最小节点数提出要求。

3. 更大的爆破半径

如果您只有几个节点,那么失败节点的影响比您有许多节点的影响要大。

例如,如果您只有两个节点,并且其中一个节点出现故障,那么大约一半的节点会消失。

Kubernetes可以将失败节点的工作负载重新安排到其他节点。

但是,如果您只有几个节点,则风险更高,因为剩余节点上没有足够的备用容量来容纳故障节点的所有工作负载。

结果是,部分应用程序将永久停机,直到再次启动故障节点。

因此,如果您想减少硬件故障的影响,您可能希望选择更多的节点。

4. 大比例增量

Kubernetes 为云基础架构提供了一个Cluster Autoscaler,允许根据当前需求自动添加或删除节点。

如果使用大型节点,则会有大的缩放增量,这会使缩放更加笨重。

例如,如果您只有2个节点,则添加其他节点意味着将群集容量增加50%。

这可能比您实际需要的多得多,这意味着您需要为未使用的资源付费。

因此,如果您计划使用集群自动缩放,则较小的节点允许更流畅且经济高效的缩放行为。

在讨论了使用”很少几个大节点”的方案的优缺点之后,让我们转向”许多小节点”的场景。

使用大量小节点

这种方法包括从许多小节点而不是几个大节点中形成集群。

这种方法的优点和缺点是什么?

使用许多小节点的优点主要对应于使用少量大节点的缺点。

1. 较小的爆破半径

如果您有更多节点,则每个节点上的pod自然会更少。

例如,如果您有100个pod和10个节点,则每个节点平均只包含10个pod。

因此,如果其中一个节点发生故障,则影响仅限于总工作负载的较小比例。

有可能只有一些应用程序受到影响,并且可能只有少量副本,因此整个应用程序都会保持运行状态。

此外,剩余节点上的备用资源很可能足以容纳故障节点的工作负载,因此Kubernetes可以重新安排所有pod,并且您的应用程序可以相对快速地返回到完全正常运行的状态。

2. 允许高可复制性

如果您有高可用性需求的应用程序和足够的可用节点,Kubernetes调度程序可以将每个副本分配给不同的节点。

您可以通过节点亲缘关系pod亲和力/反亲和力以及taint和tolerations来影响调度程序对pod放置位置的选择。

这意味着如果某个节点出现故障,则最多只有一个副本受影响且您的应用程序仍然可用。

看到使用许多小节点的优点,那它有什么缺点呢?

1. 节点数量大

如果使用容量较小的节点,则自然需要更多节点来实现给定的集群容量。

但是大量节点对Kubernetes控制平面来说可能是一个挑战。

例如,每个节点都需要能够与每个其他节点通信,这使得可能的通信路径数量以节点数量的平方的量级增长 – 所有节点都必须由控制平面管理。

Kubernetes控制器管理器中的节点控制器定期遍历集群中的所有节点以运行运行状况检查 – 更多节点意味着节点控制器的负载更多。

更多节点意味着etcd数据库上的负载也更多 – 每个kubelet和kube-proxy都会导致etcd的观察者(watch)客户端(通过API服务器),etcd必须广播对象更新。

通常,每个工作节点都会给主节点上的系统组件增加一些开销。

img{512x368}

据官方统计,Kubernetes声称支持最多5000个节点的集群

然而,在实践中,500个节点可能已经构成了较大的挑战

通过使用性能更高的主节点,可以减轻大量工作节点的影响。

这就是在实践中所做的 – 这里是kube-up在云基础架构上使用的主节点大小

  • Google云端平台
    • 5个工作节点→ n1-standard-1主节点
    • 500个工作节点→ n1-standard-32主节点
  • 亚马逊网络服务
    • 5个工作节点→ m3.medium主节点
    • 500个工作节点→ c4.8xlarge主节点

如您所见,对于500个工作节点,使用的主节点分别具有32和36个CPU核心以及120 GB和60 GB内存。

这些都是相当大的机器!

因此,如果您打算使用大量小节点,则需要记住两件事:

  • 您拥有的工作节点越多,您需要的性能就越高
  • 如果您计划使用超过500个节点,则可能会遇到一些需要付出一些努力才能解决的性能瓶颈

Virtual Kubelet这样的新项目允许绕过这些限制,并允许具有大量工作节点的集群。

2. 更多系统开销

Kubernetes在每个工作节点上运行一组系统守护进程 – 包括容器运行时(例如Docker),kube-proxy和包含cAdvisor的kubelet。

cAdvisor包含在kubelet二进制文件中。

所有这些守护进程一起消耗固定数量的资源。

如果使用许多小节点,则这些系统组件使用的资源部分比例会更大。

例如,假设单个节点的所有系统守护程序一起使用0.1个CPU内核和0.1 GB内存。

如果您拥有10个CPU核心和10 GB内存的单个节点,那么守护程序将占用集群容量的1%。

另一方面,如果您有1个CPU核心和1 GB内存的10个节点,则后台程序将占用集群容量的10%。

因此,在第二种情况下,10%的账单用于运行系统,而在第一种情况下,它只有1%。

因此,如果您希望最大化基础架构支出的回报,那么您可能更喜欢更少的节点。

3. 降低资源利用率

如果您使用较小的节点,那么最终可能会有大量资源片段太小而无法分配给任何工作负载,因此保持未使用状态。

例如,假设您的所有pod都需要0.75 GB的内存。

如果你有10个1 GB内存的节点,那么你可以运行10个这些pod – 你最终会在每个节点上有一块0.25 GB的内存,你不能再使用它了。

这意味着,集群总内存的25%被浪费了。

另一方面,如果您使用具有10 GB内存的单个节点,那么您可以运行13个这样的pod – 而只有0.25 GB的单块内存剩下无法使用。

在这种情况下,您只会浪费2.5%的内存。

因此,如果您想最大限度地减少资源浪费,使用更大的节点可能会提供更好的结果。

4. 小节点上的Pod限制

在某些云基础架构上,小节点上允许的最大pod数量比您预期的要限制得多。

Amazon Elastic Kubernetes Service(EKS)就是这种情况,其中每个节点的最大pod数取决于实例类型。

例如,对于一个t2.medium实例,pod的最大数量是17,因为t2.small它是11,而t2.micro它是4。

这些都是非常小的数字!

任何超出这些限制的pod都无法由Kubernetes调度程序安排,这些pod会一直保持在Pending状态。

如果您不了解这些限制,则可能导致难以发现的错误。

因此,如果您计划在Amazon EKS上使用小节点,请检查相应的每节点pods数,并多算几次计算节点是否可以容纳所有pod。

结论

那么,您应该在集群中使用少量大型节点还是许多小型节点?

一如既往,没有明确的答案。

您要部署到集群的应用程序类型可能会指导您的决策。

例如,如果您的应用程序需要10 GB内存,则可能不应使用小节点 – 集群中的节点应至少具有10 GB内存。

或者,如果您的应用程序需要10倍的复制性以实现高可用性,那么您可能不应该只使用2个节点 – 您的集群应该至少有10个节点。

对于中间的所有场景,它取决于您的具体要求。

以上哪项优缺点与您相关?哪个不是?

话虽如此,没有规则规定所有节点必须具有相同的大小。

没有什么能阻止您在集群中使用不同大小节点混合在一起的方案。

Kubernetes集群的工作节点可以是完全异构的。

这可能会让您权衡两种方法的优缺点。

最后,证明布丁好坏就在于吃 – 最好的方法是试验并找到最适合你的组合!


我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://tonybai.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats