应用部署方式演变
传统部署
:互联网早期,会直接将应用程序部署在物理机上
- 优点:简单,不需要其他技术的参与
- 缺点:不能为应用程序定义资源使用边界,很难合理地分配计算机资源,而且程序之间容易产生影响
虚拟化部署
:可以在一台物理机
上运行多个虚拟机
,每个虚拟机
都是独立的一个环境
- 优点:程序环境不会相互产生影响,提供了一定程度的安全性
- 缺点:增加了操作系统,浪费了部分资源
容器化部署
:与虚拟化类似,但是共享了操作系统
注意
容器化部署方式
给我们带来了很多的便利,但是也会出现一些问题,比如说:
一个容器
故障停机
了,怎么样让另外一个容器
立刻启动去替补停机的容器
- 当
并发访问量变大
的时候,怎么样做到横向扩展容器数量
容器编排应用
为了解决这些容器编排问题
,就产生了一些容器编排的软件
:
Swarm
:Docker
自己的容器编排工具
Mesos
:Apache
的一个资源统一管控
的工具,需要和Marathon
结合使用Kubernetes
:Google
开源的的容器编排工具
Kubernetes
简介
- 在
Docker
作为高级容器引擎
快速发展的同时
,在Google
内部,容器技术
已经应用了很多年 Borg系统
运行管理着成千上万的容器应用
。Kubernetes
项目来源于Borg
,可以说是集结了Borg
设计思想的精华,并且吸收了Borg
系统中的经验和教训
。Kubernetes
对计算资源
进行了更高层次的抽象
,通过将容器
进行细致的组合
,将最终的应用服务
交给用户
。
kubernetes
的本质
是一组服务器集群
,它可以在集群
的每个节点上
运行特定的程序
,来对节点
中的容器
进行管理
。目的是实现资源管理
的自动化
,主要提供了如下的主要功能
:
自我修复
:一旦某一个容器崩溃
,能够在1秒
中左右迅速启动新的容器
弹性伸缩
:可以根据需要,自动
对集群
中正在运行的容器
数量进行调整
服务发现
:服务
可以通过自动发现
的形式找到它所依赖的服务
负载均衡
:如果一个服务
起动了多个容器
,能够自动
实现请求的负载均衡
版本回退
:如果发现新发布的程序
版本有问题
,可以立即回退到原来的版本
存储编排
:可以根据容器自身的需求
自动创建存储卷
k8s
的设计架构
一个kubernetes
集群主要是由控制节点
(master
)、工作节点
(node
)构成,每个节点上
都会安装不同的组件
master
:集群的控制平面
,负责集群的决策
ApiServer
:资源操作
的唯一入口
,接收用户输入
的命令
,提供认证、授权、API注册和发现
等机制Scheduler
: 负责集群资源调度
,按照预定的调度策略
将Pod
调度到相应的node节点
上。scheduler
会合理
的对node
上的的pod
进行调度
ControllerManager
: 负责维护集群的状态
,比如程序部署安排、故障检测、自动扩展、滚动更新
等Etcd
:负责存储
集群中各种资源对象的信息,状态等
,记录k8s
集群期望的状态
,当实际状态
和Etcd
中记录的期望状态不一致
时,由controler-manager
进行控制
node
:集群的数据平面
,负责为容器
提供运行环境
kubelet
:负责维护容器
的生命周期
,同时也负责Volume
(CVI
)和网络
(CNI
)的管理
,接收apiserver
传过来的信息,来构建容器
Container runtime
:负责镜像管理
以及Pod
和容器
的真正运行
(CRI
)kube-proxy
:负责为Service
提供cluster
内部的服务发现
和负载均衡
,也可以说是负责网络通信
总结
- 可以把
pod
理解为一个系统
,Container容器
理解为一个程序
,一个系统
中可以跑多个程序
外部访问
的时候感觉是3台主机
,其实是3台pod
pod
可以想象为一台linux真机
中的虚拟机
,虚拟机
可以有多个
k8s
各组件之间的调用关系
当我们要运行一个web
服务时
kubernetes
环境启动之后,master
和node
都会将自身的信息
存储到etcd数据库
中web服务
的安装请求
会首先被发送到master节点
的apiServer组件
apiServer组件
会调用scheduler组件
来决定
到底应该把这个服务
安装到哪个node节点
上。在此时,它会从etcd
中读取各个node节点
的信息,然后按照一定的算法
进行选择
,并将结果
告知apiServer
apiServer
调用controller-manager
去调度node节点
安装web服务
kubelet
接收到指令
后,会通知docker
,然后由docker
来启动
一个web服务
的pod
- 如果
外部
需要访问web服务
,就需要通过kube-proxy
来对pod
产生访问的代理
k8s
的常用名词概念
Master
:集群控制节点
,每个集群
需要至少一个master
节点负责集群的管控
Node
:工作负载节点
,由master
分配容器
到这些node工作节点
上,然后node节点
上的运行容器
Pod
:kubernetes
的最小控制单元
,容器
都是运行在pod
中的,一个pod
中可以有1个或者多个容器
Controller
:控制器
,通过它来实现对pod
的管理
,比如启动pod
、停止pod
、伸缩pod
的数量
等等Service
:pod
对外服务
的统一入口
,维护
着同一类
的多个pod
Label
:标签
,用于对pod
进行分类
,同一类pod
会拥有相同的标签
NameSpace
:命名空间
,用来隔离pod
的运行环境
k8s
的分层架构
核心层
:Kubernetes
最核心
的功能
,对外
提供API
构建高层的应用
,对内
提供插件式
应用执行环境
应用层
:部署
(无状态应用
、有状态应用
、批处理任务
、集群应用
等)和路由
(服务发现
、DNS解析
等)管理层
:系统度量
(如基础设施
、容器
和网络的度量
),自动化
(如自动扩展
、动态Provision
等)以及策略管理
(RBAC
、Quota
、PSP
、NetworkPolicy
等)接口层
:kubectl命令行
工具、客户端SDK
以及集群联邦
生态系统
:在接口层
之上的庞大容器集群管理调度
的生态系统
,可以划分为两个范畴
Kubernetes
外部:日志
、监控
、配置管理
、CI
、CD
、Workflow
、FaaS
、OTS
应用、ChatOps
等Kubernetes
内部:CRI
、CNI
、CVI
、镜像仓库
、Cloud Provider
、集群自身的配置
和管理
等