目录
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部署到集群中,由他来对外提供度量的数据
replication controller ?副本控制器,控制的是Pod的副本数
deployment controller 节点控制器,部署Pod
HPA控制副本的数量以及控制如何部署Pod
1、定义pod的时候必须要有资源限制,否则HPA无法进行监控
2、扩容时即时的,只要超过阀值会立刻扩容,不是立刻扩容到最大副本数。他会在最小值和最大值之间波动。如果扩容的数量满足了需求,不会在扩容
3、缩容时缓慢的。如果业务的峰值较高,回收的策略太积极的话,可能会产生业务的崩溃。缩容的速度比较慢,扩容比较快
原因:周期性的获取数据,缩容的机制问题
kubectl scale命令行扩缩容
kubectl edit deployment进入该replicas
进yaml文件改replicas,apply -f 部署更新
HPA监控的是CPU,根据CPU自动扩缩容。扩的比较快(要立即满足需求),缩的比较慢(方式业务崩溃)
将镜像包拖到所有节点
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占用主机资源的情况
实现:
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
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
#查看命名空间的资源限制
对整个命名空间中的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部署
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容器抓包:
kubectl describe pod nginx1-6f44454d69-shqcr
docker inspect --format '{{.State.Pid}}' 0bd8136bfb03b0717bf72c3793b9e4cfa15d809e85389a2f14f7b7ae0a78e172
nsenter -n -t50148
#进入容器内的网络命名空间
ip addr
#查看网卡设备名
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协议包