k8s资源之vpa

 欢迎关注我的公众号:

 目前刚开始写一个月,一共写了18篇原创文章,文章目录如下:

istio多集群探秘,部署了50次多集群后我得出的结论

istio多集群链路追踪,附实操视频

istio防故障利器,你知道几个,istio新手不要读,太难!

istio业务权限控制,原来可以这么玩

istio实现非侵入压缩,微服务之间如何实现压缩

不懂envoyfilter也敢说精通istio系列-http-rbac-不要只会用AuthorizationPolicy配置权限

不懂envoyfilter也敢说精通istio系列-02-http-corsFilter-不要只会vs

不懂envoyfilter也敢说精通istio系列-03-http-csrf filter-再也不用再代码里写csrf逻辑了

不懂envoyfilter也敢说精通istio系列http-jwt_authn-不要只会RequestAuthorization

不懂envoyfilter也敢说精通istio系列-05-fault-filter-故障注入不止是vs

不懂envoyfilter也敢说精通istio系列-06-http-match-配置路由不只是vs

不懂envoyfilter也敢说精通istio系列-07-负载均衡配置不止是dr

不懂envoyfilter也敢说精通istio系列-08-连接池和断路器

不懂envoyfilter也敢说精通istio系列-09-http-route filter

不懂envoyfilter也敢说精通istio系列-network filter-redis proxy

不懂envoyfilter也敢说精通istio系列-network filter-HttpConnectionManager

不懂envoyfilter也敢说精通istio系列-ratelimit-istio ratelimit完全手册

 

————————————————

vpa

VPA 全称 Vertical Pod Autoscaler,即垂直 Pod 自动扩缩容,可以根据容器资源使用情况自动设置 CPU 和 内存 的请求值,从而允许在节点上进行适当的调度,以便为每个 Pod 提供适当的资源。它既可以缩小过度请求资源的容器,也可以根据其使用情况随时提升资源不足的容量。

部署:

git clone GitHub - kubernetes/autoscaler: Autoscaling components for Kubernetes

cd vertical-pod-autoscaler/

./hack/vpa-up.sh

VPA 有以下四种更新策略

Initial:仅在 Pod 创建时修改资源请求,以后都不再修改。

Auto:默认策略,在 Pod 创建时修改资源请求,并且在 Pod 更新时也会修改。

Recreate:类似 Auto,在 Pod 的创建和更新时都会修改资源请求,不同的是,只要Pod 中的请求值与新的推荐值不同,VPA 都会驱逐该 Pod,然后使用新的推荐值重新启一个。因此,一般不使用该策略,而是使用 Auto,除非你真的需要保证请求值是最新的推荐值。

Off:不改变 Pod 的资源请求,不过仍然会在 VPA 中设置资源的推荐值。

recommand:

[root@master01 recommend]# cat ./*
apiVersion: autoscaling.k8s.io/v1beta2
kind: VerticalPodAutoscaler
metadata:
  name: my-rec-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: my-rec-deployment
  updatePolicy:
    updateMode: "Off"
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-rec-deployment
  labels:
    purpose: try-recommend
spec:
  selector:
    matchLabels:
      purpose: try-recommend
  replicas: 2
  template:
    metadata:
      labels:
        purpose: try-recommend
    spec:
      containers:
      - name: my-rec-container
        image: nginx:latest

auto:

[root@master01 try-auto-requests]# cat ./*
apiVersion: autoscaling.k8s.io/v1beta2
kind: VerticalPodAutoscaler
metadata:
  name: my-rec-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: my-deployment
  updatePolicy:
    updateMode: "Auto"
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    purpose: try-auto-requests
spec:
  replicas: 2
  selector:
    matchLabels:
      purpose: try-auto-requests
  template:
    metadata:
      labels:
        purpose: try-auto-requests
    spec:
      containers:
      - name: my-container
        image: alpine:latest
        resources:
          requests:
            cpu: 100m
            memory: 50Mi
        command: ["/bin/sh"]
        args: ["-c", "while true; do timeout 0.5s yes >/dev/null; sleep 0.5s; done"]

VPA 主要包含三个组件:

Admission Controller

Recommender

Updater

<think>嗯,用户想了解Kubernetes集群节点的资源配置最佳实践和要求。首先,我需要回忆一下K8s的官方文档和相关实践经验。记得K8s对节点的资源有一定的建议,但具体数值可能因版本而异。比如,控制平面节点和工作节点的需求不同,控制平面需要更高的CPU和内存来处理调度和API请求。 接下来,用户提到的CPU、内存、存储,每个部分都需要详细说明。CPU方面,控制节点至少需要2核,生产环境可能需要4核以上,而工作节点根据负载调整。内存的话,控制节点至少2GB,生产可能4GB以上,工作节点同样需要根据应用需求来定。存储方面,系统盘、容器运行时、持久化卷这些分区要考虑,还有IOPS的要求。 然后,最佳实践部分,比如资源预留、监控、水平扩展、存储选择、标签管理、污点容忍这些点都要覆盖。用户可能想知道如何优化节点配置,避免资源不足或浪费。另外,引用中的资料提到通过Java查询资源使用情况,说明用户可能对监控工具也有兴趣,可以提到Prometheus或者kubectl top这样的工具。 还要注意用户的真实需求,他们可能在部署集群时遇到资源配置的问题,或者想优化现有集群。需要强调一致性、监控的重要性,以及根据应用负载动态调整的策略。可能还需要解释节点资源不足会导致Pod被驱逐,影响服务稳定性,所以预留资源很关键。 最后,相关问题部分要引导用户深入思考,比如如何监控资源、处理资源不足、优化存储性能,以及自动扩缩容的机制。确保回答结构清晰,分点明确,引用相关的参考资料来增强可信度。需要检查是否有遗漏的重要点,比如节点操作系统、内核版本的影响,或者网络带宽的要求,但根据引用内容,用户主要关注CPU、内存、存储,所以可以集中在这些方面。</think>### Kubernetes集群节点资源配置要求与最佳实践 #### 一、基础资源配置要求 1. **控制平面节点(Master节点)** - **CPU**:至少2核(推荐4核以上),用于处理API请求、调度、控制器等核心组件[^2] - **内存**:最低2GB(生产环境建议4GB以上),需支撑`kube-apiserver`、`etcd`等高消耗组件 - **存储**:系统盘建议50GB以上(需考虑`etcd`数据增长),IOPS不低于500[^3] 2. **工作节点(Worker节点)** - **CPU**:根据负载动态调整,建议预留至少1核供系统/K8s组件使用 - **内存**:总量需满足`Pod需求 + 系统预留(至少1GB)`,避免因OOM(内存溢出)导致Pod驱逐 - **存储**: - 容器运行时存储(如Docker):推荐100GB以上,支持镜像分层 - 持久化卷(PV):独立分区,根据业务需求配置(如SSD优化IO密集型应用) #### 二、最佳实践 1. **资源预留策略** - 通过`kubelet`配置`--system-reserved`和`--kube-reserved`参数,为系统/K8s组件保留资源 - 示例:预留10% CPU和15%内存防止资源争抢 ```yaml kubeletArguments: system-reserved: ["cpu=500m,memory=1Gi"] ``` 2. **监控与调优** - 使用`kubectl top nodes`或`Prometheus`监控实时资源利用率[^1] - 通过`Vertical Pod Autoscaler(VPA)`自动调整Pod资源请求 3. **水平扩展原则** - 单节点资源上限建议: - CPU不超过64核(避免调度粒度问题) - 内存不超过256GB(防止垃圾回收延迟) 4. **存储配置建议** - 使用本地SSD或高性能云盘(如AWS EBS gp3) - 分离`/var/lib/kubelet`(Pod卷)和`/var/lib/docker`(镜像存储)的存储路径 #### 三、特殊场景要求 1. **有状态应用(如数据库)** - 配置`Local PersistentVolume`并绑定NUMA节点,减少跨CPU访问延迟 - 内存分配需包含缓存需求(如Redis建议预留30%额外内存) 2. **边缘计算场景** - 最小化节点配置(如1核2GB内存)时,需关闭非核心组件(如`kube-proxy`替换为`Cilium`) #### 四、配置验证方法 ```bash # 查看节点资源容量与分配 kubectl describe nodes | grep -A 10 "Capacity" # 输出示例: # Capacity: # cpu: 8 # memory: 16302084Ki # Allocatable: # cpu: 7800m # memory: 14462244Ki ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

hxpjava1

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值