【云原生】kubernetes中容器的资源限制

目录

[1 metrics-server](#1 metrics-server)

[2 指定内存请求和限制](#2 指定内存请求和限制)

[3 指定 CPU 请求和限制](#3 指定 CPU 请求和限制)

---

资源限制

在k8s中对于容器资源限制主要分为以下两类:

• 内存资源限制: 内存请求 （request）和内存限制（limit）分配给一个容器。 我们保障容器拥有它请求数量的内存，但不允许使用超过限制数量的内存。

  • 官网参考地址: 为容器和 Pod 分配内存资源 | Kubernetes

• CPU 资源限制: 为容器设置 CPU request（请求） 和 CPU limit（限制）。 容器使用的 CPU 不能超过所配置的限制。 如果系统有空闲的 CPU 时间，则可以保证给容器分配其所请求数量的 CPU 资源。

  • 官网参考地址: 为容器和 Pods 分配 CPU 资源 | Kubernetes

请求 request memory cpu :可以使用的基础资源 100M

限制 limit memory cpu :可以使用的最大资源 200M 超过最大资源之后容器会被 kill , OOM 错误

1 metrics-server

官网地址: GitHub - kubernetes-sigs/metrics-server: Scalable and efficient source of container resource metrics for Kubernetes built-in autoscaling pipelines.

Kubernetes Metrics Server (Kubernetes指标服务器)，它是一个可扩展的、高效的容器资源度量源。Metrics Server 用于监控每个 Node 和 Pod 的负载（用于Kubernetes内置自动扩缩管道）。Metrics Server 从Kubelets 收集资源指标，并通过 Metrics API 在Kubernetes apiserver中公开，供 Horizontal Pod Autoscaler 和 Vertical Pod Autoscaler 使用。Metrics API 也可以通过 kubectl top 访问，使其更容易调试自动扩缩管道。

• 查看 metrics-server（或者其他资源指标 API metrics.k8s.io 服务提供者）是否正在运行， 请键入以下命令：

kubectl get apiservices

• 如果资源指标 API 可用，则会输出将包含一个对 metrics.k8s.io 的引用。

NAME
v1beta1.metrics.k8s.io

• 安装 metrics-server

  components.yaml

  apiVersion: v1
  kind: ServiceAccount
  metadata:
  labels:
  k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRole
  metadata:
  labels:
  k8s-app: metrics-server
  rbac.authorization.k8s.io/aggregate-to-admin: "true"
  rbac.authorization.k8s.io/aggregate-to-edit: "true"
  rbac.authorization.k8s.io/aggregate-to-view: "true"
  name: system:aggregated-metrics-reader
  rules:
  - apiGroups:
  - metrics.k8s.io
  resources:
  - pods
  - nodes
  verbs:
  - get
  - list
  - watch

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRole
  metadata:
  labels:
  k8s-app: metrics-server
  name: system:metrics-server
  rules:
  - apiGroups:
  - ""
  resources:
  - nodes/metrics
  verbs:
  - get
  - apiGroups:
  - ""
  resources:
  - pods
  - nodes
  verbs:
  - get
  - list
  - watch

  apiVersion: rbac.authorization.k8s.io/v1
  kind: RoleBinding
  metadata:
  labels:
  k8s-app: metrics-server
  name: metrics-server-auth-reader
  namespace: kube-system
  roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: extension-apiserver-authentication-reader
  subjects:
  - kind: ServiceAccount
  name: metrics-server
  namespace: kube-system

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRoleBinding
  metadata:
  labels:
  k8s-app: metrics-server
  name: metrics-server:system:auth-delegator
  roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:auth-delegator
  subjects:
  - kind: ServiceAccount
  name: metrics-server
  namespace: kube-system

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRoleBinding
  metadata:
  labels:
  k8s-app: metrics-server
  name: system:metrics-server
  roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:metrics-server
  subjects:
  - kind: ServiceAccount
  name: metrics-server
  namespace: kube-system

  apiVersion: v1
  kind: Service
  metadata:
  labels:
  k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
  spec:
  ports:
  - name: https
  port: 443
  protocol: TCP
  targetPort: https
  selector:
  k8s-app: metrics-server

  apiVersion: apps/v1
  kind: Deployment
  metadata:
  labels:
  k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
  spec:
  selector:
  matchLabels:
  k8s-app: metrics-server
  strategy:
  rollingUpdate:
  maxUnavailable: 0
  template:
  metadata:
  labels:
  k8s-app: metrics-server
  spec:
  containers:
  - args:
  - --cert-dir=/tmp
  - --secure-port=4443
  - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
  - --kubelet-use-node-status-port
  - --metric-resolution=15s
  - --kubelet-insecure-tls #修改去掉证书验证
  image: dyrnq/metrics-server:v0.6.2 #修改官方无法下载
  imagePullPolicy: IfNotPresent
  livenessProbe:
  failureThreshold: 3
  httpGet:
  path: /livez
  port: https
  scheme: HTTPS
  periodSeconds: 10
  name: metrics-server
  ports:
  - containerPort: 4443
  name: https
  protocol: TCP
  readinessProbe:
  failureThreshold: 3
  httpGet:
  path: /readyz
  port: https
  scheme: HTTPS
  initialDelaySeconds: 20
  periodSeconds: 10
  resources:
  requests:
  cpu: 100m
  memory: 200Mi
  securityContext:
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  runAsNonRoot: true
  runAsUser: 1000
  volumeMounts:
  - mountPath: /tmp
  name: tmp-dir
  hostNetwork: true #必须指定这个才行
  nodeSelector:
  kubernetes.io/os: linux
  priorityClassName: system-cluster-critical
  serviceAccountName: metrics-server
  volumes:
  - emptyDir: {}
  name: tmp-dir

  apiVersion: apiregistration.k8s.io/v1
  kind: APIService
  metadata:
  labels:
  k8s-app: metrics-server
  name: v1beta1.metrics.k8s.io
  spec:
  group: metrics.k8s.io
  groupPriorityMinimum: 100
  insecureSkipTLSVerify: true
  service:
  name: metrics-server
  namespace: kube-system
  version: v1beta1
  versionPriority: 100

$ kubectl appply -f components.yaml

2 指定内存请求和限制

官网: 为容器和 Pod 分配内存资源 | Kubernetes

为容器指定内存请求，请在容器资源清单中包含 resources：requests 字段。 同理，要指定内存限制，请包含 resources：limits。

# nginx-memory-demo.yaml
#内存资源的基本单位是字节（byte）。你可以使用这些后缀之一，将内存表示为 纯整数或定点整数：E、P、T、G、M、K、Ei、Pi、Ti、Gi、Mi、Ki。 例如，下面是一些近似相同的值：128974848, 129e6, 129M, 123Mi

apiVersion: v1
kind: Pod
metadata:
  name: nginx-memory-demo
spec:
  containers:
  - name: nginx-memory-demo
    image: nginx:1.19
    resources:
      requests:
        memory: "100Mi" 
      limits:
        memory: "200Mi"

• 查看容器内存使用情况

$ kubectl get pod nginx-memory-demo --output=yaml

• 查看容器正在使用内存情况

$ kubectl top pod nginx-memory-demo 

• 内存请求和限制的目的

  通过为集群中运行的容器配置内存请求和限制，你可以有效利用集群节点上可用的内存资源。 通过将 Pod 的内存请求保持在较低水平，你可以更好地安排 Pod 调度。 通过让内存限制大于内存请求，你可以完成两件事：

  • Pod 可以进行一些突发活动，从而更好的利用可用内存。

  • Pod 在突发活动期间，可使用的内存被限制为合理的数量。

• 没有指定内存限制

  如果你没有为一个容器指定内存限制，则自动遵循以下情况之一：

  • 容器可无限制地使用内存。容器可以使用其所在节点所有的可用内存， 进而可能导致该节点调用 OOM Killer。 此外，如果发生 OOM Kill，没有资源限制的容器将被杀掉的可行性更大。

  • 运行的容器所在命名空间有默认的内存限制，那么该容器会被自动分配默认限制。

3 指定 CPU 请求和限制

官网: 为容器和 Pods 分配 CPU 资源 | Kubernetes

为容器指定 CPU 请求，请在容器资源清单中包含 resources: requests 字段。 要指定 CPU 限制，请包含 resources:limits。

# nginx-cpu-demo.yaml
#CPU 资源以 CPU 单位度量。小数值是可以使用的。一个请求 0.5 CPU 的容器保证会获得请求 1 个 CPU 的容器的 CPU 的一半。 你可以使用后缀 m 表示毫。例如 100m CPU、100 milliCPU 和 0.1 CPU 都相同。 CPU 请求只能使用绝对数量，而不是相对数量。0.1 在单核、双核或 48 核计算机上的 CPU 数量值是一样的。

apiVersion: v1
kind: Pod
metadata:
  name: nginx-cpu-demo
spec:
  containers:
  - name: nginx-cpu-demo
    image: nginx:1.19
    resources:
      limits:
        cpu: "1"
      requests:
        cpu: "0.5"

• 显示 pod 详细信息

$ kubectl get pod nginx-cpu-demo --output=yaml 

• 显示 pod 运行指标

$ kubectl top pod nginx-cpu-demo

• CPU 请求和限制的初衷

  通过配置你的集群中运行的容器的 CPU 请求和限制，你可以有效利用集群上可用的 CPU 资源。 通过将 Pod CPU 请求保持在较低水平，可以使 Pod 更有机会被调度。 通过使 CPU 限制大于 CPU 请求，你可以完成两件事：

  • Pod 可能会有突发性的活动，它可以利用碰巧可用的 CPU 资源。

  • Pod 在突发负载期间可以使用的 CPU 资源数量仍被限制为合理的数量。

• 如果不指定 CPU 限制

  如果你没有为容器指定 CPU 限制，则会发生以下情况之一：

  • 容器在可以使用的 CPU 资源上没有上限。因而可以使用所在节点上所有的可用 CPU 资源。

  • 容器在具有默认 CPU 限制的名字空间中运行，系统会自动为容器设置默认限制。

• 如果你设置了 CPU 限制但未设置 CPU 请求

如果你为容器指定了 CPU 限制值但未为其设置 CPU 请求，Kubernetes 会自动为其 设置与 CPU 限制相同的 CPU 请求值。类似的，如果容器设置了内存限制值但未设置 内存请求值，Kubernetes 也会为其设置与内存限制值相同的内存请求。