这篇文章主要介绍了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进行资源共享。
控制循环的控制器函数,主要由事件处理函数
和worker组成。
事件处理函数,会监听资源的新增、更新、删除事件,并根据控制器的逻辑,决定是否需要处理。
对于需要处理的事件,会把事件关联资源的命名空间,以及资源的名字塞入一个工作队列中,并且由worker池中的一个worker进行处理。
工作队列会对存储的事件进行去重,从而避免多个worker处理同一个资源的情况。
worker在处理资源对象时,一般会根据其名字来获取最新的数据,用来创建/更新资源对象,或调用其他外部服务。
worker处理失败的时候,会把资源事件重新加入工作队列中,方便之后重试。
控制器模式总结:
声明式api驱动- 对k8s资源对象的修改
控制器异步控制系统向终态趋近
使系统的自动化和无人值守成为可能
自定义资源和控制器(operator)便于系统扩展
定义一组pod的期望数量,controller会维持pod数量与期望数量一致。
配置pod发布方式,controller会按照给定的策略更新pod,保证更新过程中不可用的pod数量在限定范围内。
如果发布有问题,支持“一键”回滚。
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都是相同版本。
checkpaused: 检查dp是否需要禁止新的发布,
dp的控制器实际上做了一些更复杂的事情,包括版本管理,而将具体版本下的数量维持工作交给replicaset来做。
扩容-发布-回滚
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不可用。
创建一个或多个pod确保指定数量的pod可以成功地运行终止。
跟踪pod状态,根据配置及时重试失败的pod。
确定依赖关系,保证上一个任务运行完毕后再运行下一个任务。
控制任务并行度,并根据配置确保pod队列大小。
completions: 代表本pod队列执行次数,这里8代表这个任务将被执行8次。
parallelism: 代表并行执行个数,这里的2代表并行执行的pod数量,也就是会有2个pod同时运行。
schedule: crontab时间格式相同
startingDeadlineSeconds: job最长启动时间
concurrencyPolicy: 是否允许并行运行
successfulJobsHistoryLimit: 允许留存历史job个数
Job controller 负责根据配置创建pod
job controller跟踪job状态,根据配置及时重试pod或者继续创建
job controller会自动添加label,来跟踪对应pod,并根据配置并行或串行创建pod
所有的job都是一个controller,它会去watch kube-apiserver,我们每次提交一个yaml,会经过apiserver存到etcd里,然后job controller 会注册几个handler,每次我们有添加/更新/删除等操作时,他会通过一个消息队列发送到job controller里,job controller检查当前存在的active pod, ……
保证集群内每一个(或者一些)节点都运行一组相同的pod
跟踪集群节点状态,保证新加入的节点自动创建对应的pod
跟踪集群节点状态,保证移除的节点删除对应的pod
跟踪pod状态,保证每个节点pod处于运行状态
RollingUpdate: DaemonSet默认更新策略,当更新Daemonset模板后,老的pod会被先删除,然后再去创建新的pod,可以配合健康检查做滚动更新。
OnDelete: 当DaemonSet模板更新后,只有手动的删除某一个对应的pod,此节点Pod才会被更新。
DaemonSet Controller负责根据配置创建Pod
DaemonSet Controller跟踪pod状态,根据配置及其重试pod或者继续创建
DaemonSet Controller会自动添加affinity&label来跟踪对应的pod,并根据配置在每个节点或者适合的部分节点创建pod
pod的配置管理包括:
可变配置(configmap),
敏感信息(secret),
身份认证(serviceAccount),
资源配置(spec.containers[].Resources.limits/requests),
安全管控(spec.containers[].securitycontext),
前置校验(spec.Initcontainers)。
主要管理容器运行所需的配置文件,环境变量,命令行参数等可变配置。用于解耦容器镜像和可变配置,从而保障工作负载(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
configmap文件大小限制: 1MB (etcd要求)
pod只能引用相同namespace中的configmap
pod引用的configmap不存在时,pod无法创建成功。即pod创建前需要先创建好configmap.
使用envFrom从configmap来配置环境变量时,如果configmap中的某些key认为无效(比如key中带有数字),该环境变量将不会注入容器,但是pod可以正常创建。
只有通过k8s api创建的pod才能使用configmap, 其他方式创建的pod(如manifest创建的static pod)不能使用configmap.
在集群中用于存储密码,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
secret文件大小限制: 1MB
secret虽然采用base-64编码,但可以简单解码查看原始信息。对secret加密有较强需求,可以考虑结合k8s+vault来解决敏感信息的加密和权限管理。
secret最佳实践:因为list/watch的一般处理将获取到namespace下所有的secret,因此不建议采取list/watch的方式获取secret信息,而推荐使用GET,从而减少更多secret暴露的可能性。
主要用于解决pod在集群中的身份认证问题。其中认证使用的授权信息,则利用前面讲到的secret(type=kubernetes.io/service-account-token)进行管理。
实现原理:
pod创建时admission controller会根据指定的service account(默认为default)把对应的secret挂载到容器中固定的目录下(/var/run/secrets/kubernetes.io/serviceaccount).
当pod访问集群时,可以默认利用secret其中的token文件来认证pod的身份。
默认token的认证信息为:
Group: system:serviceaccounts:[namespaces-name]
User: system:serviceaccount:[namespace-name]:[pod-name]
如果一个pod中某一个容器异常退出,被kubelet拉起如何保证之前产生的重要数据不丢?
同一个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
pod中声明的volume的生命周期与pod相同,以下常见场景:
pod销毁重建(dp管理的pod镜像升级)
宿主机故障迁移(statefulset管理的pod带远程volume迁移)
多pod共享同一个数据volume
数据volume快照,resize等功能的扩展实现
一个PV可以设置多个访问策略,PVC与PV bound时,PV controller会优先找到AccessModes列表最短并且匹配的PVC Acessmodes列表的pv集合,然后从集合中找到capacity最小且符合pvc size需求的pv对象。
职责分离,PVC中只用声明自己需要的存储size、access mode(单node独占还是多node共享?只读还是读写访问?)等业务真正关心的存储需求(不用关心存储实现细节),PV和其对应的后端存储信息则由交给集群管理员统一运维和管控,安全访问策略更容易控制。
PVC简化了用户对存储的需求,pv才是存储的实际信息承载体。通过kube-controller-manager中的PersisentVolumeController将PVC与合适的pv bound到一起,从而满足用户对存储的实际需求。
PVC像是面向对象编程中抽象出来的接口,PV是接口对应的实现。
前者需要集群管理员提前规划或预测存储需求,后者可以通过stroageclass创建不同的PV模板,user无需关心这些PV的细节,k8s结合PVC和storageclasss两者动态创建PV对象。
StorageClassName:
pvc 可通过该字段找到相同值的PV(静态provisioning)
也可通过该字段对应的storageclass从而动态provisioning新PV对象。
说明:到达released状态的PV无法根据reclaim policy回到available状态而再次bound新的PVC。
此时,如果想复用原来PV对应的存储中的数据,只有两种方式:
复用old pv中记录的存储信息,新建pv对象。
直接从pvc对象复用,即不unbound pvc和pv。(即:statefulset处理存储状态的原理)
用户创建一个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.
create /attach/ mount 三个阶段:
本质问题
PV在Binding或者Dynamic Provisioning时,并不知道使用它的pod会被调度到哪些Node上?但PV本身的访问对node的“位置”(拓扑)有限制。
流程改进
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对象。
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.
用户创建一个包含pvc的pod(使用动态存储卷);
PV controller发现这个pvc处于待绑定状态,调用volume plugin(in-tree 或 out-of-tree)创建存储卷,并创建PV对象;并将创建的PV与pvc绑定。
Scheduler根据pod配置、节点状态、pv配置等信息,把pod调度到某个node节点上。
AD controller发现pod和pvc处于待挂载状态,调用volume plugin(in-tree 或 out-of-tree)实现设备挂载到目标节点(/dev/vdb);
在node节点上,kubelet(volume manager)等待设备挂载完成,通过volume plugin将设备挂载到指定目录:/var/lib/kubelet/pods/646154cf-xxx-xxx-xxx/volumes/alicloud~disk/pv-disk
kubelet在被告知挂载目录准备好后,启动pod中的containers,用docker -v方式(bind mount)将已经挂载到本地的卷映射到容器中。
主要概念:
PersistentVolume: 持久化存储卷,详细定义预挂载存储空间的各项参数;无namespace限制,一般由集群管理员创建维护PV;
PersistentVolumeClaim: 持久化存储卷声明,用户使用的存储接口,对存储细节无感知,属于某namespace.
StorageClass: 存储类,创建PV存储的模板类,即系统会按照StorageClass定义的存储模板创建存储卷(包括真实存储空间和PV对象);
主要任务:
PV、PVC声明周期管理:创建、删除PV对象;负责PV、PVC的状态迁移;
绑定PVC、PV对象:一个pvc必须与一个PV绑定后才能被应用使用;pv-controller会根据绑定条件和对象状态对pv、pvc进行bound、unbound操作。
ClaimWorker:
实现PVC的状态迁移;
通过系统标签“pv.kubernetes.io/bind-completed"来标识一个pvc是为bound状态;
当pvc为unbound时,触发PV筛选逻辑,如果找到合适的PV则bound,如果找不到则触发provision。(如果不是in-tree provisioner则等待)
VolumeWorker:
实现PV的状态迁移;
通过ClaimRef来判断PV是bound还是released,pv状态为released时,若reclaim为delete,则执行删除逻辑。
AD controller负责将数据卷挂载/卸载到特定节点上;
核心对象:DesiredStateOfWorld, ActualStateOfWorld
核心逻辑:Reconcile, desiredStateOfWorldPopulator
DesiredStateOfWorld: 集群中预期要达到的数据卷挂载状态
ActualStateOfWorld:集群中实际存在的数据卷挂载状态
desiredStateOfWorldPopulator:根据卷挂载状态,更新DSW,ASW数据;
reconcile: 根据DSW, ASW对象状态,轮询执行attach, detach操作。
它是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来控制
根据不同的存储类型提供数据卷Provision, Delete, Attach, Detach, Mount, Unmount具体操作实现,是多种具体存储类型的功能抽象接口。
关于“kubernetes核心原理是什么”这篇文章的内容就介绍到这里,感谢各位的阅读!相信大家对“kubernetes核心原理是什么”知识都有一定的了解,大家如果还想学习更多知识,欢迎关注创新互联行业资讯频道。