当前位置：首页 > news >正文

Kubernetes高级功能

news 文章来源：https://blog.csdn.net/m0_75135871/article/details/142633917 2024/11/20 2:35:23

资源配额

什么是资源配额

资源配额，通过 ResourceQuota 对象来定义，对每个命名空间的资源消耗总量提供限制。它可以限制命名空间中某种类型的对象的总数目上限，也可以限制命名空间中的 Pod 可以使用的计算资源的总上限。

资源配额应用

创建的ResourceQuota对象将在test名字空间中添加限制，每个容器必须设置内存请求（memory request），内存限额（memory limit），cpu请求（cpu request）和cpu限额（cpu limit），所有容器的内存请求总额不得超过2GiB，所有容器的内存限额总额不得超过4 GiB，所有容器的CPU请求总额不得超过2 CPU，所有容器的CPU限额总额不得超过4CPU

[root@master ~]# cat namespace_ResourceQuota.yaml
apiVersion: v1
kind: Namespace
metadata:name: test
---
apiVersion: v1
kind: ResourceQuota
metadata:name: mem-cpu-quotanamespace: test
spec:hard:requests.cpu: "2"requests.memory: 2Gilimits.cpu: "4"limits.memory: 4Gi
[root@master ~]# kubectl apply -f namespace_ResourceQuota.yaml 
namespace/test created
resourcequota/mem-cpu-quota created# 可以通过describe查看到test命名空间中我们设置的资源配额限制
[root@master ~]# kubectl describe ns test
Name:         test
Labels:       kubernetes.io/metadata.name=test
Annotations:  <none>
Status:       ActiveResource QuotasName:            mem-cpu-quotaResource         Used  Hard--------         ---   ---limits.cpu       0     4limits.memory    0     4Girequests.cpu     0     2requests.memory  0     2GiNo LimitRange resource.

针对Pod设置资源配额

对于有资源限制的命名空间，下面的pod，创建pod时候必须设置资源限额，否则创建失败。

requests：代表容器启动请求的资源限制，分配的资源必须要达到此要求

limits：代表最多可以请求多少资源

单位m：CPU的计量单位叫毫核(m)。一个节点的CPU核心数量乘以1000，得到的就是节点总的CPU总数量。如，一个节点有两个核，那么该节点的CPU总量为2000m。

该容器启动时请求500/2000的核心（25％）

[root@master ~]# cat pod_resources.yaml
apiVersion: v1
kind: Pod
metadata: name: test-nginxnamespace: testlabels:app: nginx
spec:containers:- name: nginxports:- containerPort: 80image: nginximagePullPolicy: IfNotPresentresources:requests:memory: "100Mi"cpu: "500m"limits:memory: "2Gi"cpu: "2"[root@master ~]# kubectl apply -f pod_resources.yaml 
pod/test-nginx created

HorizontalPodAutoscaler（HPA）弹性伸缩

Horizontal Pod Autoscaling（Pod水平自动伸缩），简称HPA。HAP通过监控分析RC或者Deployment控制的所有Pod的负载变化情况来确定是否需要调整Pod的副本数量，这是HPA最基本的原理

HorizontalPodAutoscaler（简称 HPA ）自动更新工作负载资源（例如 Deployment 或者 StatefulSet），目的是自动扩缩工作负载以满足需求。

水平扩缩意味着对增加的负载的响应是部署更多的 Pod。这与“垂直（Vertical）”扩缩不同，对于 Kubernetes，垂直扩缩意味着将更多资源（例如：内存或 CPU）分配给已经为工作负载运行的 Pod。

如果负载减少，并且 Pod 的数量高于配置的最小值， HorizontalPodAutoscaler 会指示工作负载资源（Deployment、StatefulSet 或其他类似资源）缩减

HorizontalPodAutoscaler支持的指标

HPA支持的指标可以使用kubectl api-versions | grep autoscal命令查询

[root@master ~]# kubectl api-versions | grep autoscal

autoscaling/v1

autoscaling/v2

autoscaling/v2beta1

autoscaling/v2beta2

autoscaling/v1只支持基于CPU指标的缩放；

autoscaling/v2beta1支持Resource Metrics（资源指标，如pod的CPU，内存）和Custom Metrics（自定义指标）的缩放；

autoscaling/v2beta2支持Resource Metrics（资源指标，如pod的CPU，内存）和Custom Metrics（自定义指标）和ExternalMetrics（额外指标）的缩放，但是目前也仅仅是处于beta阶段

autoscaling/v2（稳定版本）其中包括对基于内存和自定义指标执行扩缩的支持

如下图没有Metrics这个插件，所以需要部署资源清单

部署Metrics

1.上传文件components.yaml

2.上传文件道所有节点，并且加载（metrics-server_v0.6.4.tar.gz）

docker load < metrics-server_v0.6.4.tar.gz

3.执行yaml文件，即可开启Metrics

kubectl apply -f components.yaml
kubectl get pod -n kube-system

准备测试服务

1.在所有节点上传镜像文件，加载镜像（cpu_stress_v3.tar.gz）

docker load < cpu_stress_v3.tar.gz

2.在master节点，编写yaml文件，启动服务

vi stress.yaml

apiVersion: apps/v1
kind: Deployment
metadata: name: stress
spec:replicas: 1selector:matchLabels:app: stresstemplate:metadata:labels:app: stressspec:containers:- name: stressimage: cpu_stress:v3imagePullPolicy: IfNotPresentports:- containerPort: 80resources:requests:cpu: "100m"limits:cpu: "500m"---
apiVersion: v1
kind: Service
metadata:name: stress
spec:ports:- port: 80targetPort: 80selector:app: stress

4.启动服务

kubectl apply -f stress.yaml

配置HPA的两种方式

命令行配置

# --cpu-percent指定pod的cpu使用率维持在50%左右
# --min 指定pod数量最少多少
# --max 指定pod数量最多多少
kubectl autoscale deployment stress --cpu-percent=50 --min=1 --max=10[root@master ~]# kubectl autoscale deployment stress --cpu-percent=50 --min=1 --max=10
horizontalpodautoscaler.autoscaling/stress autoscaled# 查看hpa
[root@master ~]# kubectl get hpa
NAME     REFERENCE           TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
stress   Deployment/stress   0%/50%    1         10        1          16s

资源清单配置

# scaleTargetRef指定要缩放的目标,在这里是 "stress" 这个 Deployment
# minReplicas: 1缩放的最小 pod 数量
# maxReplicas: 10缩放的最大 pod 数量
# 
[root@master ~]# cat stress_hpa.yaml 
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:name: stress
spec:scaleTargetRef:apiVersion: apps/v1kind: Deploymentname: stressminReplicas: 1maxReplicas: 10metrics:- type: Resource # 指定缩放所用的指标类型,这里是资源利用率指标resource:name: cpu # 指定资源类型,这里是 CPUtarget:type: Utilization # 表示基于 CPU利用率百分比来自动扩缩容。averageUtilization: 50 # 目标 cpu 平均利用率为 50%。当利用率超过这个目标值时会缩放 pod 数量。[root@master ~]# kubectl apply -f stress_hpa.yaml 
horizontalpodautoscaler.autoscaling/stress created[root@master ~]# kubectl get hpa
NAME     REFERENCE           TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
stress   Deployment/stress   1%/50%    1         10        1          39s

HPA测试

kubectl get hpa[root@master ~]# cat test.yaml 
apiVersion: apps/v1
kind: Deployment
metadata: name: cpustress
spec:replicas: 1selector:matchLabels:app: cpustresstemplate:metadata:labels:app: cpustressspec:containers:- name: cpustressimage: alpineimagePullPolicy: IfNotPresentcommand:- "sh"- "-c"- "sed -i 's/mirrors.aliyun.com/mirrors.ustc.edu.cn/g' /etc/apk/repositories && apk update && apk add curl && while true; do curl stress/stress?duration=30&load=70 ;sleep 32;done"# 运行测试容器
[root@master ~]# kubectl apply -f test.yaml 
deployment.apps/cpustress created# 查看hpa情况
[root@master ~]# kubectl get hpa
NAME     REFERENCE           TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
stress   Deployment/stress   62%/50%   1         10        10         51m# pod也启动了多个
[root@master ~]# kubectl get pod
NAME                         READY   STATUS    RESTARTS   AGE
cpustress-649d7f6485-gd6ld   1/1     Running   0          2m10s
stress-548b54ff89-2nlzk      1/1     Running   0          78s
stress-548b54ff89-5cz58      1/1     Running   0          93s
stress-548b54ff89-6cfpx      1/1     Running   0          63s
stress-548b54ff89-946kd      1/1     Running   0          78s
stress-548b54ff89-b9k48      1/1     Running   0          78s
stress-548b54ff89-k7d59      1/1     Running   0          93s
stress-548b54ff89-mw786      1/1     Running   0          63s
stress-548b54ff89-pcgc7      1/1     Running   0          93s
stress-548b54ff89-psb2f      1/1     Running   0          52m
stress-548b54ff89-zb2xl      1/1     Running   0          78s# 停止压力测试
[root@master ~]# kubectl delete -f test.yaml 
deployment.apps "cpustress" deleted# 等待一段时间会发现pod数量降下来了，可能需要几分钟
[root@master ~]# kubectl get pod
NAME                      READY   STATUS    RESTARTS   AGE
stress-548b54ff89-psb2f   1/1     Running   0          61m

节点选择器

通过nodeSelector

nodeSelector 是节点选择约束的最简单推荐形式。你可以将 nodeSelector 字段添加到 Pod 的规约中设置你希望目标节点所具有的节点标签。 Kubernetes 只会将 Pod 调度到拥有你所指定的每个标签的节点上

[root@master ~]# cat pod_nodeSelector.yaml 
apiVersion: v1
kind: Pod
metadata:name: podnodeselectornamespace: defaultlabels: app: nginx
spec:nodeSelector:disk: cephcontainers:- name: podnodeselectorports:- containerPort: 80image: nginximagePullPolicy: IfNotPresentresources:requests:memory: '100Mi'cpu: '500m'limits:memory: '1Gi'cpu: '1'# 部署资源
[root@master ~]# kubectl apply -f pod_nodeSelector.yaml 
pod/podnodeselector created# 可以看到没有节点带有disk=ceph标签，所以pod是Pending   
[root@master ~]# kubectl get pod
NAME              READY   STATUS    RESTARTS   AGE
podnodeselector   0/1     Pending   0          39s
[root@master ~]# kubectl get node -l disk=ceph
No resources found# 给node1节点打标签，然后pod就自动运行在有指定标签的节点了
[root@master ~]# kubectl label node node1 disk=ceph
node/node1 labeled
[root@master ~]# kubectl get pod -o wide
NAME              READY   STATUS    RESTARTS   AGE     IP           NODE    NOMINATED NODE   READINESS GATES
podnodeselector   1/1     Running   0          2m46s   10.244.1.3   node1   <none>           <none>

通过nodeName

nodeName 是比亲和性或者 nodeSelector 更为直接的形式。nodeName 是 Pod 规约中的一个字段。如果 nodeName 字段不为空，调度器会忽略该 Pod，而指定节点上的 kubelet 会尝试将 Pod 放到该节点上。使用 nodeName 规则的优先级会高于使用 nodeSelector 或亲和性与非亲和性的规则。

局限性：

如果所指代的节点不存在，则 Pod 无法运行，而且在某些情况下可能会被自动删除。

如果所指代的节点无法提供用来运行 Pod 所需的资源，Pod 会失败，而其失败原因中会给出是否因为内存或 CPU 不足而造成无法运行。

在云环境中的节点名称并不总是可预测的，也不总是稳定的

[root@master ~]# cat nodeName.yaml 
apiVersion: v1
kind: Pod
metadata:name: podnodeselectornamespace: defaultlabels: app: nginx
spec:nodeName: node1containers:- name: podnodeselectorports:- containerPort: 80image: nginximagePullPolicy: IfNotPresent
[root@master ~]# kubectl apply -f nodeName.yaml 
pod/podnodeselector created
[root@master ~]# kubectl get pod -o wide
NAME              READY   STATUS    RESTARTS   AGE   IP           NODE    NOMINATED NODE   READINESS GATES
podnodeselector   1/1     Running   0          11s   10.244.1.4   node1   <none>           <none>

亲和性

Affinity 翻译成中文是“亲和性”，它对应的是 Anti-Affinity，我们翻译成“互斥”。这两个词比较形象，可以把 pod 选择 node 的过程类比成磁铁的吸引和互斥，不同的是除了简单的正负极之外，pod 和 node 的吸引和互斥是可以灵活配置的

优点：

匹配有更多的逻辑组合，不只是字符串的完全相等

调度分成软策略(soft)和硬策略(hard)，在软策略下，如果没有满足调度条件的节点，pod会忽略这条规则，继续完成调度

Node亲和性

[root@master ~]# cat pod-node-affinity-demo.yaml
apiVersion: v1
kind: Pod
metadata:name: pod-node-affinity-demonamespace: defaultlabels:app: nginx
spec:containers:- name: nginxports:- containerPort: 80image: nginximagePullPolicy: IfNotPresentaffinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:- matchExpressions:- key: disktypeoperator: Invalues:- ssd- hhd[root@master ~]# kubectl apply -f pod-node-affinity-demo.yaml 
pod/pod-node-affinity-demo created# 查看pod状态是Pending，因为没有节点带有disktype=ssd标签或者disktype=hhd标签
[root@master ~]# kubectl get pod
NAME                     READY   STATUS    RESTARTS   AGE
pod-node-affinity-demo   0/1     Pending   0          30s
[root@master ~]# kubectl get node -l disktype=ssd
No resources found
[root@master ~]# kubectl get node -l disktype=hhd
No resources found# 打标签以后发现节点就运行了，并且是运行在打赏标签的哪个节点上
[root@master ~]# kubectl label node node1 disktype=ssd
node/node1 labeled
[root@master ~]# kubectl get pod -o wide
NAME                     READY   STATUS              RESTARTS   AGE    IP       NODE    NOMINATED NODE   READINESS GATES
pod-node-affinity-demo   0/1     ContainerCreating   0          3m4s   <none>   node1   <none>           <none>

Pod亲和性

pod自身的亲和性调度有两种表示形式

podaffinity：pod和pod更倾向腻在一起，把相近的pod结合到相近的位置，如同一区域，同一机架，这样的话pod和pod之间更好通信，比方说有两个机房，这两个机房部署的集群有1000台主机，那么我们希望把nginx和tomcat都部署同一个地方的node节点上，可以提高通信效率；

podunaffinity：pod和pod更倾向不腻在一起，如果部署两套程序，那么这两套程序更倾向于反亲和性，这样相互之间不会有影响。

第一个pod随机选则一个节点，做为评判后续的pod能否到达这个pod所在的节点上的运行方式，这就称为pod亲和性；我们怎么判定哪些节点是相同位置的，哪些节点是不同位置的；我们在定义pod亲和性时需要有一个前提，哪些pod在同一个位置，哪些pod不在同一个位置，这个位置是怎么定义的，标准是什么？以节点名称为标准，这个节点名称相同的表示是同一个位置，节点名称不相同的表示不是一个位置。

topologyKey：

位置拓扑的键，这个是必须字段

怎么判断是不是同一个位置：

rack=rack1

row=row1

使用rack的键是同一个位置

使用row的键是同一个位置

labelSelector：

我们要判断pod跟别的pod亲和，跟哪个pod亲和，需要靠labelSelector，通过labelSelector选则一组能作为亲和对象的pod资源

namespace：

labelSelector需要选则一组资源，那么这组资源是在哪个名称空间中呢，通过namespace指定，如果不指定namespaces，那么就是当前创建pod的名称空间

[root@master ~]# cat podAffinity.yaml
apiVersion: v1
kind: Pod
metadata:name: nginx01namespace: defaultlabels:app01: nginx01
spec:containers:- name: mynginxports:- containerPort: 80image: nginximagePullPolicy: IfNotPresent
---
apiVersion: v1
kind: Pod
metadata:name: nginx02namespace: defaultlabels:app02: nginx02
spec:containers:- name: mynginxports:- containerPort: 80image: nginximagePullPolicy: IfNotPresentaffinity:podAffinity:requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchExpressions:- key: app01operator: Invalues: - nginx01topologyKey: kubernetes.io/hostname # 每个节点都有kubernetes.io/hostname标签，这个标签通常是主机名，topologyKey指定了这个标签意思就是限定在一个节点上
[root@master ~]# kubectl apply -f podAffinity.yaml 
pod/nginx01 created
pod/nginx02 created
[root@master ~]# kubectl get pod -o wide
NAME      READY   STATUS    RESTARTS   AGE   IP           NODE    NOMINATED NODE   READINESS GATES
nginx01   1/1     Running   0          82s   10.244.1.5   node1   <none>           <none>
nginx02   1/1     Running   0          82s   10.244.1.6   node1   <none>           <none>

反亲和性

[root@master ~]# cat podAntiAffinity.yaml
apiVersion: v1
kind: Pod
metadata:name: nginx01namespace: defaultlabels:app01: nginx01
spec:containers:- name: mynginxports:- containerPort: 80image: nginximagePullPolicy: IfNotPresent
---
apiVersion: v1
kind: Pod
metadata:name: nginx02namespace: defaultlabels:app02: nginx02
spec:containers:- name: mynginxports:- containerPort: 80image: nginximagePullPolicy: IfNotPresentaffinity:podAntiAffinity:requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchExpressions:- key: app01operator: Invalues: - nginx01topologyKey: kubernetes.io/hostname
[root@master ~]# kubectl apply -f podAntiAffinity.yaml
pod/nginx01 created
pod/nginx02 created
[root@master ~]# kubectl get pod -o wide
NAME      READY   STATUS         RESTARTS   AGE   IP           NODE    NOMINATED NODE   READINESS GATES
nginx01   1/1     Running        0          95s   10.244.1.7   node1   <none>           <none>
nginx02   1/1     Running        0          95s   10.244.2.2   node2   <none>           <none>

污点容忍

节点亲和性是 Pod 的一种属性，它使 Pod 被吸引到一类特定的节点（这可能出于一种偏好，也可能是硬性要求）。污点（Taint）则相反——它使节点能够排斥一类特定的 Pod。

容忍度（Toleration）是应用于 Pod 上的。容忍度允许调度器调度带有对应污点的 Pod。容忍度允许调度但并不保证调度：作为其功能的一部分，调度器也会评估其他参数。

污点和容忍度（Toleration）相互配合，可以用来避免 Pod 被分配到不合适的节点上。每个节点上都可以应用一个或多个污点，这表示对于那些不能容忍这些污点的 Pod，是不会被该节点接受的。

污点

我们给节点打一个污点，不容忍的pod就运行不上来，污点就是定义在节点上的键值属性数据，可以定决定拒绝那些pod。

使用kubeadm安装的Kubernetes集群的master节点默认具有node-role.kubernetes.io/master:NoSchedule污点。

每个污点有一个key和value作为污点的标签，effect描述污点的作用。当前taint effect支持如下效果：

NoSchedule：表示K8S将不会把Pod调度到具有该污点的Node节点上
PreferNoSchedule：表示K8S将尽量避免把Pod调度到具有该污点的Node节点上
NoExecute：表示K8S将不会把Pod调度到具有该污点的Node节点上，同时会将Node上已经存在的Pod驱逐出去

添加污点

# 给节点 node1 增加一个污点，它的键名是 key1，键值是 value1，效果是 NoSchedule
kubectl taint nodes node1 key1=value1:NoSchedule

查看污点

# 查询node1节点的污点，找到Taints
kubectl describe nodes node1[root@master ~]# kubectl describe nodes node1 | grep Taints
Taints:             key1=value1:NoSchedule

删除污点

# 去除节点node1的污点，它的键名是 key1，键值是 value1，效果是 NoSchedule
kubectl taint nodes node1 key1=value1:NoSchedule-

容忍

默认情况下，Pod是不会运行在具有污点的节点上，但是我们可以配置容忍，让Pod运行在这个节点

设置污点

[root@master ~]# kubectl get node
NAME     STATUS   ROLES                  AGE     VERSION
master   Ready    control-plane,master   6d23h   v1.23.0
node1    Ready    <none>                 6d23h   v1.23.0
node2    Ready    <none>                 6d23h   v1.23.0
[root@master ~]# kubectl taint node node1 node-type=test:NoSchedule
node/node1 tainted
[root@master ~]# kubectl taint node node2 node-type=production:NoSchedule
node/node2 tainted

运行没有容忍的Pod

[root@master ~]# cat nginx-taint.yaml 
apiVersion: v1
kind: Pod
metadata:name: nginxnamespace: defaultlabels:app: nginx
spec:containers:- name: nginximage: nginxports:- name: httpcontainerPort: 80
[root@master ~]# kubectl apply -f nginx-taint.yaml 
pod/nginx created[root@master ~]# kubectl get pod
NAME    READY   STATUS    RESTARTS   AGE
nginx   0/1     Pending   0          15s# 使用describe查询
[root@master ~]# kubectl describe pod nginx
Name:         nginx
Namespace:    default
Priority:     0
Node:         <none>
Labels:       app=nginx
Annotations:  <none>
Status:       Pending
IP:           
IPs:          <none>
Containers:nginx:Image:        nginxPort:         80/TCPHost Port:    0/TCPEnvironment:  <none>Mounts:/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-7tgj2 (ro)
Conditions:Type           StatusPodScheduled   False 
Volumes:kube-api-access-7tgj2:Type:                    Projected (a volume that contains injected data from multiple sources)TokenExpirationSeconds:  3607ConfigMapName:           kube-root-ca.crtConfigMapOptional:       <nil>DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300snode.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:Type     Reason            Age   From               Message----     ------            ----  ----               -------Warning  FailedScheduling  54s   default-scheduler  0/3 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 1 node(s) had taint {node-type: production}, that the pod didn't tolerate, 1 node(s) had taint {node-type: test}, that the pod didn't tolerate.

运行带有容忍的Pod

[root@master ~]# cat nginx-taint.yaml 
apiVersion: v1
kind: Pod
metadata:name: nginxnamespace: defaultlabels:app: nginx
spec:containers:- name: nginximage: nginxports:- name: httpcontainerPort: 80# 容忍key是node-type，value是production，污点级是NoSchedule的污点tolerations:- key: "node-type"operator: "Equal"value: "production"effect: "NoSchedule"
[root@master ~]# kubectl apply -f nginx-taint.yaml 
pod/nginx configured# 因为该Pod定义了容忍node-type=production:NoSchedule污点所以可以在node2节点运行
[root@master ~]# kubectl get pod -o wide
NAME    READY   STATUS    RESTARTS   AGE     IP           NODE    NOMINATED NODE   READINESS GATES
nginx   1/1     Running   0          3m24s   10.244.2.3   node2   <none>           <none># 只要对应的键是存在的，exists，其值被自动定义成通配符
tolerations:
- key: "node-type"operator: "Exists"value: ""effect: "NoSchedule# 有一个node-type的键，不管值是什么，不管是什么效果，都能容忍
tolerations:
- key: "node-type"operator: "Exists"value: ""effect: ""