Prefacio
Este artículo lo llevará a comprender la implementación azul y verde, la versión canary, la actualización continua y otros métodos de publicación en kubernetes. Mis artículos originales tienen mucho contenido y básicamente tienen más de 5,000 palabras. Si no lo termina , primero preste atención a la colección., Lleno de productos secos ~~
Descripción general de los métodos de lanzamiento múltiples de Kubernetes
Introducción de la implementación azul-verde de Kubernetes, versión canary, actualización continua
Versión Canary (también conocida como versión en escala de grises, actualización en escala de grises):
Las versiones Canary generalmente se lanzan primero en 1 máquina, o en un pequeño porcentaje, como el 2% de los servidores, principalmente para la verificación del tráfico, también conocidas como pruebas canarias, que a menudo se denominan pruebas en escala de grises en China. En el pasado, antes de bajar a la mina, se colocaba un canario para detectar si hay gas nocivo en la cueva, para ver si el canario puede sobrevivir, y el canario soltó su nombre. Las pruebas canarias simples generalmente se verifican mediante pruebas manuales, mientras que las pruebas canarias complejas requieren una infraestructura de monitoreo relativamente completa.A través de la retroalimentación del indicador de monitoreo, observe la salud del canario como base para la posterior liberación o reversión. Si pasa la prueba del cable dorado, todas las versiones restantes de V1 se actualizan a las versiones V2. Si la prueba del canario falla, el canario se revierte directamente y la liberación falla.
Actualización continua:
Una mayor optimización y mejora sobre la base del lanzamiento canario es un método de lanzamiento con un mayor grado de automatización y una experiencia de usuario relativamente fluida. Actualmente, es el método de lanzamiento principal adoptado por organizaciones técnicas maduras. Un lanzamiento continuo se compone generalmente de varios lotes de lanzamiento, y la cantidad de cada lote es generalmente configurable (se puede definir mediante la plantilla de lanzamiento). Por ejemplo, el primer lote de 1 (canario), el segundo lote del 10%, el tercer lote del 50% y el cuarto lote del 100%. Hay un intervalo de observación entre cada lote, y la verificación manual o la retroalimentación de monitoreo se utilizan para garantizar que no haya ningún problema antes de enviar el siguiente lote. Por lo tanto, el proceso de liberación progresiva es generalmente más lento (en el que el tiempo del canario es generalmente más largo que el lote posterior Más largo, como 10 minutos para canarios y 2 minutos para intervalos posteriores).
Despliegue azul-verde:
Algunas aplicaciones solo necesitan implementar una nueva versión y deben cambiar a esta versión inmediatamente. Por lo tanto, necesitamos realizar una implementación azul / verde. En una implementación azul / verde, se implementará una nueva copia (verde) de la aplicación junto con la versión existente (azul). Luego actualice la entrada / enrutador de la aplicación para cambiar a la nueva versión (verde). Luego, debe esperar a que la versión anterior (azul) complete todas las solicitudes que se le envían, pero en la mayoría de los casos, el tráfico de la aplicación se cambiará a la nueva versión de una vez; Kubernetes no es compatible con la versión azul / despliegue verde. La mejor manera en la actualidad es crear una nueva implementación y luego actualizar el servicio de la aplicación (como el servicio) para que apunte a la nueva implementación; la implementación azul-verde es mantener la versión anterior, implementar la nueva versión y luego probar, confirmar Bien y gradualmente corte el tráfico a la nueva versión. La implementación azul-verde no requiere tiempo de inactividad y es menos riesgosa.
Definición de implementación
Deployment implementa la lógica de actualización y la estrategia de actualización mediante ReplicaSet. ¿Cuáles son los campos que se pueden definir para un objeto de recurso como Deployment? Puedes visualizarlo con el siguiente comando:
kubectl explicar implementar
La pantalla es la siguiente:
TIPO: Implementación VERSIÓN: extensiones / v1beta1 DESCRIPCIÓN: DESPRECADO - Esta versión grupal de Implementación está obsoleta por apps / v1beta2 / Deployment. Consulte las notas de la versión para obtener más información. La implementación habilita actualizaciones declarativas para Pods y ReplicaSets. # 我们 使用 apps / v1FIELDS: apiVersion <string> APIVersion define el esquema versionado de esta representación de un objeto. Los servidores deben convertir los esquemas reconocidos al último valor interno y pueden rechazar los valores no reconocidos. Más información: https://git.k8s.io/community/contributors/devel/api-conventions.md#resources kind <string> El tipo es un valor de cadena que representa el recurso REST que representa este objeto. Los servidores pueden inferir esto desde el punto final al que el cliente envía las solicitudes. No se puede actualizar. En CamelCase. Más información: https: //git.k8s. io / community / contributors / devel / api-conventions.md # types-types metadata <Objeto> Metadatos de objeto estándar. spec <Objeto> Especificación del comportamiento deseado del Despliegue. status <Objeto> Estado observado más recientemente de la implementación.
kubectl explica deploy.spec
La pantalla es la siguiente:
TIPO: DespliegueVERSIÓN: extensiones / v1beta1RESOURCE: spec <Objeto> DESCRIPCIÓN: Especificación del comportamiento deseado del Despliegue. DeploymentSpec es la especificación del comportamiento deseado de Deployment.FIELDS: minReadySeconds <integer> Número mínimo de segundos durante los cuales un pod recién creado debe estar listo sin que ninguno de sus contenedores se bloquee, para que se considere disponible. El valor predeterminado es 0 (el pod se considerará disponible tan pronto como esté listo) paused <boolean> Indica que la implementación está en pausa y no será procesada por el controlador de implementación. # 暂停 ， 当 我们 更新 的 时候 创建 pod 先 暂停 ， 不是立即 更新 progressDeadlineSeconds <integer> El tiempo máximo en segundos para que una implementación progrese antes de que se considere que ha fallado. El controlador de implementación continuará procesando implementaciones fallidas y aparecerá una condición con un motivo ProgressDeadlineExceeded en el estado de implementación. Tenga en cuenta que el progreso no se estimará durante el tiempo que se pausa una implementación. Esto no está configurado de forma predeterminada. réplicas <integer> Número de pods deseados. Este es un puntero para distinguir entre cero explícito y no especificado. El valor predeterminado es 1. revisionHistoryLimit <integer> El número de ReplicaSets antiguos que se deben retener para permitir la reversión. Este es un puntero para distinguir entre cero explícito y no especificado. # 保留 的 历史 版本 数 ， 默认 是 是 10 个 rollbackTo <Object> DEPRECATED. La configuración a la que está retrocediendo esta implementación. Se borrará una vez realizada la reversión. selector <Objeto> Selector de etiquetas para pods. Los ReplicaSets existentes cuyos pods sean seleccionados por esto serán los afectados por esta implementación. estrategia <Objeto> La estrategia de implementación que se utilizará para reemplazar los pods existentes por otros nuevos. # 更新 策略 ， 支持 的 滚动 更新 策略 template <Objeto> -required- Template describe los pods que se crearán.
kubectl explica deploy.spec.strategy
La pantalla es la siguiente:
TIPO: ImplementaciónVERSIÓN: extensiones / v1beta1RESOURCE: estrategia <Objeto> DESCRIPCIÓN: La estrategia de implementación que se utilizará para reemplazar los pods existentes por nuevos. DeploymentStrategy describe cómo reemplazar los pods existentes por otros nuevos.CAMPOS: rollingUpdate <Objeto> Parámetros de configuración de actualización continua. solo si DeploymentStrategyType = RollingUpdate. type <string> Tipo de implementación. Puede ser "Recrear" o "RollingUpdate". El valor predeterminado es RollingUpdate. # Admite dos tipos de actualizaciones, Recreate y RollingUpdate # Recreate es una actualización de reconstrucción, elimina una actualización y una #RollingUpdate Actualización continua, que define el método de actualización de la actualización continua, es decir, la cantidad de pods puede ser mayor o menor y el grado de actualización está controlado.
kubectl explica deploy.spec.strategy.rollingUpdate
La pantalla es la siguiente:
TIPO: Implementación VERSIÓN: extensiones / v1beta1 RECURSO: rollingUpdate <Objeto> DESCRIPCIÓN: Parámetros de configuración de actualización continua. Presente solo si DeploymentStrategyType = RollingUpdate. Especificación para controlar el comportamiento deseado de la actualización continua. CAMPOS: maxSurge <string> El número máximo de pods que se pueden programar por encima del número deseado de pods. El valor puede ser un número absoluto (p. Ej., 5) o un porcentaje de las vainas deseadas (p. Ej., 10%). No puede ser 0 si MaxUnavailable es 0. El número absoluto se calcula a partir del porcentaje redondeando hacia arriba. De forma predeterminada, se utiliza un valor de 1. Ejemplo: cuando se establece en 30%, el nuevo RC se puede escalar inmediatamente cuando comienza la actualización continua, de modo que el número total de pods antiguos y nuevos no supere el 130% de los pods deseados. Una vez que se hayan matado las vainas viejas,
Demostración de la estrategia de actualización de la aplicación de implementación de implementación
Suponiendo que hay 5 copias, como máximo una no está disponible, significa que hay al menos 4 disponibles, la implementación es una estructura de tres niveles, la implementación controla el conjunto de réplicas, el conjunto de réplicas controla el pod, usa la implementación para crear un pod
cd / root / demo-test
Cree un
archivo deploy-demo.yaml El contenido del archivo de configuración deploy-demo.yaml es el siguiente:
apiVersion: apps / v1kind: Deploymentmetadata: name: myapp-deploy namespace: testspec: réplicas: 3 selector: matchLabels: app: myapp release: canary template: metadata: labels: app: myapp release: canary spec: contenedores: - nombre: myapp imagen: myapp: puertos v1: - nombre: http containerPort: 80
kubectl apply -f deploy-demo.yaml
kubectl get deploy -n prueba
Puede ver que el nombre del controlador creado es myapp-deploy. El
valor esperado del pod es 2, el valor actual es 2, el estado listo es 2 y el disponible es 2.
kubectl get rs -n prueba
La pantalla es la siguiente:
上面表示创建deploy的时候也会创建一个rs（replicaset），7657db6c59这个随机数字是我们引用pod的模板template的名字的hash值
kubectl get pods -n test
显示如下：
deploy在实现中心应用时，可以直接编辑配置文件实现，比方说想要修改副本数，把两个变成3个，打开deploy-demo.yaml，直接修改replicas数量，把2变成3，修改之后保存退出，执行如下
kubectl apply -f deploy-demo.yaml
apply不同于create，apply可以执行多次；create执行一次，再执行就会报错有重复。
kubectl get pods
可以看到pod副本数变成了3个
kubectl describe deploy myapp
查看myapp这个控制器的详细信息
Name: myapp-deployNamespace: defaultCreationTimestamp: Thu, 27 Dec 2018 15:47:48 +0800Labels: <none>Annotations: deployment.kubernetes.io/revision=1 kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"name":"myapp-deploy","namespace":"default"},"spec":{"replicas":3,"selector":{...Selector: app=myapp,release=canaryReplicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailableStrategyType: RollingUpdate#默认的更新策略rollingUpdateMinReadySeconds: 0RollingUpdateStrategy: 25% max unavailable, 25% max surge#最多允许多25%个pod，25%表示不足一个，可以补一个Pod Template: Labels: app=myapp release=canary Containers: myapp: Image: ikubernetes/myapp:v1 Port: 80/TCP Host Port: 0/TCP Environment: <none> Mounts: <none> Volumes: <none>Conditions: Type Status Reason ---- ------ ------ Progressing True NewReplicaSetAvailable Available True MinimumReplicasAvailableOldReplicaSets: <none>NewReplicaSet: myapp-deploy-69b47bc96d (3/3 replicas created)Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ScalingReplicaSet 26m deployment-controller Scaled up replica set myapp-deploy-69b47bc96d to 2 Normal ScalingReplicaSet 4m deployment-controller Scaled up replica set myapp-deploy-69b47bc96d to 3
案例演示
例1：金丝雀发布
打开一个标签监测更新过程
kubectl get pods -l app=myapp -n test -w，（也可以使用kubectl rollout statusdeployment myapp-deploy，显示Waiting for deployment "myapp-deploy"rollout to finish: 1 out of 5 new replicas have been updated），下面命令执行完之后显示如下，之前的pod还在，新创建了一个pod，没有立即删除。
打开另一个标签操作如下：
kubectl set image deployment myapp-deploy myapp:v2 -n test && kubectl rolloutpause deployment myapp-deploy -n test
注：上面的步骤解释说明
把myapp这个容器的镜像更新到myapp:v2版本，更新镜像之后，创建一个新的pod就立即暂停，这就是我们说的金丝雀发布；如果暂停几个
小时之后没有问题，那么取消暂停，就会依次执行后面步骤，把所有pod都升级。（1）解除暂停
打开一个新的标签
kubectl get pods -l app=myapp -n test -w
打开另一个标签
kubectl rollout resume deployment myapp-deploy -n test
在刚才监测的界面可以看到如下一些信息，下面过程是把余下的pod里的容器都更新到新的版本：
myapp-deploy-6bdcd6755d-llrw8 0/1 Pending 0 0smyapp-deploy-6bdcd6755d-llrw8 0/1 ContainerCreating 0 0smyapp-deploy-67f6f6b4dc-7cs8v 0/1 Terminating 0 1hmyapp-deploy-67f6f6b4dc-7cs8v 0/1 Terminating 0 1hmyapp-deploy-67f6f6b4dc-7cs8v 0/1 Terminating 0 1hmyapp-deploy-67f6f6b4dc-7cs8v 0/1 Terminating 0 1hmyapp-deploy-6bdcd6755d-llrw8 1/1 Running 0 16smyapp-deploy-67f6f6b4dc-nhcp2 1/1 Terminating 0 1hmyapp-deploy-6bdcd6755d-r4mrl 0/1 Pending 0 0smyapp-deploy-6bdcd6755d-r4mrl 0/1 Pending 0 1smyapp-deploy-6bdcd6755d-r4mrl 0/1 ContainerCreating 0 1smyapp-deploy-67f6f6b4dc-nhcp2 0/1 Terminating 0 1hmyapp-deploy-67f6f6b4dc-nhcp2 0/1 Terminating 0 1hmyapp-deploy-6bdcd6755d-r4mrl 1/1 Running 0 5smyapp-deploy-67f6f6b4dc-hwx7w 1/1 Terminating 0 1hmyapp-deploy-6bdcd6755d-j8nj8 0/1 Pending 0 0smyapp-deploy-6bdcd6755d-j8nj8 0/1 Pending 0 0smyapp-deploy-6bdcd6755d-j8nj8 0/1 ContainerCreating 0 0smyapp-deploy-67f6f6b4dc-nhcp2 0/1 Terminating 0 1hmyapp-deploy-67f6f6b4dc-nhcp2 0/1 Terminating 0 1hmyapp-deploy-67f6f6b4dc-hwx7w 0/1 Terminating 0 1hmyapp-deploy-6bdcd6755d-j8nj8 1/1 Running 0 4smyapp-deploy-67f6f6b4dc-dbcqh 1/1 Terminating 0 1hmyapp-deploy-6bdcd6755d-lpk5b 0/1 Pending 0 1smyapp-deploy-6bdcd6755d-lpk5b 0/1 Pending 0 1smyapp-deploy-6bdcd6755d-lpk5b 0/1 ContainerCreating 0 1smyapp-deploy-67f6f6b4dc-dbcqh 0/1 Terminating 0 1hmyapp-deploy-6bdcd6755d-lpk5b 1/1 Running 0 4smyapp-deploy-67f6f6b4dc-b4wfc 1/1 Terminating 0 1hmyapp-deploy-67f6f6b4dc-b4wfc 0/1 Terminating 0 1hmyapp-deploy-67f6f6b4dc-hwx7w 0/1 Terminating 0 1hmyapp-deploy-67f6f6b4dc-hwx7w 0/1 Terminating 0 1hmyapp-deploy-67f6f6b4dc-b4wfc 0/1 Terminating 0 1hmyapp-deploy-67f6f6b4dc-b4wfc 0/1 Terminating 0 1hmyapp-deploy-67f6f6b4dc-dbcqh 0/1 Terminating 0 1hmyapp-deploy-67f6f6b4dc-dbcqh 0/1 Terminating 0 1h
kubectl get rs -n test
可以看到replicaset控制器有2个了
（2）回滚
如果发现刚才升级的这个版本有问题可以回滚,查看当前有哪几个版本：
kubectl rollout history deployment myapp-deploy -n test
显示如下：
上面可以看到第一版没了，被还原成了第三版，第三版的前一版是第二版
kubectl get rs -n test -o wide
显示如下：
可以看到上面的rs已经用第一个了，这个就是还原之后的rs
例2：滚动更新
(1) kubectl get pods -l app=myapp -n test -w
在一个窗口监测，打开另外一个窗口按如下操作：
cd /root/demo_test
cat deploy-demo.yaml
把myapp:v1改成myapp:v3
保存退出，执行如下
kubectl apply -f deploy-demo.yaml
再在监测的那个窗口可以看到信息如下：
pending表示正在进行调度，ContainerCreating表示正在创建一个pod，running表示运行一个pod，running起来一个pod之后再Terminating（停掉）一个pod，以此类推，直到所有pod完成滚动升级
在另外一个窗口执行kubectl get rs -n test，显示如下：
上面可以看到rs有两个，上面那个是升级之前的，已经被停掉，但是可以随时回滚，kubectl rollout history deployment myapp-deploy -n test
查看myapp-deploy这个控制器的滚动历史，显示如下：
回滚的话操作如下：
kubectl rollout undo
(2) 扩容到5个
cat deploy-demo.yaml
修改replicas数值是5
kubectl apply -f deploy-demo.yaml
kubectl get pods -n test显示如下：
上面说明扩容成功了
（3）修改maxSurge和maxUnavailable用来控制滚动更新的更新策略
修改更新策略最多不可用0个，也就是少不能少于5个，最大不能超过6个
kubectl patch deployment myapp-deploy -p '{"spec":{"strategy":{"rollingUpdate":{"maxSurge":1,"maxUnavailable":0}}}}' -n test
kubectl describe deployment myapp-deploy -n test
查看myapp-deploy这个控制器的详细信息
上面可以看到RollingUpdateStrategy: 0 max unavailable, 1 max surge
这个rollingUpdate更新策略变成了刚才设定的，因为我们设定的pod副本数是5，0和1表示最少不能少于5个pod，最多不能超过6个pod
这个就是通过控制RollingUpdateStrategy这个字段来设置滚动更新策略的
例3：蓝绿部署
lan.yaml配置文件内容如下：
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-v1
namespace: blue-green
spec:
replicas: 3
selector:
matchLabels:
app: myapp
version: v1
template:
metadata:
labels:
app: myapp
version: v1
spec:
containers:
- name: myapp
image: janakiramm/myapp:v1
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
lv.yaml配置文件内容如下：
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-v2
namespace: blue-green
spec:
replicas: 3
selector:
matchLabels:
app: myapp
version: v2
template:
metadata:
labels:
app: myapp
version: v2
spec:
containers:
- name: myapp
image: janakiramm/myapp:v2
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
service_lanlv.yaml 配置文件内容如下：
apiVersion: v1
kind: Service
metadata:
name: myapp-lan
namespace: blue-green
labels:
app: myapp
version: v1
spec:
type: NodePort
ports:
- port: 80
nodePort: 30062
name: http
selector:
app: myapp
version: v1
cd /root/demo_test/lanlv
kubectl apply -f lan.yaml
kubectl apply -f lv.yaml
kubectl get pods -n blue-green
显示如下：
上面可以看到有两个pod，一个是myapp-v1这个是蓝程序（升级之前的程序），一个是myapp-v2这个是绿程序（升级之后的程序），蓝绿程序一起运行kubectl apply -f service_lanlv.yaml
kubectl get svc -n blue-green
在浏览器访问http://<k8s集群任何一个节点ip>:port 显示如下：
修改service_lanlv.yaml 配置文件，修改标签，让其匹配到绿程序（升级之后的程序）
service_lv.yaml 文件内容如下：
apiVersion: v1
kind: Service
metadata:
name: myapp-lan
namespace: blue-green
labels:
app: myapp
version: v2
spec:
type: NodePort
ports:
- port: 80
nodePort: 30062
name: http
selector:
app: myapp
version: v2
kubectl apply -f service_lv.yaml
kubectl get svc -n blue-green 显示如下：
在浏览器访问http://<k8s集群任何一个节点ip>:port
显示如下：
