背景
扩展资源是 kubernetes.io 域名之外的标准资源名称。它们使得集群管理员能够颁布非Kubernetes 内置资源,而用户可以使用他们。
自定义扩展资源无法使用 kubernetes.io 作为资源域名。
管理扩展资源
- 节点级扩展资源
节点级扩展资源绑定到节点. - 设备插件管理的资源
发布在各节点上由设备插件所管理的资源,如 GPU(GPUmanager),智能网卡等。
为节点配置资源
- 集群管理员可以向apierver提交 PATCH的HTTP 请求,然后在节点的 status.capacity 中为其配置资源。
- kubelet 会异步地对 status.allocatable 字段执行自动更新操作,使之包含新资源。
- 调度器在评估 Pod 是否适合在某节点上执行时会使用节点的 status.allocatable 值,在更新节点容量使之包含新资源之后和请求该资源的第一个 Pod 被调度到该节点之间,可能会有短暂的延迟。
集群层面的扩展资源
- 可选择由默认调度器管理资源,默认调度器像管理其他资源一样管理扩展资源。
- Request 与 Limit 必须一致,因为 Kubernetes无法确保扩展资源的超售。
- 更常见的场景是,由调度器扩展程序(Scheduler Extenders)管理,这些程序处理资源消耗和资源配额。
- 修改调度器策略配置 ignored ByScheduler 字段
可配置调度器不要检查自定义资源。
- 修改调度器策略配置 ignored ByScheduler 字段
实践
- 查看当前环境的kubeconfig
cat ~/.kube/config
- 解码并生成证书
echo LS0tL...== | base64 -d > admin.crt echo LS0tL...== | base64 -d > admin.key
- 执行patch命令添加资源
curl --key admin.key --cert admin.crt --header "Content-Type: application/json-patch+json" --request PATCH -k --data '[{"op": "add", "path": "/status/capacity/extended-cpu", "value": "2"}]' https://192.168.0.6:6443/api/v1/nodes/node1/status
这里会报错,因为匿名用户没有patch的权限,需要授权。
- 授权
k create clusterrolebinding test:anonymous --clusterrole=cluster-admin --user=system:anonymous
- 再次执行patch命令,成功。
- 查看node的资源信息。
- 部署带额外资源的pod。
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx resources: limits: # 这里先超出额外资源做测试 wgh/extended-cpu: 3 requests: wgh/extended-cpu: 3
k create -f deployment.yaml k get po
由于设置的额外资源只有2,deployment中requests需要3,所以pod处于pending状态。
- 修改wgh/extended-cpu为2,pod调度成功。
- 删除额外资源。
curl --key admin.key --cert admin.crt --header "Content-Type: application/json-patch+json" --request PATCH -k --data '[{"op": "remove", "path": "/status/capacity/wgh~1extended-cpu", "value": "2"}]' https://192.168.0.6:6443/api/v1/nodes/node1/status
已经没有wgh/extended-cpu的资源了。