Kubernetes节点使用舵图的基于条件的调度

如何解决Kubernetes节点使用舵图的基于条件的调度

团队，需要一些帮助。

根据报告的节点条件进行Pod调度

kubectl get node node1 -o yaml

我们可以执行基于node.condition的调度..如下所示使用nodeSelector的方式吗？

nodeSelector:
  team.nb/service: services
  nodeType: cpu

基本上，如果k8s工作节点在其node.yaml中报告以下情况，我该如何设置舵图以匹配该条件？

  - lastHeartbeatTime: "2020-09-29T00:06:24Z"
    lastTransitionTime: "2020-08-16T12:47:16Z"
    message: kubelet has disk pressure
    reason: KubeletHasNoDiskPressure
    status: "false"
    type: DiskPressure

我们可以基于此值构建helm_chart来调度Pod吗？这样只有当以下条件为True时，豆荚才能降落在上面

我正在搜索google，但找不到任何线索。

  nodeConditions:
    reason: KubeletHasNoDiskPressure
    status: True

解决方法

您可能希望使用资源约束来请求实际需要的磁盘空间，或者更好的是，避免需要大量的本地磁盘空间。

Assigning Pods to Nodes上的Kubernetes文档指出了可用的选项：将Pod固定到特定节点，按标签匹配或根据其他已知Pod的存在建议放置。它还指出

通常这种约束是不必要的，因为调度程序会自动进行合理的放置（例如，将Pod分散到各个节点上，而不是将Pod放置在可用资源不足的节点上，等等）....

可以将群集配置为make "ephemeral storage" a resource type；这包括容器文件系统使用的磁盘。如果您知道需要“大量”磁盘空间并且为此配置了集群，则可以在YAML文件中放置一个适当的资源请求：

containers:
  - name: main
    resources:
      requests:
        ephemeral-storage: 20Gi

如果您确实需要那么多存储空间，那么volume是更好的选择。如果您有多个副本，则可能需要一个StatefulSet来为每个副本自动创建PersistentVolumeClaim。请注意，emptyDir的数量计入临时存储限制，并且无法解决这个问题。

如果某个卷也不正确，则值得研究为什么需要那么多存储空间。如果您需要临时空间来进行非常大的计算，则必须将其放在某个地方。当我遇到这样的麻烦时，这是一个调试级别的日志文件，超出了控制范围，正确的答案是调低日志级别。

让Pod或节点崩溃是合法的选择！如果Pod崩溃，通常它将重新启动（尽管在同一节点上；正确指定资源限制很重要）。如果某个节点发生故障，则将在其他节点上重新创建其上的Pod。如果您有一个群集自动缩放器，并且由于资源限制而无法调度节点，则这将导致存在更多节点，并且可以在此处重新调度Pod。

,

调度程序已经执行了这样的操作-如果节点具有磁盘压力，则节点控制器将对其进行污染，以便调度程序不会在其上放置任何其他内容。换句话说，如果节点没有磁盘压力，那么调度程序将在其中放置容器，这似乎就是您想要的？

节点控制器在某些情况下会自动污染节点 条件是真的。内置以下污点：

node.kubernetes.io/disk-pressure：节点具有磁盘 压力。

您还可以调整Kubelet配置，以在剩余磁盘空间少于xyz％时将其移出Pod，以防止出现磁盘压力。

我知道您的问题有点像基于条件的调度，但是您想要在没有磁盘压力的情况下调度节点上的Pod的特定示例是开箱即用的，因此没有理由这样做。