google compute engine - pricing - Implementación del Controlador de replicación VS en Kubernetes

kubernetes google cloud tutorial (5)

Quería saber cuál es la diferencia entre un controlador de replicación y una implementación dentro de Kubernetes (1.2). Revisando el documento de inicio ( http://kubernetes.io/docs/hellonode/ ) He creado una implementación, pero no aparece en la interfaz de usuario web.

Cuando creo aplicaciones desde la interfaz de usuario web, se crean como controladores de replicación. Funcionalmente, sin embargo, parecen muy similares (ambos manejan pods y tienen servicios).

Entonces, ¿cuál es la diferencia y cuándo debo usar cada uno?

Ahora, con la versión 1.1, Dashboard admite implementaciones. Puede implementar o actualizar su tablero sin tener que esperar a la versión 1.3 de k8s. Por ejemplo, puede usar el YAML oficial , que acabamos de cambiar para usar Deployments hoy.

En general, recomendaría (y la gente de Google y los contribuyentes de Kubernetes también lo hacen) usar Implementaciones sobre RC ya que son una primitiva mucho más poderosa (incluyen actualizaciones continuas, versiones / auditorías, implementaciones de canaray / verde-azul, retrocesos, etc.) .

Desde mi experiencia, las implementaciones no proporcionan toda la funcionalidad que necesito. O, tal vez, los estoy usando de manera incorrecta.

Cuando es necesario reiniciar el servidor de nodo (todos los pods que se ejecutan en ese servidor iniciado por la implementación) fallan. Y no puedo encontrar una manera de evitar esto.

Pero,

Think Solution es un controlador de replicación. Al menos en la descripción está escrito que maneja tales casos.

La principal ventaja de implementación, según lo veo, es cuando necesita cambiar la versión de su aplicación constantemente.

Entonces, ambas formas son buenas pero por diferentes razones.

El tablero (interfaz de usuario web) se ha rediseñado enormemente para admitir la administración de más recursos (como Deployments y DaemonSets , etc.) y el tablero actual no permite mucho con respecto a las Deployments .

La administración de implementaciones en el panel de control pronto se admitirá en kubernetes 1.3 (consulte el tema Solicitud de funciones : manejar implementaciones ).

Las implementaciones son un concepto más nuevo y de mayor nivel que los Controladores de replicación. Administran la implementación de los Conjuntos de réplica (también un concepto más nuevo, pero bastante equivalente a los Controladores de replicación), y permiten una fácil actualización de un Conjunto de réplica, así como la capacidad de retroceder a una implementación anterior.

Anteriormente, esto tenía que hacerse con la kubectl rolling-update que no era declarativa y no proporcionaba las funciones de reversión.

El panel de control de Kubernetes aún no se ha actualizado para admitir implementaciones, y actualmente solo admite controladores de replicación (consulte Implementaciones no visibles en el panel de control de Kubernetes ).

EDITAR: el panel ahora admite implementaciones.

Deployments todavía están en versión beta (su API está en extensions/v1beta1 ), por lo que probablemente no se muestren en la interfaz de usuario. Automatizan las transiciones de estado además de mantener vivas las cápsulas. Desde la página vinculada:

Una implementación proporciona actualizaciones declarativas para pods y conjuntos de réplica (el controlador de réplica de próxima generación). Solo necesita describir el estado deseado en un objeto de implementación, y el controlador de implementación cambiará el estado real al estado deseado a una velocidad controlada para usted. Puede definir implementaciones para crear nuevos recursos o reemplazar los existentes por otros nuevos.

También proporcionan el historial de implementación y otras características útiles.

$ kubectl rollout history deployment/nginx-deployment deployments "nginx-deployment": REVISION CHANGE-CAUSE 1 kubectl create -f docs/user-guide/nginx-deployment.yaml --record 2 kubectl apply -f docs/user-guide/new-nginx-deployment.yaml 3 kubectl apply -f docs/user-guide/bad-nginx-deployment.yaml

También realiza un seguimiento de los cambios.

$ kubectl rollout history deployment/nginx-deployment --revision=2 deployments "nginx-deployment" revision 2 Labels: app=nginx,pod-template-hash=1564180365 Annotations: kubernetes.io/change-cause=kubectl apply -f docs/user-guide/new-nginx-deployment.yaml Image(s): nginx:1.9.1 No volumes.