一、部署模式
传统部署模式： 在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界，这会导致资源分配问题。例如：在物理服务器上运行多个应用程序，可能会出现一个应用程序占用大部分资源的情况，导致其他应用程序的性能将下降。解决方案是在不同的物理服务器上运行每个应用程序。但是，这并没有随着资源利用不足而扩展，并且组织维护许多物理服务器增加运维成本。
虚拟化部署模式：将计算机的各种实体资源，如服务器、网络、内存及存储等，予以抽象、转换后呈现出来，打破实体结构间的不可切割的障碍，使用户可以更好地利用物理服务器中的资源，并可以实现更好的可伸缩性，轻松地添加或更新应用程序，降低硬件成本。
容器部署模式：容器类似于VM，但是它们具有轻松的隔离属性和易迁移的特性，可以在应用程序之间共享操作系统（OS）。容器有独立的网络和存储栈，还拥有自己的资源管理能力，使得同一台宿主机中的多个容器可以友好的共存。由于它们与基础架构分离，因此可以跨云和OS分发进行移植。
使用容器部署模式可以帮助开发和运维人员在快捷、灵活的部署应用，专注于构件程序和使用容器而非管理设备上，只需要完成程序的Docker化，不需要关心云上的Iaas层计算资源，就可以通过部署容器把应用程序运行起来。
二、kubernetes基本概念
Kubernetes(k8s)是Google开源的容器集群管理系统（谷歌内部:Borg）。在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。Kubernetes是为生产环境而设计的容器调度管理系统，对于负载均衡、服务发现、高可用、滚动升级、自动伸缩等容器云平台的功能要求有原生支持。由于Kubernetes在K和s间有8个字母，因此常简称K8s。
1、Cluster（集群）
Cluster 是计算、存储和网络资源的集合，Kubernetes 利用这些资源运行各种基于容器的应用。最简单的 Cluster 可以只有一台主机（它既是 Mater 也是 Node），常用Cluster部署为3主4从。
2、Master（主节点）
Master 是 Cluster 的大脑，主要负责对Node进行管理，对Pod进行分配调度。
（1）etcd：对集群中的资源、对象进行持久化存储，主要包括Node、Service、Pod、RC、Namespace等。
（2）api service：为操做资源、对象提供统一访问入口，例如可以对资源数据进行查询、监控等。
（3）scheduler：负责Pod在集群节点中的分配。
（4）controller manager：集群的管理控制中心，主要负责检测集群故障和恢复的自动化工作。
a、Deployment：对 Pod 中的多个副本进行管理，确保 Pod 按照期望的状态运行。
b、ReplicaSet：Deployment 使用时会自动创建 ReplicaSet，通过 ReplicaSet 来管理 Pod 的多个副本。
c、DaemonSet：对 Node 节点中最多只运行一个 Pod 副本的使用场景。
d、StatefuleSet：负责 Pod中每个副本在整个生命周期中信息的一致性。例如：某个 Pod 发生故障需要删除并重启时保证Pod 的名称不变。同时 StatefuleSet 会保证副本按照固定的顺序启动、更新或者删除。
e、主要用于运行结束就删除的应用。
3、Node（从节点）
Node 负责为容器应用提供运行环境，并对容器状态向master进行汇报，并根据 Master 的指令对容器应用进行全生命周期管理。
（1）docker：提供Pod运行环境。
（2）kubelet：负责对Node节点上的Pod进行全生命周期管理，同时负责将本节点状态上报给Master和api server。
（3）kubeproxy：实现了Service的代理和软件模式的负载均衡器。
4、Pod（容器组）
Pod 是 Kubernetes 的最小工作单元。每个 Pod 包含一个或多个容器。Pod 中的容器会作为一个整体被 Master 调度到一个 Node 上运行。
5、service（服务）
定义了外界访问一组特定 Pod 的方式。Service 有自己的 IP 和端口，Service 为 Pod 提供了负载均衡。Kubernetes中 运行容器（Pod）与访问容器（Pod）这两项任务分别由 Controller 和 Service 执行。
5、Namespace（命名空间）
将一个物理的 Cluster 逻辑上划分成多个虚拟 Cluster，每个 Cluster 就是一个 Namespace。不同 Namespace 里的资源是完全隔离的。
6、Ingress
一组基于DNS名称（host）或URL路径把请求转发到指定的Service资源的规则。用于将集群外部的请求流量转发到集群内部完成的服务发布。Ingress 通过把 Nginx 负载配置功能抽象出来，变成一个 Ingress 对象，不需要再修改 Nginx配置信息 ，可以通过创建 yaml ，更改 yaml 进行配置更新；
（1） Ingress controller：Ingress资源监听套接字并将流量转发的组件。不同于Master 中的Controller，Ingress controller不直接运行为kube-controller-manager的一部分，是Kubernetes集群的一个附件，类似于CoreDNS，需要在集群上单独部署。Ingress Controoler 通过与 Kubernetes API 交互，动态的去感知集群中 Ingress 规则变化，动态读取，按照他自己模板生成一段 Nginx 配置，再写到 Nginx Pod 中并进行动态更新。