Home | José Ramón López | AutoSys | Webs de interés | perl | kubernetes | azure | machine learning
Table of Contents
1.2 Labels y selectors y annotations
1.6 taints and tolerations vs Node affinity
1.7 Resource requirements and limits
1.12 Configure schedulers profile
Esto quiere decir que digo a mano el node donde va el pod con el tag nodeName o utilizar el objeto binding
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
nodeName: worker
containers:
- name: nginx
image: nginx:latest
Labels y selector van juntos
kubectl get pod --selector run=mypod
annotations da información extra
Se aplica el taint a los nodos para que acepten pods y se aplica toleration a pod para que soporten taints.
No dicen a donde van los pods sino que dice que pods pueden ir a un nodo
Kubectl taint nodes nodeName key=value:taint-effect
Kubectl taint nodes nodeName key=value:taint-effect-
Taint-effect
· noSchedule. No se adminten pod nuevos
· PreferNoSchedule: Se intenta evitar
· NoExecute. No se adminten pod nuevos y los ya existentense se le echa si no soportan en taint
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
tolerations:
- key: "example-key"
operator: "Exists"
effect: "NoSchedule"
Node selector selecciona donde se ejecuta un pod por el tag del nodo
Solo va con 1 label, para hacerl se usa node affinity
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
nodeSelector:
disktype: ssd
Este pod va al noco con tag disktype: ssd
1. Se pone label al node (kubectl label nodes cp label=value)
2. Se crea el pod
Es la version moderna de node selector
Node affinity
· requiredDuringSchedulingIgnoredDuringExecution
· preferredDuringSchedulingIgnoredDuringExecution
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: disktype
operator: In
values:
- ssd
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
taint and tolerations impiden que un pod vaya a un nodo
nodo affinity hace que un pod vaya a un nodo
Request es lo que se le da a un container al crearlo
cpu va de 0 a 1 (cpu)
memoria en megas, gigas…
Por defecto un container no tiene limite a los recursos que puede usar
Se puede poner limite a los recursos que usa un recurso
Si un container quiere usar + cpu que su limite no puede.
Si un container quiere usar + memoria es terminado, OOM
apiVersion: v1
kind: Pod
metadata:
name: frontend
spec:
containers:
- name: app
image: images.my-company.example/app:v4
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
- name: log-aggregator
image: images.my-company.example/log-aggregator:v6
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
lo normal es poner solo Request ya que te asegurar su mínimo y le dejas crecrer
se puede poner limites al crear un pod por defecto a los containers con limitrange y se hace a nivel de namespace
apiVersion: v1
kind: LimitRange
metadata:
name: cpu-resource-constraint
spec:
limits:
- default: # this section defines default limits
cpu: 500m
defaultRequest: # this section defines default requests
cpu: 500m
max: # max and min define the limit range
cpu: "1"
min:
cpu: 100m
type: Container
Tambien se puede poner quotas a nivel de namespace que son hard limits
apiVersion: v1
kind: List
items:
- apiVersion: v1
kind: ResourceQuota
metadata:
name: pods-high
spec:
hard:
cpu: "1000"
memory: 200Gi
pods: "10"
scopeSelector:
matchExpressions:
- operator : In
scopeName: PriorityClass
values: ["high"]
- apiVersion: v1
kind: ResourceQuota
metadata:
name: pods-medium
spec:
hard:
cpu: "10"
memory: 20Gi
pods: "10"
scopeSelector:
matchExpressions:
- operator : In
scopeName: PriorityClass
values: ["medium"]
- apiVersion: v1
kind: ResourceQuota
metadata:
name: pods-low
spec:
hard:
cpu: "5"
memory: 10Gi
pods: "10"
scopeSelector:
matchExpressions:
- operator : In
scopeName: PriorityClass
values: ["low"]
Se puede editar en un pod solo estos campos
si quieres editar otros campos hay que o editarlo y luego cargar el fichero temporal o guardar el yaml
un deployment si que deja cambiar mas campos
Pone un pod en cada nodo. El Daemon set respeta los taint
Por ejemplo kube-proxy o Network Solutions
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd-elasticsearch
namespace: kube-system
labels:
k8s-app: fluentd-logging
spec:
selector:
matchLabels:
name: fluentd-elasticsearch
template:
metadata:
labels:
name: fluentd-elasticsearch
spec:
tolerations:
- key: node-role.kubernetes.io/master
operator: Exists
effect: NoSchedule
containers:
- name: fluentd-elasticsearch
image: gcr.io/fluentd-elasticsearch/fluentd:v2.5.1
resources:
limits:
memory: 200Mi
requests:
cpu: 100m
memory: 200Mi
volumeMounts:
- name: varlog
mountPath: /var/log
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
terminationGracePeriodSeconds: 30
volumes:
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
Solía funcionar con la propiedad nodeName pero desde la versión v1.12 trabaja con nodeAffinity y default scheduler
Kubelet puede hacer de controlar y manejar un nodo independientemente, sin api server, etcd, scheduler…
Como crea kubelet un pod?
Se puede configurar kubelet para crear pods si su definición está en un directorio
Lo crea y se asegura que está siempre arriba.
El directorio por defecto es /etc/kubernetes/manifests
Pero se puede cambiar en las opciones de kubelet
La configuración de kubelet se puede ver
· servicio: /etc/systemd/System --pod-manifest-path=
· kubeadm: /etc/kubernetes/ staticPodPath: /etc/kubernetes/manifests
· Ps | grep kubelet
Puede haber 2 ficheros de configuración
· --kubeconfig=/etc/kubernetes/kubelet.conf
· --config=/var/lib/kubelet/config.yaml
Como no hay api server no vale el comando kubectl
Hay que usar comandos de Docker
· docker ps
kubelet
1. manifest
2. api server
kubectl al crear un static pod crea “una imagen” en el api server. Y se añade el nombre del nodo al nombre del pod.
Se usa en general para los elementos del cluster
· api-server
· controller-manager
· etcd
· ….
Para saber si un pod es statíco se ve en el owner, en el apartado owner
Kubectl get pod podName
……………………………..
ownerReferences:
- apiVersion: v1
controller: true
kind: Node ß---------------------node = pod statico
name: cp
En un kubernetes puede haber varios schedulers o se puede customizar el scheduler por defecto.
En cada pod se dice cual será su scheduler.
apiVersion: v1
kind: Pod
metadata:
name: annotation-default-scheduler
labels:
name: multischeduler-example
spec:
schedulerName: default-scheduler
containers:
- name: pod-with-default-annotation-container
image: registry.k8s.io/pause:2.0
En el scheduler config file se ve el nombre del scheduler
kubectl describe pod -n kube-system kube-scheduler-cp
Name: kube-scheduler-cp
Namespace: kube-system
Se puede ver que scheduler controla un pod en los eventos
kubectl get events --sort-by='.lastTimestamp'
kubectl logs -n kube-system kube-scheduler-cp
Se puede crear perfiles para que algunos pods se creen antes y no esperan en la queue
Se añade en el pod el priorityClassName
1. Petición de creación de un pod
2. Queue
3. Node scoring (decidir en que nodo va un pod). Se elige al nodo con + recursos disponibles
4. Binding. Se une el pod al nodo
Estos pasos se hacen con plugins
1. PrioritySort – peticiçon de creación de pod
2. NodeResources-Fit/NodeName/NodeUnschedulable – queue
3. NodeResources-Fit/imageLocality – scoring
4. defaultBinding - binding
En caso paso hay un extensión Point para customizar
En vez de usar varios scheduler uso 1 scheduler con varios profiles