目录

一、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/v1kind: Deploymentmetadata:name: centos-testlabels:test: centos1spec: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/v1kind: HorizontalPodAutoscalermetadata:name: hpa-centos7spec: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/v1kind: Deploymentmetadata:name: centos-test2namespace: test1labels:test: centos2spec: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: v1kind: ResourceQuotametadata:name: ns-resourcenamespace: test1spec: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/v1kind: Deploymentmetadata:name: centos-test2namespace: test2labels:test: centos2spec: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: v1kind: ResourceQuotametadata:name: ns-resourcenamespace: test2spec:hard:#硬限制pods: "5"services: "3"services.nodeports: "2"

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

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

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

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

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

apiVersion: apps/v1kind: Deploymentmetadata:name: centos-testnamespace: test2labels:test: centosspec: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: v1kind: LimitRange#表示使用limitrange来进行资源控制metadata:name: test2-limitnamespace: test2spec: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 80src net 192.168.10.0/24 源地址来自192.168.10.0网段的ip-w 抓包的数据,保存位置 *.capWireshark分析.cap 后缀的

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

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