【K8S 云原生】K8S之HPA自动扩缩容、命名空间资源限制、容器抓包
K8S之HPA（自动扩缩容）、K8S命名空间资源限制、K8S内容器抓包
目录
一、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协议包
K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容
更多推荐
45
0- 0
已为社区贡献11条内容
所有评论(0)