苏州知名网站建设建站公司,织梦网站栏目不显示,机械门户网站建设特点,建设网站如果赚钱当在Kubernetes中使用容器时#xff0c;重要的是要知道所涉及的资源是什么以及如何需要它们。有些进程比其他进程需要更多的CPU或内存。有些是关键的#xff0c;不应该被饿死。知道了这一点#xff0c;我们应该正确配置我们的容器和Pod#xff0c;以获得两者的最佳效果。在…当在Kubernetes中使用容器时重要的是要知道所涉及的资源是什么以及如何需要它们。有些进程比其他进程需要更多的CPU或内存。有些是关键的不应该被饿死。知道了这一点我们应该正确配置我们的容器和Pod以获得两者的最佳效果。在这篇文章中我们将看到。Kubernetes 的Limits和Requests介绍实践案例Kubernetes RequestsKubernetes LimitsCPU的特殊性内存的特殊性Namespace ResourceQutaNamespace LimitRange总结Kubernetes的Limits和Requests介绍在使用Kubernetes时Limits和Requests是重要的配置主要包含CPU和内存的配置。Kubernetes将Limits定义为一个容器使用的最大资源量这意味着容器的消耗量永远不能超过所显示的内存量或CPU量。另一方面Requests是指为容器保留的资源的最小保证量。image.png实践案例让我们来看看下面这个deployment我们需要为两个不同的容器在CPU和内存上设置Limits和Requests。kind: DeploymentapiVersion: extensions/v1beta1…template: spec: containers: - name: redis image: redis:5.0.3-alpine resources: limits: memory: 600Mi cpu: 1 requests: memory: 300Mi cpu: 500m - name: busybox image: busybox:1.28 resources: limits: memory: 200Mi cpu: 300m requests: memory: 100Mi cpu: 100m假如我们要把该deployment部署到4C16G配置的节点上可以得到如下信息。Pod的有效请求是400 MiB的内存和600 millicores的CPU你需要一个有足够自由可分配空间的节点来安排pod。Redis容器的CPU份额将是512而busybox容器是102Kubernetes总是为每个核心分配1024个份额因此redis1024 * 0.5 cores ≅ 512和busybox1024 * 0.1核 ≅ 102如果Redis容器试图分配超过600MB的RAM它将被OOM杀死很可能使pod失败。如果Redis试图在每100ms内使用超过100ms的CPU因为我们有4个核心可用时间为每100ms 400ms它将遭受CPU节流导致性能下降。如果Busybox容器试图分配超过200MB的RAM它将被OOM杀死导致一个失败的Pod。如果Busybox试图每100ms使用超过30ms的CPU它将遭受CPU节流导致性能下降。Kubernetes RequestsKubernetes将请求定义为容器使用的资源的最低保证量。基本上它将设定容器所要消耗的资源的最小数量。当一个Pod被调度时kube-scheduler将检查Kubernetes请求以便将其分配给一个特定的节点该节点至少可以满足Pod中所有容器的这个数量。如果请求的数量高于可用的资源Pod将不会被安排并保持在Pending状态。关于Pending状态的更多信息请查看Understanding Kubernetes Pod pending problems【1】。在这个例子中在容器定义中我们设置了一个请求要求100m核心的CPU和4Mi的内存。resources: requests: cpu: 0.1 memory: 4MiRequests通常被使用在以下场景当把Pod分配给一个节点时所以Pod中的容器的指定请求被满足。在运行时指定的请求量将被保证为该Pod中的容器的最小值。image.pngKubernetes LimitsKubernetes将Limits定义为一个容器使用的最大资源量。这意味着容器的消耗量永远不能超过指定的内存量或CPU量。 resources: limits: cpu: 0.5 memory: 100MiLimits通常用于以下场景当把Pod分配给一个节点时如果没有设置请求默认情况下Kubernetes将分配请求限制。在运行时Kubernetes将检查Pod中的容器所消耗的资源量是否高于限制所显示的数量。image.pngCPU的特性CPU是一种可压缩的资源这意味着它可以被拉伸以满足所有的需求。如果进程要求太多的CPU其中一些将被节制。CPU代表计算处理时间以核为单位。你可以用毫微米m来表示比一个核心更小的数量例如500米是半个核心。最小的数量是1m一个节点可能有一个以上的核心可用所以请求CPU1是可能的image.png内存的特性内存是一种不可压缩的资源意味着它不能像CPU那样被拉伸。如果一个进程没有得到足够的内存来工作这个进程就会被杀死。在Kubernetes中内存的单位是字节。你可以用EPTGMk来代表ExabytePetabyteTerabyteGigabyteMegabyte和kilobyte尽管只有最后四个是常用的。(例如500M, 4G)警告不要用小写的m表示内存这代表Millibytes低得离谱你可以用Mi来定义Mebibytes其余的也可以用Ei、Pi、Ti来定义例如500Mi一个Mebibyte以及它们的类似物Kibibyte、Gibibyte...是20字节的2次方。它的出现是为了避免与公制中的Kilo、Mega定义相混淆。你应该使用这个符号因为它是字节的典型定义而Kilo和Mega是1000的倍数。image.png最佳实践在Kubernetes中你应该很少使用限制来控制你的资源使用。这是因为如果你想避免饥饿确保每个重要的进程都能得到它的份额你应该首先使用请求。通过设置限制你只是防止进程在特殊情况下检索额外的资源在内存方面造成OOM杀戮在CPU方面造成Throttling进程将需要等待CPU可以再次使用。欲了解更多信息请查看article about OOM and Throttling【2】。如果你在一个Pod的所有容器中设置一个等于限制的请求值该Pod将获得保证的服务质量。还需要注意的是资源使用量高于请求的Pod更有可能被驱逐所以设置非常低的请求会造成弊大于利。可以在Pod eviction and Quality of Service【3】查看。Namespace ResourceQuata由于命名空间的存在我们可以将Kubernetes资源隔离到不同的组也称为租户。通过ResourceQuota你可以为整个命名空间设置一个内存或CPU限制确保其中的实体不能消耗超过这个数量。apiVersion: v1kind: ResourceQuotametadata: name: mem-cpu-demospec: hard: requests.cpu: 2 requests.memory: 1Gi limits.cpu: 3 limits.memory: 2Girequests.cpu这个命名空间中所有请求的最大CPU数量。requests.memory这个命名空间中所有请求的最大内存量。limits.cpu这个命名空间中所有限制的最大CPU数量。limits.memory这个命名空间中所有限制的总和的最大内存量。然后将其应用于你的命名空间。kubectl apply -f resourcequota.yaml --namespacemynamespace你可以用以下方法列出一个命名空间的当前ResourceQuota。kubectl get resourcequota -n mynamespace注意如果你为命名空间中的特定资源设置了ResourceQuota那么你就需要为该命名空间中的每个Pod指定相应的限制或请求。否则Kubernetes将返回一个 failed quota的错误。Error from server (Forbidden): error when creating mypod.yaml: pods mypod is forbidden: failed quota: mem-cpu-demo: must specify limits.cpu,limits.memory,requests.cpu,requests.memory如果你试图添加一个新的Pod其容器限制或请求超过了当前的ResourceQuotaKubernetes将返回一个 exceeded quota 的错误。Error from server (Forbidden): error when creating mypod.yaml: pods mypod is forbidden: exceeded quota: mem-cpu-demo, requested: limits.memory2Gi,requests.memory2Gi, used: limits.memory1Gi,requests.memory1Gi, limited: limits.memory2Gi,requests.memory1GiNamespace LimitRange如果我们想限制一个命名空间可分配的资源总量ResourceQuotas很有用。但如果我们想给里面的元素提供默认值会发生什么LimitRanges是一种Kubernetes策略它限制了命名空间中每个实体的资源设置。apiVersion: v1kind: LimitRangemetadata: name: cpu-resource-constraintspec: limits: - default: cpu: 500m defaultRequest: cpu: 500m min: cpu: 100m max: cpu: 1 type: Containerdefault。如果没有指定创建的容器将有这个值。min: 创建的容器不能有比这更小的限制或请求。max: 创建的容器不能有大于此值的限制或请求。以后如果你创建一个没有设置请求或限制的新PodLimitRange会自动为其所有的容器设置这些值。 Limits: cpu: 500m Requests: cpu: 100m现在想象一下你添加一个新的Pod以1200M为限。你会收到以下错误。Error from server (Forbidden): error when creating pods/mypod.yaml: pods mypod is forbidden: maximum cpu usage per Container is 1, but limit is 1200m请注意默认情况下Pod中的所有容器将有效地拥有100m CPU的请求即使没有设置LimitRanges。总结为我们的Kubernetes集群选择最佳限制是关键以便获得最佳的能源消耗和成本。为我们的Pod分配过多的资源可能会导致成本激增。规模过小或专用于极少的CPU或内存将导致应用程序不能正常运行甚至Pod被驱逐。如前所述除非在非常特殊的情况下否则不应该使用Kubernetes限制因为它们可能会造成更大的伤害。在内存不足的情况下容器有可能被杀死在CPU不足的情况下容器有可能被节流。对于请求当你需要确保一个进程获得一个有保障的资源份额时可以使用它们。
