目录
一、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.yamlkubectl get pod -n kube-system
kubectl top node
#查看所有节点占用主机资源的情况kubectl top pod
#查看pod占用主机资源的情况
2、实现自动扩缩容
实现:
vim hpa-test.yamlapiVersion: apps/v1
kind: Deployment
metadata:name: centos-testlabels:test: centos1
spec:replicas: 1selector:matchLabels:test: centos1template:metadata:labels:test: centos1spec:containers:- name: centosimage: centos:7command: ["/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:
#指定要自动缩放的目标对象,这里是一个DeploymentapiVersion: apps/v1kind: Deploymentname: centos-test
#标签和上面deployment对应minReplicas: 1maxReplicas: 5
#自动扩缩的副本数,最大5,最小1targetCPUUtilizationPercentage: 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-test2namespace: test1labels:test: centos2
spec:replicas: 4selector:matchLabels:test: centos2template:metadata:labels:test: centos2spec:containers:- name: centosimage: centos:7command: ["/bin/bash", "-c", "yum -y install epel-release;yum -y install stress;sleep 3600"]resources:limits:cpu: 1000mmemory: 512Mi---apiVersion: v1
kind: ResourceQuota
metadata:name: ns-resourcenamespace: test1
spec:hard:
#硬限制pods: "5"
#表示在这个命名空间内只能部署10个podrequests.cpu: "2"requests.memory: 1Gilimits.cpu: "4"
#最多能占用4个CPUlimits.memory: 2Gi
#最多能占用内存2Gconfigmaps: "10"
#当前命名空间内创建最大的configmap的数量10个persistentvolumeclaims: "4"
#当前命名空间只能使用4个PVCsecrets: "9"
#创建加密的secrets,只能9个services: "5"
#创建service,只能5个services.nodeports: "2"
#NodePort类型的svc只能2个
限制pod数量和service数量:
apiVersion: apps/v1
kind: Deployment
metadata:name: centos-test2namespace: test2labels:test: centos2
spec:replicas: 6selector:matchLabels:test: centos2template:metadata:labels:test: centos2spec:containers:- name: centosimage: centos:7command: ["/bin/bash", "-c", "yum -y install epel-release;yum -y install stress;sleep 3600"]resources:limits:cpu: 1000mmemory: 512Mi---apiVersion: v1
kind: ResourceQuota
metadata:name: ns-resourcenamespace: 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-testnamespace: test2labels:test: centos
spec:replicas: 1selector:matchLabels:test: centostemplate:metadata:labels:test: centosspec:containers:- name: centos1image: centos:7command: ["/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-limitnamespace: test2
spec:limits:- default:memory: 512Micpu: "1"defaultRequest:memory: 256Micpu: "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.captcpdump 固定格式
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协议包