问题描述
在使用Kubernetes时遇到一个问题：他希望在一个Pod启动后能够更改该Pod的CPU请求值。他们在共享的Kubernetes系统中有一个要求，即实际资源使用量与YAML文件中的资源请求值“相当接近”，否则会限制用户部署进一步的作业，直到他们纠正其资源请求。
因此，对于用户来说，能够在作业启动后调整资源请求值非常有价值。理论上，只有在节点上有足够资源（CPU、内存）可用的情况下，这样的请求才能成功。
用户注意到Kubernetes中有一个kubectl patch选项，可以进行动态更新，但目前还不清楚它是否能够实现他所需要的功能。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
在Kubernetes中，调整已经启动的Pod/Job的资源请求值并不直接支持，因为一旦Pod/Job启动，其资源配置将被固定。然而，你可以通过一些方法来达到类似的效果。
方案1：使用LimitRange
你可以使用Kubernetes的LimitRange资源来限制Pod的资源使用量。通过设置Max限制和LimitRequestRatio，可以确保用户在创建Pod时必须设置低于Max或request*ratio的资源限制，否则API服务器将返回403 Forbidden错误。
以下是如何使用LimitRange来实现的步骤：
1. 创建一个LimitRange定义，定义其中包含的资源限制规则。
2. 在需要限制资源的Namespace中应用这个LimitRange。
下面是一个示例的LimitRange定义：
apiVersion: v1
kind: LimitRange
metadata:
name: resource-limits
spec:
limits:
- max:
cpu: 1
memory: 1Gi
default:
cpu: 100m
memory: 100Mi
defaultRequest:
cpu: 50m
memory: 50Mi
type: Container
在上面的示例中，我们定义了一个LimitRange，限制了容器的最大CPU和内存使用量。同时，我们还指定了默认的CPU和内存限制，以及默认的CPU和内存请求。这样，当用户创建Pod时，它们的资源请求和限制将受到这些规则的约束。
请注意，这种方法并不是在Pod已经启动后直接调整资源请求值，而是在创建Pod时就进行了限制，从而达到类似的效果。
方案2：使用动态调整
如果你确实需要在Pod已经启动后动态调整资源请求值，那么通常需要进行一些复杂的操作，并且可能会有一些风险。这可能包括：
– 使用kubectl patch来更新Pod的描述，但这可能会导致Pod的重新调度，影响业务。
– 编写自定义控制器或脚本，监控Pod的状态，并在需要时调用Kubernetes API来更新Pod的资源配置。
请注意，这种方法可能会带来一些挑战，包括可能的数据丢失、应用程序中断等。在考虑使用这种方法时，务必进行充分的测试，并确保你的系统可以容忍这些风险。
方案3：使用Horizontal Pod Autoscaler
如果你的目标是根据Pod的实际资源使用情况来调整资源请求值，那么可以考虑使用Horizontal Pod Autoscaler（HPA）。HPA可以根据CPU或内存使用情况自动调整Pod的副本数量，从而影响资源请求的总量。
以下是使用HPA来自动调整资源请求值的步骤：
1. 创建一个Deployment或ReplicaSet，并配置HPA以监控其资源使用情况。
2. 配置HPA的资源请求目标，例如，可以设置目标CPU利用率为50%。
3. 当HPA检测到资源使用率变化时，会自动调整Pod的副本数量，从而影响总的资源请求量。
这种方法可以根据实际资源使用情况动态地调整资源请求值，从而更好地满足应用程序的需求。
注意事项
- 在尝试任何上述方法之前，请务必备份你的Pod/Job配置和数据，以防万一。
- 根据你的具体需求选择适合的方法，并在测试环境中进行充分的测试，以确保不会对生产环境造成负面影响。
注意：本文提供的解决方案可能因Kubernetes版本、集群配置等因素而有所不同。请在实际操作中根据文档进行相应调整和测试。