初识 kubernetes

1、简介

　　kubernetes是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单而且高效,Kubernetes提供了应用部署，规划，更新，维护的一种机制。

　　Kubernetes一个核心的特色就是可以自主的管理容器来保证云平台中的容器按照用户的指望状态运行着（好比用户想让apache一直运行，用户不须要关心怎么去作，Kubernetes会自动去监控，而后去重启，新建，总之，让apache一直提供服务），管理员能够加载一个微型服务，让规划器来找到合适的位置，同时，Kubernetes也系统提高工具以及人性化方面，让用户可以方便的部署本身的应用（就像canary deployments）。

2、设计架构

　　Kubernetes集群包含有节点代理kubelet和Master组件(APIs, scheduler, etc)，一切都基于分布式的存储系统。下面这张图是Kubernetes的架构图。

 

 

kuberrnetes节点

　　在这张系统架构图中，咱们把服务分为运行在工做节点上的服务和组成集群级别控制板的服务。

　　Kubernetes节点有运行应用容器必备的服务，而这些都是受Master的控制。

　　每次个节点上固然都要运行Docker。Docker来负责全部具体的映像下载和容器运行。

　　Kubernetes主要由如下几个核心组件组成：　　

• etcd保存了整个集群的状态；
• apiserver提供了资源操做的惟一入口，并提供认证、受权、访问控制、API注册和发现等机制；
• controller manager负责维护集群的状态，好比故障检测、自动扩展、滚动更新等；
• scheduler负责资源的调度，按照预约的调度策略将Pod调度到相应的机器上；
• kubelet负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；
• Container runtime负责镜像管理以及Pod和容器的真正运行（CRI）；
• kube-proxy负责为Service提供cluster内部的服务发现和负载均衡；

　　除了核心组件，还有一些推荐的Add-ons：

• kube-dns负责为整个集群提供DNS服务
• Ingress Controller为服务提供外网入口
• Heapster提供资源监控
• Dashboard提供GUI
• Federation提供跨可用区的集群
• Fluentd-elasticsearch提供集群日志采集、存储与查询

 

 

3、kubernetes的基本概念和API对象

API对象是K8s集群中的管理操做单元。K8s集群系统每支持一项新功能，引入一项新技术，必定会新引入对应的API对象，支持对该功能的管理操做。例如副本集Replica Set对应的API对象是RS。

每一个API对象都有3大类属性：元数据metadata、规范spec和状态status。元数据是用来标识API对象的，每一个对象都至少有3个元数据：namespace，name和uid；除此之外还有各类各样的标签labels用来标识和匹配不一样的对象，例如用户能够用标签env来标识区分不一样的服务部署环境，分别用env=dev、env=testing、env=production来标识开发、测试、生产的不一样服务。规范描述了用户指望K8s集群中的分布式系统达到的理想状态（Desired State），例如用户能够经过复制控制器Replication Controller设置指望的Pod副本数为3；status描述了系统实际当前达到的状态（Status），例如系统当前实际的Pod副本数为2；那么复制控制器当前的程序逻辑就是自动启动新的Pod，争取达到副本数为3。

K8s中全部的配置都是经过API对象的spec去设置的，也就是用户经过配置系统的理想状态来改变系统，这是k8s重要设计理念之一，即全部的操做都是声明式（Declarative）的而不是命令式（Imperative）的。声明式操做在分布式系统中的好处是稳定，不怕丢操做或运行屡次，例如设置副本数为3的操做运行屡次也仍是一个结果，而给副本数加1的操做就不是声明式的，运行屡次结果就错了。

Pod

K8s有不少技术概念，同时对应不少API对象，最重要的也是最基础的是微服务Pod。Pod是在K8s集群中运行部署应用或服务的最小单元，它是能够支持多容器的。Pod的设计理念是支持多个容器在一个Pod中共享网络地址和文件系统，能够经过进程间通讯和文件共享这种简单高效的方式组合完成服务。Pod对多容器的支持是K8s最基础的设计理念。好比你运行一个操做系统发行版的软件仓库，一个Nginx容器用来发布软件，另外一个容器专门用来从源仓库作同步，这两个容器的镜像不太多是一个团队开发的，可是他们一起工做才能提供一个微服务；这种状况下，不一样的团队各自开发构建本身的容器镜像，在部署的时候组合成一个微服务对外提供服务。

Pod是K8s集群中全部业务类型的基础，能够看做运行在K8s集群中的小机器人，不一样类型的业务就须要不一样类型的小机器人去执行。目前K8s中的业务主要能够分为长期伺服型（long-running）、批处理型（batch）、节点后台支撑型（node-daemon）和有状态应用型（stateful application）；分别对应的小机器人控制器为Deployment、Job、DaemonSet和PetSet，本文后面会一一介绍。

复制控制器（Replication Controller，RC）

RC是K8s集群中最先的保证Pod高可用的API对象。经过监控运行中的Pod来保证集群中运行指定数目的Pod副本。指定的数目能够是多个也能够是1个；少于指定数目，RC就会启动运行新的Pod副本；多于指定数目，RC就会杀死多余的Pod副本。即便在指定数目为1的状况下，经过RC运行Pod也比直接运行Pod更明智，由于RC也能够发挥它高可用的能力，保证永远有1个Pod在运行。RC是K8s较早期的技术概念，只适用于长期伺服型的业务类型，好比控制小机器人提供高可用的Web服务。

副本集（Replica Set，RS）

RS是新一代RC，提供一样的高可用能力，区别主要在于RS后来居上，能支持更多种类的匹配模式。副本集对象通常不单独使用，而是做为Deployment的理想状态参数使用。

部署(Deployment)

部署表示用户对K8s集群的一次更新操做。部署是一个比RS应用模式更广的API对象，能够是建立一个新的服务，更新一个新的服务，也能够是滚动升级一个服务。滚动升级一个服务，实际是建立一个新的RS，而后逐渐将新RS中副本数增长到理想状态，将旧RS中的副本数减少到0的复合操做；这样一个复合操做用一个RS是不太好描述的，因此用一个更通用的Deployment来描述。以K8s的发展方向，将来对全部长期伺服型的的业务的管理，都会经过Deployment来管理。

服务（Service）

RC、RS和Deployment只是保证了支撑服务的微服务Pod的数量，可是没有解决如何访问这些服务的问题。一个Pod只是一个运行服务的实例，随时可能在一个节点上中止，在另外一个节点以一个新的IP启动一个新的Pod，所以不能以肯定的IP和端口号提供服务。要稳定地提供服务须要服务发现和负载均衡能力。服务发现完成的工做，是针对客户端访问的服务，找到对应的的后端服务实例。在K8s集群中，客户端须要访问的服务就是Service对象。每一个Service会对应一个集群内部有效的虚拟IP，集群内部经过虚拟IP访问一个服务。在K8s集群中微服务的负载均衡是由Kube-proxy实现的。Kube-proxy是K8s集群内部的负载均衡器。它是一个分布式代理服务器，在K8s的每一个节点上都有一个；这一设计体现了它的伸缩性优点，须要访问服务的节点越多，提供负载均衡能力的Kube-proxy就越多，高可用节点也随之增多。与之相比，咱们平时在服务器端作个反向代理作负载均衡，还要进一步解决反向代理的负载均衡和高可用问题。

任务（Job）

Job是K8s用来控制批处理型任务的API对象。批处理业务与长期伺服业务的主要区别是批处理业务的运行有头有尾，而长期伺服业务在用户不中止的状况下永远运行。Job管理的Pod根据用户的设置把任务成功完成就自动退出了。成功完成的标志根据不一样的spec.completions策略而不一样：单Pod型任务有一个Pod成功就标志完成；定数成功型任务保证有N个任务所有成功；工做队列型任务根据应用确认的全局成功而标志成功。

后台支撑服务集（DaemonSet）

长期伺服型和批处理型服务的核心在业务应用，可能有些节点运行多个同类业务的Pod，有些节点上又没有这类Pod运行；然后台支撑型服务的核心关注点在K8s集群中的节点（物理机或虚拟机），要保证每一个节点上都有一个此类Pod运行。节点多是全部集群节点也多是经过nodeSelector选定的一些特定节点。典型的后台支撑型服务包括，存储，日志和监控等在每一个节点上支持K8s集群运行的服务。

有状态服务集（PetSet）

K8s在1.3版本里发布了Alpha版的PetSet功能。在云原生应用的体系里，有下面两组近义词；第一组是无状态（stateless）、牲畜（cattle）、无名（nameless）、可丢弃（disposable）；第二组是有状态（stateful）、宠物（pet）、有名（having name）、不可丢弃（non-disposable）。RC和RS主要是控制提供无状态服务的，其所控制的Pod的名字是随机设置的，一个Pod出故障了就被丢弃掉，在另外一个地方重启一个新的Pod，名字变了、名字和启动在哪儿都不重要，重要的只是Pod总数；而PetSet是用来控制有状态服务，PetSet中的每一个Pod的名字都是事先肯定的，不能更改。PetSet中Pod的名字的做用，并非《千与千寻》的人性缘由，而是关联与该Pod对应的状态。

对于RC和RS中的Pod，通常不挂载存储或者挂载共享存储，保存的是全部Pod共享的状态，Pod像牲畜同样没有分别（这彷佛也确实意味着失去了人性特征）；对于PetSet中的Pod，每一个Pod挂载本身独立的存储，若是一个Pod出现故障，从其余节点启动一个一样名字的Pod，要挂载上原来Pod的存储继续以它的状态提供服务。

适合于PetSet的业务包括数据库服务MySQL和PostgreSQL，集群化管理服务Zookeeper、etcd等有状态服务。PetSet的另外一种典型应用场景是做为一种比普通容器更稳定可靠的模拟虚拟机的机制。传统的虚拟机正是一种有状态的宠物，运维人员须要不断地维护它，容器刚开始流行时，咱们用容器来模拟虚拟机使用，全部状态都保存在容器里，而这已被证实是很是不安全、不可靠的。使用PetSet，Pod仍然能够经过漂移到不一样节点提供高可用，而存储也能够经过外挂的存储来提供高可靠性，PetSet作的只是将肯定的Pod与肯定的存储关联起来保证状态的连续性。PetSet还只在Alpha阶段，后面的设计如何演变，咱们还要继续观察。

集群联邦（Federation）

K8s在1.3版本里发布了beta版的Federation功能。在云计算环境中，服务的做用距离范围从近到远通常能够有：同主机（Host，Node）、跨主机同可用区（Available Zone）、跨可用区同地区（Region）、跨地区同服务商（Cloud Service Provider）、跨云平台。K8s的设计定位是单一集群在同一个地域内，由于同一个地区的网络性能才能知足K8s的调度和计算存储链接要求。而联合集群服务就是为提供跨Region跨服务商K8s集群服务而设计的。

每一个K8s Federation有本身的分布式存储、API Server和Controller Manager。用户能够经过Federation的API Server注册该Federation的成员K8s Cluster。当用户经过Federation的API Server建立、更改API对象时，Federation API Server会在本身全部注册的子K8s Cluster都建立一份对应的API对象。在提供业务请求服务时，K8s Federation会先在本身的各个子Cluster之间作负载均衡，而对于发送到某个具体K8s Cluster的业务请求，会依照这个K8s Cluster独立提供服务时同样的调度模式去作K8s Cluster内部的负载均衡。而Cluster之间的负载均衡是经过域名服务的负载均衡来实现的。

全部的设计都尽可能不影响K8s Cluster现有的工做机制，这样对于每一个子K8s集群来讲，并不须要更外层的有一个K8s Federation，也就是意味着全部现有的K8s代码和机制不须要由于Federation功能有任何变化。

存储卷（Volume）

K8s集群中的存储卷跟Docker的存储卷有些相似，只不过Docker的存储卷做用范围为一个容器，而K8s的存储卷的生命周期和做用范围是一个Pod。每一个Pod中声明的存储卷由Pod中的全部容器共享。K8s支持很是多的存储卷类型，特别的，支持多种公有云平台的存储，包括AWS，Google和Azure云；支持多种分布式存储包括GlusterFS和Ceph；也支持较容易使用的主机本地目录hostPath和NFS。K8s还支持使用Persistent Volume Claim即PVC这种逻辑存储，使用这种存储，使得存储的使用者能够忽略后台的实际存储技术（例如AWS，Google或GlusterFS和Ceph），而将有关存储实际技术的配置交给存储管理员经过Persistent Volume来配置。

持久存储卷（Persistent Volume，PV）和持久存储卷声明（Persistent Volume Claim，PVC）

PV和PVC使得K8s集群具有了存储的逻辑抽象能力，使得在配置Pod的逻辑里能够忽略对实际后台存储技术的配置，而把这项配置的工做交给PV的配置者，即集群的管理者。存储的PV和PVC的这种关系，跟计算的Node和Pod的关系是很是相似的；PV和Node是资源的提供者，根据集群的基础设施变化而变化，由K8s集群管理员配置；而PVC和Pod是资源的使用者，根据业务服务的需求变化而变化，有K8s集群的使用者即服务的管理员来配置。

节点（Node）

K8s集群中的计算能力由Node提供，最初Node称为服务节点Minion，后来更名为Node。K8s集群中的Node也就等同于Mesos集群中的Slave节点，是全部Pod运行所在的工做主机，能够是物理机也能够是虚拟机。不管是物理机仍是虚拟机，工做主机的统一特征是上面要运行kubelet管理节点上运行的容器。

密钥对象（Secret）

Secret是用来保存和传递密码、密钥、认证凭证这些敏感信息的对象。使用Secret的好处是能够避免把敏感信息明文写在配置文件里。在K8s集群中配置和使用服务不可避免的要用到各类敏感信息实现登陆、认证等功能，例如访问AWS存储的用户名密码。为了不将相似的敏感信息明文写在全部须要使用的配置文件中，能够将这些信息存入一个Secret对象，而在配置文件中经过Secret对象引用这些敏感信息。这种方式的好处包括：意图明确，避免重复，减小暴漏机会。

用户账户（User Account）和服务账户（Service Account）

顾名思义，用户账户为人提供帐户标识，而服务帐户为计算机进程和K8s集群中运行的Pod提供帐户标识。用户账户和服务账户的一个区别是做用范围；用户账户对应的是人的身份，人的身份与服务的namespace无关，因此用户帐户是跨namespace的；而服务账户对应的是一个运行中程序的身份，与特定namespace是相关的。

名字空间（Namespace）

名字空间为K8s集群提供虚拟的隔离做用，K8s集群初始有两个名字空间，分别是默认名字空间default和系统名字空间kube-system，除此之外，管理员能够能够建立新的名字空间知足须要。

RBAC访问受权

K8s在1.3版本中发布了alpha版的基于角色的访问控制（Role-based Access Control，RBAC）的受权模式。相对于基于属性的访问控制（Attribute-based Access Control，ABAC），RBAC主要是引入了角色（Role）和角色绑定（RoleBinding）的抽象概念。在ABAC中，K8s集群中的访问策略只能跟用户直接关联；而在RBAC中，访问策略能够跟某个角色关联，具体的用户在跟一个或多个角色相关联。显然，RBAC像其余新功能同样，每次引入新功能，都会引入新的API对象，从而引入新的概念抽象，而这一新的概念抽象必定会使集群服务管理和使用更容易扩展和重用。

 

5、核心技术概念简介

一、pod

　　一个Pod（就像一群鲸鱼，或者一个豌豆夹）至关于一个共享context的配置组，在同一个context下，应用可能还会有独立的cgroup隔离机制，一个Pod是一个容器环境下的“逻辑主机”，它可能包含一个或者多个紧密相连的应用，这些应用多是在同一个物理主机或虚拟机上。

　　Pod 的context能够理解成多个linux命名空间的联合

• PID 命名空间（同一个Pod中应用能够看到其它进程）
• 网络 命名空间（同一个Pod的中的应用对相同的IP地址和端口有权限）
• IPC 命名空间（同一个Pod中的应用能够经过VPC或者POSIX进行通讯）
• UTS 命名空间（同一个Pod中的应用共享一个主机名称）

　　同一个Pod中的应用能够共享磁盘，磁盘是Pod级的，应用能够经过文件系统调用，额外的，一个Pod可能会定义顶级的cgroup隔离，这样的话绑定到任何一个应用（好吧，这句是在没怎么看懂，就是说Pod，应用，隔离）

　　因为docker的架构，一个Pod是由多个相关的而且共享磁盘的容器组成，Pid的命名空间共享尚未应用到Docker中和相互独立的容器同样，Pod是一种相对短暂的存在，而不是持久存在的，正如咱们在Pod的生命周期中提到的，Pod被安排到结点上，而且保持在这个节点上直到被终止（根据重启的设定）或者被删除，当一个节点死掉以后，上面的全部Pod均会被删除。特殊的Pod永远不会被转移到的其余的节点，做为替代，他们必须被replace.

二、labels（标签）

　　标签其实就一对 key/value ，被关联到对象上，好比Pod,标签的使用咱们倾向于可以标示对象的特殊特色，而且对用户而言是有意义的（就是一眼就看出了这个Pod是尼玛数据库），可是标签对内核系统是没有直接意义的。标签能够用来划分特定组的对象（好比，全部女的），标签能够在建立一个对象的时候直接给与，也能够在后期随时修改，每个对象能够拥有多个标签，可是，key值必须是惟一的。

三、namespace（名称空间）

　　Namespace是对一组资源和对象的抽象集合，好比能够用来将系统内部的对象划分为不一样的项目组或用户组。常见的pods, services, replication controllers和deployments等都是属于某一个namespace的（默认是default），而node, persistentVolumes等则不属于任何namespace。

　　Namespace经常使用来隔离不一样的用户，好比Kubernetes自带的服务通常运行在kube-system namespace中。

四、replication controller

　　Replication Controller 保证了在全部时间内，都有特定数量的Pod副本正在运行，若是太多了，Replication Controller就杀死几个，若是太少了，Replication Controller会新建几个，和直接建立的pod不一样的是，Replication Controller会替换掉那些删除的或者被终止的pod，无论删除的缘由是什么（维护阿，更新啊，Replication Controller都不关心）。基于这个理由，咱们建议即便是只建立一个pod，咱们也要使用Replication Controller。Replication Controller 就像一个进程管理器，监管着不一样node上的多个pod,而不是单单监控一个node上的pod,Replication Controller 会委派本地容器来启动一些节点上服务（Kubelet ,Docker）。

　　正如咱们在pod的生命周期中讨论的，Replication Controller只会对那些RestartPolicy = Always的Pod的生效，（RestartPolicy的默认值就是Always）,Replication Controller 不会去管理那些有不一样启动策略pod如咱们在issue #503讨论的，咱们但愿在未来别的控制器被加入到Kubernete中来管理一些例如负载阿，测试等相关功能。

　　Replication Controller永远不会本身关闭，可是，咱们并不但愿Replication Controller成为一个长久存在的服务。服务可能会有多个Pod组成，这些Pod又被多个Replication Controller控制着，咱们但愿Replication Controller 会在服务的生命周期中被删除和新建（例如在这些pod中发布一个更新），对于服务和用户来讲，Replication Controller是经过一种无形的方式来维持着服务的状态。

五、node

　　Node是Pod真正运行的主机，能够物理机，也能够是虚拟机。为了管理Pod，每一个Node节点上至少要运行container runtime（好比docker或者rkt）、kubelet和kube-proxy服务。

六、replicaset

　　ReplicaSet是下一代复本控制器。ReplicaSet和 Replication Controller之间的惟一区别是如今的选择器支持。Replication Controller只支持基于等式的selector（env=dev或environment!=qa），但ReplicaSet还支持新的，基于集合的selector（version in (v1.0, v2.0)或env notin (dev, qa)）。在试用时官方推荐ReplicaSet。

　　大多数kubectl支持Replication Controller的命令也支持ReplicaSets。rolling-update命令有一个例外 。若是您想要滚动更新功能，请考虑使用Deployments。此外， rolling-update命令是必须的，而Deployments是声明式的，所以咱们建议经过rollout命令使用Deployments。

　　虽然ReplicaSets能够独立使用，可是今天它主要被 Deployments 做为协调pod建立，删除和更新的机制。当您使用Deployments时，您没必要担忧管理他们建立的ReplicaSets。Deployments拥有并管理其ReplicaSets。

七、service

　　Kubernetes Pod是平凡的，它门会被建立，也会死掉（生老病死），而且他们是不可复活的。 ReplicationControllers动态的建立和销毁Pods(好比规模扩大或者缩小，或者执行动态更新)。每一个pod都由本身的ip，这些IP也随着时间的变化也不能持续依赖。这样就引起了一个问题：若是一些Pods（让咱们叫它做后台，后端）提供了一些功能供其它的Pod使用（让咱们叫做前台），在kubernete集群中是如何实现让这些前台可以持续的追踪到这些后台的？

答案是：Service

　　Kubernete Service 是一个定义了一组Pod的策略的抽象，咱们也有时候叫作宏观服务。这些被服务标记的Pod都是（通常）经过label Selector决定的（下面咱们会讲到咱们为何须要一个没有label selector的服务）。举个例子，咱们假设后台是一个图形处理的后台，而且由3个副本。这些副本是能够相互替代的，而且前台不须要关心使用的哪个后台Pod，当这个承载前台请求的pod发生变化时，前台并不须要知道这些变化，或者追踪后台的这些副本，服务是这些pod的集合。

　　对于Kubernete原生的应用，Kubernete提供了一个简单的Endpoints API，这个Endpoints api的做用就是当一个服务中的pod发生变化时，Endpoints API随之变化，对于哪些不是原生的程序，Kubernetes提供了一个基于虚拟IP的网桥的服务，这个服务会将请求转发到对应的后台pod。

八、volume

　　容器中的磁盘的生命周期是短暂的，这就带来了一系列的问题，第一，当一个容器损坏以后，kubelet 会重启这个容器，可是文件会丢失-这个容器会是一个全新的状态，第二，当不少容器在同一Pod中运行的时候，不少时候须要数据文件的共享。Kubernete Volume解决了这个问题。

九、pv&pvc&storageclass

　　PersistentVolume（PV）是集群中已由管理员配置的一段网络存储。 集群中的资源就像一个节点是一个集群资源。 PV是诸如卷之类的卷插件，可是具备独立于使用PV的任何单个pod的生命周期。 该API对象捕获存储的实现细节，即NFS，iSCSI或云提供商特定的存储系统。
　　PersistentVolumeClaim（PVC）是用户存储的请求。 它相似于pod。 Pod消耗节点资源，PVC消耗光伏资源。 荚能够请求特定级别的资源（CPU和内存）。 权利要求能够请求特定的大小和访问模式（例如，能够一旦读/写或只读许屡次安装）。
　　虽然PersistentVolumeClaims容许用户使用抽象存储资源，可是常见的是，用户须要具备不一样属性（如性能）的PersistentVolumes，用于不一样的问题。 群集管理员须要可以提供多种不一样于PersistentVolumes的PersistentVolumes，而不只仅是大小和访问模式，而不会使用户了解这些卷的实现细节。 对于这些需求，存在StorageClass资源。

　　StorageClass为管理员提供了一种描述他们提供的存储的“类”的方法。 不一样的类可能映射到服务质量级别，或备份策略，或者由群集管理员肯定的任意策略。 Kubernetes自己对于什么类别表明是不言而喻的。 这个概念有时在其余存储系统中称为“配置文件”。

十、deployment

　　Deployment为Pod和Replica Set（下一代Replication Controller）提供声明式更新。

　　你只须要在Deployment中描述你想要的目标状态是什么，Deployment controller就会帮你将Pod和Replica Set的实际状态改变到你的目标状态。你能够定义一个全新的Deployment，也能够建立一个新的替换旧的Deployment。

　　一个典型的用例以下：

• 使用Deployment来建立ReplicaSet。ReplicaSet在后台建立pod。检查启动状态，看它是成功仍是失败。
• 而后，经过更新Deployment的PodTemplateSpec字段来声明Pod的新状态。这会建立一个新的ReplicaSet，Deployment会按照控制的速率将pod从旧的ReplicaSet移动到新的ReplicaSet中。
• 若是当前状态不稳定，回滚到以前的Deployment revision。每次回滚都会更新Deployment的revision。
• 扩容Deployment以知足更高的负载。
• 暂停Deployment来应用PodTemplateSpec的多个修复，而后恢复上线。
• 根据Deployment 的状态判断上线是否hang住了。
• 清除旧的没必要要的ReplicaSet。

十一、statefulset

　　StatefulSet是为了解决有状态服务的问题（对应Deployments和ReplicaSets是为无状态服务而设计），其应用场景包括

• 稳定的持久化存储，即Pod从新调度后仍是能访问到相同的持久化数据，基于PVC来实现
• 稳定的网络标志，即Pod从新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现
• 有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从0到N-1，在下一个Pod运行以前全部以前的Pod必须都是Running和Ready状态），基于init containers来实现
• 有序收缩，有序删除（即从N-1到0）

　　从上面的应用场景能够发现，StatefulSet由如下几个部分组成：

• 用于定义网络标志（DNS domain）的Headless Service
• 用于建立PersistentVolumes的volumeClaimTemplates
• 定义具体应用的StatefulSet

　　StatefulSet中每一个Pod的DNS格式为statefulSetName-{0..N-1}.serviceName.namespace.svc.cluster.local，其中

• serviceName为Headless Service的名字
• 0..N-1为Pod所在的序号，从0开始到N-1
• statefulSetName为StatefulSet的名字
• namespace为服务所在的namespace，Headless Servic和StatefulSet必须在相同的namespace
• .cluster.local为Cluster Domain，

十二、daemonset

　　DaemonSet保证在每一个Node上都运行一个容器副本，经常使用来部署一些集群的日志、监控或者其余系统管理应用。典型的应用包括：

• 日志收集，好比fluentd，logstash等
• 系统监控，好比Prometheus Node Exporter，collectd，New Relic agent，Ganglia gmond等
• 系统程序，好比kube-proxy, kube-dns, glusterd, ceph等

1三、job

　　Job负责批量处理短暂的一次性任务 (short lived one-off tasks)，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束。

　　Kubernetes支持如下几种Job：

• 非并行Job：一般建立一个Pod直至其成功结束
• 固定结束次数的Job：设置.spec.completions，建立多个Pod，直到.spec.completions个Pod成功结束
• 带有工做队列的并行Job：设置.spec.Parallelism但不设置.spec.completions，当全部Pod结束而且至少一个成功时，Job就认为是成功

　　根据.spec.completions和.spec.Parallelism的设置，能够将Job划分为如下几种pattern：

Job类型	使用示例	行为	completions	Parallelism
一次性Job	数据库迁移	建立一个Pod直至其成功结束	1	1
固定结束次数的Job	处理工做队列的Pod	依次建立一个Pod运行直至completions个成功结束	2+	1
固定结束次数的并行Job	多个Pod同时处理工做队列	依次建立多个Pod运行直至completions个成功结束	2+	2+
并行Job	多个Pod同时处理工做队列	建立一个或多个Pod直至有一个成功结束	1	2+

 

 

1四、ingress

　　一般状况下，service和pod的IP仅可在集群内部访问（四层）。集群外部的请求须要经过负载均衡转发到service在Node上暴露的NodePort上，而后再由kube-proxy将其转发给相关的Pod。

而Ingress就是为进入集群的请求提供路由规则的集合（七层）。

　　Ingress能够给service提供集群外部访问的URL、负载均衡、SSL终止、HTTP路由等。为了配置这些Ingress规则，集群管理员须要部署一个Ingress controller，它监听Ingress和service的变化，并根据规则配置负载均衡并提供访问入口。