Tabla de contenido
1. Proceso de programación de pods
2. Limitaciones de recursos de contenedores
2.1 Limitaciones de memoria y CPU
4.2.1 Programación de pods con afinidad de nodo preferida
4.2.2 Programación de pods según la afinidad de nodo obligatoria
6.2 Ejemplo de especificación de pod del campo NodeName
1. Proceso de programación de pods
Kubernetes utiliza una arquitectura de controlador basada en el mecanismo de vigilancia de listas para desacoplar las interacciones entre los componentes.
Otros componentes supervisan los recursos de los que son responsables. Cuando estos recursos cambien, kube-apiserver notificará a estos componentes. Este proceso es similar a la publicación y suscripción.
Programación del proceso general
- El usuario usa create yaml para crear un pod, lo solicita a apiServer y apiserver escribe la información del atributo (metadatos) en yaml para etcd
- apiServer activa el mecanismo de vigilancia para crear un pod, reenvía la información al programador, el programador usa un algoritmo de programación para seleccionar un nodo, el programador envía la información del nodo a apiServer y apiServer escribe la información del nodo enlazado en etcd
- El apiServer llama al kubelet a través del mecanismo de observación, especifica la información del pod y activa el comando de ejecución de la ventana acoplable para crear el contenedor.
- Una vez completada la creación, se retroalimenta a kubelet, y kubelet envía la información de estado del pod a apiserver.
- El apserver escribe la información de estado del pod en etcd.
- Entre ellos, la información etcd_ es invocada por el comando kubectl get pods
2. Limitaciones de recursos de contenedores
2.1 Limitaciones de memoria y CPU
El límite máximo de recursos utilizados por el contenedor:
• recursos.límites.cpu
• recursos.límites.memoria
Los requisitos mínimos de recursos utilizados por los contenedores se utilizan como base para la asignación de recursos durante la programación de contenedores:
• recursos.solicitudes.cpu
• recursos.solicitudes.memoria
Ejemplo oficial: asignación de recursos de memoria para contenedores y pods | Kubernetes
ejemplo
apiVersion: v1
kind: Pod
metadata:
name: pod-resource
spec:
containers:
- name: web
image: nginx
resources:
requests: # 容器最小资源配额
memory: "64Mi"
cpu: "250m"
limits: # 容器最大资源上限
memory: "128Mi"
cpu: "500m"Use describe para ver la información de descripción del pod
3. Selector de nodos
nodeSelector: se utiliza para programar el pod en el nodo que coincide con la etiqueta; si no hay una etiqueta que coincida, la programación fallará. efecto:
• Restringir pods para que se ejecuten en nodos específicos
• Escenarios de aplicación de etiquetas de nodos de coincidencia exacta:
• Nodos dedicados: los nodos se agrupan y gestionan según las líneas de negocio
• Equipado con hardware especial: algunos Nodos están equipados con disco duro SSD y GPU
Operación de ejemplo
### 给node2 打上SSD 的标签
kubectl label node k8s-node2 disktype=ssd
## 查看node 的标签信息
kubectl get node k8s-node2 --show-labels
Cree un pod y programe el pod para el nodo k8s-node2 con la etiqueta SSD
apiVersion: v1
kind: Pod
metadata:
name: pod-node-selector
spec:
nodeSelector:
disktype: 'ssd'
containers:
- name: web
image: nginxCompruebe si está programado para el nodo k8s-node2
4. Afinidad de nodos
4.1 Conceptos básicos
Asigne pods a los nodos trabajadores mediante la afinidad de nodos.
nodeAffinity: Node affinity, que tiene la misma función que nodeSelector, pero es más flexible y cumple más condiciones, como:
• La coincidencia tiene más combinaciones lógicas que solo la igualdad exacta de cadenas
• La programación se divide en políticas suaves y estrictas en lugar de requisitos estrictos
• Difícil (obligatorio): debe cumplir
• suave (preferido): intenta satisfacer, pero no garantiza
Operadores: In, NotIn, Exists, DoesNotExist, Gt, Lt
Ejemplo oficial:
Asignar pods a nodos con afinidad de nodos | Kubernetes
4.2 Ejemplo de cápsula
4.2.1 Programación de pods con afinidad de nodo preferida
El siguiente ejemplo de política flexible coincide con la etiqueta de nodo gpu=nvidia
apiVersion: v1
kind: Pod
metadata:
name: pod-node-affinity
spec:
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: gpu
operator: In
values:
- nvidia
containers:
- name: web
image: nginxLa estrategia suave se envía al nodo k8s-master1 Master1 no tiene la etiqueta gpu=nvidia y la estrategia suave se envía correctamente.
4.2.2 Programación de pods según la afinidad de nodo obligatoria
apiVersion: v1
kind: Pod
metadata:
name: pod-node-affinity2
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: gpu
operator: In
values:
- nvidia
containers:
- name: web
image: nginxDespués de cambiar lo anterior a una política rígida, el pod debe programarse en el nodo con la etiqueta gpu=nvidia, pero no existe tal nodo en el clúster de prueba de k8s.
A continuación, podemos ver que pod-node-affinity2 está en estado Pendiente
Use describir para ver el estado del pod, ningún nodo coincide
Advertencia FailedScheduling 36s default-scheduler 0/4 nodos disponibles: 4 nodos no coincidieron con la afinidad/selector de nodos de Pod. preferencia: 0/4 nodos disponibles: 4 La preferencia no es útil para la programación.
5. Manchas y tolerancias
5.1 Conceptos básicos
La afinidad de nodos es una propiedad de un pod que hace que un pod se sienta atraído por una clase particular de nodos (esto puede ser una preferencia o un requisito estricto). Las corrupciones son todo lo contrario: permiten que los nodos excluyan una clase específica de pods.
Las tolerancias se aplican a los pods y permiten (pero no requieren) que los pods se programen en nodos con taints coincidentes.
Las corrupciones y la tolerancia (Tolerancia) cooperan entre sí y se pueden usar para evitar que los Pods se asignen a nodos inapropiados. Se pueden aplicar uno o más taints a cada nodo, lo que significa que el nodo no aceptará los Pods que no puedan tolerar estos taints.
Contaminaciones: evite la programación de pods para un nodo específico
Tolerancias: permite que los pods se envíen a los nodos que contienen escenarios de aplicación de Taints:
• Nodos dedicados: los nodos se agrupan y administran de acuerdo con las líneas de negocio. Se espera que este nodo no se programe de manera predeterminada . Solo cuando se configura la tolerancia a la contaminación, se puede permitir la asignación.
• Equipado con hardware especial: algunos nodos están equipados con discos duros SSD y GPU. Se espera que este nodo no se programe de forma predeterminada. Solo cuando se configura la tolerancia a la contaminación, se puede permitir la asignación.
• Desalojo basado en corrupción
5.2 Manchas 与 Tolerancias
Manchas y tolerancias | Kubernetes
Ver etiquetas de nodos
pod3.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod3
spec:
containers:
- name: web
image: nginxMarque k8s-master1 y k8s-master2, el nombre de la clave es gpu, el valor de la clave es nvidia y el efecto es NoSchedule. Indica que solo los pods con una tolerancia que coincida con esta contaminación se pueden asignar a los dos nodos principales.
kubectl taint node k8s-master1 gpu=nvidia:NoSchedule
kubectl taint node k8s-master2 gpu=nvidia:NoScheduleTambién contaminar los dos nodos de nodo.
## k8s-node1 打上 GPU 污点
kubectl taint node k8s-node1 gpu=nvidia:NoSchedule
## k8s-node2 打上 ssd 污点
kubectl taint node k8s-node2 ssd=ssd:NoSchedule
## 起一个 Pod
apiVersion: v1
kind: Pod
metadata:
name: pod4
spec:
containers:
- name: web
image: nginxSe puede ver que el pod4 está en estado Pendiente y el pod no se puede programar correctamente sin la configuración de tolerancia a la contaminación.
Advertencia FailedScheduling 24s default-scheduler Hay 0/4 nodos disponibles: 1 nodo(s) tenía una corrupción no tolerada {ssd: ssd}, 3 nodo(s) tenía una corrupción no tolerada {gpu: nvidia}. preferencia: 0/4 nodos disponibles: 4 La preferencia no es útil para la programación.
Agregamos tolerancia a la corrupción de SSD a k8s-node2 y dejamos que pod5 se programe en k8s-node2
apiVersion: v1
kind: Pod
metadata:
name: pod5
spec:
tolerations:
- key: "ssd"
operator: "Equal"
value: "ssd"
effect: "NoSchedule"
containers:
- name: web
image: nginxDado que otros nodos tienen vulnerabilidades y el nodo2 tiene tolerancia a la vulnerabilidad ssd, pod5 se ejecuta correctamente en el nodo2.
removedor de manchas
kubectl taint node k8s-master2 gpu=nvidia:NoSchedule-
kubectl taint node k8s-master1 gpu=nvidia:NoSchedule-
kubectl taint node k8s-node1 gpu=nvidia:NoSchedule-
kubectl taint node k8s-node2 ssd=ssd:NoSchedule-6. Nombre de nodo
6.1 Conceptos básicos
nodeName es una forma más directa que affinity o nodeSelector. nodeName es un campo en la especificación de Pod. Si el campo nodeName no está vacío, el planificador ignorará el Pod y el kubelet en el nodo especificado intentará colocar el Pod en ese nodo. Las reglas que usan nodeName tendrán prioridad sobre las reglas que usan nodeSelector o afinidad y no afinidad.
Existen algunas limitaciones en la forma en que se usa nodeName para seleccionar nodos:
- Si el nodo al que se refiere no existe, el Pod no puede ejecutarse y puede eliminarse automáticamente en algunos casos.
- Si el nodo al que se hace referencia no puede proporcionar los recursos necesarios para ejecutar el Pod, el Pod fallará y el motivo de la falla indicará si no puede ejecutarse debido a memoria o CPU insuficientes.
- Los nombres de los nodos en entornos de nube no siempre son predecibles ni siempre estables.
6.2 Ejemplo de especificación de pod del campo NodeName
apiVersion: v1
kind: Pod
metadata:
name: pod6
spec:
containers:
- name: nginx
image: nginx
nodeName: k8s-node2Tanto k8s-master1 como k8s-master2, así como k8s-node1 y k8s-node2 están manchados y la prioridad de nodeName es mayor, por lo que el pod se programa correctamente.
