Horizontal Pod Autoscaling:pod的水平自动伸缩。这是k8s自带的模块。
pod占用cpu比率到达一定的阀值，会触发伸缩机制。
replication controller 副本控制器 pod的副本数
deployment controller 节点控制器。部署pod
hpa控制副本的数量以及控制部署pod.

hpa控制副本的数量以及控制部署pod.

1、hpa基于kube-controll-manager服务，周期性的检测pod的cpu使用率默认30秒
2、hpa和replication controller,deployment controller,都属于k8s的资源对象。通过跟踪分析副本控制器和deployment的pod的负载变化，针对性地调整目标pod的副本数。
阀值：正常情况下，pod的副本数，以及达到阀值之后，pod的扩容最大数量。
3、metrics-server 部署到集群中，对外提供度量的数据。

pod的副本数扩缩容有两种方式：

1、手动方式，修改控制器的副本数
kubectl scale deployment nginx1 --replicas=5
修改yaml文件，apply-f部署更新
2、自动扩缩容hpa 
hpa的监控的是cpu。

HPA的部署运用

//在所有 Node 节点上传 metrics-server.tar 镜像包到 /opt 目录
cd /opt/
docker load -i metrics-server.tar
 
#在主master节点上执行
kubectl apply -f components.yaml

vim    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:
  - pods
  - nodes
  - nodes/stats
  - namespaces
  - configmaps
  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
        - --kubelet-use-node-status-port
        - --kubelet-insecure-tls
        image: registry.cn-beijing.aliyuncs.com/dotbalo/metrics-server:v0.4.1
        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
          periodSeconds: 10
        securityContext:
          readOnlyRootFilesystem: true
          runAsNonRoot: true
          runAsUser: 1000
        volumeMounts:
        - mountPath: /tmp
          name: tmp-dir
      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

#部署完毕后，可以通过命令来监视pod的资源占用
kubectl top pods
 
kubectl top nodes

HPA伸缩的测试演示

创建一个用于测试的pod资源

 kubectl create deployment hpa-deploy --image=nginx:1.14 --replicas=3 -o yaml >hpa-test.yaml
 
vim hpa-test.yaml
 
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: hpa-deploy
  name: hpa-deploy
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hpa-deploy
  template:
    metadata:
      labels:
        app: hpa-deploy
    spec:
      containers:
      - image: nginx:latest
        name: nginx-hpa
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 200m
 
---
apiVersion: v1
kind: Service
metadata:
  name: hpa-deploy
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: hpa-deploy

创建HPA控制器，进行资源的限制，伸缩管理 

使用 kubectl autoscale 命令创建 HPA 控制器，设置 cpu 负载阈值为请求资源的 50%，指定最少负载节点数量为 1 个，最大负载节点数量为 10 个
 
kubectl autoscale deployment hpa-deploy  --cpu-percent=50 --min=1 --max=10

进入其中一个pod容器仲，进行死循环模拟 

kubectl exec -it hpa-deploy-5dfd5cf57b-7f4ls bash
while ture
> do
> echo this is hpa test
> done

开启另一个终端，进行hpa监视：

HPA 扩容的时候，负载节点数量上升速度会比较快；但回收的时候，负载节点数量下降速度会比较慢 

 防止在业务高峰期时因为网络波动等原因的场景下，如果回收策略比较积极的话，K8S集群可能会认为访问流量变小而快速收缩负载节点数量，而仅剩的负载节点又承受不了高负载的压力导致崩溃，从而影响业务。
1、定义pod的时候必须要有资源限制，否则HPA无法进行监控
2、扩容是即时的，只要超过阀值会立刻扩容，不是立刻扩容到最大副本数。他会在最小值和最大值波动。如果扩容的数量满足了需求，不会在扩容
3、缩容是缓慢的。如果业务的峰值较高，回收的策略太积极的话，可能会产生业务的崩溃。缩容的速度是比较慢的。周期性的获取数据，缩容的机制问题。

命名空间的资源限制

命名空间资源限制的配置字段：ResourceQuota

kubectl explain ResourceQuota

计算资源的配额限制 

apiVersion: v1
kind: ResourceQuota        #使用 ResourceQuota 资源类型
metadata:
  name: compute-resources
  namespace: spark-cluster  #指定命令空间
spec:
  hard:
    pods: "20"    #设置 Pod 数量最大值
    requests.cpu: "2"
    requests.memory: 1Gi
    limits.cpu: "4"
    limits.memory: 2Gi

以上述为例，为已创建的命名空间sapark-cluster进行计算资源限制。首先限制在该命名空间最大的pod数量为20个，预留cpu和最大限制cpu分别为两个与四个。预留内存和最大限制内存分别为2GI和4GI. 

配置对象数量配额限制

apiVersion: v1
kind: ResourceQuota
metadata:
  name: object-counts
  namespace: spark-cluster
spec:
  hard:
    configmaps: "10"
    persistentvolumeclaims: "4"        #设置 pvc 数量最大值
    replicationcontrollers: "20"    #设置 rc 数量最大值
    secrets: "10"
    services: "10"
    services.loadbalancers: "2"

上述为例，该配置是对namespace中所存在的资源对象进行限制。

如果Pod没有设置requests和limits，则会使用当前命名空间的最大资源；如果命名空间也没设置，则会使用集群的最大资源。
K8S 会根据 limits 限制 Pod 使用资源，当内存超过 limits 时 cgruops 会触发 OOM（内存溢出）。 

这里就需要创建 LimitRange 资源来设置 Pod 或其中的 Container 能够使用资源的最大默认值：

apiVersion: v1
kind: LimitRange     #使用 LimitRange 资源类型
metadata:
  name: mem-limit-range
  namespace: test    #可以给指定的 namespace 增加一个资源限制
spec:
  limits:
  - default:         #default 即 limit 的值
      memory: 512Mi
      cpu: 500m
    defaultRequest:   #defaultRequest 即 request 的值
      memory: 256Mi
      cpu: 100m
    type: Container  #类型支持 Container、Pod、PVC