kubernetes - paso - ¿Cuál es la diferencia entre un pod y un despliegue?

kubernetes vs docker

Question

He estado creando pods con type:deployment pero veo que cierta documentación usa type:pod , más específicamente la documentación para pods de contenedores múltiples :

apiVersion: v1
kind: Pod
metadata:
  name: ""
  labels:
    name: ""
  namespace: ""
  annotations: []
  generateName: ""
spec:
  ? "// See ''The spec schema'' for details."
  : ~

Pero para crear pods solo puedo usar un tipo de implementación :

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: ""
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: ""
    spec:
      containers:
        etc

Noté que la documentación del pod dice:

El comando crear se puede usar para crear un pod directamente, o puede crear un pod o pods a través de una implementación. Se recomienda encarecidamente que utilice una implementación para crear sus pods. Vigila las vainas fallidas y pondrá en marcha nuevas vainas según sea necesario para mantener el número especificado. Si no desea que una Implementación monitoree su pod (por ejemplo, su pod está escribiendo datos no persistentes que no sobrevivirán a un reinicio, o su pod está destinado a ser muy breve), puede crear un pod directamente con El comando Crear.

Nota: Recomendamos usar una Implementación para crear pods. Debe usar las instrucciones a continuación solo si no desea crear una Implementación.

Pero esto plantea la pregunta de qué kind:pod es buena? ¿Puede de alguna manera hacer referencia a pods en una implementación? No vi un camino. Parece que lo que obtienes con los pods son algunos metadatos adicionales, pero ninguna de las opciones de implementación, como una replica o una política de reinicio. ¿De qué sirve un pod que no conserva datos, sobrevive a un reinicio? Creo que también podría crear un pod de contenedores múltiples con una implementación.

Answer 1

En kubernetes, las vainas son las unidades desplegables más pequeñas. Cada vez que creamos un objeto kubernetes como Deployments, replica-sets, statefulsets, daemonsets, crea pod.

Como se mencionó anteriormente, las implementaciones crean módulos basados ​​en el estado deseado mencionado en su objeto de implementación. Entonces, por ejemplo, si desea 5 réplicas de una aplicación, mencionó replicas: 5 en su manifiesto de implementación. Ahora el controlador de implementación es responsable de crear 5 réplicas idénticas (no menos, no más) de la aplicación dada con todos los metadatos como la política RBAC, la política de redes, etiquetas, anotaciones, verificación de estado, cuotas de recursos, contaminación / tolerancias y otros y asociarse con cada pod crea.

Hay algunos casos en los que desea crear un pod, por ejemplo, si está ejecutando un sidecar de prueba en el que no necesita ejecutar la aplicación para siempre, no necesita múltiples réplicas y ejecuta la aplicación cuando desea ejecutar en ese La vaina de la caja es adecuada. Por ejemplo, helm test , que es una definición de pod que especifica un contenedor con un comando dado para ejecutar.

Answer 2

Intente evitar Pods e implemente Implementaciones para administrar contenedores, ya que los objetos de tipo Pod no se reprogramarán (ni se auto curarán) en caso de falla de un nodo o terminación del pod.

Una implementación es generalmente preferible porque define un ReplicaSet para asegurar que el número deseado de Pods esté siempre disponible y especifica una estrategia para reemplazar Pods, como RollingUpdate.

Answer 3

Kubernetes tiene tres tipos de objetos que debes conocer:

• Pods : ejecuta uno o más contenedores estrechamente relacionados
• Servicios : configura redes en un clúster de Kubernetes
• Implementación : mantiene un conjunto de pods idénticos, asegurando que tengan la configuración correcta y que exista el número correcto de ellos.

Vainas:

• Ejecuta un único conjunto de contenedores.
• Bueno para propósitos de desarrollo únicos
• Raramente usado directamente en producción

Despliegue:

• Ejecuta un conjunto de pods idénticos
• Monitorea el estado de cada pod, actualizando según sea necesario
• Bueno para dev
• Bueno para la producción

Y estaría de acuerdo con otras respuestas, olvidarme de Pods y simplemente usar Deployment. ¿Por qué? Mire la segunda viñeta, monitorea el estado de cada pod, actualizando según sea necesario.

Entonces, en lugar de luchar con mensajes de error como este:

Prohibido: las actualizaciones de pod no pueden cambiar los campos que no sean spec.containers[*].image de spec.containers[*].image

Así que simplemente refactorice o vuelva a crear completamente su Pod en una implementación que cree un pod para hacer lo que necesita hacer. Con la implementación, puede cambiar cualquier configuración que desee y no necesita preocuparse por ver ese mensaje de error.

Answer 4

La respuesta de Radek es muy buena, pero me gustaría comentar desde mi experiencia, casi nunca usarás un objeto con el pod amable , porque eso no tiene ningún sentido en la práctica.

Debido a que necesita un objeto de implementación , u otros objetos de la API de Kubernetes, como un controlador de replicación o un conjunto de réplicas , que necesita mantener vivas las réplicas (pods) (ese es el punto de usar kubernetes).

Lo que usará en la práctica para una aplicación típica son:

1. Objeto de implementación (donde especificará el contenedor / contenedores de sus aplicaciones) que alojará el contenedor de su aplicación con algunas otras especificaciones.

2. Objeto de servicio (que es como un objeto de agrupación y le da una llamada IP virtual (IP de clúster) para los pods que tienen una etiqueta determinada, y esos pods son básicamente los contenedores de aplicaciones que implementó con el objeto de implementación anterior).

Debe tener el objeto de servicio porque los pods del objeto de implementación se pueden eliminar, escalar hacia arriba y hacia abajo, y no puede confiar en sus direcciones IP porque no serán persistentes.

Por lo tanto, necesita un objeto como un servicio , que le dé a esos pods una IP estable.

Solo quería darle algo de contexto en torno a los pods , para que sepa cómo funcionan las cosas juntas.

Espero que te aclare algunas cosas, no hace mucho tiempo que estaba en tus zapatos :)

Answer 5

Pod es una colección de contenedores y objeto básico de Kuberntes. Todos los contenedores de pod se encuentran en el mismo nodo.

• No apto para producción.
• Sin actualizaciones continuas

La implementación es un tipo de controlador en Kubernetes.

Controllers use a Pod Template that you provide to create the Pods for which it is responsible.

La implementación crea un ReplicaSet que, a su vez, se asegura de que las Réplicas deseadas sean siempre las mismas que las Réplicas actuales.

Ventajas:

• Puede implementar y deshacer sus cambios utilizando la implementación
• Monitorea el estado de cada pod
• El más adecuado para la producción.
• Admite actualizaciones continuas

Answer 6

Tanto Pod como Deployment son objetos completos en la API de Kubernetes. La implementación gestiona la creación de Pods mediante ReplicaSets. Todo se reduce a que la implementación creará Pods con especificaciones tomadas de la plantilla. Es poco probable que alguna vez necesite crear Pods directamente para un caso de uso de producción.

Answer 7

Pod es instancia de contenedor.

Ese es el resultado de las replicas: 3

Piense en una deployment puede tener muchas instancias en ejecución (réplica).

//deployment.yaml
apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: tomcat-deployment222
spec:
  selector:
    matchLabels:
      app: tomcat
  replicas: 3
  template:
    metadata:
      labels:
        app: tomcat
    spec:
      containers:
      - name: tomcat
        image: tomcat:9.0
        ports:
        - containerPort: 8080