k8s---HPA 命名空间资源限制

目录

HPA相关知识

?HPA（Horizontal Pod Autoscaling）Pod 水平自动伸缩，Kubernetes 有一个 HPA 的资源，HPA 可以根据 CPU 利用率自动伸缩一个 Replication Controller、 Deployment 或者Replica Set 中的 Pod 数量。

（1）HPA 基于 Master 上的 kube-controller-manager 服务启动参数 horizontal-pod-autoscaler-sync-period 定义的时长（默认为30秒），周期性的检测 Pod 的 CPU 使用率。

（2）HPA 与之前的 RC、Deployment 一样，也属于一种 Kubernetes 资源对象。通过追踪分析 RC 控制的所有目标 Pod 的负载变化情况， 来确定是否需要针对性地调整目标Pod的副本数，这是HPA的实现原理。

（3）metrics-server 也需要部署到集群中， 它可以通过 resource metrics API 对外提供度量数据。
?

HPA部署和运用

进行HPA的部署和配置

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


mastrt节点拖入components.yaml

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

HPA伸缩的测试演示

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

apiVersion: apps/v1
kind: Deployment
metadata:
  name: centos-test
  labels:
    test: centos1
spec:
  replicas: 1
  selector:
    matchLabels: 
      test: centos1
  template:
    metadata:
      labels:
        test: centos1
    spec:
      containers:
        - name: centos
          image: centos: 7
          command: ["/bin/bash","-c","yum -y install epel-release;yum -y install stress;sleep 3600"]
          resources:
            limits:
              cpu: "1"
              memory: 512Mi
#设置资源限制。使用hpa必须添加资源限制字段，否则无法判断。
---
apiVsersion: autoscaling/v1 
kind:  HorizontalPodAutoscaler
metadata:
  name: hpa-centos7
spec:
  scaleTargetRef:
    apiVersion: apps/v1
#表示需要监控的类型是什么
    kind: Deployment
    name: centos-test
#这里表示你需要监控谁
  minReplicas: 1
#表示最小有几个
  maxReplicas: 5
#超过副本最大有几个
  targetCPUUtilzationPercentage: 50
  //设定cpu使用的阀值。高于50%缩容，低于50%扩容

进入容器占用2个cpu

stress --cpu 2

HPA的规则

1.定义pod的时候必须要有资源限制，否则HPA无法进行监控

2.扩容是即时的，只要超过阀值就会立刻扩容，不是立刻扩容到最大副本数。他会在最小值和最大值波动，如果扩容数量满足了需求，则不会在扩容。

3.缩容是缓慢的。如果业务的峰值较高，回收的策略太积极的话，可能会产生业务的崩溃。

周期性的获取数据，缩容的机制问题。

如果业务的峰值较高，回收的策略太积极的话，可能会产生业务的崩溃。

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

1、 手动的方式修改控制器的副本数。

命令行可以通过 kubectl scale deployment pod名称 --replicas=5

修改yaml文件。通过apply -f部署更新

2、 自动扩缩容HPA

hpa监控的是cpu

资源限制

pod的资源限制：在部署pod的时候加入resources字段，通过limits/request来对pod进行限制。

除了pod的资源限制还有命名空间的资源限制

命名空间 资源限制

lucky-zzr项目---部署在test1的命名空间，如果lucky-zzr不做限制，或者命名空间不做限制，他依然会占满所有集群资源

k8s集群部署pod的最大数量：10000个

实验举例

vim ns.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: centos-test2
  namespace: test1
  labels:
    test: centos2
spec:
  replicas: 11
  selector:
    matchLabels:
      test: centos2
  template:
    metadata:
      labels:
        test: centos2
    spec:
      containers:
        - name: centos
          image: centos:7
          command: ["/bin/bash", "-c", "yum -y install epel-release;yum -y install stress;sleep 3600"]
          resources:
            limits:
              cpu: 1000m
              memory: 512Mi
 
---
 
apiVersion: v1
kind: ResourceQuota
metadata:
  name: ns-resource
  namespace: test1
spec:
  hard:
#硬限制
    pods: "10"
#表示在这个命名空间内只能部署10个pod
    requests.cpu: "2"
#最多只能占用多个个cpu
    requests.memory: 1Gi
#最多只能占用多少内存
    limits.cpu: "4"
#最大需要多少cpu
    limits.memory: 2Gi
#最大需要多少内容
    configmaps: "10"
#当前命名空间内能创建最大的configmap的数量 10个
    persistentvolumeclaims: "4"
#当前命名空间只能使用4个pvc
    secrets: "9"
#创建加密的secrets。只能9个
    services: "5"
#创建service只能5个
    services.nodeports: "2"
#nodeport类型的svc只能2个

设置副本数为11个测试。当命名空间限制了之后，最多只能部署10个

通过命名空间的方式对容器进行限制

apiVersion: apps/v1
kind: Deployment
metadata:
  name: centos-test
  namespace: test2
  Labels:
    test: centos1
spec:
  replicas: 1
  selector:
    matcjhLabels: 
      test: centos1
  template:
    metdata:
      labels:
        test: centos1
    spec:
      containers:
        - name: centos
          image: centos:7
          command: ["/bin/bash","-c","yum -y install epel-release;yum -y install stress;sleep 3600"]
---
apiVersion: v1
kind: LimitRange
#表示使用limitrange来进行资源控制的类型。
metadata:
  name: test2-centos
  namespace: test2
spec:
  limits:
    default:
      memory: 512Mi
      cpu: "1"
    defaultRequest:
      memory: 256Mi
      cpu: "0.5"
    type: Container
    
#default-->limit
#defaultRequest--->request
#type支持Container ,pod ,pvc

通过命名空间对pod进行统一限制：

好处是不需要对每个pod进行限制

缺点是不够灵活

HPA自动伸缩如果使用nodeName的方式将固定在一个node上观察扩容之后，阀值是否会下降？

实验举例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: centos-test
  labels:
    test: centos1
spec:
  replicas: 1
  selector:
    matchLabels:
      test: centos1
  template:
    metadata:
      labels:
        test: centos1
    spec:
      containers:
        - name: centos
          image: centos:7
          command: ["/bin/bash", "-c", "yum -y install epel-release;yum -y install stress;sleep 3600"]
          resources:
            limits:
              cpu: 1000m
              memory: 512Mi
      nodeName: node01
#设置资源限制。使用hpa必须添加资源限制字段，否则无法判断
 
---
 
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-centos
spec:
  scaleTargetRef:
    apiVersion: apps/v1
#表示需要监控的类型是什么,基于什么控制器创建的
    kind: Deployment
    name: centos-test
#这里表示你需要监控谁
  minReplicas: 1
#表示最小有几个
  maxReplicas: 5
#超过副本最大有几个
  targetCPUUtilizationPercentage: 50
#设定cpu使用的阀值

测试即使在同一个node节点上阀值还是会下降。实验完成

总结
HPA自动扩缩容

命名空间的两种方式：

ResourceQuota：可以对命名空间进行资源限制

LimitRange：直接声明在命名空间中创建的pod，容器的资源限制。这是一种统一限制。所有的pod都受这个条件的制约。

只要是在命名空间内不管创建多少，都需要使用我声明的资源限制。

pod的资源限制：resources、limit

pod的资源限制是我们创建时候声明好的，这时必加选项。

对命名空间、使用cpu、内存一定会做限制

命名空间的资源限制：ResourceQuota

一般是对命名空间的cpu和内存做限制

命名空间统一资源限制：LimitRange

核心：pod一定要做资源限制否则会占用集群的全部资源，命名空间也需要做限制否则还是会占用集群的全部资源。防止整个集群的资源被一个服务或者一个命名空间占满。

HPA自动伸缩
?