Kubernetes在AI平台的落地实践

中国电信翼支付一直致力于将容器及云原生技术在生产环境中落地，同时AI是目前互联网行业炙手可热的“明星”，无论是老牌巨头，还是流量新贵，都在大力研发AI技术，为自家的业务赋能，其中算法从调研到最终上线发挥作用，是需要有一系列的工程开发和对接的，由此引发了新的问题：如何界定算法和工程的边界，各司其职，各善其长？如何提升算法迭代上线的速度和效率？如何快速准确评估算法的效果？而如果要解决上述的机器学习问题，则需要有一个功能强大且易用的机器学习平台来辅助算法研发人员，因此我们将Kubernetes结合AI场景研发打造出了属于自己的AIPaas平台，在平台层实现了资源的动态申请、扩缩容、灰度发布、流量控制等诸多功能；Kubernetes作为云原生的核心，帮助传统企业解决了很多痛点，但也因此给企业带来了很多新的挑战，本文为大家分享翼支付大数据部在AI方向上落地实践Kubernetes过程中的一些经验和探索，希望可以帮助到大家。

简要介绍AI平台

概述

基于基础的机器学习和深度学习计算框架进行二次开发，提供一站式的生态化的服务，为用户提供从数据预处理、模型训练、特征工程、模型训练、模型部署、模型治理和模型在线预测的全流程开发和部署支持，以期降低业务人员、算法同学的使用门槛,提供端到端的一站式的服务，帮助他们脱离繁琐的工程化开发，把有限的精力聚焦于算法策略的迭代上面。

可视化建模

支持超大规模数据分布式机器学习，内置丰富的算法组件，支持从数据预处理，特征工程，模型训练到模型服务全流程零代码开发，极大的降低了机器学习算法的使用门槛。

自助建模

为算法开发者提供交互式的开发环境，包含经典机器学习和多种深度学习框架，高性能的、异构计算（CPU/GPU）引擎支持，弹性资源调度与资源使用情况的可视化监控等，极大的提高了AI应用的开发效率。

模型服务

通过在线模型服务功能可以将模型结果一键部署成Restful API，将生成的模型与用户自身业务打通。而离线模型服务功能可以将模型结果进行封装，用于创建离线调度任务。

AI应用

结合各类具体的业务场景（如合同识别、身份证识别、银行卡识别等），将主流的机器学习算法进行产品化，用户可以自主体验和使用，大大降低了AI应用的落地门槛。

背景介绍：为什么需要Kubernetes

大数据部在使用Kubernetes之前，所有应用采用的是传统IDC机房架构，依赖IDC机房的物理机和vm节点提供服务，当大促或活动时，则需要增加物理机或者VM实现扩展。

从第1部分内容，我们大概能推断出平台所需要的主要特性，包括服务实例动态扩缩容、RBD动态按需申请、灰度发布、流量控制等等，而这些如果是基于传统的技术栈来进行开发，则会涉及到比较多的底层架构的设计以及大量与业务不相干的模块的研发。

此外，随着平台的发展，业务复杂度必然越来越大，生产环境所使用的开发语言也越来越多，技术栈和系统环境依赖也越来越复杂，不仅是管理成本的上升、单个服务的资源控制粗放问题，同时还有由于线上线下开发测试生产环境不一致等问题造成的服务不可用的情况，随之而来的排错过程成本也越来越高，如果继续基于之前传统架构思路来进行研发，则将逐渐变得不可控，因此我们决定引入容器及Kubernetes，通过技术预研，我们发现Kubernetes容器方案具有如线上线下环境一致、细粒度资源管理、轻巧灵活、自动扩展、异常自动恢复等很多优势，可以帮助解决一些关键痛点。

虽然Kubernetes有明显的优势，但其技术起点较高、技术栈多、选择难度大，且稳定性以及性能是否能满足业务需求,需要我们进行实际的测试验证；此外还要考虑如何兼容现有生产环境，实现并行平滑过渡，考虑Kubernetes网络和现有传统网络的兼容，尽量复用现有的生产网络结构；其次尽量减少开发修改服务代码；考虑Kubernetes服务本身的高可用、日志管理、监控、可视化等等，最后形成一套行之有效的方案。

Kubernetes技术栈选择

Kubernetes技术栈非常多, 下面是引用一张互联网上的图：

根据实际业务需求，我们采用了上图中绝大部分的技术栈，包括负载均衡Traefik、镜像仓库Harbor、监控告警Metricserver+Prometheus+Alertmanager、日志管理EFK、UI管理Dashboard、网络插件Calico、分布式存储Ceph等等很多组件，根据实际情况，我们也引入了Service Mesh Istio等云原生领域其他重要组件，此次只涉及讨论Kubernetes常用的组件。

AIPaas组件使用架构图大致如下：

那些年踩过的坑

为尽量满足对公司基础设施架构不造成影响的这个前提，在整个Kubernetes落地实施过程中，大数据部遇到了不少的挑战，比如像多网卡、rook-ceph中S3的rgw多实例网关问题、Istio response 500、pod shm不足、Pod长时间containerCreating、istio-mesh metric MaxpirationPolicy、Kube-proxy的ipvs模式的terminating bug等等问题，通过这个过程，收获了不少经验和心得，在这里我们摘取其中部分案例分享给大家，希望可以给大家带来一些启发。

The 1st issue：关于Docker的No_Proxy对CIDR的不支持

当我们在隔离网络内拉取公共镜像时，我们需要设置Proxy拉取镜像，大家常用的操作就是set Docker proxy[1]。

而这个在早期的版本也就是在docker-ce-18