Horizontal Pod Autoscaling 可以根据 CPU 利用率自动伸缩一个 Replication Controller、Deployment 或者 Replica Set 中的 Pod 数量。
HPA-example：资源测试时使用
HPA-example 镜像搜索：hpa-example
HPA-example 镜像安装：docker pull registry.cn-hangzhou.aliyuncs.com/hpa-example/hpa-example:v1
所有节点安装 HPA，也可以打包然后传到各个节点，master+Nodes
该剧本是用来测试使用的，创建 deployment 副本，并指定 resources.limits.cpu and resources.requests.cpu
[root@k8s-master ~]# docker pull webdevops/php-apache 所有节点pull apiVersion: apps/v1 kind: Deployment metadata: name: php-apache spec: replicas: 1 selector: matchLabels: app: php-apache template: metadata: labels: app: php-apache spec: containers: - name: php-apache image: registry.cn-hangzhou.aliyuncs.com/hpa-example/hpa-example:v1 ports: - containerPort: 80 resources: limits: cpu: 200m #CPU利用率赫兹最大200M requests: cpu: 200m根据 HPA 控制器来控制 deployment-php-apche 副本 的CPU阈值
kubectl autoscale 命令文档：http://docs.kubernetes.org.cn/486.html
kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10 #horizontalpodautoscaler.autoscaling/php-apache autoscaled kubectl autoscale：水平自动伸缩 deployment：指定deployment，并创建已经定义好资源的自动伸缩器 php-apache：设置伸缩的Pod服务 --cpu-percent=50 CPU的利用率赫兹超过50M 则创建新的 Pod 副本 --min：一次最小创建1一个 --max：最多创建到10个封顶出现以下效果，即为 HPA 开启成功
kubectl get hpa -w 实时监控 HPA 的 CPU阈值情况
kubectl get pod 因为超过了 HPA 控制器设置的 50%CPU阈值，所以增加一个新的php-apache服务
测试HPA autoscaling/v2beta1版本-基于内存的自动扩缩容
cat nginx.yaml
apiVersion:apps/v1 kind: Deployment metadata: name:nginx-hpa spec: selector: matchLabels: app: nginx replicas: 1 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.9.1 ports: - containerPort: 80 name: http protocol: TCP resources: requests: cpu: 0.01 memory: 25Mi limits: cpu: 0.05 memory: 60Mikubectl create -f nginx.yaml
kubectl get pods 显示如下，说明nginx的pod正常运行：
NAME READY STATUS RESTARTS AGE nginx-hpa-bb598885d-j4kcp 1/1 Running 0 17m**注意：**nginx的pod里需要有如下字段，否则hpa会采集不到内存指标
resources: requests: cpu: 0.01 memory: 25Mi limits: cpu: 0.05 memory: 60Mikubectl get hpa 显示如下：
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE nginx-hpa Deployment/nginx-hpa 5%/60% 1 10 1 20s登录到上面通过pod创建的nginx，并生成一个文件，增加内存 kubectl exec -it nginx-hpa-bb598885d-j4kcp – /bin/sh
压测： dd if=/dev/zero of=/tmp/a
打开新的终端： kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE nginx-hpa Deployment/nginx-hpa 200%/60% 1 10 3 12m上面的targets列可看到200%/60%，200%表示当前cpu使用率，60%表示所有pod的cpu使用率维持在60%，现在cpu使用率达到200%，所以pod增加到4个 kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE nginx-hpa 4/4 4 4 25mkubectl get pods
NAME READY STATUS RESTARTS AGE nginx-hpa-bb598885d-j4kcp 1/1 Running 0 25m nginx-hpa-bb598885d-rj5hk 1/1 Running 0 63s nginx-hpa-bb598885d-twv9c 1/1 Running 0 18s nginx-hpa-bb598885d-v9ft5 1/1 Running 0 63skubectl exec -it nginx-hpa-bb598885d-j4kcp – /bin/sh
删除/tmp/a这个文件：rm -rf /tmp/a
kubectl get hpa 显示如下,可看到内存使用率已经降到5%:
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE nginx-hpa Deployment/nginx-hpa 5%/60% 1 10 1 26mkubectl get deployment
显示如下，deployment的pod又恢复到1个了：
NAME READY UP-TO-DATE AVAILABLE AGE nginx-hpa 1/1 1 1 38mkubernetes 对资源的限制实际上是通过 cgroup 来控制的， cgroup 是容器的一组用来控制内核如何运行进程的相关属性集合。针对内存、CPU和各种设备都有对应的 cgroup
资源名称描述limits.cpunamespace下所有pod的CPU限制总和limits.memory内存限制总和requests.cpuCPU请求总和requests.memory内存限制总和requests.storagePVC请求的存储值的总和persistentvolumeclaimsPVC的数量requests.ephemeral-storage本地临时存储请求总和limits.ephemeral-storage本地临时存储限制总和默认情况下，Pod 运行没有 CPU 和内存的限额，这意味着系统中的任何 Pod 将能够像执行 Pod 所在的节点一样，会消耗足够多的 CPU 和 内存。
一般针对某些应用的 Pod 资源进行资源限制，这个资源限制是通过 resources 的 requests和limits 实现。
例：运行某 Pod。 刚开始运行的资源需求是 cpu: 250m, memory: 250Mi ; 如果资源需求达到峰值则可以超出，cpu: “4” , memory: 2Gi
spec: containers: image: ... name: ... ports: ... resource: limits: cpu: "4" memory: 2Gi requests: cpu: 250m memory: 250Mirequests 要分配的资源，limits 为最高请求的资源值，requests为需求值。limits是可以(必须)超出需求值的。
limits 的值不能低于 requests，同理 requests不能高于 limits。
ResourceQuota 是针对 namespace 做的资源限制
当多个namespace共用同一个集群的时候可能会有某一个namespace使用的资源配额超过其公平配额，导致其他namespace的资源被占用。 这个时候我们可以为每个namespace创建一个ResourceQuota，
用户在namespace中创建资源时，quota 配额系统跟踪使用情况，以确保不超过ResourceQuota的限制值。如果创建或更新资源违反配额约束，则HTTP状态代码将导致请求失败403 FORBIDDEN。资源配额的更改不会影响到已经创建的pod。apiserver的启动参数通常kubernetes默认启用了ResourceQuota.在apiserver的启动参数–enable-admission-plugins=中如果有ResourceQuota便为启动。首先创建一个namespace
创建： kubectl create namespace spark-cluster
查看：kubectl get ns
创建一个ResourceQuota
apiVersion: v1 kind: ResourceQuota metadata: name: compute-resources namespace: spark-cluster #名称控制 spec: hard: pods: "20" #能够创建的 Pod 数量 requests.cpu: "20" #使用 CPU 的需求量 requests.memory: 100Gi #使用 memory 的需求两 limits.cpu: "40" #最大 CPU 的使用量 limits.memory: 200Gi #最大 memory 的使用量kubectl create -f spark.yaml
查看 resourcequota： kubectl get resourcequota -n spark-cluster
查看详细的 resourcequota：kubectl describe resourcequotas -n spark-cluster
LimitRange是在pod和container级别的资源限制
如果 pod 不设置 limitrange，则采用当前名称空间下的最大资源运行；如果不设置 namespacequota，则采用当前节点最大资源运行 pod 。如果指定了 Limitrange 则根据配置的资源来运行。
apiVersion: v1 kind: LimitRange metadata: name: mylimits spec: limits: - max: cpu: "4" memory: 2Gi min: cpu: 200m memory: 6Mi maxLimitRequestRatio: cpu: 3 memory: 2 type: Pod #对Pod中所有容器资源总和进行限制 - default: cpu: 300m memory: 200Mi defaultRequest: cpu: 200m memory: 100Mi max: cpu: "2" memory: 1Gi min: cpu: 100m memory: 3Mi maxLimitRequestRatio: cpu: 5 memory: 4 type: Container #对Pod中所有容器资源进行限制default：limit的值
defaultRequest：request的值
Container 参数：
max： Pod 中所有容器的 Requests 值下限。min： Pod 中所有容器的 Limits 值上限。default： Pod 中容器未指定 Limits 时，将此值设置为默认值。defaultRequest： Pod 中容器未指定 Requests 是，将此值设置为默认值。maxLimitRequestRatio： Pod 中的容器设置 Limits 与 Requests 的比例的值不能超过 maxLimitRequestRatio 参数设置的值，即 Limits/Requests ≤ maxLimitRequestRatio。Pod 参数：
max： Pod 中所有容器资源总和值上限。min：* Po 中所有容器资源总和值下限。maxLimitRequestRatio： Pod 中全部容器设置 Limits 总和与 Requests 总和的比例的值不能超过maxLimitRequestRatio 参数设置的值： 即 (All Container Limits)/(All Container Requests) ≤ maxLimitRequestRatio。 容器未指定 Limits 时，将此值设置为默认值。 defaultRequest： Pod 中容器未指定 Requests 是，将此值设置为默认值。maxLimitRequestRatio： Pod 中的容器设置 Limits 与 Requests 的比例的值不能超过 maxLimitRequestRatio 参数设置的值，即 Limits/Requests ≤ maxLimitRequestRatio。