【K8S系列】深入解析K8S调度

序言

做一件事并不难,难的是在于坚持。坚持一下也不难,难的是坚持到底。

文章标记颜色说明:

  • 黄色:重要标题
  • 红色:用来标记结论
  • 绿色:用来标记论点
  • 蓝色:用来标记论点

Kubernetes (k8s) 是一个容器编排平台,允许在容器中运行应用程序和服务。今天学习一下k8s调度相关知识

希望这篇文章能让你不仅有一定的收获,而且可以愉快的学习,如果有什么建议,都可以留言和我交流

 专栏介绍

这是这篇文章所在的专栏,欢迎订阅:【深入解析k8s】专栏

简单介绍一下这个专栏要做的事:

Kubernetes是一个分布式系统,能够管理和编排容器化应用程序。其中,调度(Scheduling)是Kubernetes最重要的功能之一,它能够将容器化的应用程序(即Pod)自动分配到集群中的适当节点上。

在本文中,将详细介绍Kubernetes调度的

  • 工作原理
  • 调度算法
  • 调度器组件
  • 调度示例

1 基础介绍

1.1 什么是k8s调度

Kubernetes调度(Scheduling):是指将未调度的Pod自动分配到集群中的节点的过程

Pod是Kubernetes中最小的可部署单元,它通常包括一个或多个容器。

在Kubernetes中,容器可以在集群中的任何节点上运行,调度器可以根据节点的资源使用情况、Pod的资源需求、亲和性和反亲和性等因素,将Pod分配到最合适的节点上运行。

每个Pod都有一个调度器(Scheduler)负责将其分配到一个可用的节点上。

调度器是Kubernetes集群中的一个核心组件,它监视未调度的Pod对象,并为其选择最佳的节点。

2 Kubernetes调度的工作原理

2.1 原理详解

Kubernetes调度的工作原理可以概括为以下几个步骤:

  1. 创建Pod:用户通过Kubernetes API创建Pod对象,并在其中指定Pod的资源需求、容器镜像等信息。

  2. 调度器监视Pod:Kubernetes调度器监视集群中的未调度Pod对象,并为其选择最佳的节点。

  3. 选择节点:调度器通过算法选择最佳的节点,并将Pod绑定到该节点上。调度器选择节点的依据包括节点的资源使用情况、Pod的资源需求、亲和性和反亲和性等。

  4. 绑定Pod到节点:调度器将Pod和节点之间的绑定信息保存在etcd数据库中,以便节点可以获取Pod的调度信息。

  5. 节点启动Pod节点定期检查etcd数据库中的Pod调度信息,并启动相应的Pod。如果节点故障或资源不足,调度器会重新调度Pod,并将其绑定到其他节点上运行。

 2.2 其他因素

调度器选择节点的过程中,有以下一些因素需要考虑:

  1. 节点资源:调度器需要考虑节点的资源使用情况,如CPU、内存、磁盘等。

  2. Pod资源需求:调度器需要考虑Pod的资源需求,如CPU、内存、磁盘等。

  3. 亲和性和反亲和性:调度器可以根据Pod指定的亲和性和反亲和性规则来选择节点。

  4. 节点污点(Taints)和容忍度(Tolerations:节点可以设置污点,表示节点上不允许运行特定类型的Pod。Pod可以设置容忍度,以容忍节点上的污点。

  5. 节点标签:调度器可以根据节点的标签来选择最佳的节点。

3 调度算法

调度算法是指决定Pod应该调度到哪个节点上的算法。Kubernetes提供了多种调度算法,可以根据实际情况选择合适的算法。以下是Kubernetes常用的调度算法:

  1.  随机算法
  2. 最小负载算法
  3. 贪心算法
  4. 最佳适应算法
  5. 加权最小平均负载算法 

3.1 随机算法 

随机算法是最简单的调度算法之一。

  • 规则:它会随机选择一个可用节点,并将Pod调度到该节点上。
  • 效率:这种算法简单、快速,适用于不需要考虑资源利用率和负载均衡的场景。
  • 缺点:随机算法可能会导致节点资源的不均衡分配和资源浪费。

3.2 最小负载算法 

最小负载算法会选择当前负载最低的节点,并将Pod调度到该节点上

这种算法可以避免节点资源的不均衡分配,但是可能会导致某些节点的资源利用率过高,从而影响其他Pod的运行。

3.2.1 优点 

优点在于可以避免节点资源的不均衡分配和负载过高的问题,从而提高Kubernetes集群的资源利用率和稳定性。同时,最小负载算法可以与其他调度算法结合使用,例如可以与负载均衡算法结合使用,以进一步优化节点的资源利用率和负载均衡。

3.2.2 缺点 

缺点在于可能会导致某些节点的资源利用率过低,从而浪费资源。此外,最小负载算法不能保证Pod被调度到最优的节点上,无法满足一些特殊的需求。

3.3 贪心算法 

贪心算法是一种基于启发式的算法,它尝试在当前状态下找到最优解。

在Pod调度中,贪心算法会尝试选择最优节点,并将Pod调度到该节点上。

贪心算法的核心思想是:在每一步选择中都采取在当前状态下最优的选择,从而希望最终能够得到全局最优解。

优点 

优点在于速度快,可以快速找到局部最优解,适用于大规模的Kubernetes集群。

同时,贪心算法可以与其他调度算法结合使用,例如可以与最小负载算法或最佳适应算法结合使用,以实现更好的负载均衡和资源利用率。

缺点

贪心算法的缺点在于不能保证找到全局最优解,有可能会陷入局部最优解而无法跳出。

此外,贪心算法也可能会导致某些节点的资源利用率过高,从而影响其他Pod的运行。

使用 

在实际使用中,贪心算法可以与其他调度算法结合使用,例如可以与最小负载算法或最佳适应算法结合使用,以实现更好的负载均衡和资源利用率。同时,调度器还可以使用亲和性/反亲和性规则来筛选节点,以进一步优化贪心算法的效果。

3.4 最佳适应算法 

最佳适应算法(Best Fit Algorithm),它会选择当前可用节点中最适合Pod的节点,并将Pod调度到该节点上。

最佳适应算法考虑节点的资源利用率情况,避免将Pod调度到资源利用率不高的节点上,从而实现负载均衡和资源利用率最大化的目的。

优点

最佳适应算法的优点在于可以避免节点资源的不均衡分配和资源浪费,从而提高Kubernetes集群的资源利用率和稳定性。同时,最佳适应算法可以与其他调度算法结合使用,例如可以与贪心算法或最小负载算法结合使用,以进一步优化节点的资源利用率和负载均衡。

缺点

最佳适应算法的缺点在于可能会导致节点资源利用率的不稳定性,从而影响Pod的运行。如果节点资源利用率变化较快,最佳适应算法可能会导致Pod频繁地迁移,从而影响Pod的稳定性和性能。

3.5 加权最小平均负载算法 

加权最小平均负载算法(Weighted Least-Connection Algorithm)是一种调度算法,它会选择当前负载最低且权重最高的节点,并将Pod调度到该节点上。加权最小平均负载算法考虑节点的负载情况和权重,避免将Pod调度到负载过高或权重过低的节点上,从而实现负载均衡和资源利用率最大化的目的。

优点

加权最小平均负载算法的优点在于可以避免节点资源的不均衡分配和负载过高的问题,从而提高Kubernetes集群的资源利用率和稳定性。同时,加权最小平均负载算法可以根据节点的权重分配资源,以满足不同节点的需求。

缺点

加权最小平均负载算法的缺点在于可能会陷入局部最优解而无法跳出。如果节点资源利用率变化较快,加权最小平均负载算法可能会导致Pod频繁地迁移,从而影响Pod的稳定性和性能。

4 调度组件

Kubernetes的调度组件是Kubernetes集群中的一个核心组件,它负责将Pod调度到Kubernetes集群中的节点上,以实现负载均衡和资源利用率最大化的目的。

调度组件通常由以下两个组件组成:

  1. 调度器(Scheduler):负责对新创建的Pod进行调度,选择合适的节点,并将Pod调度到该节点上。调度器会根据节点的资源利用率、亲和性/反亲和性规则、Pod的资源需求等因素来选择节点,并确保Pod能够被成功地调度和运行。

  2. 调度器扩展器(Scheduler Extender):负责对调度器进行扩展,并提供额外的调度策略和规则。调度器扩展器可以通过插件的形式进行扩展,例如可以添加自定义的亲和性/反亲和性规则、节点选择器、调度器过滤器等,以实现更灵活和多样化的调度策略。

调度器实现

Kubernetes还提供了多种调度器实现,包括:

  1. 默认调度器(Default Scheduler):是Kubernetes中的默认调度器,负责对新创建的Pod进行调度,并将Pod调度到合适的节点上。

  2. 自定义调度器(Custom Scheduler):是一种自定义的调度器实现,可以根据实际需求来定义调度策略和规则,以实现更灵活和多样化的调度功能。

  3. 扩展调度器(Extended Scheduler):是一种支持调度器扩展器的调度器实现,可以通过调度器扩展器来添加自定义的调度规则和策略,以实现更灵活和多样化的调度功能。

总之,Kubernetes的调度组件是Kubernetes集群中的一个核心组件,可以实现负载均衡和资源利用率最大化的目的。在实际使用中,需要根据实际情况和需求来选择合适的调度器实现和调度策略,以确保Kubernetes集群的资源利用率最大化。

5 调度示例

5.1 如何实现pod的调度

当我们创建一个Pod时,Pod会被加入到调度器的无调度队列中等待被调度。调度器会定期轮询无调度队列,检查每个Pod的调度需求,然后将它们调度到最适合的节点上。调度器的调度决策是基于节点的资源利用率、Pod的资源需求和亲和性/反亲和性规则等因素。

以下是Pod的调度流程的详细步骤:

  1. 获取Pod的 调度需求
  2. 选择适合的节点
  3. 分配Pod到节点
  4. 保存调度信息
  5. 启动Pod

1 获取Pod的 调度需求

调度器首先获取Pod的调度需求,包括Pod的容器镜像、资源需求和亲和性/反亲和性规则等。

2 选择适合的节点 

调度器会根据Pod的调度需求和集群的资源情况,在可用的节点中选择最适合的一个。调度器会根据节点的资源利用率、Pod的资源需求和亲和性/反亲和性规则等因素来进行选择。如果没有可用的节点满足Pod的需求,Pod就会一直处于等待调度的状态。

3 分配Pod到节点 

调度器会将Pod分配到选择的节点上,并将Pod对象的spec.nodeName字段设置为节点的名称。这样,kubelet就可以知道Pod被分配到了哪个节点上。

4 保存调度信息 

调度器会将Pod和节点之间的绑定信息保存在etcd数据库中。这些信息包括Pod的名称、命名空间、调度时间戳和节点名称等。kube-scheduler会周期性地检查这些绑定信息,以确保Pod已经被分配到了正确的节点上。

5 启动Pod 

当Pod被分配到节点上时,kubelet会从etcd数据库中获取Pod的配置信息,并根据这些信息启动Pod中的容器。容器启动后,Pod就可以开始运行了。

总之,Pod的调度流程是由调度器来完成的。调度器会根据节点的资源利用率、Pod的资源需求和亲和性/反亲和性规则等因素来选择最适合的节点,并将Pod分配到节点上运行。一旦Pod被分配到节点上,kubelet就会从etcd数据库中获取Pod的配置信息,并启动Pod中的容器。

5.2 调度器如何选择最适合的节点?

调度器在选择最适合的节点时,会根据一定的策略和算法进行选择。以下是调度器选择节点的一些主要考虑因素:

  •  资源利用率
  • Pod的资源需求
  • 亲和性和反亲和性规则
  • 节点的标签和注释
  • 节点的负载均衡 

资源利用率 

调度器会检查集群中各个节点的资源使用情况,包括CPU、内存、磁盘和网络等方面的使用情况。调度器会选择资源利用率最低的节点,以确保Pod能够得到足够的资源。

Pod的资源需求 

调度器会检查Pod的资源需求,包括CPU和内存等方面的需求。调度器会选择可以满足Pod资源需求的节点,以避免Pod因为资源不足而无法正常运行。

亲和性和反亲和性规则 

调度器会检查Pod的亲和性和反亲和性规则。亲和性规则指定了Pod应该调度到哪些节点上,而反亲和性规则指定了Pod不应该调度到哪些节点上。调度器会根据这些规则来选择节点,以确保Pod被调度到最合适的节点上。

节点的标签和注释 

调度器会检查节点的标签和注释。节点的标签可以用来标识节点的特性和属性,而注释可以提供节点的附加信息。调度器可以使用这些信息来选择最适合的节点。

节点的负载均衡 

调度器会尝试在集群中平衡负载,避免某个节点过度负载,而其他节点资源利用率太低。调度器会选择负载均衡最优的节点,以确保集群中的资源利用率最大化。

总之,调度器在选择最适合的节点时,会考虑多个因素,包括资源利用率、Pod的资源需求、亲和性和反亲和性规则、节点的标签和注释以及负载均衡等。调度器会使用这些信息来选择最优的节点,以确保Pod被调度到最合适的节点上。

5.3 调度器如何检查Pod的资源需求?

调度器在检查Pod的资源需求时,会查看Pod的定义中

spec.containers[*].resources.requests
spec.containers[*].resources.limits

字段中指定的资源需求和资源限制。

  • resources.requests字段指定了Pod启动时所需的最小资源量。例如,CPU和内存等资源的需求量。如果Pod的实际资源使用量超过了请求量,Kubernetes会杀死该Pod并重新启动。

  • resources.limits字段指定了Pod最大可以使用的资源量。例如,CPU和内存等资源的限制量。如果Pod的实际资源使用量超过了限制量,Kubernetes会限制该Pod的资源使用,并可能导致Pod无法正常运行。

调度器会根据这些资源需求和限制来选择最适合的节点来调度Pod。调度器在选择节点时会考虑节点的资源利用率和Pod的资源需求,以确保Pod可以得到足够的资源来正常运行。

5.2 如何设置Pod的亲和性和反亲和性规则

在Kubernetes中,亲和性(Affinity)和反亲和性(Anti-Affinity)是用来指定Pod和Node之间关系的规则。通过设置亲和性和反亲和性规则,可以让调度器将Pod分配到最合适的节点上。

亲和性规则用于指示Pod应该被调度到哪些节点上,而反亲和性规则用于指示Pod不应该被调度到哪些节点上。下面是如何设置Pod的亲和性和反亲和性规则:

通过标签(Labels)设置亲和性和反亲和性规则 

可以通过标签来设置Pod的亲和性和反亲和性规则。首先,需要在Pod中定义标签选择器(Label Selector),然后使用Node Affinity和Pod Affinity来指定亲和性规则,使用Node Anti-Affinity和Pod Anti-Affinity来指定反亲和性规则。例如,以下是一个使用标签选择器和亲和性规则的Pod定义:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: my-label
            operator: In
            values:
            - my-value

在上面的示例中,Pod选择器使用matchExpressions指定了一个标签选择器,该选择器选择my-label=my-value的节点。然后,使用nodeAffinity指定了一个亲和性规则,该规则要求Pod被调度到拥有该标签的节点上。

通过拓扑域(Topology)设置亲和性和 反亲和性规则

可以使用Topology来指定Pod的亲和性和反亲和性规则。Topology是指节点的拓扑结构,如拓扑域、区域、机架等。使用Topology可以确保Pod被调度到拓扑结构相似的节点上。例如,以下是一个使用Topology和亲和性规则的Pod定义:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            app: my-app
        topologyKey: rack

在上面的示例中,Pod选择器使用matchLabels指定了一个标签选择器,该选择器选择app=my-app的Pod。然后,使用topologyKey指定了一个亲和性规则,该规则要求Pod被调度到与已经调度了app=my-app的Pod在同一个rack中的节点上。

总之,通过设置亲和性和反亲和性规则,可以让调度器将Pod分配到最合适的节点上。可以使用标签或拓扑域来设置Pod的亲和性和反亲和性规则。注意,正确的设置亲和性和反亲和性规则需要了解集群的拓扑结构和资源使用情况,否则可能会导致Pod无法正确调度。

5.2 如何设置Pod的资源限制和请求

在Kubernetes中,可以通过设置Pod的资源限制和请求来控制Pod使用的资源量。资源限制(Resource Limits)指定了Pod最大可以使用的资源量,而资源请求(Resource Requests)则指定了Pod启动时所需的最小资源量。设置Pod的资源限制和请求可以确保Pod在运行时不会使用过多的资源,并且可以提高Pod在集群中的调度成功率。

以下是如何设置Pod的资源限制和请求的示例:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    resources:
      limits:
        cpu: "1"
        memory: "500Mi"
      requests:
        cpu: "0.5"
        memory: "250Mi"

在上面的示例中,Pod中的容器my-container设置了资源限制和请求。容器的资源限制是1个CPU核心和500MiB内存,而容器的资源请求是0.5个CPU核心和250MiB内存。

可以通过以下方式设置资源限制和请求:

CPU和内存 

可以使用CPU和内存来设置资源限制和请求。CPU的单位是CPU核心,内存的单位是字节。可以使用以下格式指定CPU和内存:

  • CPU:使用分数或整数表示CPU核心数量。例如,0.5表示一半核心,1表示一个核心,2表示两个核心。
  • 内存:使用字节、千字节、兆字节或吉字节表示内存大小。例如,1Gi表示1个吉字节,500Mi表示500兆字节。

其他资源 

除了CPU和内存之外,还可以使用其他资源来设置资源限制和请求,如GPU、存储等。不同的资源可以使用不同的单位,具体取决于资源类型。可以在Kubernetes文档中查看各种资源类型的详细信息。

总之,设置Pod的资源限制和请求可以控制Pod使用的资源量。可以使用CPU和内存来设置资源限制和请求,也可以使用其他资源类型。在设置资源限制和请求时,需要考虑Pod所需的资源量以及集群的资源使用情况,以避免Pod无法正常运行或影响其他Pod的运行。

6 总结

总之,Kubernetes调度是Kubernetes的核心功能之一,它能够自动将Pod分配到最合适的节点上,并确保Pod在所选节点上正常运行。调度器通过算法选择最佳的节点,并将Pod绑定到该节点上。调度器选择节点的依据包括节点的资源使用情况、Pod的资源需求、亲和性和反亲和性等。管理员可以根据自己的需求选择不同的调度算法,并监视调度器的日志以确保集群的正常运行。 

7 投票

原文地址:https://blog.csdn.net/weixin_36755535/article/details/131415996

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


文章浏览阅读942次。kube-controller-manager 和 kubelet 是异步工作的,这意味着延迟可能包括任何的网络延迟、apiserver 的延迟、etcd 延迟,一个节点上的负载引起的延迟等等。当 Kubernetes 中 Node 节点出现状态异常的情况下,节点上的 Pod 会被重新调度到其他节点上去,但是有的时候我们会发现节点 Down 掉以后,Pod 并不会立即触发重新调度,这实际上就是和 Kubelet 的状态更新机制密切相关的,Kubernetes 提供了一些参数配置来触发重新调度的时间。_node-monitor-period
文章浏览阅读3.8k次。上篇文章详细介绍了弹性云混部的落地历程,弹性云是滴滴内部提供给网约车等核心服务的容器平台,其基于 k8s 实现了对海量 node 的管理和 pod 的调度。本文重点介绍弹性云的调度能力,分为以下部分:调度链路图:介绍当前弹性云调度体系链路,对架构体系有一个初步的认知k8s 调度能力的运用:整体介绍弹性云现在用到的 k8s 调度能力和对其的增强k8s 版本的升级:介绍到从 k8s 1.12 到 1...._滴滴机房 腾讯
文章浏览阅读897次。对于cpu来说,这种分配方式并不会有太大问题,因为cpu可以灵活调度,numa调度时我们只计算绑定了numa cpu的pod是可以接受的,但是对于内存来说,numa node上申请了的内存无法做到随时迁移,这就会导致调度器视角numa node的mem资源足够,但是等到pod真正使用时,由于没有绑定numa node的pod申请的内存,导致numa node的mem资源不足,造成swap中断或者远端内存申请,这会对绑定mem的pod来带来性能损耗。忽略了没有绑定numa node的pod资源。_kubectl numa
文章浏览阅读796次,点赞17次,收藏15次。只要在Service定义中设置了ClusterIp:None,就定义了一个HeadLess Service, 它与普通的Service关键区别在于它没有ClusterIp地址,如果解析HeadLess Service的DNS域名,则会返回该Service对应的全部Pod的EndPoint列表,这就意味着客户端是直接与后端的pod建立了TCP/IP链接进行通信的。一个Label是一个键值对。注解:属于资源对象的元数据,可以被理解为一种特殊的标签,不过更多的是与程序挂钩,通常用于实现资源对象属性的自定义扩展。
文章浏览阅读763次。但是此时如果配置成 NONE, 租户创建成功了,但是无法创建资源文件,也就是无法上传文件,可能 dolphinscheduler 团队就想着将文件上传到 hdfs,暂不支持本地。需要将 resource.storage.type 置为 NONE, 因为我之前用的 1.3.6 版本的时候,即使资源文件存在本地文件也需要配置成 hdfs。_[error] 2023-10-24 18:10:43.762 +0800 org.apache.dolphinscheduler.api.servic
文章浏览阅读2.7k次,点赞2次,收藏13次。公司使用的是交老的k8s版本(1.16),由于老版本的K8s对于现在很多新特性不支持,所以需要升级到新版本。目前2023年7月11日最新版本的k8s是v1.27.3。通过参考官方文档进行k8s部署工作。其中涉及到操作系统配置、防火墙配置、私有镜像仓库等。_k8s最新版本
文章浏览阅读1.8w次,点赞14次,收藏27次。能节省你在kubeadm init 时遇到问题的排错时间⌚️。整合了网上大佬
文章浏览阅读1.1k次,点赞2次,收藏7次。具体操作步骤可以参考之前的教程,建议是先安装一台,然后克隆虚拟机,这样速度快。注意:在克隆时记得修改Mac地址、IP地址、UUID和主机名。(最后别忘了保存下快照~)_部署k8s集群
文章浏览阅读863次,点赞23次,收藏16次。当部署完 Kubernetes,便拥有了一个完整的集群。一组工作机器,称为节点, 会运行容器化应用程序。每个集群至少有一个工作节点。工作节点会 托管Pod ,而 Pod 就是作为应用负载的组件。控制平面管理集群中的工作节点和Pod。说人话版本:集群:cluster,多个几点被组织到一起共同为系统提供服务过程称之为集群。本质上是将承载同一个软件服务节点组织到一起,称之为该软件(服务)的集群,当然集群中的节点身份地位是不一样的。k8s集群也是如此,他也是多个节点组成。
文章浏览阅读943次。Rancher是一个开源的企业级多集群Kubernetes管理平台,实现了Kubernetes集群在混合云+本地数据中心的集中部署与管理,以确保集群的安全性,加速企业数字化转型。Rancher 1.0版本在2016年就已发布,时至今日,Rancher已经成长为企业在生产环境中运行容器和Kubernetes的首要选择。_rancher管理k8s
文章浏览阅读742次,点赞2次,收藏3次。本篇来讲解如何在centos下安装部署高可用k8s集群。_kubeadm ha keepalived + nginx
文章浏览阅读1.9k次,点赞21次,收藏25次。那么这个空间设置成内存的2倍大小。点击IPv4设置--手动--添加--设置ip--设置DNS服务器,最后点击--“保存”;首先选中--“本地标准磁盘”,存储配置--自定义分区,点击--“完成”;在--主机名--设置主机名:(例如k8s-master01),点击--点击+,设置--挂载点/boot--期望容量,点击--添加挂载点;点击--+--挂载点swap--期望容量,点击--“添加挂载点”;默认选择--亚洲--上海,并调整日期和时间,点击--“完成”;设备类型--确认--LVM,卷组--选择“修改”;_euler 服务器搭建
文章浏览阅读1k次。在1.25版本的k8s集群中部署gpu-manage时,虽然显示gpu节点上gpu-manage的pod实例都是running状态,但是给pod申领。既可以用源码的Makefile自动编译打包成新的镜像,但是源码的。说明gpu-manager和容器运行时接口通信失败了。编译后的镜像在1.25版本的k8s中可以正常使用。,但是在k8s1.23版本之后,接口路径已经改为。资源时,却始终找不到有资源的节点。,另外有一些依赖需要国际上的支持。可以看到这里用的运行时接口是。查看节点的详情时,返回的。_launch gpu manager 报错 can't create container runtime manager: context dead
文章浏览阅读1k次,点赞18次,收藏16次。SelfLink:API的资源对象之一,表示资源对象在集群当中自身的一个连结,self-Link是一个唯一的标识号,可以用于标识k8s集群当中的每个资源的对象。容器里使用的配置,在provisioner当中定义好环境变量,传给容器,storageclass的名称,NFS服务器的地址,NFS的目录。NFS的provisionner的客户端以pod的方式运行在集群当中,监听k8s集群当中PV的请求,然后动态的创建于NFS相关的PV。命名为 nfs-client-provisioner-clusterrole。
文章浏览阅读6.3k次,点赞2次,收藏20次。k8s证书过期解决方案之替换证书_k8s证书过期如何更换
文章浏览阅读1k次。KMS,Key Management Service,即密钥管理服务,在K8S集群中,以驱动和插件的形式启用对Secret,Configmap进行加密。以保护敏感数据
文章浏览阅读888次。exporter对于云服务的监控还是很不完美,毕竟每家都有自己的护城河。自动发现多实例这样的借助consul 阿波罗这样的会简单一些。aws可以借助cloudwatch这样的导入模板到grafana中。还是希望能将类似腾讯云云监控中的这些指标采集到prometheus中,但是这过程应该还很遥远grafana出图 prometheus查询语法这些东西有时间的好好研究一下。报警有必要进行分级别,收敛配置一下!_command: - "-redis.password-file=/redis_passwd.json
文章浏览阅读1k次。可以在此处(https://cloud.google.com/kubernetes-engine/docs/how-to/kube-dns)和此处(https://www.digitalocean.com/community/tutorials/an-introduction-to-the-kubernetes-dns-service)找到更多的详细信息。-or-ipvs/)和此处(https://arthurchiao.art/blog/cracking-k8s-node-proxy/)。_k8s默认命名空间
文章浏览阅读4.9k次,点赞11次,收藏32次。如果运行runc命令时提示:runc: error while loading shared libraries: libseccomp.so.2: cannot open shared object file: No such file or directory,则表明runc没有找到libseccomp,需要检查libseccomp是否安装,本次安装默认就可以查询到。所有主机均需要操作。所有主机均需要操作。所有主机均需要操作。所有主机均需要操作。所有主机均需要操作。所有主机均需要操作。_kubernetes 1.28
文章浏览阅读3.6w次,点赞118次,收藏144次。Canal 提供了网络功能,使得 Kubernetes 集群中的 Pod 可以相互通信,并与集群外部的服务进行通信。它通过网络插件的方式,为每个 Pod 分配唯一的 IP 地址,并管理网络流量的路由和转发。此外,Canal 还支持网络策略,用于定义 Pod 之间的通信规则和安全策略。Canal 基于 Calico 和 Flannel 项目,结合了二者的优点。它使用 Calico 的数据平面,提供高性能的网络转发和安全特性,同时使用 Flannel 的控制平面,实现 IP 地址管理和网络策略的配置。_k8s canal