一、pod资源限制（resources）

当定义 Pod 时可以选择性地为每个容器设定所需要的资源数量。最常见的可设定资源是 CPU 和内存大小，以及其他类型的资源。

当为 Pod 中的容器指定了 request 资源时，调度器就使用该信息来决定将 Pod 调度到哪个节点上。当还为容器指定了 limit 资源时，kubelet 就会确保运行的容器不会使用超出所设的 limit 资源量。kubelet 还会为容器预留所设的 request 资源量，供该容器使用。

如果 Pod 运行所在的节点具有足够的可用资源，容器可以使用超出所设置的 request 资源量。不过，容器不可以使用超出所设置的 limit 资源量。

如果给容器设置了内存的 limit 值，但未设置内存的 request 值，Kubernetes 会自动为其设置与内存 limit 相匹配的 request 值。类似的，如果给容器设置了 CPU 的 limit 值但未设置 CPU 的 request 值，则 Kubernetes 自动为其设置 CPU 的 request 值并使之与 CPU 的 limit 值匹配。

官网示例：https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/

Pod 和容器的资源请求和限制

spec.containers[].resources.requests.cpu		//定义创建容器时预分配的CPU资源
spec.containers[].resources.requests.memory		//定义创建容器时预分配的内存资源
spec.containers[].resources.limits.cpu			//定义cpu的资源上限 
spec.containers[].resources.limits.memory		//定义内存的资源上限

案例

    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

—CPU 资源单位：Kubernetes 中的一个 cpu 相当于1个 vCPU（1个超线程）。Kubernetes 也支持带小数 CPU 的请求。spec.containers[].resources.requests.cpu 为 0.5 的容器能够获得一个 cpu 的一半 CPU 资源（类似于Cgroup对CPU资源的时间分片）。表达式 0.1 等价于表达式 100m（毫核），表示每 1000 毫秒内容器可以使用的 CPU 时间总量为 0.1*1000 毫秒。

—内存资源单位：内存以字节为单位。可以以整数表示，或者以10为底数的指数的单位（E、P、T、G、M、K）来表示，或者以2为底数的指数的单位（Ei、Pi、Ti、Gi、Mi、Ki）来表示。

二、重启策略（restartPolicy）

重启策略：Pod在遇到故障之后重启的动作

spec.Always：当容器终止退出后，总是重启容器，默认策略
spec.OnFailure：当容器异常退出（退出状态码非0）时，重启容器；正常退出则不重启容器
spec.Never：当容器终止退出，从不重启容器。

三、扩容缩容

1.手动扩容

在生产环境下，在面临服务需要扩容的场景时，可以使用Deployment/RC的Scale机制来实现。

slace扩容或缩容 Deployment、ReplicaSet、Replication Controller或 Job 中Pod数量。

Kubernetes支持对Pod的手动扩容和自动扩容。replicas决定了集群pod的数量。

创建一个单节点的web容器

kubectl apply -f apache.yaml

在集群运行的过程中我们可以动态调整集群pod的数量
修改服务配置，即时生效：

kubectl edit deployments.apps apache

scale命令，控制pod的数量

kubectl scale deployments.appse apache --replicas=3

2.自动扩容

2.1、数据采集组件

metrics-server 是一个集群范围内的资源数据集和工具，同样的，metrics-server 也只是显示数据，并不提供数据存储服务，主要关注的是资源度量 API 的实现，比如 CPU、文件描述符、内存、请求延时等指标，metric-server 收集数据给 k8s 集群内使用，如 kubectl,hpa,scheduler 等。不同k8s版本根据官网安装对应版本的metrics-server。

github地址：https://github.com/kubernetes-sigs/metrics-server/

2.1.1、部署

镜像下载

wget registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-server:v0.6.4

导入镜像

docker load -i metrics-server-0.6.4.tar.gz

修改apiserver配置

注意：会中断业务，生产环境谨慎操作！这个是 k8s 在 1.17 的新特性，如果是 1.16 版本的可以不用添加，1.17 以后要添加。这个参数的作用是 Aggregation 允许在不修改 Kubernetes 核心代码的同时扩展 Kubernetes API。

vim /etc/kubernetes/manifests/kube-apiserver.yaml
22     - --enable-aggregator-routing=true               # 增加

重启kubelet

systemctl restart kubelet

部署metrics-server 服务

用到的yaml文件到github下载，地址：https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.6.1/components.yam

kubectl apply -f components.yaml

验证

kubectl get pods -n kube-system | grep metrics

2.2、HPA

kubernetes HPA（Horizontal Pod Autoscaling）：根据监控指标（cpu 使用率、磁盘、自定义的等）自动扩容或缩容服务中的pod数量，当业务需求增加时，系统将无缝地自动增加适量 pod 容器，提高系统稳定性。hap监控容器资源的利用率。

kubernetes KPA（Knative Pod Autoscaler）：基于请求数对 Pod 自动扩缩容，KPA 的主要限制在于它不支持基于 CPU 的自动扩缩容。

kubernetes VPA（Vertical Pod Autoscaler）：基于 Pod 的资源使用情况自动设置 pod 的 CPU 和内存的 requests，从而让集群将 Pod 调度到有足够资源的最佳节点上。

HPA运作方式

整体逻辑：K8s 的 HPA controller 已经实现了一套简单的自动扩缩容逻辑，默认情况下，每 15s 检测一次指标，只要检测到了配置 HPA 的目标值，则会计算出预期的工作负载的副本数，再进行扩缩容操作。同时，为了避免过于频繁的扩缩容，默认在 5min 内没有重新扩缩容的情况下，才会触发扩缩容。

缺陷：

HPA 本身的算法相对比较保守，可能并不适用于很多场景。例如，一个快速的流量突发场景，如果正处在 5min 内的 HPA 稳定期，这个时候根据 HPA 的策略，会导致无法扩容。

pod数量计算方式

通过现有 pods 的 CPU 使用率的平均值（计算方式是最近的 pod 使用量（最近一分钟的平均值，从 metrics-server 中获得）除以设定的每个 Pod 的 CPU 使用率限额）跟目标使用率进行比较，并且在扩容时，还要遵循预先设定的副本数限制：MinReplicas <= Replicas <= MaxReplicas。
计算扩容后 Pod 的个数：sum(最近一分钟内某个 Pod 的 CPU 使用率的平均值)/CPU 使用上限的整数+1

HPA官网： Pod 水平自动扩缩 | Kubernetes

2.2.1、案例

输出nginx服务yaml文件

kubectl -n jy-test create deployment nginx-web --image=harbortest.szjs.gov.cn/zjj-public/nginx:1.22.1-arm --dry-run=client -o yaml > nginx-web.yaml

为了平常使用yaml时，由于手抖，造成的格式错误，建议尽量使用–dry-run参数来生成一个基础的yaml，再修改。

通过yaml文件创建deployment

kubectl apply -f nginx-web.yaml

对外暴露端口号

kubectl -n jy-test expose deployment nginx-web --port=80 --type=NodePort --target-port=80 --name=svc-nginx-web -o yaml >> nginx-web.yaml

通过yaml文件创建service

kubectl apply -f nginx-web.yaml

配置资源限制

kubectl -n jy-test edit deploy nginx-web

    spec:
      containers:
      - image: harbortest.szjs.gov.cn/zjj-public/nginx:1.22.1-arm
        imagePullPolicy: IfNotPresent
        name: nginx
        resources:           # 注意：nginx 的 pod 里需要有如下字段，否则 hpa 会采集不到内存指标
          limits:
            cpu: 500m
            memory: 256Mi
          requests:
            cpu: 200m
            memory: 256Mi

2.2.1.1、HPA基于cpu自动扩缩容

nginx-web 服务正在运行，使用 kubectl autoscale 创建自动缩放器，实现对 nginx-web 这个deployment 创建的 pod 自动扩缩容，下面的命令将会创建一个 HPA，HPA 将会根据 CPU资源指标增加或减少副本数，创建一个可以实现如下目的的 hpa：
（1）让副本数维持在 1-10 个之间（这里副本数指的是通过 deployment 部署的 pod 的副本数）
（2）将所有 Pod 的平均 CPU 使用率维持在 50％（通过 kubectl run 运行的每个 pod 如果是 200毫核，这意味着平均 CPU 利用率为 100 毫核）

创建HPA基于cpu自动扩缩容

kubectl -n jy-test autoscale deployment nginx-web --cpu-percent=50 --min=1 --max=10 --name=nginx-web

查看

 kubectl -n jy-test get hpa

验证：重新打开一个master节点的终端，进行如下操作

kubectl -n jy-test exec -it nginx-web-f646c4b44-nlxjq bash
/# for i in {1..500000}; do curl http://www.test.com/my_service &  done

当容器的cpu占用超过 50% 的时候，自动扩展一个POD，依次扩展，一直到最大值，如果cpu访问不足 50% 的时候，每 300s 缩减一个 POD 节点，直到最小值时停止。

查看

kubectl -n jy-test get hpa

可以看到cpu目标及当前状态，最大、最小、当前副本数。

kubectl -n jy-test get pod

2.2.1.2、HPA基于内存自动扩缩容

nginx 服务正在运行，使用 kubectl autoscale 创建自动缩放器，实现对 nginx 这个deployment 创建的 pod 自动扩缩容，下面的命令将会创建一个 HPA，HPA 将会根据内存资源指标增加或减少副本数，创建一个可以实现如下目的的 hpa：
（1）让副本数维持在 1-10 个之间（这里副本数指的是通过 deployment 部署的 pod 的副本数）
（2）将所有 Pod 的平均内存使用率维持在 60％

创建HPA基于内存自动扩缩容，yaml文件如下


apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-web-hpa2               # hpa的名称
  namespace: jy-test
spec:
  maxReplicas: 10
  metrics:
  - resource:
      name: memory
      target:
        averageUtilization: 60
        type: Utilization
    type: Resource
  minReplicas: 1
  scaleTargetRef:                   # 定义监视控制器，需要扩容缩谷时需要通知的控制器
    apiVersion: apps/v1          
    kind: Deployment
    name: nginx-web                 # 控制器的名称

创建

kubectl create -f hpa.yaml

查看

kubectl -n jy-test get hpa

可以看到当前内存使用率、目标内存使用率，最大、最小、当前副本数

2.3、cluster-autoscaler

Cluster Autoscaler (CA)是一个独立程序，是用来弹性伸缩 kubernetes 集群的。它可以自动根据部署应用所请求的资源量来动态的伸缩集群。当集群容量不足时，它会自动去 Cloud Provider （支持GCE、GKE 和 AWS）创建新的 Node，而在 Node 长时间资源利用率很低时自动将其删除以节省开支。
项目地址：GitHub - kubernetes/autoscaler: Autoscaling components for Kubernetes

在以下情况下，集群自动扩容或者缩放：

扩容：由于资源不足，某些 Pod 无法在任何当前节点上进行调度。
缩容: Node 节点资源利用率较低时，且此 node 节点上存在的 pod 都能被重新调度到其他 node节点上运行。

在以下情况下，集群节点不会被 CA 删除

1、节点上有 pod 被 PodDisruptionBudget 控制器限制。
2、节点上有命名空间是 kube-system 的 pods。
3、节点上的 pod 不是被控制器创建，例如不是被 deployment, replica set, job, stateful set 创建。
4、节点上有 pod 使用了本地存储。
5、节点上 pod 驱逐后无处可去，即没有其他 node 能调度这个 pod。
6、节点有注解：“cluster-autoscaler.kubernetes.io/scale-down-disabled”: “true”(在 CA 1.0.3 或更高版本中受支持)。

命令

 kubectl annotate node <nodename> cluster-autoscaler.kubernetes.io/scale-down-disabled=true

HPA 如何与 Cluster Autoscaler 一起使用?

Horizontal Pod Autoscaler 会根据当前 CPU 负载更改部署或副本集的副本数。如果负载增加，则 HPA 将创建新的副本，集群中可能有足够的空间，也可能没有足够的空间。如果没有足够的资源，CA将尝试启动一些节点，以便 HPA 创建的 Pod 可以运行。如果负载减少，则 HPA 将停止某些副本。结果，某些节点可能变得利用率过低或完全为空，然后 CA 将终止这些不需要的节点。