k8s限制pod磁盘（k8s pod限流）

Pod的资源限制

1、在k8s中，每个pod的容器资源限制是在创建时声明的。例如，创建一个POD时，指定每个容器所需的CPU资源为200毫核（1/5核心）和10MB内存。如果没有设置CPU请求，可能导致Pod无法获取所需资源。资源请求影响调度：调度器会以请求为基础分配资源，确保每个节点至少能满足Pod的基本需求。

2、通过APPArmor限制POD访问资源 AppArmor是linux内核中的一个实现，属于Linux Security Module框架的一部分。它通过检查并控制内核调用的准入与否，实现资源访问的安全管理。appArmor与SELinux是两种主要的安全策略控制实现，分别应用于红帽系列操作系统和Ubuntu、SUSE等Linux环境。

3、kubelet配置：kubelet通过cgroup runtime driver配置CONTAINER的资源限制，确保Pod在运行时不会超过其资源限制。cgroup层次结构：root：cgroup的根节点。kubepods：包含所有由K8s管理的Pods的cgroup。QoS级别：根据Pod的QoS级别划分资源池，实现资源的精细划分和管理。

4、示例中，Pod请求至少0.5个CPU核心，限制最大使用量为1个CPU核心。内存资源示例 示例中，Pod请求至少64兆字节内存，限制最大使用量为128兆字节。设置资源配置 Kubernetes中，资源通过Pod YAML文件配置，spec字段下的containers字段，使用resources字段进行。

kubernetes限制pod的cpu和内存

如果 CPU 可以处理当前所有进程，则无需执行任何操作。如果进程使用超过 100% 的 CPU，shares 机制就要起作用了。与任何 Linux 内核一样，Kubernetes 使用 CFS（completely Fair scheduler）机制，因此拥有更多份额的进程将获得更多的 CPU 时间。与内存不同，Kubernetes 不会因为限流而杀死 Pod。

Kubernetes资源管理涉及CPU和内存两方面。CPU资源示例 示例中，Pod请求至少0.5个CPU核心，限制最大使用量为1个CPU核心。内存资源示例 示例中，Pod请求至少64兆字节内存，限制最大使用量为128兆字节。设置资源配置 Kubernetes中，资源通过Pod YAML文件配置，spec字段下的containers字段，使用resources字段进行。

资源使用与限制：CPU和内存资源的请求不仅影响调度，还影响Pod间对剩余资源的共享。例如，两个Pod按1：5比例争夺资源，第一个Pod最多只能使用17%的节点资源。设置资源限制是保护系统健康的关键。内存限制的特殊性：内存是不可压缩的，过度使用可能导致OOM （Out of Memory），影响其他Pod。

若 Pod 状态为 OOMKilled，表示容器内存溢出。此状态常见于内存限制设置过小或程序内存泄漏。解决此类问题，需合理设置内存限制及监控内存使用情况。Pod 状态为 SysctlForbidden 时，表示 Pod 自定义了内核配置，但 kubelet 未能添加或配置不支持的内核参数。

...容器经常被kill掉,k8s中该节点的pod也被驱赶,怎么分析?

在面临docker容器被频繁kill掉，以及k8s中该节点pod被驱赶的情况时，要找出问题的根源，关键在于深入分析容器的运行状态、内存使用情况以及系统资源的分配状况。以下为解决此类问题时，可以采取的步骤与工具，帮助您更直观地找出问题所在。首先，要从容器输出和状态详情入手。

含义：调度器未能将 Pod 调度到可用节点。可能原因：节点资源不足或 Pod 依赖的资源未准备好。排查方法：检查节点资源使用情况及资源预留情况，确保集群有足够的 CPU 和其他资源。CrashLoopBackoff 状态：含义：容器在启动后立即崩溃或退出。可能原因：容器配置错误、应用程序错误、内存不足或权限问题。

Pod被调度后，节点需拉取镜像以创建容器。拉取失败可能由镜像地址配置错误、集群免密配置问题、网络不通（公网访问策略、专有网络配置、镜像加速）、带宽不足或镜像体积过大导致。依赖项错误 常见错误状态：Error 在Pod启动前，Kubelet检查依赖关系，如PersistentVolume、ConfigMap和secret。

宿主节点行为：如果Pod没有资源限制，可能会在宿主机中安装模拟内存不回收的工具，如bigmem。当分配内存时，宿主机用户使用内存增加，可用内存减少。当申请内存超过宿主机可用内存时，bigmem所在进程会被kill。查看宿主机日志可以发现，这是由Cgroup限制触发的OOMKilled。

异常场景分析 调度失败 常见错误状态：Unschedulable 当Pod创建后进入调度阶段，Kubernetes调度器依据Pod的资源需求和调度规则选择节点。如果所有节点都无法满足Pod的需求，Pod将进入Pending状态。

k8s中Pod状态及问题排查方法

1、含义：调度器未能将 Pod 调度到可用节点。可能原因：节点资源不足或 Pod 依赖的资源未准备好。排查方法：检查节点资源使用情况及资源预留情况，确保集群有足够的 CPU 和其他资源。CrashLoopBackOff 状态：含义：容器在启动后立即崩溃或退出。可能原因：容器配置错误、应用程序错误、内存不足或权限问题。

2、要排查镜像拉取问题，可使用kubectl describe pod命令检查pod事件，寻找“Failed to pull image”或“ImagePullBackOff”事件，表明镜像拉取存在问题。资源不足时，使用kubectl describe node命令检查节点资源状态。检查持久卷（PVC）状态，确保其STATUS为“Bound”，表明存储供应无问题。

3、Pod驱逐 节点资源不足时，K8s驱逐内存敏感型Pod。优化资源配额和限制值，避免资源被耗尽。Pod失联 Pod处于Unknown状态，无法获取信息。检查Kubelet状态，修复节点问题。无法被删除 Pod执行删除操作后长时间处于Terminating状态。排查删除操作和集群状态，确保删除流程顺利。

4、首先，要从容器输出和状态详情入手。通过运行`Docker logs $container_id`，您可以直接查看容器内的应用程序输出，以获取实时运行信息。接着，`docker inspect $container_id`可提供容器的详细状态信息，其中特别要注意“OOMKilled”信息，该信息表示容器因内存不足而被Docker自动终止。