BA工作坊之需求采集.pptVIP

YeahMobi中基于容器技术的运维自动化实践 Infrastructure Department Manager Chieh Chu（朱杰） Agenda 面对的问题 解决问题的思路 Yeah-PaaS平台实践 面对的问题 快速交付 服务自动化 资源多样性 快速交付 线上线下环境不一致 持续交付集成困难 快速启动 上线时服务可能中断 自动化部署 多种策略的灰度发布 出错回滚 服务依赖 服务发现 资源与应用不同级别的服务感知 服务高可用 服务需可扩展 跨Region部署 线上操作多样化 可消费资源分配问题 公共配置变更 数据库变更 不同业务间资源不共享 第三方服务 问题解决思路 容器化环境 Leveraging Docker technical 解决快速交付问题 封装 快速 轻量 版本化管理 问题解决思路 服务管理 Leveraging Kubernetes technical 解决容器化部署问题 线上容器化资源池 ReplicationController解决服务高可用 Service解决服务发现以及负载均衡 Instance lifecycle 管理 问题解决思路 服务编排 Leveraging Openstack Heat technical 解决面向应用的部署以及多样化问题 服务编排 依赖 灰度 回滚 可自定义服务类型 配置更改 数据库 第三方服务 驱动容器化部署（K8s） 整体构架简图 Docker Kubernetes 3rd Services Others K8s python API Sub-System App A App B Service A 应用举例 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 （配置文件来指定） 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：Jun