当虚拟保证 Pod 正在运行时,保证应用程序 Pod 处于待处理状态

发布于 2025-01-09 17:16:14 字数 76 浏览 0 评论 0原文

在我的项目中,我需要测试保证应用程序 Pod 是否应驱逐任何正在运行的虚拟应用程序 Pod。如何实现应用程序 Pod 始终具有最高优先级?

In my project, I need to test if Guaranteed Application pods should evict any dummy application pods which are running. How do I achieve that application pods always have the highest priority?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

£冰雨忧蓝° 2025-01-16 17:16:14

P.... 提供的答案非常好且有用。通过 Pod 优先级和抢占,您可以实现您的目标最多。

然而,除此之外,您还可以使用专用解决方案,例如在云中。查看 Google 云示例

在优先级和抢占之前,Kubernetes Pod 纯粹按照先来先服务的原则进行调度,并运行到完成(或者永远运行,对于由 Deployment 或 StatefulSet 之类的东西创建的 Pod)。这意味着不太重要的工作负载可能会阻止更重要的、稍后到达的工作负载运行,而不是达到预期的效果。优先级和抢占解决了这个问题。

优先级和抢占在许多场景中都很有价值。例如,假设您希望将自动缩放限制为最大集群大小以控制成本,或者您有无法实时增长的集群(例如,因为它们位于本地,您需要购买和安装额外的硬件) )。或者您有高优先级的云工作负载,其扩展速度需要快于集群自动缩放程序添加节点的速度。简而言之,优先级和抢占可以为关键应用程序带来更好的资源利用率、更低的成本和更好的服务水平。

针对其他云的其他指南:

请参阅还有这个有用的教程

The answer provided by the P.... is very good and useful. By Pod Priority and Preemption you can achieve what you are up to.

However, apart from that, you can use dedicated solutions, for example in the clouds. Look at the Google cloud example:

Before priority and preemption, Kubernetes pods were scheduled purely on a first-come-first-served basis, and ran to completion (or forever, in the case of pods created by something like a Deployment or StatefulSet). This meant less important workloads could block more important, later-arriving, workloads from running—not the desired effect. Priority and preemption solves this problem.

Priority and preemption is valuable in a number of scenarios. For example, imagine you want to cap autoscaling to a maximum cluster size to control costs, or you have clusters that you can’t grow in real-time (e.g., because they are on-premises and you need to buy and install additional hardware). Or you have high-priority cloud workloads that need to scale up faster than the cluster autoscaler can add nodes. In short, priority and preemption lead to better resource utilization, lower costs and better service levels for critical applications.

Additional guides for other clouds:

See also this useful tutorial.

骄傲 2025-01-16 17:16:14

您可以使用 kind: PriorityClass 为您的应用程序提供比普通 Pod 更高的优先级。

You can make use of kind: PriorityClass to give your application a higher priority then normal pods.

倚栏听风 2025-01-16 17:16:14

驱逐是基于 Pod 的优先级、QoS 和 Pod 的实际使用情况。如果Pod属于更高优先级的Pod,它的创建将抢占bestEffort,然后是burstable,最后是保证的Pod。

例如:在我的集群中,我有以下 优先级类

kubectl get priorityclasses.scheduling.k8s.io 
NAME                      VALUE        GLOBAL-DEFAULT   AGE
k8s-cluster-critical      1000000000   false            11d
system-cluster-critical   2000000000   false            11d
system-node-critical      2000001000   false            11d

为了举例,我使用了system-cluster-ritic类。不要这样做,有你的优先级。接下来的 Pod 将导致其他 Pod 被驱逐。

---
apiVersion: v1
kind: Pod
metadata:
  name: guaranteed
spec:
  nodeName: kube-worker-1
  priorityClassName: system-cluster-critical
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        cpu: 1000m
        memory: 300Mi
      limits:
        cpu: 1000m
        memory: 300Mi

在其他 pod 的描述中,您将看到以下内容:

Events:
  Type     Reason      Age    From     Message
  ----     ------      ----   ----     -------
  Normal   Pulling     3m19s  kubelet  Pulling image "nginx"
  Normal   Pulled      3m19s  kubelet  Successfully pulled image "nginx" in 495.693296ms
  Normal   Created     3m19s  kubelet  Created container app
  Normal   Started     3m19s  kubelet  Started container app
  Warning  Preempting  18s    kubelet  Preempted in order to admit critical Pod
  Normal   Killing     18s    kubelet  Stopping container app

请注意,如果您的集群中没有全局默认的优先级,则没有任何优先级的 pod 的优先级将为零(最小优先级)。因此,根据应用程序的类型,您应该创建和使用多个优先级类别。

The eviction is based on the priority of the Pod, QoS, and the actual usage of the Pod. If the Pod belongs to a higher priority pod, its creation will preempt the bestEffort, followed by burstable followed by guaranteed pods.

For example: In my cluster, I have the following priority classes:

kubectl get priorityclasses.scheduling.k8s.io 
NAME                      VALUE        GLOBAL-DEFAULT   AGE
k8s-cluster-critical      1000000000   false            11d
system-cluster-critical   2000000000   false            11d
system-node-critical      2000001000   false            11d

For the sake of example, I used the system-cluster-critical class. Do not do this, have your priority class. The following Pod would lead to the eviction of other pods.

---
apiVersion: v1
kind: Pod
metadata:
  name: guaranteed
spec:
  nodeName: kube-worker-1
  priorityClassName: system-cluster-critical
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        cpu: 1000m
        memory: 300Mi
      limits:
        cpu: 1000m
        memory: 300Mi

In the description of the other pods, you would see the following:

Events:
  Type     Reason      Age    From     Message
  ----     ------      ----   ----     -------
  Normal   Pulling     3m19s  kubelet  Pulling image "nginx"
  Normal   Pulled      3m19s  kubelet  Successfully pulled image "nginx" in 495.693296ms
  Normal   Created     3m19s  kubelet  Created container app
  Normal   Started     3m19s  kubelet  Started container app
  Warning  Preempting  18s    kubelet  Preempted in order to admit critical Pod
  Normal   Killing     18s    kubelet  Stopping container app

Note that if in your cluster there is no priority class with global default then the priority of the pods without any priority class would be zero(minimum priority). So based on the type of application you should have multiple priority classes created and used.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文