彭哲夫-容器调度编排系统在芒果TV的实践

•毕业于武汉拖(li)拉(gong)机大学•就职于金山办公软件公司写了个金山快盘•跳到豆瓣写了豆瓣的AppEngine•中途一个人重走了丝绸之路南线穿越了亚洲TV间的地•现在在ENJOYApp负责平台基础设施开发•运维和开发•容器不是银弹•调度和编排•开发部署范式•坑•运维关注更加基础性的设施•监控/报警/CMDB/LDAP•针对容器特性进行一定量的定制开发•物理基础如服务器/网络/交换机等•纯粹的体力活意义不是很大了•开发模式的改变•更稳健的运行•更快速的失败•如何保证SLA•状态是永远绕不开的坎•一劳永逸是不现实的•运维依然很重要但会更纯粹•开发依然要处理业务细节•Docker本身自己问题不少•镜像生成和分发•容器整体状态的一致性处理•服务注册和发现•Swarm/Mesos/K8S•勇士在没杀掉巨龙之前就已经成为新的巨龙了•作为企业真的需要「一套」方案么•二次开发成本•资源的维度•CPU•内存•网络•IO•CPU•按核分配,比例核的重要性•抹平机器间差异•过细颗粒度分配没太多必要•网络•Flannel/Weave/dockeroverlay•路由方案•Calico/Macvlantcp_bwtcp_lattcp_lattcp_bwtcp_bwtcp_lattcp_lattcp_bwhostflannel(vxlan)flannel(udp)calico(bgp)calico(ipip)docker(overlay)weave(udp)hostflannel(vxlan)flannel(udp)calico(bgp)calico(ipip)docker(overlay)weave(udp)400MB/sec350MB/sec300MB/sec250MB/sec200MB/sec150MB/sec100MB/sec50MB/sec0MB/sec12481632641282565121024204840968192163843276865536ze4000us3500us3000us2500us2000us1500us1000us500us0us12481632641282565121024204840968192163843276865536zehostmacvlanhostmacvlan700us612.5us525us437.5us 350us262.5us 5us 87.5us0us12481632641282565121024204840968192163843276865536ze120MB/sec105MB/sec90MB/sec75MB/sec60MB/sec45MB/sec30MB/sec15MB/sec0MB/sec12481632641282565121024204840968192163843276865536ze•MacVlan秒天秒地然并卵在云上没法用•类似于ARP欺骗,有ARP风暴可能•Calico依托于BGP网络,需要单播支持•最终一致性•需要监控整体网络连接情况•Tunnel方案无外乎是CPU换时间•Pod是个很好的逻辑概念•抹平机房服务器之间的差异•提供热拔插的可能•资源池的必要性•内存旁路控制可以满足很大一部分需求•IO目前没特别好的方案去做限制•引入IO后的冷迁移•数据不动•数据动•镜像规则•基础镜像必须自行解决•安全•时区等细节问题•隐藏部署细节•对上层业务而言看到的是一组资源•统一部署方式•结合CI实现滚动上线•日志收集的方式•外部收集•用attach接