小言_互联网的博客

云原生之k8s--------Kubernetes原理

275人阅读  评论(0)

 单机容器编排:docker-compose

容器集群编排:docker swarm,mesos+marathon,kubernetes

应用编排:ansible

一,Kubernets是什么?

Kubernetes的缩写为:K8S,这个缩写是因为k和s之间有八个字符的关系。
Kubernetes是一个可移植的、可扩展的开源平台,用于管理容器化的工作负载和服务,可促进声明式配置和自动化。Kubernetes拥有一个庞大且快速增长的生态系统。Kubernetesd的服务、支持和工具广泛可用。

 1,K8S的由来

K8S由google的Borg系统(博格系统,google内部使用的大规模容器编排工具)作为原型,后经Go语言延用Borg的思路重写并捐献给CNCF基金会开源。

Kubernetes 这个名字源于希腊语**,意为“舵手”或“飞行员”。**


  
  1. 官网: https:/ /kubernetes.io
  2. GitHub: https:/ /github.com/kubernetes /kubernetes

2,K8S的作用

用于自动部署,扩展和管理容器化(containerzized)应用程序的开源系统

可以理解为K8S是负责自动化运维管理多个容器化程序(比如docker)的集群,是一个生态机器丰富的容器编排框架工具。

二,为啥需要Kubernetes,它可以做什么?

容器是打包和运行应用程序的好方式。在生产环境中,你需要管理运行应用程序的容器,并确保不会停机,例如,如皋一个容器发生故障,则需要启动另一个容器,如皋系统处理此行为,会不会更容易?

这就是kubernetes来解决这些问题的方法,kubernetes为你提供了一个可弹性运行分布式系统的框架,kubernetes 会满足你的扩展要求,故障转移,部署等模式。

K8S是Google开源的容器集群管理系统,在docker等容器技术的基础上,为容器化的应用提供部署运行,资源调度,服务发现和动态伸缩等一系列完整功能,提高了大规模集群管理的便捷性,其主要功能如下:

1,使用docker等容器技术对应用程序包装、实例化、运行。

2,以集群的方式运行,管理跨机器的容器

3,解决了Docker 跨机器容器之间的通信问题

4,K8S的自我修复机制使得容器集群总是运行在用户期望的状态。

三,Kubernetes的特性

  1. 弹性伸缩:使用命令,UI或者基于CPU使用情况自动快速扩容和缩容应用程序实例,保证应用业务高峰并发时的高可用性,业务低峰时回收资源,以最小成本运行服务。
  2. 自我修复:在节点故障时重新启动失败的容器,替换和重新部署,保证预期的副本数量,杀死健康检查失败的容器,并且在未准备好之前不会处理客户端请求,确保线上服务不中断。
  3. 服务发现和负载均衡:K8S为多个容器提供了一个统一的访问入口(内部ip和一个DNS名称),并且负载均衡关联的所以容器,使得用户无需考虑容器ip问题。
  4. 自动发布(默认滚动发布模式)和回滚:K8S采用滚动策略更新应用,一个更新一个pod,而不是同时删除所有的pod,如果更新过程中出现问题,将回滚更改,确保升级不影响业务。
  5. 集中化配置管理和密钥管理:管理机密数据和应用程序,而不需要把敏感数据暴露在镜像里面,提高敏感数据安全性,并可以将一些常用的配置存储在K8S中,方便程序使用
  6. 存储编排;支持外挂存储并对外挂存储资源进行编排,挂载外部存储系统,无论是来自本地存储,公有云(如:AWS),还是网络存储(如:NFS、Glusterfs、Ceph)都作为集群资源的一部分使用,极大提高存储使用灵活性。
  7. 任务批量处理运行:提供一次性任务,定时任务,满足批量数据处理和分析的场景。

2,K8S特性


  
  1. 轻量级:重点在于其开发的语言go,系统资源消耗较少
  2. 开源
  3. 自我修复:控制器
  4. 弹性伸缩:yml定义的阈值,(cgroups控制的limit资源上限)和伸缩方式(水平)。
  5. 自动部署:回滚 ---yul定义的(部署方式:list-watch机制,rollback回滚)
  6. 服务发现:负载均衡 --services+kube-proxy
  7. 机密和配置管理: ----secreat+configmap(配置中心)
  8. 存储编排:静态 +动态:NFS ceph等网络存储 +本地存储 +云存储(以上是静态)pv +pvc 动态
  9. 批处理: ---一次性任务和周期性任务

K8S解决了裸跑docker的若干痛点:

  1. 单机使用,无法有效集群
  2. 随着容器数量的上升,管理成本攀升
  3. 没有有效的容灾,自愈机制
  4. 没有预设编排模板,无法实现快速,大规模的容器调度
  5. 没有统一的配置管理中心工具
  6. 没有容器生命周期的管理工具
  7. 没有图形化运维管理工具

四,Kubernetes架构

K8S属于主从设备模型,即由master节点负责集群的调度,管理和运维,slave节点是集群中的运算工作负载节点。

在K8S中,主节点一般被称为Master节点,而从节点则被称为worker node节点,每个node都会被master分配一些工作负载。

Master 组件可可以在集群中的任何计算机上运行,但建议Master 节点占据一个独立的服务器,因为因为 Master 是整个集群的大脑,如果 Master 所在节点宕机或不可用,那么所有的控制命令都将失效。除了 Master,在 K8S 集群中的其他机器被称为 Worker Node 节点,当某个 Node 宕机时,其上的工作负载会被 Master 自动转移到其他节点上去。

组件 作用
master节点
apiserver 所以服务的访问入口
controller-manager 负责根据预设模板创建pod,维持pod等资源的副本期望数目
scheduler 负责调度pod,通过预先策略,,优先策略选择最合适的node节点分配pod
etcd 分布式键值对数据库,负责存储K8S的重要信息(持久化)
work node节点
Kubelet 跟apiserver通信汇报当前node节点上的资源使用情况和状态,接受apiserver的指令跟容器引擎交互实现容器的生命周期管理
Kube-proxy 在node节点上实现pod的网络代理,维护网络规则和四层负载均衡规则,负责写入规则到iptables或ipvs实现服务映射访问
容器运行时docker 运行容器,负责本机的容器创建和管理工作

 1,Kubernetes工作流程

首先,运维人员使用kubectl命令行工具向API Server发送请求,API Server接收到请求后会写入到etcd中,API Server会让Controller-manager按照预设的模板去创建pod,Controller-manager通过API Server读取etcd中用户的预设信息,再通过API Server去找Scheduler可以为新创建的pod选择最合适的node节点。scheduler会通过API Server在etcd存储中心根据存储的node节点元信息、剩余资源等,用预选和优选策略选最优的node节点。

scheduler确定node节点后通过API Server交给这个node节点上的kubele进行pod资源的创建,kubele调用容器引擎交互创建pod,同时将pod监控信息通过API Server存储到etcd中。

用户访问时,通过kube-proxy负载、转发,访问相应的pod
决定创建pod清单的是Controller-manager控制器,而kubelet、容器引擎都是干活的

2,创建K8Spod流程

详细版
kubectl创建一个Pod(在提交时,转化为json)

  1. 首先经过auth认证(鉴权),然后传递给API Server进行处理
  2. API Server将请求信息提交给etcd
  3. scheduler和controller-manager会watch(监听)API Server,监听请求
  4. 在scheduler和controller-manager监听到请求后,scheduler会提交给API Server一个list清单-----》包含的是获取node节点信息。
  5. 此时API Server就会向etcd获取后端node节点信息,获取到后,被scheduler监听到,然后scheduler进行预选优选进行打分,最后将结果给API Server。
  6. 此时API Server也会被controller-manager 监听,controller-manager会根据请求创建Pod的配置信息(需求什么控制器),然后把控制器资源给API Server。
  7. 此时API Server会提交清单给与对应节点的kubelet(代理)。
  8. kubelet代理通过K8S与容器的接口(例如containerd)进行交互,假设是docker容器,那么此时kubelet就会通过dockershim以及runc接口与docker的守护进程docker-server进行交互,来创建对应的容器,再生成对应的Pod。
  9. kubelet同时会借助于metric server收集本节点的所有状态信息,然后再提交给API Server
  10. 10.最后API Server会提交list清单给与etcd来存储(最后api-server会将数据维护在etcd中)。
     

简单版


  
  1. 1、首先kubectl 转化为json后,向api-server 提交创建Pod请求
  2. 2、api-server将请求信息记录在etcd中
  3. 3、scheduler 监听api-server处理的请求,然后向api-server申请后端节点信息
  4. 4、api-server 从etcd中获取后端节点信息后,给与scheduler
  5. 5、scheduler 进行预选优选、打分,然后提交结果给api-server
  6. 6、controller-manager 监听api-server处理的请求信息,并将所需的控制器资源给与api-server
  7. 7、api-server 对接node节点的kubelet
  8. 8、kubelet调用资源创建pod,并将统计信息返回给api-server
  9. 9、api-server将信息记录在etcd中


转载:https://blog.csdn.net/m0_54594153/article/details/127586054
查看评论
* 以上用户言论只代表其个人观点,不代表本网站的观点或立场