kubernetes-pod的调度
- kubernetes-7
- 1、pod停止之后,服务不会停止
- 2、pod endpoint service之间的关系
- 3、pod的调度
- 总述
- 1. 资源请求(Resource Requests)和资源限制(Resource Limits)
- 2. 节点选择器(Node Selector)
- 3. 污点和容忍度(Taints and Tolerations)
- 4. 亲和性和反亲和性(Affinity and Anti-Affinity)
- 5. 优先级类(PriorityClass)
- 6. 调度策略(Scheduling Policy)
- 4、Kubernetes Pod调度:CPU和内存资源配置与调度策略详解
- 4.1、例子
- 4.2、CPU设置
- 4.3、内存设置
- 4.4、配置示例
- 4.5、调度器如何使用这些设置
- 5、Kubernetes Pod调度:定向调度
- 5.1、指定nodeName
- 5.2、nodeselector 方式实现定向调度
- 6、Kubernetes Pod调度:节点亲和性
- 6.1、概述
- 6.2、node亲和性
- 7、小知识点
kubernetes-7
1、pod停止之后,服务不会停止
使用 kubectl delete
命令删除特定的 Service:
kubectl delete service <service-name>
[root@master pod]# kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 14d
mydb ClusterIP 10.111.97.213 <none> 80/TCP 9d
myservice ClusterIP 10.110.72.101 <none> 80/TCP 9d
mysql-service NodePort 10.108.120.107 <none> 3306:30008/TCP 43h
redis-leader ClusterIP 10.98.178.58 <none> 6379/TCP 43h
scnginx-service NodePort 10.103.157.7 <none> 80:30009/TCP 43h
[root@master pod]#
[root@master pod]# kubectl delete service scnginx-service
service "scnginx-service" deleted
[root@master pod]# kubectl delete service redis-leader
service "redis-leader" deleted
[root@master pod]# kubectl delete service mysql-service
service "mysql-service" deleted
[root@master pod]# kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 14d
mydb ClusterIP 10.111.97.213 <none> 80/TCP 9d
myservice ClusterIP 10.110.72.101 <none> 80/TCP 9d
[root@master pod]#
2、pod endpoint service之间的关系
-
Pod是Kubernetes中能够创建和部署的最小单元,代表集群中的一个应用实例。每个Pod都有一个或多个容器,这些容器共享网络和存储资源。Pods可以独立运行,但通常它们被组织成更大的结构以便于管理和扩展。
-
ENDPOINTS就是service关联的pod的ip地址和端口
-
Service是定义一组Pods的逻辑集合以及访问它们的策略的抽象。Service允许外部流量通过统一的接口访问一组Pods,而不需要关心后端Pods的具体IP地址或数量。Service通常通过Label Selector来选择目标Pods,这意味着只有带有特定标签的Pods才会成为Service的一部分。
在Kubernetes集群中,Pods是运行在私有网络空间内的容器,它们被分配有集群内部的私有IP地址。这些私有IP地址对于外部网络是不可见的,因此外部用户无法直接访问到这些Pods。
Service对象在Kubernetes中充当了将Pods的私有网络接口转换为可从外部访问的接口的角色。Service通过定义一种访问策略(例如负载均衡),使得外部流量可以被均匀地分配到后端的Pods上。这个过程通常由kube-proxy来实现,它负责在集群节点上设置相应的网络规则。
Service有两种主要的类型:
ClusterIP:这是Service的默认类型,它为Service分配一个集群内部的虚拟IP地址。这个IP地址可以被集群内的其他组件(如其他Pods或Services)用来访问Service。
NodePort 或 LoadBalancer:这两种类型的Service可以将流量从集群外部导向集群内部。NodePort在集群的所有节点上分配一个端口,而LoadBalancer(如果云提供商支持)会为Service分配一个公有IP地址。这样,外部用户就可以通过这个端口或IP地址访问到Service,进而访问到后端的Pods。
Endpoints是Service背后的实际网络地址列表,它包含了所有匹配Service选择器的Pods的IP地址和端口号。当Service接收到外部请求时,它会通过Endpoints来确定应该将请求转发到哪个Pod上。
总结来说,Service通过kube-proxy作为负载均衡器,将外部的请求转发到集群内部的Pods。Service有一个虚拟的IP地址和端口,这些信息通过Endpoints映射到实际的Pods上。这样,即使Pods的私有IP地址对外部不可见,外部用户也可以通过Service访问到这些Pods上运行的应用。
一个service对应一个pod
3、pod的调度
总述
- 自动调度:根据node节点的综合算例(cpu,内存等资源) 分配–》具有随机性
- 定向调度:指定在哪个node节点上 —>NodeName、NodeSelector
- 亲和性和反亲和性调度:
- pod亲和性
- node亲和性
- pod反亲和性:排斥,互斥
- 污点和容忍度
1. 资源请求(Resource Requests)和资源限制(Resource Limits)
apiVersion: v1
kind: Pod
metadata:name: my-pod
spec:containers:- name: my-containerimage: my-imageresources:requests:cpu: "500m"memory: "256Mi"limits:cpu: "1"memory: "512Mi"
在这个例子中,my-pod
Pod中的容器my-container
请求了500毫核的CPU和256Mi的内存。同时,它设置了1个CPU核心和512Mi内存的资源限制。
2. 节点选择器(Node Selector)
apiVersion: v1
kind: Pod
metadata:name: my-pod
spec:nodeSelector:disktype: ssdcontainers:- name: my-containerimage: my-image
这里,my-pod
将被调度到带有disktype: ssd
标签的节点上。
3. 污点和容忍度(Taints and Tolerations)
apiVersion: v1
kind: Pod
metadata:name: my-pod
spec:tolerations:- key: "example-key"operator: "Equal"value: "example-value"effect: "NoSchedule"containers:- name: my-containerimage: my-image
在这个Pod定义中,my-pod
容忍了一个名为example-key
的污点,其操作符为Equal
,值为example-value
,并且这个污点的效果是NoSchedule
,意味着这个Pod不会被调度到带有不匹配污点的节点上。
4. 亲和性和反亲和性(Affinity and Anti-Affinity)
apiVersion: v1
kind: Pod
metadata:name: my-pod
spec:affinity:podAffinity:requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchExpressions:- key: exampleoperator: Invalues:- valuetopologyKey: "kubernetes.io/hostname"containers:- name: my-containerimage: my-image
这个Pod定义使用了podAffinity
来指定my-pod
在调度时需要与具有example: value
标签的Pods在同一主机(kubernetes.io/hostname
)上运行。
5. 优先级类(PriorityClass)
apiVersion: v1
kind: Pod
metadata:name: my-podannotations:"scheduler.alpha.kubernetes.io/critical-pod": ""
spec:priorityClassName: high-prioritycontainers:- name: my-containerimage: my-image
这里,my-pod
使用了high-priority
优先级类,这意味着它在资源不足时会比其他低优先级的Pod更有可能被调度。
6. 调度策略(Scheduling Policy)
apiVersion: v1
kind: Pod
metadata:name: my-pod
spec:schedulerName: my-schedulercontainers:- name: my-containerimage: my-image
在这个例子中,my-pod
指定了使用名为my-scheduler
的调度器,而不是默认的调度器。
4、Kubernetes Pod调度:CPU和内存资源配置与调度策略详解
4.1、例子
在Kubernetes中,Pod的自动调度涉及到多个与资源相关的设置,尤其是CPU和内存的配置。以下是关于CPU和内存设置的详细信息,这些设置会影响Pod的调度行为:
4.2、CPU设置
-
CPU请求(cpuRequests):
- 指定Pod需要的最小CPU资源量。
- 例如:
cpuRequests: "250m"
表示Pod需要250毫核(millicores)的CPU资源。
-
CPU限制(cpuLimits):
- 指定Pod可以使用的最大CPU资源量。
- 例如:
cpuLimits: "500m"
表示Pod最多只能使用500毫核的CPU资源。
4.3、内存设置
-
内存请求(memoryRequests):
- 指定Pod需要的最小内存资源量。
- 例如:
memoryRequests: "128Mi"
表示Pod需要128 Mebibytes(Mi)的内存资源。
-
内存限制(memoryLimits):
- 指定Pod可以使用的最大内存资源量。
- 例如:
memoryLimits: "256Mi"
表示Pod最多只能使用256 Mebibytes的内存资源。
4.4、配置示例
以下是一个Pod定义文件的示例,展示了如何设置CPU和内存的请求和限制:
apiVersion: v1
kind: Pod
metadata:name: my-pod
spec:containers:- name: my-containerimage: my-imageresources:requests:cpu: "250m"memory: "128Mi"limits:cpu: "500m"memory: "256Mi"
在这个示例中,my-pod
Pod中的my-container
容器请求了250毫核的CPU和128Mi的内存。同时,它设置了500毫核CPU和256Mi内存的限制。
4.5、调度器如何使用这些设置
Kubernetes调度器在调度Pod时会考虑这些资源请求和限制:
- 过滤(Filtering)阶段: 调度器会筛选出具有足够资源(基于请求)的节点。
- 打分(Scoring)阶段: 调度器会根据资源的使用情况和其他策略(如亲和性规则)为每个节点打分,选择得分最高的节点来调度Pod。
正确配置资源请求和限制对于确保Pod的稳定运行和集群资源的有效管理至关重要。请求设置得太小可能会导致Pod在资源紧张时被频繁地驱逐,而请求设置得太大可能会导致资源浪费。限制设置得太小可能会导致Pod在资源使用高峰时被杀掉,而设置得太大则可能会导致集群资源过载。
5、Kubernetes Pod调度:定向调度
5.1、指定nodeName
[root@master sch]# vim pod.yaml
apiVersion: v1
kind: Pod
metadata:name: pod-nodenamenamespace: sc
spec:containers:- name: nginximage: nginx:latestimagePullPolicy: IfNotPresentnodeName: node-1
[root@master sch]#
[root@master sch]# kubectl apply -f pod.yaml
pod/pod-nodename created
[root@master sch]# kubectl get pod -n sc
NAME READY STATUS RESTARTS AGE
pod-nodename 1/1 Running 0 11s
[root@master sch]# kubectl get pod -n sc -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-nodename 1/1 Running 0 21s 10.244.84.152 node-1 <none> <none>
[root@master sch]#
5.2、nodeselector 方式实现定向调度
NodeSelector用于将pod调度到添加了指定标签的node节点上。它是通过kubernetes的label-selector机制实现的,也就是说,在pod创建之前,会由scheduler使用MatchNodeSelector调度策略进行label匹配,找出目标node,然后将pod调度到目标节点,该匹配规则是强制约束。
-
首先分别为node-2节点添加标签:nodeenv=prod
[root@master sch]# kubectl label nodes node-2 nodeenv=prod node/node-2 labeled [root@master sch]# kubectl get nodes --show-labels NAME STATUS ROLES AGE VERSION LABELS node-2 Ready worker 11d v1.20.6 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node-2,kubernetes.io/os=linux,node-role.kubernetes.io/worker=worker,nodeenv=prod [root@master sch]#
-
给node-1节点添加标签: nodeenv=test
[root@master sch]# kubectl label nodes node-1 nodeenv=test node/node-1 labeled [root@master sch]# kubectl get nodes --show-labels|grep node-1 node-1 Ready worker 11d v1.20.6 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node-1,kubernetes.io/os=linux,node-role.kubernetes.io/worker=worker,nodeenv=test [root@master sch]#
-
创建一个pod-node-selector.yaml文件,并使用它创建Pod
[root@master sch]# vim pod-node-selector.yaml apiVersion: v1 kind: Pod metadata:name: pod-nodeselectornamespace: sc spec:containers:- name: nginximage: nginx:latestimagePullPolicy: IfNotPresentnodeSelector:nodeenv: prod # 指定调度到具有nodeenv=prod标签的节点上 [root@master sch]#
[root@master sch]# kubectl apply -f pod-node-selector.yaml pod/pod-nodeselector created [root@master sch]# kubectl get -f pod-node-selector.yaml NAME READY STATUS RESTARTS AGE pod-nodeselector 1/1 Running 0 9s [root@master sch]# kubectl get -f pod-node-selector.yaml -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-nodeselector 1/1 Running 0 14s 10.244.247.28 node-2 <none> <none> [root@master sch]#
6、Kubernetes Pod调度:节点亲和性
6.1、概述
节点亲和性(Node Affinity)是 Kubernetes 中的一个调度特性,它允许你定义规则,指导调度器将 Pod 调度到具有特定特征的节点上。这些特征可以是节点的标签(Labels),也可以是节点的其他属性,如硬件类型、区域等。节点亲和性的目的是确保 Pod 能够运行在最适合其运行条件的节点上,从而优化资源利用率、提高性能或满足特定的部署要求。
亲和性调度(Aw inity)主要分为三类:
- nodeAw inity(node亲和性):以node为目标,解决pod可以调度到哪些node的问题
- podAw inity(pod亲和性) :以pod为目标,解决pod可以和哪些已存在的pod部署在同一个拓扑域中的问题
- podAntiAw inity(pod反亲和性) : 以pod为目标,解决pod不能和哪些已存在pod部署在同一个拓扑域中的问题
6.2、node亲和性
1.选择一个节点,给它添加一个标签:
[root@master sch]# kubectl label nodes node-1 disktype=hdd
node/node-1 labeled
[root@master sch]# kubectl get nodes --show-labels|grep node-1
node-1 Ready worker 11d v1.20.6 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,disktype=hdd,kubernetes.io/arch=amd64,kubernetes.io/hostname=node-1,kubernetes.io/os=linux,node-role.kubernetes.io/worker=worker,nodeenv=test
[root@master sch]#
2.创建pod-nginx的yaml文件
[root@master sch]# vim pod-nginx-podaffinity.yaml
[root@master sch]# cat pod-nginx-podaffinity.yaml
apiVersion: v1
kind: Pod
metadata:name: nginx
spec:affinity: #亲和性nodeAffinity: #节点亲和性requiredDuringSchedulingIgnoredDuringExecution: #硬限制nodeSelectorTerms:- matchExpressions: #匹配标签- key: disktypeoperator: Invalues:- hdd containers:- name: nginximage: nginx:latestimagePullPolicy: IfNotPresent
[root@master sch]#
[root@master sch]# kubectl apply -f pod-nginx-podaffinity.yaml
pod/nginx created
[root@master sch]# kubectl get -f pod-nginx-podaffinity.yaml -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx 1/1 Running 0 10s 10.244.84.147 node-1 <none> <none>
[root@master sch]#
7、小知识点
- 每个服务都会有一个ip
- 通过访问宿主机上的端口,映射到pod里–》外网就可以访问内部的pod了
- kubectl get service —》用于获取集群中服务(Service)的列表或特定服务的详细信息。
- kubectl get nodes --show-labels —》查看节点打的标签
- disk磁盘类型:hdd—>机械磁盘 hard disk driver ssd:固态磁盘