1.应用创建：模板+配置管理
2.应用部署：多集群一键部署+灰度更新发布
3.应用弹性伸缩：手工扩容 | 基于cpu使用率自动扩容 | 基于自定义业务指标自动扩容
4.应用的日志管理和监控管理
在容器云平台为租户提供了各种资源之后，租户就能在平台上管理自己的业务应用了。
对应用的管理主要包括：应用部署、更新策略（灰度发布）、弹性扩缩容、日志和监控。
模板
在容器云平台，租户应该省去创建和编辑不同类型应用的k8s配置文件和在后台执行kubectl命令风复杂的手工工作，通过平台提供的简单、灵活的应用部署可视化页面工具，来提高应用管理的工作效率。
在部署应用前，容器云平台应该根据应用的类型提供不同的应用创建模板。
配置管理
在制作容器镜像时，应用程序使用的配置文件应剥离于镜像之外，这样能避免因为配置发生变更而重新打包镜像。
应用配置应在容器云平台上统一管理，在创建容器时在进行注入，供应用程序使用。
当容器云平台需要管理数以万计的应用是，对各个应用的配置管理就尤为重要了。
企业级容器云平台应提供统一的服务配置中心，将应用程序需要使用的所有配置文件上传到服务配置中心，服务配置中心对所有配置文件进行统一存储、变更、版本维护等操作。
这样，运维人员就可以将应用配置与应用进行关联来完成部署工作。
在k8s平台上，可以使用ConfigMap将应用要使用的多个配置文件进行保存。
对于配置文件本身的管理，则可使用Git或SVN工具来完成。
当配置文件的内容发生变化时，容器云平台应该能够更新配置文件的内容到k8s的ConfigMap中。
在基于应用模板创建应用后，需部署应用到可用的资源分区上。
部署后应进入应用的运维管理阶段。
应用的部署管理包括多集群环境下应用的一键部署管理，以及对应用更新时的灰度发布策略。
手工扩容
通过命令行工具kubectl进行手工扩缩容的方式为：
kubectl scale rc redis-slave --replica=3
在扩缩容完成后，k8s的kube-proxy将自动完成从service到各pod的负载分发，这对客户端容器应用来说是透明的，客户端无需感知提供服务的容器实例的变化。
应用场景：通常用于预先知道业务量变化的情况，在业务高峰过去后，预期业务量下降，可手工减少容器实例来释放系统资源。
基于cpu使用率自动扩容
k8s从v1.1版本开始，引入了一个新的控制器HPA（Horizontal Pod Autoscaler），用于实现基于CPU使用率进行自动pod扩缩容的功能。
对pod的CPU使用率性能参数的采集需要Heapster组件提供支持，同时要求pod必须设置CPU资源请求（cpu request）。
使用HPA控制器和Heapster采集的CPU使用率共同完成自动扩缩容。
k8s如何启用基于CPU的自动扩缩容机制：
1.为pod设置资源请求cpu request：spec.resources.requests.cpu: 200m
2.创建HPA资源对象，指定minReplicas、maxReplicas和targetCPUUtilization Percentage参数，表示每个pod的目标cpu使用率和pod的数量范围（在minReplicas与maxReplicas之间调整）
应用场景：基于cpu使用率的自动扩缩容可应用于cpu密集型的应用程序，在cpu使用率提高时能够通过水平扩展来完成更多的计算。
缺点：基于Heapster的HPA仅支持以CPU使用率为触发扩缩容的性能指标。在实际系统中，很多业务并非cpu密集型，需综合考虑如QPS（每秒请求数）、内存使用率、队列长度、业务指标等才能更准确的实现弹性伸缩。另外，如果目标cpu使用率和副本数量的最大、最小值设置得不合理，则可能会产生系统频繁扩缩容的问题，导致系统不能稳定运行。
基于自定义业务指标自动扩容
k8s从v1.7版本开始，对支持自定义指标的HPA架构进行了重新设计，引入了api server aggregation层、custom metric server等组件来实现自定义业务指标的采集、保存和查询，再提供给HPA控制器进行扩缩容决策，被称为HPA v2版本。
我们可以自定义Custom Metrics Server（Prometheus Adapter），例如可以用Prometheus系统来实现。
1.部署Prometheus
2.创建一个以prometheus-adapter实现的Custom Metric Server，其中指定了Prometheus服务的地址kind：Deployment-》containers：image：directxman12/k8s-prometheus-adapter
3.创建一个HPA对象
4.部署应用
业务应用在上容器云平台之前，需提前考虑日志和运维相关的如下运维需求：
应用在上容器云平台前需要做到合理的微服务拆分和容器化改造，需仔细设计应用的日志输出格式及日志输出路径，以及是否需要将关键业务日志保存到共享存储中等。