企业级容器技术 k8s 容器资源限制器

本文深入探讨Kubernetes中资源限制的重要性,包括内存和CPU的限制设置,如何通过limit和request控制资源分配,以及如何为namespace设置资源配额和限制pod数量。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

资源限制k8s采用limit和request两种
limit资源限额,最多是多少。
request资源需求,满足最基本的才能运行。

内存限制

首先做一个测试,创建一个pod

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo
spec:
  containers:
  - name: memory-demo
    image: stress  ##专门做压力测试的镜像
    args:  ##镜像参数
    - --vm
     - "1"
    - --vm-bytes
    - 200M    ##测试200M内存
    resources:
      requests:
        memory: 50Mi  ##最小50
      limits:
        memory: 100Mi  ##不能超过100M

使用文件创建pod

[kubeadm@server1 limit]$ kubectl get pod
NAME          READY   STATUS      RESTARTS   AGE
memory-demo   0/1     OOMKilled   2          42s

在这里我们看到这个pod已经OOMKilled,这时因为内存超出了设定的值。
当我们将最后两行,最大值去掉后再运行这个pod,状态就会变成running,就可以使用200M的内存。

cpu限制

apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo
spec:
  containers:
  - name: cpu-demo
    image: stress
    args: 
    - -c
    - "2"
    resources:
      requests:
        cpu: "5"
      limits:
        memory: "10"

使用这个文件创建pod,pod也不会运行,因为最少需要5个cpu但是镜像只运行两个,达不到要求,所以状态会变成Pending。

[kubeadm@server1 limit]$ kubectl get pod
NAME       READY   STATUS    RESTARTS   AGE
cpu-demo   0/1     Pending   0          3s

为namespace设置资源限制

apiVersion: v1
kind: LimitRange  ##资源限制
metadata:
  name: limitrange-memory
spec:
  limits:   ##限制了两种内存和cpu
  - max:    ##最主要就是设置最小和最大
      cpu: 1
      memory: 1Gi
    min:
      cpu: 0.1
      memory: 100Mi
    default:    ##当pod没有定义资源限制时用这个
      memory: 512Mi
      cpu: 0.5
    defaultRequest:
      memory: 256Mi
      cpu: 0.1
    type: Container
[kubeadm@server1 limit]$ kubectl describe limitranges 
Name:       limitrange-memory
Namespace:  default
Type        Resource  Min    Max  Default Request  Default Limit  Max Limit/Request Ratio
----        --------  ---    ---  ---------------  -------------  -----------------------
Container   cpu       100m   1    100m             500m           -
Container   memory    100Mi  1Gi  256Mi            512Mi          -

这样设置完成后创建一个pod,如果不定以资源限制,则会自动将使用Default中的信息进行限制。

为namespaces设置资源配额

apiVersion: v1
kind: ResourceQuota
metadata:
  name: mem-cpu-demo
spec:
  hard:
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi

启用了这个资源配额,每个容器必须设置限额和请求cpu和内存都要设置。如果不设置会报错。

[kubeadm@server1 limit]$ kubectl describe resourcequotas 
Name:            mem-cpu-demo
Namespace:       default
Resource         Used  Hard
--------         ----  ----
limits.cpu       0     2      ##现在使用是空,没有使用
limits.memory    0     2Gi
requests.cpu     0     1
requests.memory  0     1Gi

现在启动一个不指定cpu和内存的pod,创建以后会提示forbidden。只有设置完成或者提前设置了limitrange后才可以创建。

[kubeadm@server1 limit]$ kubectl describe resourcequotas
Name:            mem-cpu-demo
Namespace:       default
Resource         Used   Hard
--------         ----   ----
limits.cpu       500m   2
limits.memory    512Mi  2Gi
requests.cpu     100m   1
requests.memory  256Mi  1Gi
限制pod的数量
apiVersion: v1
kind: ResourceQuota
metadata:
  name: pod-demo
spec:
  hard:
    pods: "2"  ##限制pod数量
[kubeadm@server1 limit]$ kubectl describe resourcequotas 
Name:       pod-demo
Namespace:  default
Resource    Used  Hard
--------    ----  ----
pods        1     2
<think>好的,我现在需要回答用户关于企业级Kubernetes使用方法和最佳实践的问题。首先,我应该回顾用户提供的引用内容,看看有哪些相关的信息可以利用。 用户提到了四个引用,其中引用[1]提到Kubernetes的学习曲线陡峭,生产操作需谨慎,并建议关注可观察性、日志记录、集群监控和安全配置。引用[4]则详细介绍了使用Prometheus监控Kubernetes的最佳实践,包括Annotations的作用和监控指标分类。引用[2]和[3]讨论了Kubernetes与Kubeflow、Spring Boot等的结合,但用户的问题更偏向于企业级使用的最佳实践,所以可能需要更关注引用[1]和[4]。 接下来,我需要整理企业级Kubernetes的最佳实践,涵盖部署、管理、监控、安全等方面。根据引用[1],安全配置是关键,需要包括RBAC、网络策略等。引用[4]提到的监控部分,Prometheus和Annotations的使用也应该包含进去。此外,用户可能还需要了解高可用性部署、资源管理、CI/CD集成等。 需要注意的是,回答的结构要清晰,分点列出,每个部分给出具体建议,并自然地插入引用标注。同时,按照用户要求,生成相关问题,这些问题应该与用户的问题相关,帮助他们进一步深入理解。 在整理过程中,要确保使用正确的中文表达,数学公式和代码块按照系统级指令处理。不过这个问题主要不涉及数学公式,可能更多的是代码块,比如部署文件示例或命令。但用户示例中的快速排序用了代码块,所以可能需要适当加入相关YAML或命令示例。 最后,检查是否符合所有格式要求,比如引用标注的位置,避免使用Markdown,行内公式用$...$,独立公式用$$...$$,但这里可能不需要公式。确认没有使用任何Markdown格式,使用自然的中文,分步骤说明,结构清晰。</think>### 企业级 Kubernetes 使用教程与最佳实践 企业级 Kubernetes 的管理需要结合稳定性、安全性和可扩展性。以下是关键步骤与最佳实践: --- #### **一、部署规划** 1. **高可用架构** - 控制平面(Control Plane)需部署至少3个节点,通过多副本的 API Server、Scheduler、Controller Manager 避免单点故障。 - 使用负载均衡器(如 HAProxy 或云厂商的 LB)分发流量到 API Server 节点[^1]。 2. **集群网络设计** - 选择成熟的 CNI 插件(如 Calico、Cilium),确保 Pod 间通信和网络策略支持。 - 通过 `NetworkPolicy` 实现微服务间的隔离,例如限制特定命名空间的访问权限[^4]。 --- #### **二、安全配置** 1. **RBAC 权限控制** - 为每个用户或服务账户分配最小权限,例如: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: dev name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"] ``` - 定期审计权限分配,避免过度授权[^1]。 2. **镜像与运行时安全** - 使用私有镜像仓库(如 Harbor),并扫描镜像漏洞(Trivy、Clair)。 - 启用 Pod Security Admission,限制特权容器运行。 --- #### **三、可观察性与监控** 1. **Prometheus + Grafana 监控** - 部署 `kube-prometheus-stack` 采集集群指标,包括节点 CPU/内存、Pod 状态、网络流量等。 - 配置告警规则(如节点磁盘压力超过 80% 时触发通知)。 2. **日志聚合** - 使用 EFK(Elasticsearch + Fluentd + Kibana)或 Loki 集中存储日志。 - 通过 `Annotations` 标记关键服务,例如记录部署版本信息。 --- #### **四、资源管理与优化** 1. **资源配额与限制** - 在命名空间中设置 `ResourceQuota`,防止资源耗尽: ```yaml apiVersion: v1 kind: ResourceQuota metadata: name: mem-cpu-quota spec: hard: requests.cpu: "10" requests.memory: 20Gi limits.cpu: "20" limits.memory: 40Gi ``` 2. **自动扩缩容** - 配置 HPA(Horizontal Pod Autoscaler)基于 CPU/内存或自定义指标扩缩 Pod。 - 使用 Cluster Autoscaler 动态调整节点数量(适用于云环境)。 --- #### **五、持续交付与 GitOps** 1. **CI/CD 流水线集成** - 通过 Argo CD 或 Flux 实现 GitOps,将部署配置存储在 Git 仓库中,确保版本可追溯。 - 在流水线中加入自动化测试与金丝雀发布策略[^3]。 2. **配置标准化** - 使用 Helm Charts 或 Kustomize 管理应用配置,避免手动修改 YAML 文件。 --- #### **六、灾难恢复** 1. **定期备份** - 使用 Velero 备份集群资源(如 PV、Deployment)到对象存储(如 S3)。 - 测试备份恢复流程,确保 RTO(恢复时间目标)符合 SLA。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值