1、传统应用部署方式

• 手动部署
• 脚本部署
• 通过自动化工具部署
  • ansible
  • saltstack
  • puppet
  • 此类自动化工具本身就是一款应用编排工具，它能够安装、配置、启动，甚至可以用自己定义的状态文件来实现批量部署

传统的应用部署方式是通过插件或脚本来安装应用。这样做的缺点是应用的运行、配置、管理、所有生存周期将与当前操作系统绑定，这样做并不利于应用的升级更新/回滚等操作，当然也可以通过创建虚拟机的方式来实现某些功能，但是虚拟机非常重，并不利于可移植性。

2、docker部署方式

以往手工管理的对象是直接部署在操作系统环境中的应用程序，但是有了docker以后，应用程序被容器化，各种应用程序都被封装在容器中执行。

每个容器之间互相隔离，每个容器有自己的文件系统 ，容器之间进程不会相互影响，能区分计算资源。相对于虚拟机，容器能快速部署，由于容器与底层设施、机器文件系统解耦的，所以它能在不同云、不同版本操作系统间进行迁移。

容器占用资源少、部署快，每个应用可以被打包成一个容器镜像，每个应用与容器间成一对一关系也使容器有更大优势，使用容器可以在build或release 的阶段，为应用创建容器镜像，因为每个应用不需要与其余的应用堆栈组合，也不依赖于生产环境基础结构，这使得从研发到测试、生产能提供一致环境。类似地，容器比虚拟机轻量、更“透明”，这更便于监控和管理。

那么我们在使用saltstack等自动化运维工具编排应用程序时会发现它的对象已经发生变化了。此时我们的自动化运维工具已经不再适用于容器化应用程序的编排工作了，因为容器化所提供的接口与早期传统意义上应用程序的访问、控制和管理接口有所不同，所以，docker时代就呼唤新式的、面向容器化应用程序的编排工具的实现

1、docker compose（单机编排）

• 只能管理一台主机上的容器，无法跨主机启动其他主机上的容器

2、docker swarm（多机编排）

• 面向集群
• docker swarm能够将多个docker host整合为同一平台之下的管理机制的一个集群工具
• 能够将多个docker host的计算资源整合成一个资源池，然后用docker compose编排时，只需要面向swarm整合出来的资源池进行编排
• docker swarm是docker自身的一个应用程序

3、docker machine（docker主机）

每个主机在在一开始的时候怎么去把它安装成为docker host，这个docker host要能够加入到docker swarm的资源池，成为swarm的成员，它首先自己得是个docker host，那么docke怎么安装上去，如何初始化成能够直接加入、成为docker swarm中的成员主机呢？此时我们就需要用到docker machine来实现此功能。
docker machine能够将一个主机迅速初始化为能加入swarm集群的一台docker host。

是一个IDC的OS，能够把一个IDC中的所有硬件所提供的计算资源统一调度和分配。但是它所面向的上层接口所提供的不是容器运行的接口，而只是个资源分配工具，非能够直接运行托管运行容器的。所以在此基础之上它必须要提供一个能面向容器编排的框架，这个框架就是marathon

Kubernetes是一个开源的，开箱即用的容器集群管理器和业务流程。它具有出色的构建 调度器 和资源管理器，用于以更有效和高度可用的方式部署容器。Kubernetes已成为许多组织事实上的容器编排工具。kubernetes项目由google与世界各地的贡献者维护。它提供了本机Docker工具不提供的许多功能。而且，使用kubernetes很容易上手。

Openshift建立在kubernetes之上。Openshift项目由Redhat维护。它同时具有开源（openshift orgin）和企业版（openshift容器平台）。连同核心的Kubernetes功能，它提供了用于容器管理和编排的开箱即用组件。

• CI（持续集成）
• CD（持续交付Delivery）
• CD（持续部署Deployment）

Kubernetes是一个完备的分布式系统支撑平台，具有完备的集群管理能力，多扩多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、內建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力。同时Kubernetes提供完善的管理工具，涵盖了包括开发、部署测试、运维监控在内的各个环节。

Kubernetes设计了Pod对象，将每个服务进程包装到相对应的Pod中，使其成为Pod中运行的一个容器。为了建立Service与Pod间的关联管理，Kubernetes给每个Pod贴上一个标签Label

Kubernetes将集群中的机器划分为一个Master节点和一群工作节点Node，其中，在Master节点运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kube-scheduler，这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理能力，并且都是全自动完成的。Node作为集群中的工作节点，运行真正的应用程序，在Node上Kubernetes管理的最小运行单元是Pod。Node上运行着Kubernetes的kubelet、kube-proxy服务进程，这些服务进程负责Pod的创建、启动、监控、重启、销毁以及实现软件模式的负载均衡器。

1、容器编排
2、轻量级
3、开源
4、弹性伸缩
5、负载均衡

Kubernetes 为你提供：

• 服务发现和负载均衡
  Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器，如果进入容器的流量很大， Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。

• 存储编排
  Kubernetes 允许你自动挂载你选择的存储系统，例如本地存储、公共云提供商等。

• 自动部署和回滚
  你可以使用 Kubernetes 描述已部署容器的所需状态，它可以以受控的速率将实际状态 更改为期望状态。例如，你可以自动化 Kubernetes 来为你的部署创建新容器， 删除现有容器并将它们的所有资源用于新容器。

• 自动完成装箱计算
  Kubernetes 允许你指定每个容器所需 CPU 和内存（RAM）。 当容器指定了资源请求时，Kubernetes 可以做出更好的决策来管理容器的资源。

• 自我修复
  Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的 运行状况检查的容器，并且在准备好服务之前不将其通告给客户端。

• 密钥与配置管理
  Kubernetes 允许你存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。 你可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥。

1、Master 组件
Master组件提供集群的管理控制中心。
Master组件可以在集群中任何节点上运行。但是为了简单起见，通常在一台VM/机器上启动所有Master组件，并且不会在此VM/机器上运行用户容器

• kube-apiserver
  ube-apiserver用于暴露Kubernetes API。任何的资源请求/调用操作都是通过kube-apiserver提供的接口进行
• ETCD
  存储服务
• kube-controller-manager
  kube-controller-manager运行管理控制器，它们是集群中处理常规任务的后台线程。逻辑上，每个控制器是一个单独的进程，但为了降低复杂性，它们都被编译成单个二进制文件，并在单个进程中运行。
  这些控制器包括：
  • 节点（Node）控制器。
  • 副本（Replication）控制器：负责维护系统中每个副本中的pod。
  • 端点（Endpoints）控制器：填充Endpoints对象（即连接Services&Pods）。
  • Service Account和Token控制器：为新的Namespace创建默认帐户访问API Token。
• cloud-controller-manager
  云控制器管理器负责与底层云提供商的平台交互
• kube-scheduler
  kube-scheduler监视新创建没有分配到Node的Pod，为Pod选择一个Node
• 插件 addons
  插件（addon）是实现集群pod和Services功能的。Pod由Deployments，ReplicationController等进行管理。Namespace 插件对象是在kube-system Namespace中创建。

API Server ：负责接收并处理请求
Scheduler： 调度容器创建的请求
Controller： 确保已创建的容器处于健康状态
Controller Manager： 确保后端节点上的控制器处于健康状态

2、节点（Node）组件
Node是Kubernetes集群架构中运行Pod的服务节点。Node承载Kubernetes集群操作的单元Pod的运行，是Pod运行的宿主机。关联Master管理节点，拥有名称和IP、系统资源信息。运行docker eninge服务，守护进程kunelet及负载均衡器kube-proxy.

• kubelet
  kubelet是主要的节点代理，它会监视已分配给节点的pod，具体功能：
  • 安装Pod所需的volume。
  • 下载Pod的Secrets。
  • Pod中运行的 docker（或experimentally，rkt）容器。
  • 定期执行容器健康检查。
  • 通过创建必要的镜像podif，向系统的其他部分报告pod的状态
  • 向系统的其他部分报告节点的状态。
• kube-proxy
  kube-proxy 是集群中每个节点上运行的网络代理， 实现 Kubernetes 服务（Service） 概念的一部分。
  kube-proxy 维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。
  如果操作系统提供了数据包过滤层并可用的话，kube-proxy 会通过它来实现网络规则。否则， kube-proxy 仅转发流量本身。
• docker
  docker用于运行容器。
• RKT
  RKT运行容器，作为docker工具的替代方案。
• supervisord
  supervisord是一个轻量级的监控系统，用于保障kubelet和docker运行。
• fluentd
  fluentd是一个守护进程，可提供cluster-level logging

1、pod
运行于Node节点上，若干相关容器的组合。一个Pod可以包含一个容器或者多个相关容器。虽然一个pod中可以容纳多个容器，但是一般在实际应用中只跑一个容器，便于管理。

Pod是Kurbernetes进行创建、调度和管理的最小单位。

Pod内包含的容器运行在同一宿主机上，使用相同的网络命名空间、IP地址和端口，能够通过localhost进行通。

Pod一旦被创建，就会被放入etcd存储中，随后会被Kubernetes Master调度到某个具体的Node上进行绑定，随后该Pod被对应的Node上的kubelet进程实例化成一组相关的Docker容器并启动起来，在默认情况下，当Pod里的某个容器停止时，Kubernetes会自动检测到这个问起并且重启这个Pod（重启Pod里的所有容器），如果Pod所在的Node宕机，则会将这个Node上的所有Pod重新调度到其他节点上。

2、Label
Kubernetes中的任意API对象都是通过Label进行标识，Label的实质是一系列的Key/Value键值对，其中key于value由用户自己指定。

Label可以附加在各种资源对象上，如Node、Pod、Service、RC等，一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上去。Label是Replication Controller和Service运行的基础，二者通过Label来进行关联Node上运行的Pod。

3、Node
Node是Kubernetes集群架构中运行Pod的服务节点，Node是Kubernetes集群操作的单元，用来承载被分配Pod的运行，是Pod运行的宿主机
node可以是任何形式的计算设备，只要此设备上能够有传统意义上的CPU、内存、存储空间,并且能装上k8s的集群代理程序，它都可以作为整个k8s集群一个成员,只要能装上kunelet就能成为一个节点