服务介绍
应用管理基于Kubernetes技术为您提供了一站式应用生命周期管理和治理服务，可以帮助您简化应用管理的过程，实现云上高效运维。应用管理主要提供如下功能：
应用组
为了更好的将若干个共同支撑业务的应用抽象为一个整体，实现众多应用间的逻辑隔离，并对其进行统一管理，提出了应用组的概念。一个应用组中可以包含多个应用，用户在创建应用（即部署软件包）时需为应用选择所属的应用组。在应用组中，用户可实现对应用的生命周期管理，如增删查、启停、升级回滚等操作。对于Spring Cloud和Istio类型的应用组，还支持负载均衡、熔断、限流等服务治理功能。
应用列表
应用列表用于展示所有已创建的应用。您可以在应用列表中查看已创建的应用详细，并对其进行管理。
应用配置
配置项和密钥组成了Kubernetes的配置系统。应用配置的目的是为了将配置与容器分离，使配置信息不随容器的销毁或重启而消失或改变，容器创建后可直接加载使用，以实现最大化的可移植性；同时，通过统一的配置中心，也可以集中式的对配置信息进行管理维护。
|
|
应用是以容器的形态运行的，而Kubernetes的最小调度单位是Pod，一个Pod中存在一个或多个容器，因此，对于应用的管理本质上是对容器的管理。 |
配置项用于定义容器服务的一些固定配置信息，即Kubernetes中的configmap对象，如日志存储路径、Pod间依赖关系等。
密钥用于存储Pod的一些敏感数据，如密码、token、密钥等信息，即Kubernetes中的secret对象。
应用仓库
应用仓库提供用于存储、管理应用包的场所。在应用仓库中可以轻松地存储、使用、管理应用包，将企业应用统一管理起来。
存储应用包
系统支持上传的应用包类型包括War包、Jar包以及Helm包。上传应用包时需选择存放的仓库类型，包括公有仓库和私有仓库。还可以在仓库中创建应用包分类，以便灵活分类存储应用包。
公有仓库用于存放和管理正式发布版本的应用包，系统所有成员均可使用，便于对企业发布级的应用进行管理，降低了各个组织部门的沟通成本。
私有仓库用于存放和管理开发版本或内部版本的应用包，组织内成员可以上传自己的应用包并自己进行使用与管理。私有仓库中的应用包可以发布至公有仓库。
使用应用包
部署：用户可在应用仓库中直接选择需要的应用包进行部署，避免了先进入应用部署服务再在部署过程中找到该应用包的繁琐流程。
下载：若需要在系统外使用应用包时还可以将应用包下载至用户本地。
管理应用包
系统支持对应用包进行版本管理，即可以为一个应用包添加多个版本并上传该版本对应的文件。当上传的应用包与已有应用包同名时，系统可自动识别该应用包已有信息，如所属分类、历史版本信息，并将校验新版本号是否与旧版本号重复。另外还支持对应用包进行编辑、删除。
其他应用管理功能
对应用的管理根据应用的部署位置区分为容器应用和主机应用两种。
访问方式
1. 容器应用
应用管理为容器应用提供了服务、应用域名、网络策略三种对外提供服务的方式。
服务
“服务”（即Service）是Kubernetes中应用提供服务的入口，是一个应用访问另一个应用的方式。Service代表一组Pod，由于Pod IP是随机的，且可能会因重启改变，因此不应该直接访问Pod IP。而集群IP是Service在集群中的具体实现，该IP地址一经创建便不会改变。Kubernetes负责建立和维护Service与Pod的映射关系，因此用户只需要访问Service的IP，无论后端Pod如何变化，对用户都不会有任何影响。Service提供了三种访问容器服务的方式：
集群外访问：
节点访问：请求通过节点IP、节点端口、Service端口和容器端口访问对应容器。
集群内访问（ClusterIP）：通过集群IP、Service端口和容器端口访问对应容器。
图-1 Service架构图
应用域名
“应用域名”（即Ingress）可以允许Kubernetes中一个应用通过域名的访问另一个应用，相当于一种“路由规则”，即通过域名将访问流量路由到对应容器。使用应用域名作为访问方式，需首先在DNS上配置域名与容器所在集群VIP的对应关系。
网络策略
网络策略为应用提供了基于策略的网络控制，以白名单的方式支持指定远端访问本端容器端口，用于隔离应用并减少攻击面。使用网络策略作为访问方式的集群需要安装网络插件如Calico、Romana、Weave Net和trireme，系统默认已安装了Weave Net插件。
主机应用：为主机应用提供了应用域名和IaaS负载均衡两种对外提供服务的方式。
IaaS负载均衡
需配合IaaS负载均衡服务使用，将访问流量根据转发策略分发到后端多台虚拟机上。
弹性伸缩
对Pod实例的个数进行调整。
容器应用：支持自动伸缩、手动伸缩、定时伸缩、周期伸缩四种方式。
自动伸缩：通过对CPU/内存使用率或HTTP请求速率、最小/最大实例数等阀值的配置，使系统根据监控情况自动调整服务中Pod实例的个数，保证系统业务平稳健康的运行。
手动伸缩：用户可根据需求手动设置Pod实例的个数，系统会将实例数量调整至设置预期。
定时伸缩：系统将在到达设置的触发时间时自动将实例数量调整至设置的预期值。
周期伸缩：在所选择的日期范围内，每天到达触发时间时自动将实例数量调整至设置的预期值。
主机应用：支持自动伸缩、手动伸缩两种方式。
自动伸缩：通过对检查周期、CPU/内存使用率、TCP连接数、最大后端服务数等阀值的配置，使系统根据监控情况自动调整服务中Pod实例的个数，保证系统业务平稳健康的运行。
手动伸缩：通过修改虚拟机实例个数进行扩缩容。
服务治理
对于Spring Cloud和Istio类型的应用组，系统支持进行服务治理。服务治理由微服务引擎完成，系统支持Spring Cloud和Istio两种业内最常用微服务管理引擎，帮助您实现服务与服务间链路的可视化拓扑监控和微服务治理功能，包括调用链展示、服务启停、负载均衡、服务限流、服务熔断、故障注入、超时重试等。关于服务治理的更多介绍请参见[企业应用指南-微服务-服务介绍]章节的内容。
应用升级
应用升级包括替换升级、滚动升级和灰度升级三种策略。
|
|
· 部署到单个虚拟机实例的应用仅支持替换升级和灰度升级，部署到多个虚拟机实例的应用仅支持滚动升级和灰度升级。 · 部署到容器集群的应用仅支持滚动升级和灰度升级。 · 如需使用灰度升级需为应用配置应用域名作为访问方式。 |
替换升级：旧版本直接全部被新版本替换。优点是不占用更多的资源，缺点是一旦新版本出现问题，由于没有旧版本承担业务，会导致业务的中断。
滚动升级：默认的升级策略，通过新的服务实例逐个更新来实现零停机的部署升级，即先升级并启动一台新版本，再停止其老版本，使得在整个滚动过程期间，保证始终有可用的副本在运行，从而平滑地发布新版本。优点是节约资源，不需要同时运行两倍的实例个数，缺点是回滚过程困难。
灰度升级：在进行灰度升级时，不停止老版本，同时会部署一套新版本，用户可自定义配置新旧版本间的流量权重，新旧版本按照流量权重承担流量，同时对外提供服务。待新版验证完毕即可完成升级或取消升级，可以保证整体系统的稳定和平滑过渡。优点是无需停机，风险较小，回滚简单，缺点是同时运行新旧两套版本，需要两倍的资源。
|
|
如需使用灰度升级，需为应用配置应用域名作为访问方式。 |
