Lista de recursos y ciclo de vida del pod
La lista de recursos es equivalente a un script,
- Recursos en K8s
- Lista de recursos
- Explicación de campo común
- Ciclo de vida del contenedor
¿Qué son los recursos?
Todo el contenido de K8s se abstrae como recursos. Una vez que se crean instancias de los recursos, se denominan objetos.
Tipo de recurso
Clasificación de recursos de clúster
- Nivel de espacio de nombres: solo tiene efecto en este nivel de nombre. Por ejemplo, los componentes del sistema de k8s se colocan bajo su propio sistema kube, por lo que cuando ejecutamos el comando kubectl get pod -n default, no podemos ver los componentes del sistema en sí.
- Nivel de clúster: rol (visibilidad y llamada de consulta global) sin importar qué espacio de nombres, puedo verlo en el proceso de consulta global, es decir, no especificamos el clúster cuando lo definimos, y le damos un acceso global Permisos.
- Tipo de metadatos: Proporcionarnos un indicador y operar a través de indicadores.
Nivel de espacio de nombres
- Recursos de carga de trabajo (carga de trabajo): Pod, ReplicaSet, Deployment, StatefulSet, DaemonSet, Job, CronJob (ReplicationController quedó obsoleto en v1.11
- Recursos de equilibrio de carga y descubrimiento de servicios (ServiceDiscoveryLoadBalance): Service, Ingress, ...
- Recursos de configuración y almacenamiento: Volumen (volumen de almacenamiento), CSI (interfaz de almacenamiento de contenedores, que puede expandir varios volúmenes de almacenamiento de terceros)
- Tipos especiales de volúmenes de almacenamiento: ConfigMap (tipo de recurso utilizado cuando se usa el centro de configuración), Secreto (guardar datos confidenciales), DownwardAPI (información de salida en el entorno externo al contenedor)
Pod es el componente más pequeño de K8s. El
tipo de controlador
ReplicaSet es RS (administra la creación de Pod y controla la cantidad de réplicas de pod a través de la selección de etiquetas)
Implementación (controlador, crea Pod controlando RS)
StateFulSet (para resolver el problema de los servicios con estado, Poseer almacenamiento persistente estable e identificación de red estable)
DaemonSet (DaemonSet asegura que todos o algunos nodos ejecuten una copia de un Pod)
Trabajo / CronJob (adecuado para tareas de procesamiento por lotes)
Recursos a nivel de clúster
Espacio de nombres, Nodo, Rol, ClusterRole, RoleBinding, ClusterRoleBinding
Recurso de metadatos
HPA, PodTemplate (plantilla de pod), LimitRange (límite de recursos)
Formato YAML
Significado de la lista de recursos: en k8s, los archivos en formato yaml se utilizan generalmente para crear pods que cumplen con nuestras expectativas. Estos archivos yaml generalmente se denominan listas de recursos.
Yaml es un formato muy legible que se utiliza para expresar secuencias de datos. YAML en realidad significa: sigue siendo un lenguaje de marcado, pero para eliminar este lenguaje, los datos son el centro, no el lenguaje de marcado.
Gramática básica
- La tecla de tabulación no está permitida al sangrar, solo se permiten espacios
- El número de espacios con sangría no es importante, siempre que los elementos del mismo nivel estén alineados a la izquierda
- # El comentario de identificación, desde este carácter hasta el final de la línea, será ignorado por el intérprete
Estructura de datos compatible con YAML
- Objeto: una colección de pares clave-valor, también conocida como mapeo / hash / diccionario
- Matriz: un conjunto de valores dispuestos en orden, también conocido como secuencia / lista
- Escalares: un valor único e indivisible
Tipo de objeto: un conjunto de pares clave-valor del objeto, representado por una estructura de dos puntos
name: Steve
age: 18
Yaml también permite otra forma de escribir todos los pares clave-valor como un objeto en línea
hash: {
name: Steve,age: 18}
Tipo de matriz: un conjunto de líneas al comienzo de la línea de conjunción para formar una matriz
animal
- Cat
- Dog
Las matrices también pueden usar notación en línea
animal: [Cat,Dog]
复合结构：对象和数组可以结合使用，形成复合结构
```bash
languages:
- Ruby
- Perl
- Python
websites:
YAML: yaml.org
Ruby: ruby-lang.org
Python: python.org
Perl: use.perl.org
Escalar: Escalar es el valor más básico e indivisible. Los siguientes tipos de datos son escalares
1 字符串 布尔值 整数 浮点数 Null
2 时间 日期
数值直接以字面量的形式表示
number: 12.30
布尔值用true和false表示
isSet: true
null用 ~ 表示，不写也代表是null
parent: ~
时间采用 ISO8601 格式
iso8601: 2001‐12‐14t21:59:43.10‐05:00
日期采用复合 iso8601 格式的年、月、日表示
date: 1976‐07‐31
YAML 允许使用两个感叹号，强制转换数据类型
e: !!str 123
f: !!str true
Cadena La
cadena no se expresa entre comillas de forma predeterminada
str: 这是一行字符串
Si la cadena contiene espacios o caracteres especiales, debe estar entre comillas
str: '内容： 字符串'
Se pueden utilizar comillas simples y comillas dobles, las comillas dobles no escaparán a los caracteres especiales
s1: '内容\n字符串'
s2: "内容\n字符串"
Si hay una comilla simple en la comilla simple, debe ir acompañada de dos comillas simples consecutivas.
str: 'labor''s day'
输出 labor's day
La cadena se puede escribir en varias líneas, comenzando desde la segunda línea, debe haber una sangría de un solo espacio. Las nuevas líneas se convertirán en espacios
str: 这是一段
多行
字符串
Las cadenas de varias líneas pueden usar | para mantener nuevas líneas o usar> para contraer nuevas líneas
this: |
Foo
Bar
that: >
Foo
Bar
+ Significa mantener la nueva línea al final del bloque de texto, -significa eliminar la nueva línea al final de la cadena. Situación de texto de varias líneas
s1: |
Foo
s2: |+
Foo
s3: |‐
Foo
Explicación de campo común
1. Atributos obligatorios (definir pod, atributos que deben existir al ingresar yaml)
2. Tipo de objeto principal (algunos pueden no estar escritos, hay valores predeterminados)
imagen El nombre de la imagen que se usará para la definición debe ser escrito por usted mismo
3. Elementos de parámetros adicionales
Ayuda: kubectl explica pod
kubectl explica pod.apiVersion
4. Formato de configuración de campo
apiVersion <string> #表示字符串类型
metadata <Object> #表示需要嵌套多层字段
labels <map[string]string> #表示由k:v组成的映射
finalizers <[]string> #表示字串列表
ownerReferences <[]Object> #表示对象列表
hostPID <boolean> #布尔类型
priority <integer> #整型
name <string> -required- #如果类型后面接 -required-，表示为必填字段
kubectl get pod xx.xx.xx -o yaml
<!--使用 -o 参数加 yaml，可以将资源的配置以 yaml的格式输出出来，也可以使用json，输出为json格式-->
Ejemplos de listas de recursos
1. Notas
apiVersion: group/apiversion # 如果没有给定 group 名称，那么默认为 core，可以使用 kubectl
api-versions # 获取当前 k8s 版本上所有的 apiVersion 版本信息( 每个版本可能不同 )
kind: #资源类别
metadata： #资源元数据
name
namespace
lables
annotations # 主要目的是方便用户阅读查找
spec: # 期望的状态（disired state）
status： # 当前状态，本字段有 Kubernetes 自身维护，用户不能去定义
2. ❤ Crear un nuevo pod. Ejemplo
vim pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
version: v1
spec:
containers:
- name: app
image: hub.atguigu.com/library/myapp:v1
Cree un objeto de recurso: kubectl apply -f pod.yaml (cree si la aplicación no está disponible, actualice si la hay)
kubectl get pod
Ver los detalles del objeto de recurso de descripción: kubectl describe pod myapp-pod
Ver el registro del contenedor: kubectl logs myapp-pod -c app
(si un contenedor no necesita especificar -c, si varios contenedores requieren -c)
Eliminar objeto de recurso: kubectl eliminar pod myapp-pod
Crear objeto de recurso: kubectl create -f pod.yaml
Ver objeto de recurso: kubectl get pod -o wide
curl 10.244.2.5/hostname.html
ciclo de vida de la vaina
¿Qué proceso atravesó cuando se creó el pod?
Primero, después de que kubectl envíe instrucciones a la interfaz de kubeapi, kubeapi enviará a Kubelet (este proceso se almacena a través de etcd), Kubelet operará CRI y CRI completará la inicialización del contenedor. Durante el proceso de inicialización, un contenedor de pausa básico (responsable de la red y Volumen de almacenamiento compartido), y luego realice múltiples inicializaciones de init C, ingrese al contenedor principal de Main C para ejecutarlo y ejecute STOP cuando Main C salga y termine todo el ciclo de vida del Pod.
¿Por qué readlines no es el encabezado y el extremo izquierdo? Porque se permite definir el número de segundos después de que el contenedor se ejecuta antes de continuar.
readlines: obtenga el estado de acuerdo con el comando, la conexión TCP y el protocolo HTTP para determinar si el servicio está disponible. Si está disponible, cambie el estado de ejecución a En ejecución, que puede exponerse para proporcionar acceso a Internet
Liveness: acompañará a todo el ciclo de vida del contenedor principal Main C. Cuando el proceso en el contenedor principal es inconsistente con la detección de Liveness, el contenedor principal tiene un problema y no puede proporcionar acceso a la red externa normalmente, y luego ejecuta el comando reiniciar o eliminar.
initC
El pod puede tener varios contenedores, la aplicación se ejecuta en el contenedor, pero también puede tener uno o más contenedores Init que comienzan antes del contenedor de la aplicación.
Los contenedores Init son muy similares a los contenedores ordinarios, excepto por los dos puntos siguientes:
- El contenedor de inicio siempre se ejecuta hasta que se completa correctamente
- Cada contenedor de inicio debe completarse correctamente antes de que comience el siguiente contenedor de inicio
Si el contenedor de inicio del pod falla, Kubernetes continuará reiniciando el pod hasta que el contenedor de inicio tenga éxito. Sin embargo, si la política de reinicio correspondiente al Pod es Nunca, no se reiniciará
Debido a que el contenedor Init tiene una imagen separada del contenedor de la aplicación, su código relacionado con el inicio tiene las siguientes ventajas:
- Pueden contener y ejecutar utilidades, pero por razones de seguridad, no se recomienda incluir estas utilidades en la imagen del contenedor de la aplicación. Por lo tanto , se pueden crear con anticipación durante la inicialización de Init C , y es posible que Main C no incluya estos archivos. , Y puede ser referenciado por init C
- Pueden incluir herramientas y código personalizado para instalar, pero no pueden aparecer en la imagen de la aplicación. Por ejemplo, para crear una imagen, no es necesario DESDE otra imagen, solo necesita usar herramientas como sed, awk, python o excavar durante el proceso de instalación.
- La duplicación de aplicaciones puede separar las funciones de creación e implementación, y no es necesario combinarlas para crear una única duplicación.
- El contenedor Init usa LinuxNamespace, por lo que tiene una vista del sistema de archivos diferente en comparación con el contenedor de la aplicación. Por lo tanto, pueden tener acceso a Secret, mientras que los contenedores de aplicaciones no.
- Deben ejecutarse hasta su finalización antes de que se inicie el contenedor de la aplicación, y los contenedores de la aplicación se ejecutan en paralelo, por lo que el contenedor Init puede proporcionar una forma sencilla de bloquear o retrasar el inicio del contenedor de la aplicación hasta que se cumplan una serie de requisitos previos.
init C también se puede usar para detectar si mysql es normal, si es normal, salga del contenedor init e inicie Apache.
Pero debido a que Apache + PHP se inicia un poco más rápido, el inicio retrasado de mysql hace que todo el pod se reinicie continuamente.
(Para servicios con fuertes dependencias)
instancia de contenedor init
plantilla de inicio
1、docker pull busybox # 在node01、02运行
2、vim init-pod.yaml # 在master编辑
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec: # 详细描述信息
containers:
- name: myapp-container # 运行一个pod，pod里有一个容器叫myapp-container
image: busybox # myapp-container使用了busybox镜像，它是封装了很多小工具的一个镜像
command: ['sh','-c','echo The app is running! && sleep 3600'] # 输出一句话之后，容器在6分钟内不会退出
initContainers: # 定义了一组初始化容器initC，有两个init容器
- name: init-myservice
image: busybox
command: ['sh','-c','until nslookup myservice; do echo waiting for myservice; sleep 2;done;'] # nslookup解析成功则退出，不成功输出一段话休眠2秒再第二次循环
- name: init-mydb
image: busybox
command: ['sh','-c','until nslookup mydb; do echo waiting for mydb; sleep 2; done;'] # nslookup mydb的svc
①vim init-pod.yaml
②kubectl eliminar implementación
--todos los kubectl eliminar pod
--todos los ③kubectl create -f init-pod.yaml está
en init: 0/2, compruebe por qué
kubectl describe pod myapp-pod
kubectl logs myapp-pod -c init -myservice Mira el registro del proceso de inicialización y el
análisis no es exitoso
Crear svc
3、service可以简称svc，一旦有svc,那么k8s集群内部的dns就会把svc解析为ip
创建service,
（1）vim myservice.yaml
kind: Service
apiVersion: v1
metadata:
name: myservice
spec: # 详细描述信息
ports:
- protocol: TCP
port: 80
targetPort: 9376
（2）vim mydb.yaml
kind: Service
apiVersion: v1
metadata:
name: mydb
spec:
ports:
- protocol: TCP
port: 80
targetPort: 9377
kubectl create -f myservice.yaml
kubectl create -f mydb.yaml
kubectl get pod
kubectl get svc
kubectl descirbe pod myapp-pod
Una vez creado el svc de myservice, el dns del sistema kube del clúster local lo resolverá en ip
——————————————————————————————————
Suplemento: si elimina delete pod --todo directamente, continuará reconstruyéndose de acuerdo con el mecanismo de implementación,
por lo que primero debe eliminar la implementación
kubectl delete deployment
--all kubectl delete pod --all
————————————— ——————————————————————
init instrucciones especiales
- Durante el proceso de inicio del Pod, el contenedor Init se iniciará secuencialmente después de que se inicialicen la red y los volúmenes de datos. Cada contenedor debe salir correctamente antes de que se inicie el siguiente (la red y la inicialización del volumen de datos se realiza en Pausa)
- Si sale debido a un tiempo de ejecución o una falla, el contenedor no se iniciará y volverá a intentarlo de acuerdo con la política especificada por la política de reinicio del pod. Sin embargo, si la política de reinicio del pod se establece en Siempre, la política de reinicio se usará cuando el contenedor de inicio falle.
- Antes de que todos los contenedores de inicialización fracasen, el pod no estará listo. Los puertos del contenedor Init no se agregarán en el Servicio. El pod que se está inicializando está en estado pendiente, pero el estado de inicialización debe establecerse en verdadero
- Si el pod se reinicia, todos los contenedores de inicio deben ejecutarse nuevamente
- # Las modificaciones a la especificación del contenedor de inicio están restringidas al campo de imagen del contenedor, y las modificaciones a otros campos no tendrán efecto. Cambiar el campo de imagen del contenedor Init equivale a reiniciar el Pod.
kubectl edit pod myapp-pod - El contenedor Init tiene todos los campos del contenedor de la aplicación. Excepto por readinessProbe (detección de preparación), porque el contenedor de inicialización no puede definir estados distintos de preparación además de finalización. Esto se hará cumplir durante el proceso de verificación.
- El nombre de cada aplicación y contenedor de inicio en el pod debe ser único; compartir el mismo nombre con cualquier otro contenedor arrojará un error durante la verificación
Investigacion
La sonda no la inicia el servidor principal, sino que la realiza el kubelet donde se encuentra cada nodo, en este caso la presión sobre la programación principal será menor.
Las sondas son diagnósticos periódicos realizados por kubelet en el contenedor. Para realizar el diagnóstico, kubelet llama al Handler implementado por el contenedor. Hay tres tipos de manipuladores:
ExecAction：在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功。
TCPSocketAction：对指定端口上的容器的IP地址进行TCP检查。如果端口打开，则诊断被认为是成功的。
HTTPGetAction：对指定的端口和路径上的容器的IP地址执行HTTPGet请求。如果响应的状态码大于等于200且小于400，则诊断被认为是成功的
Cada sonda obtendrá uno de los siguientes tres resultados:
成功：容器通过了诊断。
失败：容器未通过诊断。
未知：诊断失败，因此不会采取任何行动
Método de detección
-
livenessProbe: indica si el contenedor se está ejecutando. Si la detección de supervivencia falla, el kubelet matará el contenedor y el contenedor se verá afectado por su estrategia de reinicio. Si el contenedor no proporciona una sonda de supervivencia, el estado predeterminado es Éxito (siempre existirá con el ciclo de vida del contenedor)
(la vida seguirá el ciclo de vida de todo el contenedor y la vida comenzará hasta el final del pod) -
readinessProbe: indica si el contenedor está listo para atender la solicitud. Si la detección de preparación falla, el controlador del punto final borrará la dirección IP del Pod de todos los puntos finales del Servicio que coincidan con el Pod. El estado listo antes de la demora inicial tiene como valor predeterminado Fallo. Si el contenedor no proporciona una sonda lista, el estado predeterminado es Éxito
(después de que la verificación de preparación sea exitosa, Main C puede anunciar el acceso externo)
detección de vainas
Prueba Prueba de sonda lista
redinessProbe-httpget
read.yaml
apiVersion: v1
kind: Pod
metadata:
name: readiness-httpget-pod
namespace: default
spec:
containers:
- name: readiness-httpget-container
image: hub.atguigu.com/library/myapp:v1
imagePullPolicy: IfNotPresent # 如果有就不下载
readinessProbe: # 就绪检测方案
httpGet:
port: 80
path: /index1.html
initialDelaySeconds: 1
periodSeconds: 3
kubectl create -f read.yaml
kubectl get pod
puede encontrar que STATUS se está ejecutando, pero no está listo
kubectl describe pod readiness-httpget-pod, y encontró que 404 falló porque no hay index1.html definido arriba para
kubectl exec readiness-httpget-pod -it -- /bin/bash
ingresar al contenedor de pod, si solo hay uno Contenedor, no es necesario especificar el nombre del contenedor, si hay más de uno, se requiere -c containerName. -significa interacción abierta, - / bin / sh es un formato fijo
Sonda de detección Detección de supervivencia
livenessProbe-exec
apiVersion: v1
kind: Pod
metadata:
name: liveness-exec-pod
namespace: default
spec:
containers:
- name: liveness-exec-container
image: busybox
imagePullPolicy: IfNotPresent # 如果有就不下载。即使默认为lastest，也不会从远程下载
command: ["/bin/sh","-c","touch /tmp/live ; sleep 60; rm -rf /tmp/live;sleep 3600"]
livenessProbe:
exec:
command: ["test","-e","/tmp/live"] # 检测文件是否存在，如果存在返回0
initialDelaySeconds: 1 # 延时1秒，容器启动1秒以后才开始liveness
periodSeconds: 3 # 重试循环时间3秒
kubectl get pod -w
creará / tmp / live cuando se inicie el contenedor y el archivo exista hace 60 segundos. Después de 60 segundos, el archivo ya no existe.
Entonces la prueba no puede detectarlo, por lo que el contenedor se mata. Luego, el contenedor correspondiente a la cápsula muere, la cápsula se reiniciará y todo el proceso se reanudará.
kubectl delete pod --todos
livenessProbe-httpget
vim live-http.yaml
apiVersion: v1
kind: Pod
metadata:
name: liveness-httpget-pod
namespace: default
spec:
containers:
- name: liveness-httpget-container
image: hub.atguigu.com/library/myapp:v1
imagePullPolicy: IfNotPresent # 如果有就不下载。即使默认为lastest，也不会从远程下载
ports:
- name: http
containerPort: 80
livenessProbe:
httpGet:
port: http
path: /index.html # 测试文件是否能正常访问
initialDelaySeconds: 1 # 延时1秒，容器启动1秒以后才开始liveness
periodSeconds: 3 # 重试循环时间3秒
timeoutSeconds: 10 # 最大超时10秒，超出这个时间代表失败
Ingrese al contenedor para matar el archivo, pruebe la situación, busque 404 y luego reinicie la cantidad de veces que es 2.
La sonda detecta una anomalía y la ejecución de la actividad no se realiza correctamente. El contenedor se cerrará y el pod se reiniciará (porque la estrategia de reinicio predeterminada es siempre)
livenessProbe-httpget
vim live-probe.yaml
apiVersion: v1
kind: Pod
metadata:
name: probe-tcp
spec:
containers:
- name: liveness-httpget-container
image: hub.atguigu.com/library/myapp:v1
livenessProbe:
initialDelaySeconds: 5 # 延时5秒，容器启动1秒以后才开始liveness
timeoutSeconds: 1 # 最大超时1秒，超出这个时间代表失败
tcpSocket:
port: 8080 #因为80是nginx端口，8080端口没搭理，超时1秒表示检测失败
periodSeconds: 3
Supervivencia y preparación integral
vim live-http.yaml
apiVersion: v1
kind: Pod
metadata:
name: liveness-httpget-pod
spec:
containers:
- name: liveness-httpget-container
image: hub.atguigu.com/library/myapp:v1
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
readinessProbe: # 就绪检测方案
httpGet:
port: 80
path: /index1.html
initialDelaySeconds: 1
periodSeconds: 3
livenessProbe: # 存活检测
httpGet:
port: http
path: /index.html # 测试文件是否能正常访问
initialDelaySeconds: 1 # 延时1秒，容器启动1秒以后才开始liveness
periodSeconds: 3 # 重试循环时间3秒
timeoutSeconds: 10 # 最大超时10秒，超出这个时间代表失败
kubectl apply -f live-http.yaml
Se
puede encontrar que kubectl get pod se está ejecutando, pero no está listo.
kubectl exec liveness-httpget-pod -it- / bin / sh
crea index1.html y sale.
kubectl get pod comprueba que está listo
kubectl exec liveness-httpget-pod -it - rm -rf /usr/share/nginx/html/index.html
Debido a que se requiere la existencia de index.html en la prueba de supervivencia, la detección de la sonda es anormal y la ejecución de liveness falla, el contenedor se cerrará , Y luego el pod se reinicia (porque la estrategia de reinicio predeterminada es siempre)
después de reiniciar, la verificación de preparación también se ejecutará nuevamente, index1.html no existe, por lo que listo es 0/1
INICIO y PARO
Iniciar y salir de acciones. Si es una base de datos, se puede hacer una copia de seguridad al salir y guardarla en una ruta determinada.
post.yam
apiVersion: v1
kind: Pod
metadata:
name: lifecycle-demo
spec:
containers:
- name: lifecycle-demo-container
image: hub.atguigu.com/library/myapp:v1
lifecycle:
postStart:
exec:
command: ["/bin/sh", "-c", "echo Hello from the postStart handler >/usr/share/message"]
preStop:
exec:
command: ["/bin/sh", "-c", "echo Hello from the poststop handler >/usr/share/message"]
kubectl exec lifecycle-demo -it - / bin / sh
Podhase
El campo de estado de un Pod es un objeto PodStatus y hay un campo de fase en PodStatus.
La fase de un Pod es una descripción macro simple del Pod en su ciclo de vida. Esta etapa no es un resumen completo de contenedores o pods, ni pretende ser una máquina de estado completa
. El número y el significado de las fases de pod se especifican estrictamente. Además de los estados enumerados en este documento, no se debe asumir que Pod tiene otros valores de fase
Valores posibles de podphase
- Pendiente: el sistema de Kubernetes aceptó el pod, pero aún no se han creado una o más imágenes de contenedor. El tiempo de espera incluye el tiempo para programar el Pod y el tiempo para descargar el espejo a través de la red, lo que puede llevar algún tiempo.
- En ejecución: el pod se ha vinculado a un nodo y se han creado todos los contenedores en el pod. Al menos un contenedor se está ejecutando, o se está iniciando o reiniciando
- Correcto: todos los contenedores del pod se han terminado correctamente y no se reiniciarán
- Fallido: todos los contenedores del Pod se terminaron y al menos un contenedor se terminó debido a una falla. En otras palabras, el contenedor sale con un estado distinto de cero o es terminado por el sistema
- Desconocido: el estado del pod no se puede obtener por algunas razones, generalmente porque falla la comunicación con el host donde se encuentra el pod
Sugerencias:
kubectl eliminar implementación --todos eliminar todas las implementaciones
kubectl eliminar pod --todos eliminar todas las
versiones del pod , es mejor no usar la última; porque la versión actual es diferente de la última versión en el futuro