应用部署及管理从容器技术开始大热开始，就是一个很大的话题，本身容器技术很大一部分动机就是解决应用如何部署，以及部署后如何弹性扩展伸缩，以便更好地便捷部署应用、增加应用弹性、提升资源使用率。
我们来回顾一下，最早容器应用部署一般都是编写Dockerfile，在Dockerfile里根据基础镜像，使用镜像操作指令，组合定义生成新的Image,然后简单的docker run启动并进行容器的启动，整个过程非常简便。
但是我们都知道，真正的应用，特别是企业级的应用，不会把所有应用信息放入到一个简单的容器运行，往往需要多个容器一起协同工作，复杂的应用整体运行起来，多的话要上百个容器应用同时运行，而如何进行折现容器管理，包括容器的调度管理、监控、容器存储管理等，往往成了一个很大的瓶颈。因此，为了解决这些问题，容器的编排调度平台，成了业界热点，其中包括Kubernetes、 Mesos、Swarm，也就是我们以前熟知的“三驾马车“。
但事实上，随着技术的快速不断迭代发展，Kubernetes大获全胜，成了事实上的容器编排管理主流平台。但现在，应用在Kubernetes上的部署方式多种多样，这些部署方式都对应什么场景，如何出现的，我们如何选择合适的部署方式，对我们来讲不免常常困惑，因此如何在Kubernetes，以及基于Kubernetes基础上的容器管理平台，如红帽的Openshift上进行应用的部署、管理，值得我们探索究竟。
以下，是初步整理的容器化应用部署方式：
基于Dockerfile部署
出现较早，根据基础镜像，编写Dockerfile脚本，然后根据Dockerfile生成新的镜像直接部署；
适合应用相对简单，演示类型应用， 但编写Dokerfile相对费力；
单容器化应用部署；
直接镜像部署
根据已经生成的镜像，直接部署，如已经把镜像做好后上传到镜像仓库，客户端可直接pull镜像仓库到本地，然后直接执行运行镜像；
单容器化应用部署；
K8S的Deployment部署
单镜像部署如上所述，存在了许多的问题，所以K8S里面有对应用的部署标准描述，也就是K8S原生的对象Deployment，我们可以在Deployment里面定义部署的应用上下文信息，包括包含的镜像，容器的部署分布方式，Pod的个数等，K8S根据Deployment信息进行Pod的自动部署等；
Helm部署应用；
基于Deployment的部署，给我们在应用部署上带来了很多的便利，包括声明式的说明应用的部署逻辑，但总的来讲，直接采用Deployment部署在复杂应用部署上，还是有一定的繁琐性，以及Deployment所依赖的一些资源对象，我们也得额外配置。 因此，如何更高效部署应用，也是业界人士探索的，其中解决方案包括Helm，Helm 是 Kubernetes 的包管理器，Helm类似于Linux的yum一样，能快速查找、下载和安装基于K8S的软件包。Helm 由客户端组件 helm 和服务端组件 Tiller 组成, 能够将一组K8S资源打包统一管理, 是查找、共享和使用为Kubernetes构建的软件的一种便捷方式。
更便捷的部署，不仅仅部署Deployment，还包括Deployment部署所需的一组资源对象。
Openshift的template部署
在此介绍红帽的混合容器云平台Openshift，它除了支持常规的K8S部署，如Deployment、镜像部署、Helm等，它还有一直部署方式，就是基于template文件部署，一个template模版是一系列可以被参数化并创建一组对象的集合。模版可以创建任何你有权限创建的任意对象，相当于定义一组可带参数的对象集合，需要使用的时候直接执行这个template脚本，如oc create -f templatefile.yaml。
基于Openshift template也有一个特点，就是如果是已经上传到global template library，那么可以通过Openshfit 控制台部署应用；
如果你的应用逻辑比较复杂，甚至需要关联多个容器的情况下建议使用Template。
Template是Openshift所特有的，在没有Helm之前，用户可以使用Template进行应用的上下文打包部署，有了Helm后，用户可以把Template转成相应的Helm部署包，具体参见：From Templates to Openshift Helm Charts https://cloud.redhat.com/blog/from-templates-to-openshift-helm-charts
Template出现在Helm之前，是在没有Helm之前的Openshift打包应用部署解决方案。
Operator 部署
其实，Docker 镜像的提出，是完成了应用静态描述的标准化。而 Kubernetes Operator 的出现，终于为应用的动态描述提出了一套行之有效的实现规范，相比于Helm,它还强调应用部署后的运维、调整等应用的全生命周期管理。
K8S是声明式管理在其之上的对象状态，“声明式 API”的核心原理，就是当用户向 Kubernetes 提交了一个 API 对象的描述之后，Kubernetes 会负责为你保证整个集群里各项资源的状态，都与你生命的 API 对象描述的需求相一致。
Operator本质上是自我实现一个控制器，对自定义的CRD资源对象进行控制，而整个应用部署集群的状态和定义，都成了Kubernetes 控制器需要保证的“终态”。
因此，Operator上可以定义应用运行后需要的状态，如果状态不对，则需要进行怎么样的调整。
Operator的目标类似于定义一个企业级应用的"App Store",我们可以制作Operator，然后再发布到Operator Hub上，然后需要部署应用的时候，直接拉取应用，执行运行，而运行时候，Operator可以自我管理调整。
kustomize部署管理
kustomize 是 kubernetes 原生的配置管理，以无模板方式来定制应用配置。而kustomize出现的意义是什么呢？一般应用都会有多套部署环境：开发环境、测试环境、生产环境，多套环境意味着存在多套 K8S 应用资源 YAML配置。而这么多套 YAML 之间只存在很小配置区别，比如镜像版本不同、Label 不同等，而这些不同环境下的YAML 经常会因为人为疏忽导致配置错误，因此如何管理多套环境，存在不少问题：
如何管理不同环境或不同团队的应用的 Kubernetes YAML 资源
如何以某种方式管理不同环境的微小差异，使得资源配置可以复用，减少 copy and change 的工作量
如何简化维护应用的流程，不需要额外学习模板语法
Kustomize 通过以下几种方式解决上述几个问题：
而kustomize 通过 Base & Overlays 方式方式维护不同环境的应用配置
kustomize 使用 patch 方式复用 Base 配置，并在 Overlay 描述与 Base 应用配置的差异部分来实现资源复用
kustomize 管理的都是 Kubernetes 原生 YAML 文件
kustomize通过继承式进行应用部署描述，可以对多套环境进行统一管理。
相比Helm，Kustomize 给 Kubernetes 的用户提供一种可以重复使用配置的声明式应用管理，从而在配置工作中，用户只需要管理Kubernetes 的原生 API 对象，而不需要使用复杂的模版。
适用于需要管理多套K8S环境场景
GitOps部署管理
典型的部署方式为ArgoCD，GitOps的主要思想是将应用系统的声明性基础架构和应用程序存放在Git的版本控制库中，即一切都是以生明式为基础，未来应用部署，所有的部署上下文、配置、应用包、源代码均可放置在Git中，通过新式的部署工具，如ArgoCD，实时监测Git上的那些配置的变动，随时更新K8S上的资源，以此达到配置驱动应用部署管理。因此,GitOps可以更为高效的管理应用部署，应用的部署均可以通过版本化控制、回滚等。
适合于对部署管理进行自动化、版本控制场景。
