大厂容器云实践之路（四）

news2024/10/6 1:43:43

7-爱奇艺基于 Docker 的 App Engine 实践

背景

业务上

虚机承载的业务：

后台服务：25%

worker：20%

其他：55%

技术上

2014年第三季度

出发点

目标

道路曲折

用户受益

• 资源到位快
• 部署快（上线、升级）
• 扩容快
• 自动故障转移，免运维
• 完善的监控预警
• 持续集成、发布

iQIYI App Engine 设计与实现

iQIYI App Engine (QAE)

QAE — 监控和预警

QAE — 自动扩展（Auto Scaling）

QAE — 事件总线

QAE — 服务发现

QAE — 日志

QAE — CI/CD

一些经验（坑）

容器监控 — Zabbix

• 优势
• 已有 Zabbix 基础服务
• Auto Discovery 能发现容器启动/消失事件
• 劣势
• 需要在容器内部安装 zabbix, overhead 太大
• 不是很稳定
• 数据统计比较复杂

容器监控 — cAdvisor

• 优势
• 背靠 Google 且开源
• 监控数据详尽
• 劣势
• 集群化开发成本较高，Kubernetes heapster 实现
• influxDB 而非 graphite（当时有基础服务）

容器监控 — dAdvisor

• Docker Advisor
• 采集：CPU, 内存，磁盘，网络
• 集成现有 Graphite
• 统计数据方便（Graphite 内置一些操作符）
• 呈现方便（Graphite Render URL API）
• 开发量不大

Time Series Database — Graphite

• 优势
• 老牌（Since 1999），已有服务，经过验证
• 简单、内置 aggregator，Render URL API
• 劣势
• 项目及社区已经几乎停滞
• 集群化配置复杂，需要详细规划
• 缺乏多用户认证，授权机制，黑白名单太单薄
• 数据删除缺少 API

服务发现（Service Discovery）

• 负载均衡/反向代理方案
• HAProxy：Marathon 支持，用户少
• Nginx：大量用户
• 服务发现
• Flask 推送，SSH，不可靠，不安全
• Ansible 推送，SSH，不可靠，不安全
• event bus + guardro-template

日志

• ELK (Elasticsearch + Logstash + Kibana)
• 延时较高（分钟级）
• 只支持格式化后的日志（for machine）
• 用户诉求
• 低延时（秒级），准实时
• 裸日志（for real person）
• 备份日志（Apache Flume）

现状与展望

现状

• 处于活跃开发状态
• 接入了几十个业务
• 主要业务类型：服务型，RPC，Worker
• 服务型业务 QPS 大于 10 万
• 4 个数据中心

展望

• 支持短任务
• Quota 和计费
• Web Console
• 内置典型服务（如：Tomcat）数据统计
• Docker 持久化卷和跨主机通信
• 支持更多类型服务：Cache, DB, MQ 等

8-蘑菇街基于Docker的私有云实践

做私有云的原因

1、越来越多的机器，集群管理，基础平台的建设
2、提高资源的利用率
3、服务化，平台化，可视化
4、提升发布和部署的效率
5、实现业务的弹性，水平扩展

Docker的优势

1、轻量，秒级的启动速度
2、简单，易用，活跃的社区
3、标准统一的打包/部署/运行方案
4、镜像支持增量分发，易于部署
5、易于构建，良好的REST API，也很适合自动化测试和持续集成
6、性能，尤其是内存和IO的开销

简单易用

docker run -d
--net=none
--name=$name
-h $name
-v /var -v $tmpdir/resolv.conf:/etc/resolv.conf -v $tmpdir/hosts:/etc/
hosts
--cpuset="$cpuset"
-m ${mem}m
--privileged=true
$image

劣势

1、资源调度/集群管理还在春秋战国时期
2、隔离性-仅用cgroup/namespace够吗
3、网络/存储支持完善吗
4、不支持热迁移-CRIU
5、各种坑

Docker@蘑菇街

1、2014年圣诞节期间上线，OpenStack IceHouse + Docker1.3.2。经历过5次+大促，包括双11/双12，线上运行稳定。
2、Machine Container或“胖容器”，用supervisord管理容器中的多进程。
3、每个机房一个OpenStack集群，一个Docker Registry。每个集群可以同时管理KVM，Docker。
4、支持OpenvSwitch VLAN和Linux Bridge两种网络模式，不用Docker原生的NAT网络模式，other_args="--bridge=none"。
5、自研了基于OpenStack的PaaS平台，虚拟化交付系统，虚拟化管理控制台。

为什么都把Docker当成虚拟机

只有Docker是不够的

集群管理

逻辑架构图

nova-docker

• spawn: create -> start -> post_start docker
• 容器启动前做的事情：
• 根据ip段的规则来生成容器的hostname
• 动态添加ip:hostname映射到/etc/hosts
• 启动docker实例时指定CPU set/weight
• 自定义需要mount的folder/file volume
• 扩展OpenStack API，通过cgroup限制磁盘IO和网络IO
• 和Linux bridge/Openvswitch对接网络
• 实现快照方式的冷迁移
https://github.com/openstack/nova-docker/

监控

和已有监控系统的深度集成
实时监控和阈值报警：节点存活性/语义监控，关键进程，内核日志，实时pid数量，网络连接跟踪数，容器oom报警
阈值报警：短信报警，IM报警等多种形式
健康检查：部署环境/配置的一致性检查
container-tools:
参考内核算法实现容器内load值的计算
替换了uptime，top，free，df，类似docker stats。

Container-tools

• mount /cgroup 到容器内
• 容器启动时用docker exec创建一个文件记录每个容器使用的cpuset，实例uuid等信息
• 修改uptime，top，free，df，tsar等源码，读取 /cgroup下的cpu/memory/IO值信息
• 曾经尝试过lxcfs，但问题很多，限制也很多。

实时监控和报警

网络

• NAT-20% performance lost
• Host mode? No network isolation
• Linux bridge without iptables
• OVS VLAN without iptables
• other_args="—bridge=none"

容灾

• 离线恢复docker容器中的数据的能力
• Docker实例跨物理机的冷迁移：docker commit，docker push。
• 动态的CPUٖ内存扩容：cgroup。
• 网络IO/磁盘IO的限速: cgroup/tc。
http://mogu.io/127-127

PaaS

• 目标
• 快速的系统构建
• 业务的平滑部署升级
• 自动的运维管理
• 自研的轻量PaaS，实现编排能力
• 支持基于容器的持续集成：Jenkins+Docker，从编译到构建全自动化
• 概念
• App：一个应用包含一个或多个Stack
• Stack：相同的Docker实例，一个Stack中的不同实例尽量部署在不同的物理机上

Docker Registry

基于Docker的持续集成

基于PaaS的业务平台

遇到的坑

• devicemapper中thin-provisioning的discard功能引起的kernel crash

DOCKER_STORAGE_OPTIONS="--storage-opt dm.mountopt=nodiscard --storage-opt dm.blkdiscard=false"
http://mogu.io/docker_crash-79

隔离
• 物理机上无法执行命令操作。“bash: fork: Cannot allocate memory”
• 容器内如果创建大量的进程，并且不回收，是会导致系统内核的pid_max达到上限
• ٖ内核中的pid_max(/proc/sys/kernel/pid_max)是全局共享的
• Process Number Controller:
• 仅最新的4.3-rc1支持，pid-max per containers̶
• https://www.kernel.org/doc/Documentation/cgroups/pids.txt

• 容器内的内存值计算不准确，比实际低一个量级
• /cgroup/memory/docker/id/memory.usage_in_bytes