kubernetes核心原理是什么

这篇文章主要介绍了kubernetes核心原理是什么的相关知识,内容详细易懂,操作简单快捷,具有一定借鉴价值,相信大家阅读完这篇kubernetes核心原理是什么文章都会有所收获,下面我们一起来看看吧。

创新互联建站成都网站建设专业公司,是成都网站设计公司,为成都木制凉亭提供网站建设服务,有成熟的网站定制合作流程,提供网站定制设计服务:原型图制作、网站创意设计、前端HTML5制作、后台程序开发等。成都网站营销推广热线:028-86922220

核心原理:控制器模式

控制器逻辑中包括controller, sensor 和system 三个逻辑组件,通过修改spec中相关的字段来触发事件,controller通过比较当前状态和期望状态,来触发对系统的具体操作。

sensor中则包括reflector, informer, indexer 三个组件,

reflector通过list&watch apiserver 来获取资源的数据,

list 用来在controller重启或者watch中断的情况下,对资源进行全量的更新。

watch则在多次list之间进行增量的更新。

reflector会在获取资源信息之后,会在delta queue中加入一个包括资源信息本身和资源对象事件类型的delta数据,delta队列可以保证同一个对象在队列中仅有一条记录,从而避免在reflector list&watch的时候产生重复的记录。

informer组件不断从delta队列中弹出delta记录,一方面把资源对象交给资源回调函数,同时又把资源对象交给indexer, indexer默认将资源对象记录在缓存中,通 过namespace作为其索引值,并且能被controller-manager的多个controller进行资源共享。 kubernetes核心原理是什么

控制循环的控制器函数,主要由事件处理函数和worker组成。

  1. 事件处理函数,会监听资源的新增、更新、删除事件,并根据控制器的逻辑,决定是否需要处理。

  2. 对于需要处理的事件,会把事件关联资源的命名空间,以及资源的名字塞入一个工作队列中,并且由worker池中的一个worker进行处理。

  3. 工作队列会对存储的事件进行去重,从而避免多个worker处理同一个资源的情况。

  4. worker在处理资源对象时,一般会根据其名字来获取最新的数据,用来创建/更新资源对象,或调用其他外部服务。

  5. worker处理失败的时候,会把资源事件重新加入工作队列中,方便之后重试。

kubernetes核心原理是什么

kubernetes核心原理是什么

kubernetes核心原理是什么

控制器模式总结:

  • 声明式api驱动- 对k8s资源对象的修改

  • 控制器异步控制系统向终态趋近

  • 使系统的自动化和无人值守成为可能

  • 自定义资源和控制器(operator)便于系统扩展

Deployment: 管理部署发布的控制器

  1. 定义一组pod的期望数量,controller会维持pod数量与期望数量一致。

  2. 配置pod发布方式,controller会按照给定的策略更新pod,保证更新过程中不可用的pod数量在限定范围内。

  3. 如果发布有问题,支持“一键”回滚。

更新镜像

kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1

快速回滚

kubectl rollout undo deployment/nginx-deployment

kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2

kubectl rollout history deployment.v1.apps/nginx-deployment

管理模式

Deployment只负责管理不同版本的ReplicaSet, 由ReplicaSet管理Pod副本数。每个ReplicaSe对应Deployment template的一个版本,一个RS下的pod都是相同版本。

Deployment控制器

kubernetes核心原理是什么

checkpaused: 检查dp是否需要禁止新的发布,

dp的控制器实际上做了一些更复杂的事情,包括版本管理,而将具体版本下的数量维持工作交给replicaset来做。

ReplicaSet控制器

kubernetes核心原理是什么 扩容-发布-回滚

spec字段解析

MinReadySeconds: 判断Pod available的最小ready时间

RevisionHistoryLimit: 保留历史revision(replicaset)的数量,默认值为10

paused: 标识deployment制作数量维持,不做新的发布

progressDealineSeconds: 判断dp status condition 为failed的最大时间。(dp处于processing最大多长时间,则认为dp status 为failed.)

升级策略字段解析

MaxUnavailable: 滚动过程中最多有多少个pod不可用。

MaxSurge: 滚动过程最多存在多少个pod超过期望replicas数量。

maxunavailable 和 max surge不能同时为0?

因为,当maxsurge=0时,就必须先删一个pod再创建一个新pod,因为新扩出来一个pod,会导致rs超过期望数量。

maxsurge保证不能新扩pod,maxunavailable保证不能有pod不可用。

Job:管理任务的控制器- 通过pod运行任务进程

  1. 创建一个或多个pod确保指定数量的pod可以成功地运行终止。

  2. 跟踪pod状态,根据配置及时重试失败的pod。

  3. 确定依赖关系,保证上一个任务运行完毕后再运行下一个任务。

  4. 控制任务并行度,并根据配置确保pod队列大小。

并行运行Job

  1. completions: 代表本pod队列执行次数,这里8代表这个任务将被执行8次。

  2. parallelism: 代表并行执行个数,这里的2代表并行执行的pod数量,也就是会有2个pod同时运行。

CronJob语法

  1. schedule: crontab时间格式相同

  2. startingDeadlineSeconds: job最长启动时间

  3. concurrencyPolicy: 是否允许并行运行

  4. successfulJobsHistoryLimit: 允许留存历史job个数

管理模式

  1. Job controller 负责根据配置创建pod

  2. job controller跟踪job状态,根据配置及时重试pod或者继续创建

  3. job controller会自动添加label,来跟踪对应pod,并根据配置并行或串行创建pod

Job控制器

kubernetes核心原理是什么

所有的job都是一个controller,它会去watch kube-apiserver,我们每次提交一个yaml,会经过apiserver存到etcd里,然后job controller 会注册几个handler,每次我们有添加/更新/删除等操作时,他会通过一个消息队列发送到job controller里,job controller检查当前存在的active pod, ……

DaemonSet:守护进程控制器- 让每个集群内的节点都运行一个相同的pod

  1. 保证集群内每一个(或者一些)节点都运行一组相同的pod

  2. 跟踪集群节点状态,保证新加入的节点自动创建对应的pod

  3. 跟踪集群节点状态,保证移除的节点删除对应的pod

  4. 跟踪pod状态,保证每个节点pod处于运行状态

更新策略

  1. RollingUpdate: DaemonSet默认更新策略,当更新Daemonset模板后,老的pod会被先删除,然后再去创建新的pod,可以配合健康检查做滚动更新。

  2. OnDelete: 当DaemonSet模板更新后,只有手动的删除某一个对应的pod,此节点Pod才会被更新。

管理模式

  1. DaemonSet Controller负责根据配置创建Pod

  2. DaemonSet Controller跟踪pod状态,根据配置及其重试pod或者继续创建

  3. DaemonSet Controller会自动添加affinity&label来跟踪对应的pod,并根据配置在每个节点或者适合的部分节点创建pod

DaemonSet控制器

kubernetes核心原理是什么

应用配置管理

pod的配置管理包括:

可变配置(configmap),

敏感信息(secret),

身份认证(serviceAccount),

资源配置(spec.containers[].Resources.limits/requests),

安全管控(spec.containers[].securitycontext),

前置校验(spec.Initcontainers)。

Configmap

主要管理容器运行所需的配置文件,环境变量,命令行参数等可变配置。用于解耦容器镜像和可变配置,从而保障工作负载(pod)的可移植性。

kubectl create configmap kube-flannel-cfg --from-file=configure-pod-container/configmap/cni-conf.json -n kube-system
kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm

tips:

  1. configmap文件大小限制: 1MB (etcd要求)

  2. pod只能引用相同namespace中的configmap

  3. pod引用的configmap不存在时,pod无法创建成功。即pod创建前需要先创建好configmap.

  4. 使用envFrom从configmap来配置环境变量时,如果configmap中的某些key认为无效(比如key中带有数字),该环境变量将不会注入容器,但是pod可以正常创建。

  5. 只有通过k8s api创建的pod才能使用configmap, 其他方式创建的pod(如manifest创建的static pod)不能使用configmap.

Secret

在集群中用于存储密码,token等敏感信息用的资源对象。其中敏感数据采用base-64编码保存,相比存储在明文的configmap中更规范和安全。

kubectl create secret generic myregistrykey --from-file=.dockerconfigjson=/root/.docker/config.json --type=kubernetes.io/dockerconfigjson
kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11

tips:

  1. secret文件大小限制: 1MB

  2. secret虽然采用base-64编码,但可以简单解码查看原始信息。对secret加密有较强需求,可以考虑结合k8s+vault来解决敏感信息的加密和权限管理。

  3. secret最佳实践:因为list/watch的一般处理将获取到namespace下所有的secret,因此不建议采取list/watch的方式获取secret信息,而推荐使用GET,从而减少更多secret暴露的可能性。

ServiceAccount

主要用于解决pod在集群中的身份认证问题。其中认证使用的授权信息,则利用前面讲到的secret(type=kubernetes.io/service-account-token)进行管理。

实现原理:

  1. pod创建时admission controller会根据指定的service account(默认为default)把对应的secret挂载到容器中固定的目录下(/var/run/secrets/kubernetes.io/serviceaccount).

  2. 当pod访问集群时,可以默认利用secret其中的token文件来认证pod的身份。

  3. 默认token的认证信息为:

  4. Group: system:serviceaccounts:[namespaces-name]

  5. User: system:serviceaccount:[namespace-name]:[pod-name]

容器资源配置管理

kubernetes核心原理是什么

kubernetes核心原理是什么

kubernetes核心原理是什么

应用存储和持久化数据卷

pod volumes:

  1. 如果一个pod中某一个容器异常退出,被kubelet拉起如何保证之前产生的重要数据不丢?

  2. 同一个pod的多个容器如何共享数据?

k8s volume类型:

1)本地存储: emptydir/hostpath

2)网络存储:

in-tree: awsEBS/gcePersistentDisk/nfs...

out-tree: flexvolume/csi volume plugin

3)projected volume: secret/configmap/downwardAPI/serviceAccountToken

4)pvc、pv

Persistent Volume

pod中声明的volume的生命周期与pod相同,以下常见场景:

  1. pod销毁重建(dp管理的pod镜像升级)

  2. 宿主机故障迁移(statefulset管理的pod带远程volume迁移)

  3. 多pod共享同一个数据volume

  4. 数据volume快照,resize等功能的扩展实现

一个PV可以设置多个访问策略,PVC与PV bound时,PV controller会优先找到AccessModes列表最短并且匹配的PVC Acessmodes列表的pv集合,然后从集合中找到capacity最小且符合pvc size需求的pv对象。

pvc设计意图

  1. 职责分离,PVC中只用声明自己需要的存储size、access mode(单node独占还是多node共享?只读还是读写访问?)等业务真正关心的存储需求(不用关心存储实现细节),PV和其对应的后端存储信息则由交给集群管理员统一运维和管控,安全访问策略更容易控制。

  2. PVC简化了用户对存储的需求,pv才是存储的实际信息承载体。通过kube-controller-manager中的PersisentVolumeController将PVC与合适的pv bound到一起,从而满足用户对存储的实际需求。

  3. PVC像是面向对象编程中抽象出来的接口,PV是接口对应的实现。

Static Volume Provisioning && Dynamic Volume Provisioning

前者需要集群管理员提前规划或预测存储需求,后者可以通过stroageclass创建不同的PV模板,user无需关心这些PV的细节,k8s结合PVC和storageclasss两者动态创建PV对象。

StorageClassName:

pvc 可通过该字段找到相同值的PV(静态provisioning)

也可通过该字段对应的storageclass从而动态provisioning新PV对象。

PV状态流转

kubernetes核心原理是什么 说明:到达released状态的PV无法根据reclaim policy回到available状态而再次bound新的PVC。

此时,如果想复用原来PV对应的存储中的数据,只有两种方式:

  1. 复用old pv中记录的存储信息,新建pv对象。

  2. 直接从pvc对象复用,即不unbound pvc和pv。(即:statefulset处理存储状态的原理)

PV&PVC体系完整流程详解

kubernetes核心原理是什么 用户创建一个pvc对象,会被csi-provisioner watch到,结合pvc对象以及在其中声明的storageclass,通过grpc调用csi plugin. 会请求云存储服务并实际申请pv存储。

之后pvcontroller 会将pvc和申请到的pv做bound,之后这块pv就可被使用了。

当用户创建pod对象,通过kube-scheduler调度到具体的node节点后,通过csi-node-server将申请的pvmount到pod可以使用的路径,然后再create/start container.

kubernetes核心原理是什么 create /attach/ mount 三个阶段:

存储拓扑调度

  1. 本质问题

PV在Binding或者Dynamic Provisioning时,并不知道使用它的pod会被调度到哪些Node上?但PV本身的访问对node的“位置”(拓扑)有限制。

  1. 流程改进

Binding/Dynamic Provisioning PV的操作Delay到Pod调度结果确定之后做,好处:

  • 对于pre-provisioned的含有node affinity的pv对象,可以在pod运行的node确认之后,根据node找到合适的pv对象,然后与pod中使用的pvc binding,保证pod运行的node满足pv对访问“位置”的要求。

  • 对于dynamic provisioning PV场景,在pod运行的node确认之后,可以结合node的“位置”信息创建可被该node访问的pv对象。

  1. k8s相关组件改进

  • PV controller: 支持延迟binding操作

  • dynamic pv provisioner: 动态创建pv时要结合pod待运行的node的“位置”信息

  • scheduler: 选择node时要考虑pod的pvc binding需求,也就是要结合pre-provisioned 的PV 的node affinity以及dynamic provisioning时 pvc指定的storageclass.allowedTopologies的限制

当该PVC对象被创建之后由于对应StorageClass的BindingMode为 WaitForFirstConsumer并不会马上动态生成PV对象,而是要等到使用该PVC对象的第一个pod调度出结果之后,而且kube-scheduler在调度pod的时候会去选择满足storageclass.allowedTopologies中指定的拓扑限制的nodes.

k8s对volume topology-aware scheduling流程处理

kubernetes核心原理是什么

k8s存储架构及插件使用

k8s挂载volume过程

kubernetes核心原理是什么

  1. 用户创建一个包含pvc的pod(使用动态存储卷);

  2. PV controller发现这个pvc处于待绑定状态,调用volume plugin(in-tree 或 out-of-tree)创建存储卷,并创建PV对象;并将创建的PV与pvc绑定。

  3. Scheduler根据pod配置、节点状态、pv配置等信息,把pod调度到某个node节点上。

  4. AD controller发现pod和pvc处于待挂载状态,调用volume plugin(in-tree 或 out-of-tree)实现设备挂载到目标节点(/dev/vdb);

  5. 在node节点上,kubelet(volume manager)等待设备挂载完成,通过volume plugin将设备挂载到指定目录:/var/lib/kubelet/pods/646154cf-xxx-xxx-xxx/volumes/alicloud~disk/pv-disk

  6. kubelet在被告知挂载目录准备好后,启动pod中的containers,用docker -v方式(bind mount)将已经挂载到本地的卷映射到容器中。

k8s存储架构

kubernetes核心原理是什么

PV Controller介绍

主要概念:

  • PersistentVolume: 持久化存储卷,详细定义预挂载存储空间的各项参数;无namespace限制,一般由集群管理员创建维护PV;

  • PersistentVolumeClaim: 持久化存储卷声明,用户使用的存储接口,对存储细节无感知,属于某namespace.

  • StorageClass: 存储类,创建PV存储的模板类,即系统会按照StorageClass定义的存储模板创建存储卷(包括真实存储空间和PV对象);

主要任务:

  • PV、PVC声明周期管理:创建、删除PV对象;负责PV、PVC的状态迁移;

  • 绑定PVC、PV对象:一个pvc必须与一个PV绑定后才能被应用使用;pv-controller会根据绑定条件和对象状态对pv、pvc进行bound、unbound操作。

kubernetes核心原理是什么

kubernetes核心原理是什么

PV Controller实现

kubernetes核心原理是什么

  • ClaimWorker:

    • 实现PVC的状态迁移;

    • 通过系统标签“pv.kubernetes.io/bind-completed"来标识一个pvc是为bound状态;

    • 当pvc为unbound时,触发PV筛选逻辑,如果找到合适的PV则bound,如果找不到则触发provision。(如果不是in-tree provisioner则等待)

kubernetes核心原理是什么

  • VolumeWorker:

    • 实现PV的状态迁移;

    • 通过ClaimRef来判断PV是bound还是released,pv状态为released时,若reclaim为delete,则执行删除逻辑。

AD Controller介绍

AD controller负责将数据卷挂载/卸载到特定节点上;

核心对象:DesiredStateOfWorld, ActualStateOfWorld

核心逻辑:Reconcile, desiredStateOfWorldPopulator

kubernetes核心原理是什么 DesiredStateOfWorld: 集群中预期要达到的数据卷挂载状态

ActualStateOfWorld:集群中实际存在的数据卷挂载状态

desiredStateOfWorldPopulator:根据卷挂载状态,更新DSW,ASW数据;

reconcile: 根据DSW, ASW对象状态,轮询执行attach, detach操作。

kubernetes核心原理是什么

Volume Manager介绍

  • 它是kubelet中的一个manager,调用本节点Volume的attach/detach/mount/umount操作;

  • volumeManager实时扫描本节点的pod状态,对需要更新状态的volume通过调用volume plugin执行相应操作。

    • volumeManager根据存储类型需要还会执行一些公共操作,例如:块设备的格式化、挂载块设备到公共目录等。

数据结构:

  • VolumePluginMgr:管理本节点上in-tree/out-of-tree的插件列表;

  • desiredStateOfWorld: 记录节点上数据卷的期望挂载状态;

  • actualStateOfWorld:记录节点上数据卷的实际挂载状态;

核心逻辑:

  • desiredStateOfWorldPopulator:同步包含数据卷的pod状态;

  • Reconciler:循环执行attach/detach/mount/unmount, 具体操作通过调用volume plugin实现的接口完成。

AD controller还是volume manager做attach/detach操作?

  • 通过--enable-controller-attach-detach来控制

Volume Plugins介绍

根据不同的存储类型提供数据卷Provision, Delete, Attach, Detach, Mount, Unmount具体操作实现,是多种具体存储类型的功能抽象接口。

kubernetes核心原理是什么

kubernetes核心原理是什么

关于“kubernetes核心原理是什么”这篇文章的内容就介绍到这里,感谢各位的阅读!相信大家对“kubernetes核心原理是什么”知识都有一定的了解,大家如果还想学习更多知识,欢迎关注创新互联行业资讯频道。


网页标题:kubernetes核心原理是什么
链接URL:http://pwwzsj.com/article/iecedg.html