Kubernetes --- 详细介绍和架构详解

Kubernetes是一个跨主机集群的开源的容器调度平台,它能够自动化应用容器的部署,扩展和操做,提供以容器为中心的基础架构

目录
一. Kubernetes用途
二. Kubernetes特色
三. 介绍容器技术
四. Kubernetes能作什么?
五. 使用Kubernetes的好处
六. 了解架构

一. Kubernetes用途

Kubernetes是容器集群管理系统,是一个开源的平台,能够实现容器集群的自动化部署,自动扩缩容,维护等功能

• 快速部署应用
• 快速扩展应用
• 无缝对接新的应用功能
• 节省资源,优化硬件资源的使用

二. Kubernetes特色

• 可移植 : 支持公有云,私有云,混合云,多重云
• 可扩展 : 模块化,插件化,可挂载,可组合,支持各类形式的扩展
• 自动化 : 自动部署,自动重启,自动复制,自动伸缩/扩展,经过声明式语法提供了强大的自修复能力

Kubernetes是Google2014年建立管理的,是Google10多年大规模容器管理技术Borg的开源版本

三. 介绍容器技术

Kubernetes使用Linux容器技术来提供应用的隔离,如Docker或者rkt

容器容许你在同一台机器上运行多个服务,不只提供不一样的环境给每一个服务,并且将它们互相隔离,容器相似于虚拟机,但开销小不少

一个容器仅仅是运行在宿主机上被隔离的单个进程,仅消耗应用容器消耗的资源,不会有其余进程的开销

容器都是调用同一个内核,天然会有安全隐患

容器实现隔离机制介绍

有两个机制可用 :
第一个是Linux命名空间,它使每一个进程只能看到它本身的系统视图(文件,进程,网络接口,主机名等)
第二个是Linux控制组(cgroups),它限制了进程能使用的资源量(CPU,内存,网络带宽等)

Docker容器镜像层

容器镜像层是只读的,容器运行时,一个新的可写层在镜像层之上被建立容器中进程写入位于底层的一个文件时,此文件的一个拷贝在顶层被建立,进程写得此时拷贝

容器镜像可移植性的限制

一个在特定硬件架构之上编译的容器化应用,只能在有相同硬件架构的机器上运行

容器优势

• 敏捷的应用程序建立和部署 : 与虚拟机镜像相比,容器镜像更容器建立,提高了硬件的使用效率
• 持续开发,集成和部署 : 提供可靠与频繁的容器镜像构建和部署,能够很方便及快速的回滚(因为镜像不可变性)
• 关注开发与运维的分离 : 在构建/发布时建立应用程序容器镜像,从而将应用程序和基础架构分离
• 开发,测试和生产环境的一致性 : 在笔记本电脑上运行与云中同样
• 云和操做系统的可移植性 : 可运行在Ubuntu,RHEL,CoreOS,内部部署,Google 容器引擎和其余任何地方
• 以应用为中心的管理 : 提高了操做系统的抽象级别,以便在使用逻辑资源的操做系统上运行应用程序
• 松耦合,分布式,弹性伸缩,微服务 : 应用程序被分红更小,更独立的部分,能够动态部署和管理,而不是巨型单体应用运行在专用的大型机上
• 资源隔离 : 经过对应用进行资源隔离,能够很容易的预测应用程序性能
• 资源利用 : 高效率和高密度

四. Kubernetes能作什么?

最基础的,Kubernetes能够在物理或虚拟机集群上调度和运行应用程序容器.然而,Kubernetes还容许开发人员从物理和虚拟机'脱离',从以主机为中心的基础架构转移到以容器为中心的基础架构,这样能够提供容器固有的所有优势和益处.Kubernetes提供了基础设施来构建一个真正以容器为中心的开发环境

Kubernetes知足了生产中运行应用程序的许多常见的需求

• Pod提供复合应用并保留一个应用一个容器的容器模型
• 挂载外部存储
• Secret管理
• 应用健康检查
• 副本应用实例
• 横向自动扩缩容
• 服务发现
• 负载均衡
• 滚动更新
• 资源监测
• 日志采集和存储
• 支持自检和调试
• 认证和鉴权

这提供了平台即服务(PAAS)的简单性以及基础架构即服务(IAAS)的灵活性,并促进跨基础设施供应商的可移植性

五. 使用Kubernetes的好处

• 简化应用程序部署
• 更好的利用硬件
• 健康检查和自修复
• 自动扩容
• 简化应用部署

六. 了解架构

Kubernetes集群分为两部分 :

• Kubernetes控制平面
• (工做)节点

控制平面的组件 :

• etcd分布式持久化存储
• API服务器
• 调度器
• 控制器管理器

这些组件用来存储,管理集群状态,但它们不是运行应用的容器

工做节点上运行的组件 :

• Kubelet
• Kubelet服务代理(kube-proxy)
• 容器进行时(Docker,rkt或者其余)

附加组件 :

• Kubernetes DNS服务器
• 仪表板
• Ingress控制器
• Heapster(容器集群监控)
• 容器网络接口插件

etcd

建立的全部对象 - pod,ReplicationController,服务和私密凭据等,须要以持久化方式存储到某个地方,这样它们的manifest在API服务器重启和失败的时候才不会丢失.为此,Kubernetes使用了etcd

etcd是一个响应快,分布式,一致的Key-value存储.由于它是分布式的,故能够运行多个etcd实例来获取高可用性和更好的性能

惟一能直接和etcd通讯的是Kubernetes的API服务器.全部其余组件经过API服务器间接地读取,写入数据到etcd.这带来一些好处,其中之一就是加强乐观锁系统,验证系统的健壮性;而且,经过把实际存储机制从其余组件抽离,将来替换起来也更容易.值得强调的是,etcd是Kubernetes存储集群状态和元数据的惟一的地方

API服务器

Kubernetes API服务器做为中心组件,其余组件或者客户端都会去调用它.以RESTful API的形式提供了能够查询,修改集群状态的CRUD(Create,Read,Update,Delete)接口.他将状态存储到etcd中

API服务器除了提供一种一致的方式将对象存储到etcd,也对这些对象作校验,这样客户端就没法存入非法的对象(直接写入存储的话是有可能的).除了检验,还会处理乐观锁,这样对于并发更新的状况,对对象作更改就不会被其余客户端覆盖

API服务器的客户端之一就是使用的命令行工具kubectl,也支持监听资源

调度器

一般不会去指定pod应该运行在哪一个集群节点上,这项工做交给调度器.宏观来看,调度器的操做比较简单.就是利用API服务器的监听机制等待新建立的pod,而后给每一个新的,没有节点集的pod分配节点

调度器不会命令选中的节点去运行pod.调度器作的就是经过API服务器更新pod的定义.而后API服务器再去通知Kubelet该pod已经被调度过.当目标节点上的Kubelet发现该pod被调度到本节点,他就会建立而且运行pod的容器

尽管宏观上调度的过程看起来比较简单,但实际上为pod选择最佳节点的任务并不简单.固然,最简单的调度方式是不关心节点上已经运行的pod,随机选择一个节点.另外一方面,调度器能够利用高级技术,例如机器学习,来预测接下来几分钟或几小时哪一种类型的pod将会被调度,而后以最大的硬件利用率,无须从新调度已运行pod的方式来调度.Kubernetes的默认调度器实现方式处于最简单和最复杂程度之间

控制器管理器

API服务器只作了存储资源到etcd和通知客户端有变动的工做.调度器则只是给pod分配节点,因此须要有活跃的组件确保系统真实状态朝API服务器定义的指望的状态收敛.这个工做由控制器管理器里的控制器来实现

单个控制器,管理器进程当前组合了多个执行不一样非冲突任务的控制器.这些控制器最终会被分解到不一样的进程,若是须要的话,咱们可以用自定义实现替换它们每个

控制器包括 :

• Replication管理器(ReplicationController资源的管理器)
• ReplicaSet,DaemonSet以及Job控制器
• Deployment控制器
• StatefulSet控制器
• Node控制器
• Service控制器
• Endpoints控制器
• Namespace控制器
• PersistentVolume控制器
• 其余

Kubelet

Kubelet就是负责全部运行在工做节点上内容的组件.它第一个任务就是在API服务器中建立一个Node资源来注册该节点.而后须要持续监控API服务器是否把该节点分配给pod,而后启动pod容器.具体实现方式是告知配置好的容器进行时来从特定容器镜像运行容器,Kubelet随后持续监控运行的容器,向API服务器报告他们的状态,事件和资源消耗

Kubelet也是运行容器存活探针的组件,当探针报错时它会重启容器.最后一点,当pod从API服务器删除时,Kubelet终止容器,并通知服务器pod已经被终止了

kube-proxy

每一个工做节点都会运行kube-proxy,用于确保客户端能够经过Kubernetes API链接到你定义的服务

kube-proxy确保对服务IP和端口的链接最终能到达支持服务的某个pod处.若是有多个pod支撑一个服务,那么代理会发挥对pod的负载均衡做用

Kubernetes插件

DNS服务器

集群中的全部pod默认配置使用集群内部DNS服务器.这使得pod可以轻松地经过名称查询到服务,甚至是无头服务pod的IP地址

DNS服务pod经过kube-dns服务对外暴露,使得该pod可以像其余pod同样在集群中移动.服务的IP地址在集群每一个容器的/etc/reslv.conf文件的nameserver中定义.kube-dns pod利用API服务器的监控机制来订阅Service和Endpoint的变更,以及DNS记录的变动,是的其客户端老是可以获取到最新的DNS信息.客观的说,在Service和Endpoint资源发生变化到DNS pod收到订阅通知时间点之间,DNS记录可能会无效

Ingress控制器

Ingress控制器运行一个反向代理服务器,根据集群中定义的Ingress,service以及Endpoint资源来配置该控制器.因此须要订阅这些资源,而后每次其中一个发生变化则更新代理服务器的配置

尽管Ingress资源的定义指向一个Service,Ingress控制器会直接将流量转到服务的pod而不通过服务IP.当外部客户端经过Ingress控制器链接时,会对客户端IP进行保存,这使得在某些用例中,控制器比Service更受欢迎

其余插件都须要监听集群状态,当有变动时执行相应动做

我天天会写文章记录K8S学习之路,另外我本身整理了些云计算的学习资料,目前所有放在个人公众号"SmallBird技术分享",加入咱们一块儿学习交流,而且回复’分享’会有大数据,云计算资源惊喜等着你~