Kubernetes做为容器编排生态圈中重要一员,是Google大规模容器管理系统borg的开源版本实现,吸取借鉴了google过去十年间在生产环境上所学到的经验与教训。 Kubernetes提供应用部署、维护、 扩展机制等功能,利用Kubernetes能方便地管理跨机器运行容器化的应用。当前Kubernetes支持GCE、vShpere、CoreOS、OpenShift、Azure等平台,除此以外,也能够直接运行在物理机上.kubernetes是一个开放的容器调度管理平台,不限定任何一种言语,支持java/C++/go/python等各种应用程序 。
kubernetes是一个完备的分布式系统支持平台,支持多层安全防御、准入机制、多租户应用支撑、透明的服务注册、服务发现、内建负载均衡、强大的故障发现和自我修复机制、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力,完善的管理工具,包括开发、测试、部署、运维监控,一站式的完备的分布式系统开发和支撑平台。前端
实际上,使用Kubernetes只需一个部署文件,使用一条命令就能够部署多层容器(前端,后台等)的完整集群java
(1)Podnode
Pod是Kubernetes中最小部署单元,全部的容器均在Pod中运行,一个Pod能够承载一个或者多个相关的容器。Pod中容器共享存储和网络,同一个Pod中的容器会部署在同一个docker宿主机上而且可以共享资源。python
(2)Serviceweb
Service是一个应用服务抽象,定义了Pod逻辑集合和访问这个pod集合的策略(好比访问策略)。Service代理Pod集合对外表现为一个访问入口,分配一个机器IP地址,来自这个IP的请求将负载均衡转发到后端Pod中的容器。Service经过Lable Selector选择一组Pod提供服务。算法
(3)Volumedocker
数据卷后端
(4)Namespaceapi
是kubernetes系统中的另外一个重要的概念,经过将系统内部的对象“分配”到不一样的Namespace中,造成逻辑上分组的不一样项目、小组或用户组,便于不一样的分组在共享使用整个集群的资源的同时还能被分别管理。Kubernetes集群在启动后,会建立一个名为“default”的Namespace,若是不特别指明Namespace,则用户建立的Pod、RC、Service都被系统建立到“default”的Namespace中。安全
(5)Label
Label机制是K8S中一个重要设计,经过Label进行对象弱关联,灵活地分类和选择不一样服务或业务,让用户根据本身特定的组织结构以松耦合方式进行服务部署。Label是一对KV,对用户而言很是有意义的,但对K8S自己而言没有直接意义的。Label能够在建立对象时指定,也能够在后期修改,每一个对象能够拥有多个标签,但key值必须是惟一的。
(6)RC(Replication Controller)
Replication Controller确保任什么时候候Kubernetes集群中有指定数量的pod副本(replicas)在运行, 若是少于指定数量的pod副本(replicas),Replication Controller会启动新的Container,反之会杀死多余的以保证数量不变。Replication Controller使用预先定义的pod模板建立pods,一旦建立成功,pod 模板和建立的pods没有任何关联,能够修改pod 模板而不会对已建立pods有任何影响,也能够直接更新经过Replication Controller建立的pods。对于利用pod 模板建立的pods,Replication Controller根据label selector来关联,经过修改pods的label能够删除对应的pods。
(7)Deployment
Kubernetes Deployment提供了官方的用于更新Pod和Replica Set(下一代的Replication Controller)的方法,您能够在Deployment对象中只描述您所指望的理想状态(预期的运行状态),Deployment控制器为您将如今的实际状态转换成您指望的状态,例如,您想将全部的webapp:v1.0.9升级成webapp:v1.1.0,您只需建立一个Deployment,Kubernetes会按照Deployment自动进行升级。如今,您能够经过Deployment来建立新的资源(pod,rs,rc),替换已经存在的资源等。
Deployment集成了上线部署、滚动升级、建立副本、暂停上线任务,恢复上线任务,回滚到之前某一版本(成功/稳定)的Deployment等功能,在某种程度上,Deployment能够帮咱们实现无人值守的上线,大大下降咱们的上线过程的复杂沟通、操做风险。
(8)StatefulSet
使用Deployment建立的Pod是无状态的,当挂在Volume以后,若是该Pod挂了,Replication Controller会再run一个来保证可用性,可是因为是无状态的,Pod挂了的时候与以前的Volume的关系就已经断开了,新起来的Pod没法找到以前volume。StatefulSet 的目的就是给为数众多的有状态负载提供正确的控制器支持。
当应用有如下任意要求时,StatefulSet的价值就体现出来了。
● 稳定的、惟一的网络标识。
● 稳定的、持久化的存储。
● 有序的、优雅的部署和扩展。
● 有序的、优雅的删除和中止。
(9)DaemonSet
DaemonSet可以让全部(或者一些特定)的Node节点运行同一个pod。当节点加入到kubernetes集群中,pod会被(DaemonSet)调度到该节点上运行,当节点从kubernetes集群中被移除,被(DaemonSet)调度的pod会被移除,若是删除DaemonSet,全部跟这个DaemonSet相关的pods都会被删除。
(10)Job
在有些场景下,是想要运行一些容器执行某种特定的任务,任务一旦执行完成,容器也就没有存在的必要了。在这种场景下,建立pod就显得不那么合适。因而就是了Job,Job指的就是那些一次性任务。经过Job运行一个容器,当其任务执行完之后,就自动退出,集群也再也不从新将其唤醒。还能够执行定时任务。
1.kubectl
客户端命令行工具,将接受的命令格式化后发送给kube-apiserver,做为整个系统的操做入口。
2.kube-apiserver
做为整个系统的控制入口,以REST API服务提供接口。
3.kube-controller-manager
用来执行整个系统中的后台任务,包括节点状态情况、Pod个数、Pods和Service的关联等。
4.kube-scheduler
负责节点资源管理,接受来自kube-apiserver建立Pods任务,并分配到某个节点。
5.etcd
负责节点间的服务发现和配置共享。
6.kube-proxy
运行在每一个计算节点上,负责Pod网络代理。定时从etcd获取到service信息来作相应的策略。
7.kubelet
运行在每一个计算节点上,做为agent,接受分配该节点的Pods任务及管理容器,周期性获取容器状态,反馈给kube-apiserver。
8.DNS
一个可选的DNS服务,用于为每一个Service对象建立DNS记录,这样全部的Pod就能够经过DNS访问服务了。
1.Kubectl(user commands): k8s APIs客户端工具,经过用户输入命令操做APIs资源
2.认证,用户输入命令要经过APIs的认证
3.认证经过以后,交由APIs中REST中对象处理(Kubernetes以RESTFul形式开放接口,用户可操做的REST对象有三个Pod,service,controller)
4.APIs中的操做处理都会持久化存储到一个分布式存储etcd
5.Scheduler调度组件,会检测REST对象中是否有新的动做产生,并将具体操做,根据算法下发到node节点中
6.Controller经过API Server提供的接口实时监控整个集群的每一个资源对象的当前状态,当发生各类故障致使系统状态发生变化时,会尝试将系统状态修复到“指望状态”
7.kubeletl相似于一个agent,处理AIPs下发的任务,如建立Pod、容器、获取节点信息等
8.proxy负责网络代理,Service具体实现就是有proxy处理,维护网络规则和四层负载均衡工做