K8S实践 - Promethues从VM迁移K8S实录-低调大师

K8S实践 - Promethues从VM迁移K8S实录

2019-07-08 953

背景

公司落地容器化及Kubernetes，既有的监控部署在虚拟机上，需要迁移到K8S集群中来缩减虚拟机的开销，我们基于Prometheus的监控系统搭建近一年，保存数据周期为180填，目前的数据量在800GB左右，下面讲述的是我们的迁移方案及迁移过程。

方案

1. Kubernetes集群内

创建好存储，PV，PVC
创建好StatefulSet，Service等
在K8S内拉起Prometheus+Grafana
测试验证，验证通过后kubectl delete删除相关的实例，保留好yaml

2. 旧Prometheus及Grafana实例上

将K8S集群内刚刚验证好的那块盘挂载到待迁移数据机器实例上
迁移数据
修改数据所属组及权限
卸载新盘

3. Kubernetes集群内

再次部署预定义好并经过测试的yaml
观察，测试
切换Grafana数据源，指向K8S中的Prometheus

实施过程

K8S集群内拉起新Prometheus

 kubectl logs prometheus-ecs-0 -n monitoring
...
level=info ts=2019-07-08T04:14:50.715Z caller=main.go:714 msg="Notifier manager stopped"
level=info ts=2019-07-08T04:14:50.715Z caller=main.go:544 msg="Scrape manager stopped"
level=error ts=2019-07-08T04:14:50.715Z caller=main.go:723 err="opening storage failed: mkdir data/: permission denied"

权限问题报错了，增加securityContext相关描述，再试，此处参考Google-Groups或者Github Issue

kind: StatefulSet
metadata:
  name: prometheus-ecs
  namespace: monitoring
spec:
  serviceName: "prometheus-ecs"
  selector:
    matchLabels:
      app: prometheus-ecs
  template:
    metadata:
      labels:
        app: prometheus-ecs
    spec:
      ...
      securityContext:
        runAsUser: 1000
        fsGroup: 2000
        runAsNonRoot: true
      ...

增加描述后重新拉起POD，数据能够正常生成了，看下面的data文件夹

/prometheus $ ls -l
total 5242908
drwxr-sr-x    3 1000     2000          4096 Jul  8 04:26 data
drwxrwsr-x    4 root     2000          4096 Jul  8 04:09 k8s-resource-monitoring
drwxrwS---    2 root     2000         16384 Jul  8 02:37 lost+found

接下来我们kubectl delete删除刚刚创建的所有对象，把yaml准备好，然后把磁盘挂载到计划迁移的机器上，同步数据。

将磁盘挂载到旧Prometheus机器上

挂载创建的目标磁盘到旧Prometheus的虚拟机上，然后用rsync将数据追平，注意用--bwlimit控制速度，不然可能会导致磁盘打满影响线上性能，我们是SSD盘所以指定200M依然剩余100M的速度空间保证线上使用。

rsync -av --bwlimit=200M --delete --progress --log-file=/tmp/rsync.log /data/coohua/prometheus/data /data1/data

确认迁移过程中系统稳定，各项参数正常

# dstat -a
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw 
 28   0  72   0   0   0| 652k  666k|   0     0 |   0     0 |1953  1401 
 37   4  54   5   0   0| 141M  237M| 344k 5408B|   0     0 |6918  5466 
 39   6  47   9   0   0| 205M  293M|  17k 3006B|   0     0 |7477  5874 
 48   6  38   8   0   0| 201M  306M| 959k   10k|   0     0 |8001  5705 
 50   5  45   0   0   0| 187M   12M|  83k 3531B|   0     0 |7589  5135 
 41   6  50   3   0   0| 204M  113M| 360k   11k|   0     0 |9505  8630 
 38   5  47   9   0   1| 177M  204M|  84k 1468B|   0     0 |8268  7147 
 71   5  20   4   0   0| 147M  308M| 131k 4766B|   0     0 |8334  5281 
 94   4   2   0   0   0| 132M  301M| 180k 4392B|   0     0 |9274  5789 
 46   5  48   0   0   0| 210M   42M| 393k 5334B|   0     0 |7928  6030 
 40   5  55   0   0   0| 190M    0 | 361k   16k|   0     0 |6994  5119 
 28   5  58   9   0   0| 156M  228M|  80k 3554B|   0     0 |5414  4121 

# top
top - 14:21:03 up 186 days, 23:07,  2 users,  load average: 6.36, 5.54, 5.07
Tasks: 144 total,   4 running, 140 sleeping,   0 stopped,   0 zombie
%Cpu0  : 85.0 us,  0.0 sy,  0.0 ni, 15.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  : 29.1 us,  1.0 sy,  0.0 ni, 61.6 id,  7.9 wa,  0.0 hi,  0.3 si,  0.0 st
%Cpu2  : 27.1 us,  3.3 sy,  0.0 ni, 69.6 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  : 66.3 us,  1.7 sy,  0.0 ni, 29.0 id,  3.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu4  : 37.3 us, 11.0 sy,  0.0 ni, 51.0 id,  0.7 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu5  : 31.8 us,  8.4 sy,  0.0 ni, 54.2 id,  5.7 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu6  : 61.8 us,  3.0 sy,  0.0 ni, 34.6 id,  0.7 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu7  : 31.5 us, 12.2 sy,  0.0 ni, 46.1 id, 10.2 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 16267428 total,   160392 free,  7907888 used,  8199148 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  7989000 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                                                                   
 4903 coohua    20   0  0.682t 7.784g 817072 S 279.7 50.2  62469:47 prometheus                                                                                                                                                                
20712 root      20   0  129656   1180    332 R  62.1  0.0   2:10.42 rsync                                                                                                                                                                     
20710 root      20   0  129696   2348   1232 R  56.1  0.0   1:53.88 rsync                                                                                                                                                                     
   61 root      20   0       0      0      0 S   6.6  0.0 110:21.78 kswapd0    

# iostat -xdm 1
Linux 3.10.0-514.26.2.el7.x86_64 (monitor-storage001)     2019年07月08日     _x86_64_    (8 CPU)

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.64    0.06    1.33     0.00     0.01    17.52     0.01    7.71   23.99    6.95   0.86   0.12
vdb               0.01     0.36    4.11    1.88     0.67     0.64   446.97     0.04    7.46   10.11    1.67   1.35   0.81
vdc               0.00     0.00    0.00    0.08     0.00     0.04   959.25     0.01  179.72   32.19  179.79   1.54   0.01

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
vdb               0.00     2.00  359.00    2.00   160.00     0.02   907.79     3.16    8.33    8.37    1.00   1.34  48.50
vdc               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
vdb               1.00     0.00  470.00    8.00   208.55     3.44   908.30     4.50    9.82    9.48   30.00   1.31  62.40
vdc               0.00     8.00    0.00  409.00     0.00   190.92   955.99    68.50  154.77    0.00  154.77   1.47  60.30

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     4.00    0.00    2.00     0.00     0.02    24.00     0.00    0.50    0.00    0.50   0.50   0.10
vdb               0.00     0.00  457.00    0.00   202.09     0.00   905.65     4.32    9.48    9.48    0.00   1.33  61.00
vdc               0.00     0.00    0.00  640.00     0.00   300.49   961.58   127.32  194.03    0.00  194.03   1.56 100.10

坐等数据同步完毕

磁盘再次挂载到POD中使用迁移过来的数据

数据迁移完成了，查看迁移过程中磁盘的读写情况，由于我们限速为200MiB，所以情况如预期

注意修改数据权限，要不然到时候POD又起不来

# umount -l /data1
# chown -R 1000:2000 /data1/data

PV/PVC没删干净会出现下面的问题，PV处于Released状态不能再次使用

kubectl get pvc -n monitoring pv-metrics-ecs-promethues
NAME                        STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
pv-metrics-ecs-promethues   Pending   

kubectl get pv -n monitoring pv-metrics-ecs-promethues 
NAME                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS     CLAIM                                  STORAGECLASS   REASON   AGE
pv-metrics-ecs-promethues   1Ti        RWX            Retain           Released   monitoring/pv-metrics-ecs-promethues   disk                    3h32m

简单粗暴的删除PV/PVC重建即可
然后在Kubernetes内启动原来准备好的StatefulSet即可，就会直接用迁移后的数据了，然后创建NodePort类型的Service，用来让还没迁移进K8S的Grafana连接
接下来修改Grafana的数据源，指向迁移后的Prometheus，大功告成，迁移过程中断服务丢失的数据<10分钟

总结 & 思考

不完美的方案，但是简单可行

数据同步完成后然后在K8S中拉起POD，POD初始化后Prometheus需要处理数据，然后开始拉新数据，这个过程中中断的时间可能要10至15分钟，也就是说最少要丢失10至15分钟的监控数据，这个我们从业务上衡量是可以接受的，找一个合适的时间操作即可。
有完美的方案吗？
官方社区Prometheus的Developer提到的方案是，起一个新的实例跑同样的配置，等到足够长的时间，旧的自然就退休了，这个可能是最完美的方案，但是在我们的场景，我们数据保存180天将近1T的数据，而且使用SSD作为存储，这个退休的时间内我们的硬件成本是双倍的，从经济上考虑，我们还是否定了这个方案。

慎用NFS为存储的PV

第一次尝试迁移使用了NFS，因为云提供商的特性，NFS较为经济，而且可以多处挂载，数据的管理也是十分的便利，但是迁移过来后测试发现，一个大的查询就差点把网卡跑满，load瞬间爆炸，赶紧下线。所以在重IO的场景，真的慎重考虑NFS，一定要做好性能评估。

微信关注我们

原文链接：https://yq.aliyun.com/articles/708186

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

【产品功能】创建实例支持同时加入多个安全组

背景：长期以来，创建ECS实例只支持同时加入一个安全组，但是某些友商支持多个安全组，这会增加混合云用户上云成本，比如基于Terraform的国际站用户想迁移到阿里云就要修改大量代码。为此ECS提供了创建实例同时加入多个安全组的功能，此功能一方面可以让上述用户最小成本使用阿里云，另外一方面也降低实例加入多个安全组的复杂度，可以方便的随实例创建同时加入多个安全组。如何使用 1. RunInstances新增参数名称类型是否必填描述 SecurityGroupIds.N List<String> 否传入多个随实例创建加入的安全组 2. ECS控制台开发中，敬请期待限制批量的安全组必须属于同一个VPC，并且与vSwitch属于一个VPC。不能既有普通组又有企业安全组。多安全组功能不支持CLASSIC类型实例。 SecurityGroupI

2019-07-08

692

简介 MySQL原本是一个开放源码的关系数据库管理系统，原开发者为瑞典的MySQL AB公司，该公司于2008年被昇阳微系统（Sun Microsystems）收购。2009年，甲骨文公司（Oracle）收购昇阳微系统公司，MySQL成为Oracle旗下产品。安装今天我们介绍一种更快速的安装方法，那就是通过URLOS一键安装MySQL。urlos是什么？ URLOS是一个云主机管理软件，基于Docker容器技术打包和运行应用，包含负载均衡和故障转移等高级功能，可自动识别机器和云应用的故障并将云应用转移至可用的机器上，单机故障并不影响业务开展。你可以使用以下命令安装URLOS： curl -LO www.urlos.com/iu && sh iu 在此不讨论URLOS的使用方法，感兴趣的朋友请自行搜索，我们直接来看URLOS如何快速安装MySQL。登录URLOS系统后台，在应用市场中搜索“MySQL”，找到之后，直接点击安装按钮：安装流程如下： 1. 填写服务名称、选择运行节点、选择智能部署 1）这里需要注意的是服务端口是选填的，这是对外网开放的端口。 2）默认...

2019-07-09

586

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。