目录
一、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协议包
