YeahMobi中基于容器技术的运维自动化实践 Infrastructure Department Manager Chieh Chu（朱杰）

Agenda 面对的问题 解决问题的思路 Yeah-PaaS平台实践

面对的问题 快速交付 服务自动化 资源多样性 快速交付：互联网公司往往是轻测试重交付，需要快速试错来改进与提高产品质量，如何做到快速的交付产品做到唯快不破就成为首要解决的问题。包括：环境一致性，持续交付集成，快速启动，无服务中断 服务自动化：灰度发布,回滚,服务依赖,服务发现(统一对外endpoint,readiness),高可用,服务可扩展,Multi-Regions等 资源多样：可消费资源，公共配置变更，数据库，不同项目资源的反亲和性，第三方服务等

快速交付 线上线下环境不一致 持续交付集成困难 快速启动 上线时服务可能中断

自动化部署 多种策略的灰度发布 出错回滚 服务依赖 服务发现 资源与应用不同级别的服务感知 服务高可用 服务需可扩展 跨Region部署

线上操作多样化 可消费资源分配问题 公共配置变更 数据库变更 不同业务间资源不共享 第三方服务

问题解决思路 容器化环境 Leveraging Docker technical 解决快速交付问题 封装 快速 轻量 版本化管理

问题解决思路 服务管理 Leveraging Kubernetes technical 解决容器化部署问题 线上容器化资源池 ReplicationController解决服务高可用 Service解决服务发现以及负载均衡 Instance lifecycle 管理 Readiness（用于保留现场）, Liveness（目前无restart limit）, PreStop, PostStart

问题解决思路 服务编排 Leveraging Openstack Heat technical 解决面向应用的部署以及多样化问题 依赖 灰度 回滚 可自定义服务类型 配置更改 数据库 第三方服务 驱动容器化部署（K8s）

整体构架简图 App A App B Service A K8s plugin Other plugins Openstack Heat K8s python API 3rd Services Others Sub-System Kubernetes Docker AWS Region1 IaaS AWS Region2 RS Region1 SL Region1 Ali Region1

应用举例 Facebook广告发布系统 内部组件间需要服务发现 组件间存在生产与消费关系，服务启动，撤销存在组件依赖 某些比较heavy的组件（生产者）启动会较耗时，这时需要保证存在依赖的服务需等该服务ready后方可部署 组件下线时，已调度的作业需执行完操作后方可结束，同时该组件不应再接受新的作业 Facebook客户级别导致的广告发布限制，导致无法进行A|B灰度 相同环境线下测试时需要自动接入Facebook的Mock API service

Docker的配置 Version: 1.6.2 用于设置Labels，类似于set metadata K8s依赖这一特性：preStop, postStart, readiness Flannel: 0.3.0 配置：同K8s共用etcd 部署相对简单 同属CoreOS 评测性能小幅下降：TCP bandwidth 约10% drop

高可用 Private Docker Hub

Kubernetes的配置 Version：Self complied 0.19.1(RC) + bug fix One container per Pod Admin setting Resource quota Total amount for namespace: kmem, cpu, # of pod/rc Limits：The limit of all Pods within the specific namespace-wide App Setting Resource limits 针对pod的mem, cpu （配置文件来指定） bug fix: Readiness失败会引起container重启

Kubernetes的配置

Kubernetes的配置 需要考虑资源与业务间的服务发现级联问题 （leverage instance lifecycle） preStop Usecase：Graceful delete, 保证正在执行的任务完成，并不会接受新的请求，或服务主动从服务发现中清除。 postStart Usecase：识别并接入Facebook API mock Readiness 服务状态监控 组件间依赖，用于配合Heat的dependence实现类似waitcondition的功能 Liveness 类似Readiness，不过false时会重启container

Kubernetes的配置 安全设置 API SSL enable, token 认证，统一出口由Heat控制 Unique namespace for one product 使用的调度策略 ServiceSpread：尝试避免同构的Pod被schedule在相同的minions Packing：尝试保证相同product的Pod被schedule在一起 Anti-affinity：保证不同的product不会被schedule在相同的minions LabelSpread（计划中）：保证相同属性的Pod不会被schedule在一起，i.e.：CPU/Mem/IO intensive

Heat相关改动 Version：Juno release 重写K8s 全功能Python API 增加K8s resource types GoogleInc::Kubernetes::ReplicationController GoogleInc::Kubernetes::Service (Others: Scripts, DB related etc) 为每一个resource type实现下列接口 handle_create, check_create_complete handle_update, check_update_complete handle_delete, check_delete_complete

Heat相关改动 GoogleInc::Kubernetes::ReplicationController GoogleInc::Kubernetes::Service

监控相关事项 Kubernetes 自身的页面 现有Pod，RC的信息等 cAdvisor实时数据 Heapster基于cAdvisor 加入告警项 Host level – zabbix Container – cAdveriser数据导出从而被zabbix监控

监控相关事项 目前接入 Zabbix ，支持自动化告警的监控项主要有： Host 告警 Ping 、 CPU 、 Memory 、 Disk 进程监控 etcd kube-apiserver/kube-scheduler/kube-controller-manager/kubelet/kube-proxy flanneld/docker heat-engine/heat-api 服务端口监控 PaaS 服务： kubernetes/heat/etcd Docker Hub 服务： registry/registry-ui/registry-proxy/heapster/influxdb

监控相关事项

Troubleshooting pod状态长期处于pending状态 kube-scheduler调度延时；kubelet启动延时；etcd bug引起，升级etcd v2.0.5 -> v2.0.9解决 inode被耗光，主要消耗在/var/lib/docker/aufs crontab定时清除以下内容: 需要清除docker registry 清除docker images 清除已死docker container # remove exited container. docker ps -a|grep Exit|cut -d' ' -f 1|xargs docker rm # remove images as possible that has no name/tag docker images -a|grep '^<none>'|tr -s ' '|cut -d' ' -f 3|xargs docker rmi

Troubleshooting 删除namespace的结果 namespace下的RC被删除，所有Pod会变成pending状态，docker container正常 将该namespace重新创建之后，Pod会变成running的正常态，但RC不再了 kube 0.18.0指定memory limit创建Pod失败 可能是docker不支持swap memlimit导致，需要打开grub开关

About me 朱杰 Email: chieh.chu@Hotmail.com