⼀、编排分类
单机容器编排
:
docker-compose
容器集群编排
:
docker swarm
、
mesos+marathon
、
kubernetes
应⽤编排
:
ansible(
模块,剧本,⻆⾊
)
⼆、系统管理进化史
1.
传统部署时代
早期,各个组织是在物理服务器上运⾏应⽤程序。 由于⽆法限制在
物理服务器中运⾏的应⽤程序资源使⽤,因此会导致资源分配问
题。
例如,如果在同⼀台物理服务器上运⾏多个应⽤程序, 则可能会出
现⼀个应⽤程序占⽤⼤部分资源的情况,⽽导致其他应⽤程序的性
能下降。
⽽⼀种解决⽅案是将每个应⽤程序都运⾏在不同的物理服务器上,
但是当某个应⽤程序资源利⽤率不⾼时,剩余资源⽆法被分配给其
他应⽤程序,⽽且维护许多物理服务器的成本很⾼。
2.
虚拟化部署时代
⽽后,虚拟化技术被引⼊了。虚拟化技术允许在单个物理服务器的
CPU
上运⾏多台虚拟机
(VirtureMachine)
。 虚拟化能使应⽤程序在不
同
VM
之间被彼此隔离,且能提供⼀定程度的安全性, 因为⼀个应
⽤程序的信息不能被另⼀应⽤程序随意访问。
虚拟化技术能够更好地利⽤物理服务器的资源,并且因为可轻松地
添加或更新应⽤程序,⽽因此可以具有更⾼的可扩缩性,以及降低
硬件成本等等的好处。通过虚拟化,你可以将⼀组物理资源呈现为
可丢弃的虚拟机集群。
每个
VM
是⼀台完整的计算机,在虚拟化硬件之上运⾏所有组件,
包括其⾃⼰的操作系统,所以由此看来,虚拟机技术占⽤资源量
⼤,在⼀台主机上最多运⾏⼗⼏台,效率不⾼。
3.
容器部署时代
容器,衍⽣于虚拟技术,但具有更宽松的隔离特性,使容器可以在
共享操作系统的同时,还能保持其轻量级的特点。⽽且每个容器都
具有⾃⼰的⽂件系统、
CPU
、内存、进程空间等,且具有最良好的
可移植性和平台兼容性。
敏捷应⽤程序的创建和部署:
与使⽤
VM
镜像相⽐,提⾼了容
器镜像创建的简便性和效率
持续开发、集成和部署:通过快速简单的回滚
(
由于镜像不可变
性
)
,提供可靠且频繁的容器镜像构建和部署。
关注开发与运维的分离:
在构建、发布时创建应⽤程序容器镜
像,⽽不是在部署时,从⽽将应⽤程序与基础架构分离。
可观察性:
不可以显示
OS
级别的信息和指标,还可以显示应⽤
程序的运⾏状况和其他指标信。
跨开发、测试和⽣产的环境⼀致性:
在笔记本计算机上也可以和
在云中运⾏⼀样的应⽤程序。
跨云和操作系统发⾏版本的可移植性:
可在
Ubuntu
、
RHEL
、
CoreOS
、本地、
GoogleKubernetes Engine
和其他任何地⽅运
⾏。
以应⽤程序为中⼼的管理:
提⾼抽象级别,从在虚拟硬件上运⾏
OS
到使⽤逻辑资源在
OS
上运⾏应⽤程序。
松散耦合、分布式、弹性、解放的微服务:
应⽤程序被分解成较
⼩的独⽴部分, 并且可以动态部署和管理
-
⽽不是在⼀台⼤型单
机上整体运⾏。
资源隔离:
可预测的应⽤程序性能。
资源利⽤:
⾼效率和⾼密度。
三、
Kubernetes
简介
Kubernetes
缩写:
K8S
,
k
和
s
之间有⼋个字符,所以因此得名。
Kubernetes
由
google
的
Brog
系统作为原型,后经
Go
语⾔延⽤
Brog
的思路重写,并捐献给
CNCF
基⾦会开源。
Kubernetes
是⼀个可移植的、可扩展的开源平台,⽤于管理容器化
的⼯作负载和服务,可促进声明式配置和⾃动化。
官⽹:
https://kubernetes.io
Github
:
https://github.com/kubernetes/kubernetes
四、
Kubernetes
功能
Kubernetes
的⽬标是让部署容器化的应⽤简单并且⾼效,提供了应
⽤部署,规划,更新,维护的⼀种机制。
Kubernetes
在
Docker
等容器技术的基础上,为容器化的应⽤提供
部署运⾏、资源调度、服务发现和动态伸缩等⼀系列完整功能,提
⾼了⼤规模容器集群管理的便捷性。
主要功能:
1.
使⽤
Docker
等容器技术对应⽤程序包装
(package)
、实例化
(instantiate)
、运⾏
(run)
。
2.
以集群的⽅式运⾏、管理跨机器的容器,解决
Docker
跨机器容
器之间的通讯问题。
3. K8S
的⾃我修复机制使得容器集群总是运⾏在⽤户期望的状
态。
五、
Kubernetes
特性
五、
Kubernetes
特性
1.
⾃动装箱
:
Kubernetes
可以根据所需资源和其他限制条件智能
地定位容器,⽽不会影响可⽤性。
2.
弹性伸缩:
使⽤命令、
UI
或者基于
CPU
使⽤情况⾃动快速扩容
和缩容应⽤程序实例,保证应⽤业务⾼峰并发时的⾼可⽤性;业
务低峰时回收资源,以最⼩成本运⾏服务。
3.
⾃我修复:
在节点故障时重新启动失败的容器,替换和重新部
署,保证预期的副本数量;杀死健康检查失败的容器,并且在未
准备好之前不会处理客户端请求,确保线上服务不中断。
4.
服务发现和负载均衡:
K8S
为多个容器提供⼀个统⼀访问⼊⼝
(内部
IP
地址和⼀个
DNS
名称),并且负载均衡关联的所有容
器,使得⽤户⽆需考虑容器
IP
问题。
5.
⾃动发布(默认滚动发布模式)和回滚:
K8S
采⽤滚动策略更新
应⽤,⼀个更新⼀个
Pod
,⽽不是同时删除所有的
Pod
,如果更
新过程中出现问题,将回滚更改,确保升级不收影响业务。
6.
集中化配置管理和密钥管理:
管理机密数据和应⽤程序配置,⽽
不需要把敏感数据暴露在镜像⾥,提⾼敏感数据安全性,并可以
将⼀些常⽤的配置存储在
K8S
中,⽅便应⽤程序使⽤。
7.
存储编排:
⽀持外挂存储并对外挂存储资源进⾏编排,挂载外部
存储系统,⽆论是来⾃本地存储,公有云(如:
AWS
),还是
⽹络存储(如:
NFS
、
Glusterfs
、
Ceph
)都作为集群资源的⼀
部分使⽤,极⼤提⾼存储使⽤灵活性。
8.
任务批量处理运⾏:
提供⼀次性任务,定时任务,满⾜批量数据
处理和分析的场景。
六、
K8S
解决裸跑
Docker
的痛点
1.
单机使⽤,⽆法有效集群。
2.
随着容器数量的上升,管理成本攀升。
3.
没有有效的容灾、⾃愈机制。
4.
没有预设编排模板,⽆法实现快速、⼤规模容器调度。
5.
没有统⼀的配置管理中⼼⼯具。
6.
没有容器⽣命周期的管理⼯具。
7.
没有图形化运维管理⼯具。
七、
Kubernetes
架构
K8S
属于主从设备模型(
Mater-Slave
架构)
,由
Master
节点负责
集群的调度、管理和运维(分配活的),
Slave
节点是运算⼯作负载
节点(⼲活的),被称为
Worker Node
节点。
Master
需要占据⼀个独⽴服务器运⾏,因为其是整个集群的
“
⼤
脑
”
,⼀旦宕机或不可⽤,那么所有控制命令都将失效,可对主节点
进⾏⾼可⽤配置。
当
Worker Node
节点宕机时,其上的⼯作负载会被
Master
⾃动转
移到其他节点上。
![](https://i-blog.csdnimg.cn/direct/8fbcbaea428b4a6db9bc89f095a053e5.png)
1. Master
节点组件
API Server
*
整个集群的控制中枢,提供集群中各个模块之间的数据交换
*
,并将
集群状态和信息存储到分布式键
-
值
(key-value)
存储系统
Etcd
集群
中。
同时它也是集群管理、资源配额、提供完备的集群安全机制的⼊
⼝,为集群各类资源对象提供增删改查以及
watch
的
REST API
接
⼝。
Controller-manager
集群状态管理器,以保证
Pod
或其他资源达到期望值
*
。
*
当集群中
某个
Pod
的副本数或其他资源因故障和错误导致⽆法正常运⾏,没
有达到设定的值时,
Controller Manager
会尝试⾃动修复并使其达到
期望状态。
Scheduler
*
集群
Pod
的调度中⼼,主要是通过调度算法将
Pod
分配到最佳的
Node
节点
*
,它通过
APIServer
监听所有
Pod
的状态,⼀旦发现新
的未被调度到任何
Node
节点的
Pod(PodSpec.NodeName
为空
)
,就
会根据⼀系列策略选择最佳节点进⾏调度。
Etcd
*
⽤于可靠地存储集群的配置数据,是⼀种持久性、轻量型、分布式
的键
-
值
(key-value)
数据存储组件
*
,作为
Kubernetes
集群的持久化
存储系统。
注:⽣产环境建议存放到单个的
SSD
硬盘,并且做好冗余。
2. Work Node
节点
Kubelet
*
负责与
Master
通信协作,管理该节点上的
Pod
,对容器进⾏健康
检查及监控,同时负责上报节点和节点上⾯
Pod
的状态。
*
Kube-proxy
*
运⾏在每个
node
节点上,实现
pod
的⽹络代理,维护⽹络规则和
四层负载均衡规则
*
,负责写⼊规则到
iptables
或
ipvs
实现服务映射
访问。
Runtime
*
负责容器的管理
*
(
新版本
K8S
使⽤的是
Containerd)
。
CoreDNS
⽤于
Kubernetes
集群内部
Service
的解析
,可以让
Pod
把
Service
名称解析成
Service
的
IP
然后通过
Service
的
IP
地址进⾏
连接到对应的应⽤上。
Calico
符合
CNI
标准的⼀个⽹络插件,它
*
负责给每个
Pod
分配⼀个不会
重复的
IP
,并且把每个节点当做⼀各
“
路由器
”*
,这样⼀个节点的
Pod
就可以通过
IP
地址访问到其他节点的
Pod
。
Docker
*
运⾏容器,负责本机的容器创建和管理⼯作。
*
⼋、
Pod
概念
⼋、
Pod
概念
Pod
是
Kubernetes
中的基本构建块,它代表⼀个或⼀组相互关联的
容器。
Pod
是
Kubernetes
的最⼩部署单元,可以包含⼀个或多个容
器,这些容器共享存储、⽹络和运⾏配置。
容器之间可以使⽤
localhost:port
相互访问,可以使⽤
volume
等实
现数据共享。根据
Docker
的构造,
Pod
可被建模为⼀组具有共享命
令空间、卷、
IP
地址和
Port
端⼝的容器。
Pod
的主要特点包括:
1.
共享存储:
Pod
中的所有容器都可以访问同⼀个存储卷
(
Persistent Volume
),实现数据共享。
2.
共享⽹络:
Pod
中的所有容器都共享同⼀个⽹络命名空间,可
以相互通信。
3.
共享运⾏配置:
Pod
中的所有容器都共享相同的运⾏配置,例
如容器的启动参数、环境变量等。
Pause
容器:
Pod
的⽗容器,它主要负责僵⼫进程的回收管理,同时通过
Pause
容器可以使同⼀个
Pod
⾥⾯的不同容器进⾏共享存储、⽹络、
PID
、
IPC
等。
九、
Kubernetes
⼯作流程
九、
Kubernetes
⼯作流程
1.
运维⼈员使⽤
kubectl
命令⼯具向
API Server
发送请求,
API
Server
接收请求后写⼊到
Etcd
中。
2. API Server
让
Controller-manager
按照预设模板去创建
Pod
。
3. Controller-manager
通过
API Server
读取
Etcd
中⽤户的预设信
息,再通过
API Server
找到
Scheduler
,为新创建的
Pod
选择
最合适的
Node
⼯作负载节点。
4. Scheduler
通过
API Server
在
Etcd
找到存储的
Node
节点元信
息、剩余资源等,⽤预选和优选策略选择最优的
Node
节点。
5. Scheduler
确定
Node
节点后,通过
API Server
交给这个
Node
节点上的
Kubelet
进⾏
Pod
资源的创建。
6. Kubelet
调⽤容器引擎交互创建
Pod
,同时将
Pod
监控信息通
过
API Server
存储到
Etcd
中。
7.
当⽤户访问时,通过
Kube-proxy
负载、转发,访问相应的
Pod
。
8.
注:
决定创建
Pod
清单的是
Controller-manager
控制器,
Kubelet
和容器引擎只是⼲活的。
![](https://i-blog.csdnimg.cn/direct/cca5166f2da2443f9753c4f0f7f92f8e.png)
⼗、
K8S
创建
Pod
流程
1.
详细流程
⾸先
Kubectl
创建⼀个
Pod
,在提交时转化为
json
。
再经过
auth
认证
(
鉴权
)
,然后传递给
API Server
进⾏处理。
API Server
将请求信息存储到
Etcd
中。
Scheduler
和
Controller-manager
会监听
API Server
的请求。
在
Scheduler
和
Controller-manager
监听到请求后,
Scheduler
会提交给
API Server
⼀个
list
清单
——
包含的是获取
node
节点信
息。
当
API Server
从
Etcd
获取后端
Node
节点信息后,会同时被
Scheduler
监听到,然后
Scheduler
进⾏优选打分制,最后将评
估结果传递给
API Server
。
⽽后,
API Server
会提交清单给对应节点的
Kubelet
(代理)。
Kubelet
代理通过
K8S
与容器的接⼝
(
例如
containerd)
进⾏交
互,假设是
docker
容器,那么此时
kubelet
就会通过
dockershim
以及
runc
接⼝与
docker
的守护进程
docker-server
进⾏交互,来创建对应的容器,再⽣成对应的
Pod
。
Kubelet
同时会借助
Metric Server
收集本节点的所有状态信
息,然后提交给
API Server
。
最后
API Server
将该节点的容器和
Pod
信息存储到
Etcd
中。
2.
简化流程
⽤户通过
kubectl
或其他
API
客户端提交
Pod Spec
给
API
Server
。
API Server
尝试将
Pod
对象的相关信息存⼊
etcd
中,待写⼊操
作执⾏完成,
API Server
即会返回确认信息⾄客户端。
Controller
通过
API Server
的
Watch
接⼝发现新的
Pod
,将
Pod
加⼊到任务队列,并启动
Pod Control
机制创建与之对应的
Pod
。
所有
Controler
正常后,将结果存⼊
etcd
。
Scheduler
通过
API Server
的
Watch
接⼝监测发现新的
Pod
,
经过给主机打分之后,让
Pod
调度到符合要求的
Node
节点,
并将结果存⼊到
etcd
中。
Kubelet
每隔⼀段时间向
API Server
通过
Node name
获取⾃身
Node
上要运⾏的
Pod
并通过与⾃身缓存⽐较,来创建新
Pod
。
Containerd
启动容器。
最后
API Server
将本节点的容器和
Pod
信息存储到
etcd
。