中国联通大数据能力开放平台为支撑公司内部数据运营和外部数据合作提供了丰富的框架资源、数据资源、多样化的组件和工具以及应用部署环境。
平台为每个入驻租户都提供了独享和隔离的计算框架和数据库服务，包括关系型、离线分析型、流数据类、KV类型等；提供的数据服务包括抽取联通脱敏后的用户标签数据；提供的数据加工、分析类组件种类就更多了，包括元数据、数据质量、地图服务、分布式服务框架、分布式ETL、工作流引擎等二十多种。
随着容器技术的普及，一些租户也提出了希望开放平台能够提供一个友好的容器开发和运行环境，开放平台团队经过三个月的选型和研发，近期发布了自己的容器云平台，利用容器资源隔离、分布式部署、水平动态扩展、负载均衡、高可用等核心技术为公共、专业、创新等各类应用的快速部署提供快速支撑。
容器云实践
联通大数据能力开放平台容器云，是基于Kubernetes和Docker生态圈相关技术，结合联通大数据能力开放的特定业务场景，自主研发的一套完整容器云集群部署和管理平台，实现快速部署、秒级停启各类应用，支持多种服务的集群部署、负载均衡、灾难恢复和弹性伸缩。
关于Docker、Kubernetes的功能和技术特性，就不在本文做具体的介绍了，感兴趣的可以很容易找到各种技术资料，本文重点介绍支撑数据中心能力开放具体业务应用场景，有针对性的优化和改进。
1. 服务发现和路由
传统基于虚拟机、物理机部署应用时，首先要确定该业务是通过互联网访问还是通过内部生产网访问，通常我们的运维人员都需要在互联网访问区或用户访问区的代理设备上人工配置Nginx或者Apache等代理网关，才能保证服务被正确可控访问。
这种人工配置的方式显然不适合容器化部署的需要，更不适合多租户场景下的自动运维需要。为此我们对Kubernetes的代理访问功能进行优化，自主研发了kubernetesNG组件，该组件一方面能够快速发现和注册服务，实时监控服务信息变化并自动完成代理访问接入控制，另一方面对请求被跨节点转发做了针对性的优化，下面是对使用kubernetesNG和没有使用kubernetesNG时的对比：
使用KubernetesNG前服务发现和路由
这是使用kubernetesNG前的服务访问方式，集群内部署了3个应用A、B、C，每个应用有2个docker实例，外部访问请求由Kubernetes负责调度到随机的一个Node节点上，一般情况下还要由这个node节点上的Kube-proxy再次转发到真正有服务的node节点上，客观上在物理节点间形成了转发。
每次发布新的应用都由Kubernetes分配一个对应端口NodePort，通常管理员需要手动的把NodePort配置到互联网区或者用户访问区内的Nginx负载均衡器上。
下面再来看看使用了kubernetesNG后的情况。
使用kubernetesNG后的服务发现和路由
kubernetesNG与负载均衡器安装在同一台机器上，kubernetesNG会实时监控服务的变化，包括服务暴露区域（公网访问区或者内网访问区），并且根据变化更新负载均衡器配置，然后调用负载均衡器的重新加载配置命令，实时生效，从而完成服务对外发布动作。
由于kubernetesNG可以实时的发现应用部署的真正节点位置，所以通过配置负载均衡器，直接把请求分发到应用所在的机器上，比如访问应用A，就会直接把请求分发到机器1和2上的kube-proxy，由kube-proxy把请求直接发给本机的应用上（开源的kube-proxy会分发到其它机器上的，这里需要修改源码）。通过对比我们发现，新服务发布不再需要管理员手动配置负载均衡器了；原来请求需要经过两次负载均衡才能到达应用，现在实际上只需要一次负载均衡就可以到达应用了（第二次转发由于在同一节点内部完成，效率大大提高可以忽略不计了）。
2. 服务可视化调试
在租户自助进行应用容器化的部署和调试过程中，我们发现用户问的最多的是怎么调试，能不能ssh登陆上去，能不能替换容器内的配置文件。一般在容器中修改和调试脚本首选需要将sshd进程启动起来， 再ssh登录上去，然后修改容器内的文件，但如果这时容器重启了，Kubernetes会从自动仓库重新拉取原来的镜像，用户所做的修改全都丢失，如何解决这个问题？