中国电力建设股份有限公司网站,微商城怎么注册怎么弄,沈阳网站seo优化哪家好,wordpress 添加 links资源配额 什么是资源配额 资源配额#xff0c;通过 ResourceQuota 对象来定义#xff0c;对每个命名空间的资源消耗总量提供限制。 它可以限制命名空间中某种类型的对象的总数目上限#xff0c;也可以限制命名空间中的 Pod 可以使用的计算资源的总上限。 资源配额应用 创建的…资源配额 什么是资源配额 资源配额通过 ResourceQuota 对象来定义对每个命名空间的资源消耗总量提供限制。 它可以限制命名空间中某种类型的对象的总数目上限也可以限制命名空间中的 Pod 可以使用的计算资源的总上限。 资源配额应用 创建的ResourceQuota对象将在test名字空间中添加限制每个容器必须设置内存请求memory request内存限额memory limitcpu请求cpu request和cpu限额cpu limit所有容器的内存请求总额不得超过2GiB所有容器的内存限额总额不得超过4 GiB所有容器的CPU请求总额不得超过2 CPU所有容器的CPU限额总额不得超过4CPU
[rootmaster ~]# 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: 2requests.memory: 2Gilimits.cpu: 4limits.memory: 4Gi
[rootmaster ~]# kubectl apply -f namespace_ResourceQuota.yaml
namespace/test created
resourcequota/mem-cpu-quota created# 可以通过describe查看到test命名空间中我们设置的资源配额限制
[rootmaster ~]# kubectl describe ns test
Name: test
Labels: kubernetes.io/metadata.nametest
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代表最多可以请求多少资源 单位mCPU的计量单位叫毫核(m)。一个节点的CPU核心数量乘以1000得到的就是节点总的CPU总数量。如一个节点有两个核那么该节点的CPU总量为2000m。 该容器启动时请求500/2000的核心25
[rootmaster ~]# 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: 100Micpu: 500mlimits:memory: 2Gicpu: 2[rootmaster ~]# kubectl apply -f pod_resources.yaml
pod/test-nginx created
HorizontalPodAutoscalerHPA弹性伸缩 Horizontal Pod AutoscalingPod水平自动伸缩简称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命令查询 [rootmaster ~]# 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: 100mlimits: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-percent50 --min1 --max10[rootmaster ~]# kubectl autoscale deployment stress --cpu-percent50 --min1 --max10
horizontalpodautoscaler.autoscaling/stress autoscaled# 查看hpa
[rootmaster ~]# 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 数量
#
[rootmaster ~]# 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 数量。[rootmaster ~]# kubectl apply -f stress_hpa.yaml
horizontalpodautoscaler.autoscaling/stress created[rootmaster ~]# kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
stress Deployment/stress 1%/50% 1 10 1 39s HPA测试
kubectl get hpa[rootmaster ~]# 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?duration30load70 ;sleep 32;done# 运行测试容器
[rootmaster ~]# kubectl apply -f test.yaml
deployment.apps/cpustress created# 查看hpa情况
[rootmaster ~]# kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
stress Deployment/stress 62%/50% 1 10 10 51m# pod也启动了多个
[rootmaster ~]# 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# 停止压力测试
[rootmaster ~]# kubectl delete -f test.yaml
deployment.apps cpustress deleted# 等待一段时间会发现pod数量降下来了可能需要几分钟
[rootmaster ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
stress-548b54ff89-psb2f 1/1 Running 0 61m
节点选择器 通过nodeSelector nodeSelector 是节点选择约束的最简单推荐形式。你可以将 nodeSelector 字段添加到 Pod 的规约中设置你希望目标节点所具有的节点标签。 Kubernetes 只会将 Pod 调度到拥有你所指定的每个标签的节点上
[rootmaster ~]# 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: 100Micpu: 500mlimits:memory: 1Gicpu: 1# 部署资源
[rootmaster ~]# kubectl apply -f pod_nodeSelector.yaml
pod/podnodeselector created# 可以看到没有节点带有diskceph标签所以pod是Pending
[rootmaster ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
podnodeselector 0/1 Pending 0 39s
[rootmaster ~]# kubectl get node -l diskceph
No resources found# 给node1节点打标签然后pod就自动运行在有指定标签的节点了
[rootmaster ~]# kubectl label node node1 diskceph
node/node1 labeled
[rootmaster ~]# 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 不足而造成无法运行。 在云环境中的节点名称并不总是可预测的也不总是稳定的 [rootmaster ~]# cat nodeName.yaml
apiVersion: v1
kind: Pod
metadata:name: podnodeselectornamespace: defaultlabels: app: nginx
spec:nodeName: node1containers:- name: podnodeselectorports:- containerPort: 80image: nginximagePullPolicy: IfNotPresent
[rootmaster ~]# kubectl apply -f nodeName.yaml
pod/podnodeselector created
[rootmaster ~]# 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亲和性
[rootmaster ~]# 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[rootmaster ~]# kubectl apply -f pod-node-affinity-demo.yaml
pod/pod-node-affinity-demo created# 查看pod状态是Pending因为没有节点带有disktypessd标签或者disktypehhd标签
[rootmaster ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
pod-node-affinity-demo 0/1 Pending 0 30s
[rootmaster ~]# kubectl get node -l disktypessd
No resources found
[rootmaster ~]# kubectl get node -l disktypehhd
No resources found# 打标签以后发现节点就运行了并且是运行在打赏标签的哪个节点上
[rootmaster ~]# kubectl label node node1 disktypessd
node/node1 labeled
[rootmaster ~]# 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自身的亲和性调度有两种表示形式 podaffinitypod和pod更倾向腻在一起把相近的pod结合到相近的位置如同一区域同一机架这样的话pod和pod之间更好通信比方说有两个机房这两个机房部署的集群有1000台主机那么我们希望把nginx和tomcat都部署同一个地方的node节点上可以提高通信效率 podunaffinitypod和pod更倾向不腻在一起如果部署两套程序那么这两套程序更倾向于反亲和性这样相互之间不会有影响。 第一个pod随机选则一个节点做为评判后续的pod能否到达这个pod所在的节点上的运行方式这就称为pod亲和性我们怎么判定哪些节点是相同位置的哪些节点是不同位置的我们在定义pod亲和性时需要有一个前提哪些pod在同一个位置哪些pod不在同一个位置这个位置是怎么定义的标准是什么以节点名称为标准这个节点名称相同的表示是同一个位置节点名称不相同的表示不是一个位置。 topologyKey 位置拓扑的键这个是必须字段 怎么判断是不是同一个位置 rackrack1 rowrow1 使用rack的键是同一个位置 使用row的键是同一个位置 labelSelector 我们要判断pod跟别的pod亲和跟哪个pod亲和需要靠labelSelector通过labelSelector选则一组能作为亲和对象的pod资源 namespace labelSelector需要选则一组资源那么这组资源是在哪个名称空间中呢通过namespace指定如果不指定namespaces那么就是当前创建pod的名称空间
[rootmaster ~]# 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指定了这个标签意思就是限定在一个节点上
[rootmaster ~]# kubectl apply -f podAffinity.yaml
pod/nginx01 created
pod/nginx02 created
[rootmaster ~]# 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 反亲和 性
[rootmaster ~]# 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
[rootmaster ~]# kubectl apply -f podAntiAffinity.yaml
pod/nginx01 created
pod/nginx02 created
[rootmaster ~]# 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 key1value1:NoSchedule 查看污点
# 查询node1节点的污点找到Taints
kubectl describe nodes node1[rootmaster ~]# kubectl describe nodes node1 | grep Taints
Taints: key1value1:NoSchedule 删除污点
# 去除节点node1的污点它的键名是 key1键值是 value1效果是 NoSchedule
kubectl taint nodes node1 key1value1:NoSchedule- 容忍 默认情况下Pod是不会运行在具有污点的节点上但是我们可以配置容忍让Pod运行在这个节点 设置污点
[rootmaster ~]# 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
[rootmaster ~]# kubectl taint node node1 node-typetest:NoSchedule
node/node1 tainted
[rootmaster ~]# kubectl taint node node2 node-typeproduction:NoSchedule
node/node2 tainted 运行没有容忍的Pod
[rootmaster ~]# cat nginx-taint.yaml
apiVersion: v1
kind: Pod
metadata:name: nginxnamespace: defaultlabels:app: nginx
spec:containers:- name: nginximage: nginxports:- name: httpcontainerPort: 80
[rootmaster ~]# kubectl apply -f nginx-taint.yaml
pod/nginx created[rootmaster ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx 0/1 Pending 0 15s# 使用describe查询
[rootmaster ~]# kubectl describe pod nginx
Name: nginx
Namespace: default
Priority: 0
Node: none
Labels: appnginx
Annotations: none
Status: Pending
IP:
IPs: none
Containers:nginx:Image: nginxPort: 80/TCPHost Port: 0/TCPEnvironment: noneMounts:/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: nilDownwardAPI: true
QoS Class: BestEffort
Node-Selectors: none
Tolerations: node.kubernetes.io/not-ready:NoExecute opExists for 300snode.kubernetes.io/unreachable:NoExecute opExists 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 didnt tolerate, 1 node(s) had taint {node-type: production}, that the pod didnt tolerate, 1 node(s) had taint {node-type: test}, that the pod didnt tolerate. 运行带有容忍的Pod
[rootmaster ~]# cat nginx-taint.yaml
apiVersion: v1
kind: Pod
metadata:name: nginxnamespace: defaultlabels:app: nginx
spec:containers:- name: nginximage: nginxports:- name: httpcontainerPort: 80# 容忍key是node-typevalue是production污点级是NoSchedule的污点tolerations:- key: node-typeoperator: Equalvalue: productioneffect: NoSchedule
[rootmaster ~]# kubectl apply -f nginx-taint.yaml
pod/nginx configured# 因为该Pod定义了容忍node-typeproduction:NoSchedule污点所以可以在node2节点运行
[rootmaster ~]# 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-typeoperator: Existsvalue: effect: NoSchedule# 有一个node-type的键不管值是什么不管是什么效果都能容忍
tolerations:
- key: node-typeoperator: Existsvalue: effect:
