【K8S 云原生】K8S之HPA自动扩缩容、命名空间资源限制、容器抓包

发布时间:2024年01月23日

目录

一、HPA概述

1、概念

2、两个重要的组件:

3、HPA的规则:

4、pod的副本数扩容有两种方式:

4.1、手动扩缩容,修改副本数:

4.2、自动扩缩容HPA

二、实验部署:

1、部署HPA

2、实现自动扩缩容

三、命名空间资源限制:

1、对命名空间进行限制

2、对命名空间中pod整体进行限制:

四、总结:

五、补充:哪些服务会部署在K8S当中:

六、K8S容器的抓包:

第一步:获取容器的container id

第二步:将container id解析为pid

第三步:进入容器内的网络命名空间

第四步:tcpdump抓包

补充:Linux中真机抓包

容器内抓包:


一、HPA概述

1、概念

Horizontal Pod Autoscaling:Pod的水平自动伸缩

K8S自带的模块

是根据Pod占用CPU的比率,到达一定的阀值,会触发伸缩机制

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

1、HPA是基于kube-controll-manager服务,周期性的检测Pod的CPU使用率,默认30s检测一次

2、HPA和副本控制器replication controller以及deployment controller,都属于K8S的资源对象。通过跟踪分析副本控制器和deployment的Pod的负载变化,针对性的调整目标Pod的副本数。

阀值:正常情况下,Pod的副本数,以及达到阀值后,Pod的扩容最大数量

3、metrics-server部署到集群中,由他来对外提供度量的数据

2、两个重要的组件:

replication controller ?副本控制器,控制的是Pod的副本数

deployment controller 节点控制器,部署Pod

HPA控制副本的数量以及控制如何部署Pod

3、HPA的规则:

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

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

3、缩容时缓慢的。如果业务的峰值较高,回收的策略太积极的话,可能会产生业务的崩溃。缩容的速度比较慢,扩容比较快

原因:周期性的获取数据,缩容的机制问题

4、pod的副本数扩容有两种方式:

4.1、手动扩缩容,修改副本数:

kubectl scale命令行扩缩容

kubectl edit deployment进入该replicas

进yaml文件改replicas,apply -f 部署更新

4.2、自动扩缩容HPA

HPA监控的是CPU,根据CPU自动扩缩容。扩的比较快(要立即满足需求),缩的比较慢(方式业务崩溃)

二、实验部署:

1、部署HPA

将镜像包拖到所有节点
docker load -i metrics-server.tar

上传 components.yaml
配置文件改好了,直接用即可

kubectl apply -f components.yaml

kubectl get pod -n kube-system

kubectl top node
#查看所有节点占用主机资源的情况

kubectl top pod
#查看pod占用主机资源的情况

2、实现自动扩缩容

实现:
vim hpa-test.yaml

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


---
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-centos7
spec:
  scaleTargetRef:
#指定要自动缩放的目标对象,这里是一个Deployment
    apiVersion: apps/v1
    kind: Deployment
    name: centos-test
#标签和上面deployment对应
  minReplicas: 1
  maxReplicas: 5
#自动扩缩的副本数,最大5,最小1
  targetCPUUtilizationPercentage: 50
#CPU利用率的阀值50%

进容器:

压力测试

容器占满两个CPU

因为他Limit资源限制最大使用是1个CPU,所以这里虽然压力2个,但是最多是能占一个CPU

#查看pod占用CPU状态
kubectl top pod

#kubectl get hpa -w
动态查看HPA

这里资源超过设定阀值后,会动态扩容,减轻资源压力。

比如,这里是一个pod的最大CPU使用率是1000,阀值是500,这里给1000的压力,超过500,选择扩容

扩容一个pod后,最大使用率是2000,压力是1000,加上进程的本身资源使用,他的CPU使用率实际上是超过50%,也就是1000m的,继而选择再次扩容

再扩容一个之后,三个pod最大使用率3000,阀值变成1500。给的CPU是1000,不足1500

所以不再继续扩容

所以这里显示的副本数停在了3个,而CPU使用率是33%,1000/3000

停止压力,测试缩容:

当CPU使用率不足阀值时,pod会缓慢、谨慎的缩容

扩容很快,缩容很慢

三、命名空间资源限制:

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

K8S集群部署pod的最大数量:10000

busybox:就是最小化的centos 4M

1、对命名空间进行限制

apiVersion: apps/v1
kind: Deployment
metadata:
  name: centos-test2
  namespace: test1
  labels:
    test: centos2
spec:
  replicas: 4
  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: "5"
#表示在这个命名空间内只能部署10个pod
    requests.cpu: "2"
    requests.memory: 1Gi
    limits.cpu: "4"
#最多能占用4个CPU
    limits.memory: 2Gi
#最多能占用内存2G
    configmaps: "10"
#当前命名空间内创建最大的configmap的数量10个
    persistentvolumeclaims: "4"
#当前命名空间只能使用4个PVC
    secrets: "9"
#创建加密的secrets,只能9个
    services: "5"
#创建service,只能5个
    services.nodeports: "2"
#NodePort类型的svc只能2个

限制pod数量和service数量:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: centos-test2
  namespace: test2
  labels:
    test: centos2
spec:
  replicas: 6
  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: test2
spec:
  hard:
#硬限制
    pods: "5"
    services: "3"
    services.nodeports: "2"

设置完限制只能在这个命名空间中只能有5个pod和3个service

kubectl describe ns test1
#查看命名空间的资源限制

2、对命名空间中pod整体进行限制:

对整个命名空间中的pod进行全局的限制(内存、CPU),不够灵活

工作中还是对每个pod进行自定义限制


?

apiVersion: apps/v1
kind: Deployment
metadata:
  name: centos-test
  namespace: test2
  labels:
    test: centos
spec:
  replicas: 1
  selector:
    matchLabels:
      test: centos
  template:
    metadata:
      labels:
        test: centos
    spec:
      containers:
        - name: centos1
          image: centos:7
          command: ["/bin/bash","-c","yum -y install epel-release.noarch; yum -y install stress;sleep 3600"]
          resources:
            limits:
              cpu: "1"
              memory: 512Mi
---
apiVersion: v1
kind: LimitRange
#表示使用limitrange来进行资源控制
metadata:
  name: test2-limit
  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(很少有)

四、总结:

HPA自动扩缩容

命名空间限制:

第一种:resourcequote

可以对命名空间进行限制

第二种:LimitRange

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

限制方式:

1、pod资源限制,一般是创建的时候声明好的,在工作中是必加选项

resources:

??limt

2、命名空间资源限制,对命名空间使用CPU和内存一定会做限制

resourcequote

3、命名空间统一资源限制,掌握即可,工作中一般配置前两个

LimitRange

在工作中一定对pod和命名空间资源(CPU和内存)进行限制

防止整个集群的资源,被一个服务或者命名空间占满

五、补充:哪些服务会部署在K8S当中:

中间键:一定K8S部署

kafka:6个pod

redis:3个pod

哪些服务会部署在K8S当中:

中间键:一定K8S部署

kafka:6个pod

redis:3个pod

业务服务:一定K8S部署

自定义的镜像创建的容器:

前端:50%容器化部署,前面两个容器化这个大概率容器化部署

nginx:3-6个pod

一般一共12个pod左右,每个都是独立的业务

mysql是实际部署的

ELK可能docker可能docker可能真机部署

一定在K8S部署的:

1、自定义的镜像创建的容器:

2、前端:50%容器化部署,前面两个容器化这个大概率容器化部署

nginx:3-6个pod

一般一共12个pod左右,每个都是独立的业务

mysql是实际部署的

ELK可能docker可能docker可能真机部署

六、K8S容器的抓包:

K8S容器抓包:

第一步:获取容器的container id

kubectl describe pod nginx1-6f44454d69-shqcr

第二步:将container id解析为pid

docker inspect --format '{{.State.Pid}}' 0bd8136bfb03b0717bf72c3793b9e4cfa15d809e85389a2f14f7b7ae0a78e172

第三步:进入容器内的网络命名空间

nsenter -n -t50148
#进入容器内的网络命名空间

ip addr
#查看网卡设备名

第四步:tcpdump抓包

补充:Linux中真机抓包

Linux能否抓包????????

tcpdump(系统自带的)

指定抓包

动态抓包,一直获取,手动停止

只抓不分析

tcpdump tcp -i ens33 -t -s0 -c 10 and dst port 80 and src net 192.168.10.0/24 -w ./target.cap

tcpdump 固定格式
tcp 抓取tcp协议
-i 只抓经过ens33的数据包
-t 不显示时间戳
-s0 抓完整的数据包
-c 指定抓包的个数
dst port 80 访问httpd 80
src net 192.168.10.0/24   源地址来自192.168.10.0网段的ip
-w 抓包的数据,保存位置 
*.cap  Wireshark分析.cap 后缀的

容器内抓包:
tcpdump tcp -i eth0
#抓取tcp协议的数据包,指定经过eth0网卡

tcpdump icmp -i eth0
#抓取经过eth0网卡的icmp协议包

文章来源:https://blog.csdn.net/koeda1/article/details/135792811
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。