黑客入侵网站怎么做,东莞建设网企业沟通平台,网页美工设计工作内容,wordpress上传的地址加一、前言
使用 Kubernetes 时#xff0c;内存不足 (OOM) 错误和 CPU 节流是云应用程序中资源处理的主要难题#xff0c;这是为什么呢#xff1f;云应用程序中的 CPU 和内存要求变得越来越重要#xff0c;因为它们与云成本直接相关。通过 limits 和 requests #xff0c;可…一、前言
使用 Kubernetes 时内存不足 (OOM) 错误和 CPU 节流是云应用程序中资源处理的主要难题这是为什么呢云应用程序中的 CPU 和内存要求变得越来越重要因为它们与云成本直接相关。通过 limits 和 requests 可以配置 pod 应如何分配内存和 CPU 资源以防止资源匮乏并调整云成本。 如果节点没有足够的资源 Pod 可能会通过抢占或节点压力被驱当一个进程运行内存不足 (OOM) 时它会被终止因为它没有所需的资源 如果 CPU 消耗高于实际限制进程将开始节流但是如何主动监控 Kubernetes Pod 到达 OOM 和 CPU 节流的距离有多近
二、Kubernetes OOM
Pod 中的每个容器都需要内存才能运行。Kubernetes limits 是在 Pod 定义或 Deployment 定义中为每个容器设置的。所有现代 Unix 系统都有一种方法来终止进程以防它们需要回收内存这将被标记为错误 137 或 OOMKilled。
State: RunningStarted: Thu, 10 Oct 2019 11:14:13 0200Last State: TerminatedReason: OOMKilledExit Code: 137Started: Thu, 10 Oct 2019 11:04:03 0200Finished: Thu, 10 Oct 2019 11:14:11 0200此退出代码 137 表示该进程使用的内存超过允许的数量必须终止。这是 Linux 中存在的一个特性内核 oom_score 为系统中运行的进程设置一个值。此外它允许设置一个名为 oom_score_adj 的值Kubernetes 使用该值来允许服务质量。它还具有一个 OOM Killer功能它将审查进程并终止那些使用比他们应该使用上限更多的内存的进程。请注意在 Kubernetes 中进程可以达到以下任何限制 在容器上设置的 Kubernetes Limit 在命名空间上设置的 Kubernetes ResourceQuota 节点的实际内存大小。 三、内存过量使用
Limits 可以高于 requests因此所有限制的总和可以高于节点容量这称为过度使用这很常见。实际上如果所有容器使用的内存都比请求的多它可能会耗尽节点中的内存这通常会导致一些 pod 被杀死以释放一些内存。
① 监控 Kubernetes OOM
在 Prometheus 中使用 node exporter 时有一个指标称为 node_vmstat_oom_kill跟踪 OOM 终止发生的时间很重要但可能希望在此类事件发生之前提前了解此类事件。相反可以检查进程与 Kubernetes 限制的接近程度
(sum by (namespace,pod,container)
(rate(container_cpu_usage_seconds_total{container!}[5m])) / sum by
(namespace,pod,container)
(kube_pod_container_resource_limits{resourcecpu})) 0.8② Kubernetes CPU 节流
CPU 节流 是一种行为当进程即将达到某些资源限制时进程会变慢。与内存情况类似这些限制可能是 在容器上设置的 Kubernetes Limit。 在命名空间上设置的 Kubernetes ResourceQuota。 节点的实际CPU大小。 想想下面的类比我们有一条有一些交通的高速公路其中 CPU 就是路。 车辆代表进程每个车辆都有不同的大小。 多条通道代表有多个核心。 一个 request 将是一条专用道路如自行车道。这里的节流表现为交通堵塞最终所有进程都会运行但一切都会变慢。 ③ Kubernetes 中的 CPU 进程
CPU 在 Kubernetes 中使用 shares 处理每个 CPU 核心被分成 1024 份然后使用 Linux 内核的 cgroups控制组功能在所有运行的进程之间分配。 可以处理所有当前进程则不需要任何操作。如果进程使用超过 100% 的 CPU那么份额就会到位。与任何 Linux Kernel 一样Kubernetes 使用 CFSCompletely Fair Scheduler机制因此拥有更多份额的进程将获得更多的 CPU 时间。与内存不同Kubernetes 不会因为节流而杀死 Pod 可以在 /sys/fs/cgroup/cpu/cpu.stat 中查看 CPU 统计信息。
四、CPU 过度使用
当想要限制进程的资源消耗时设置限制或请求很重要。然而请注意不要将请求总数设置为大于实际 CPU 大小因为这意味着每个容器都应该有一定数量的 CPU。监控 Kubernetes CPU 节流可以检查进程与 Kubernetes 限制的接近程度
(sum by (namespace,pod,container)(rate(container_cpu_usage_seconds_total
{container!}[5m])) / sum by (namespace,pod,container)
(kube_pod_container_resource_limits{resourcecpu})) 0.8如果想跟踪集群中发生的节流量cadvisor 提供 container_cpu_cfs_throttled_periods_total 和 container_cpu_cfs_periods_total有了这两个就可以轻松计算出所有 CPU 周期的 throttling 百分比。
五、最佳实践
① 注意 limits 和 requests
限制是在节点中设置最大资源上限的一种方法但需要谨慎对待这些限制因为可能最终会遇到一个进程被限制或终止的情况。
② 做好被驱逐的准备
通过设置非常低的请求可能认为这会为您的进程授予最少的 CPU 或内存。但是 kubelet 会首先驱逐那些使用率高于请求的 Pod因此将它们标记为第一个被杀死。如果需要保护特定 Pod 免遭抢占当 kube-scheduler 需要分配新 Pod 时请为最重要的进程分配优先级。
③ 节流是无声的敌人
通过设置不切实际的限制或过度使用可能没有意识到您的进程正在受到限制并且性能受到影响。主动监控 CPU 使用率并了解在容器和命名空间中的实际限制。
