La API de Kubernetes va cambiando la versión de los diferentes recursos conforme van madurando y pasando de alphas a betas y de estas a estables, o reorganizándolos en diferentes puntos de entrada. Estos cambios no son de una versión para otra, sino que se anuncian al menos con 3 versiones de antelación en el caso de las beta y se marca una versión de obsolescencia para esos recursos o el cambio en el punto de entrada a la API de los mismos.
¿Qué recursos cambian en el API en Kubernetes v1.16?
Los recursos que cambian de punto de entrada de la API de esta nueva versión son los siguientes:
El cambio más visible de cada uno de ellos es el punto del API al que se interroga para acceder a estos recursos. ¿En la práctica qué significa? Pues que en el fichero de yaml de configuración de cada uno de estos recursos, en la línea de donde se define el campo "apiVersion" habrá que poner el nuevo punto de acceso al API. Concretamente:
- Todos los recursos que se sirvan desde "apps/v1beta1" y "apps/v1beta2" pasarán a servirse desde "apps/v1"
- NetworkPolicy pasa de estar en "extensions/v1beta1" a "networking.k8s.io/v1"
- podsecuritypolicies pasa de "extensions/v1beta1" a "policy/v1beta1"
Por ejemplo, un yaml de un deployment en la v1.14 podría tener la siguiente pinta:
apiVersion: apps/v1beta2
kind: Deployment
metadata:
name: ejemplo-nginx
labels:
app: nginx
spec:
replicas: 5
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
Como veis, en este ejemplo el campo apiVersion tiene valor "apps/v1beta2". Este valor ya se anunció en las notas de versión de v1.14 y v1.15 que en esta versión v1.16 iba a dejar de servirse en ese punto de la API y se debían cambiar por "apps/v1".
Estos cambios de la API en versión beta a versión estable en algunas ocasiones pueden suponer cambios también en la estructura de los ficheros. Campos que cambian de nombre, que desaparecen, que aparecen... Para cada uno de ellos deberemos consultar la documentación correspondiente.
¿Qué tengo que hacer para asegurarme de que todo seguirá funcionando?
Aunque a alguno se le puede pasar por la cabeza quedarse como está, no actualizar a Kubernetes v1.16 no es una opción. Así que (además de otras acciones que deben tenerse en cuenta), habrá que cambiar al menos el campo apiVersion de todos los recursos que estén aún utilizando puntos de entrada al API antiguos.Esto puede ser suficiente en el caso de ingress. Pero en el caso de los deployments, donde hay algunos campos que cambian, en el blog de Kubernetes recomiendan utilizar el comando kubectl convert. Un ejemplo de como convertir un deployment de app/v1beta2 a app/v1:
kubectl convert -f ./fichero-a-convertir.yaml --output-version apps/v1
Es posible que no tengáis muchos ficheros que cambiar, ya que como he comentado antes este es un cambio que se anunció en v1.14 y v.1.5, pero si no lo hacéis corréis el riesgo de que los recursos configurados en ellos dejen de funcionar.
En el caso de que no podáis cambiarlos, no estéis seguros de que están todos cambiados o simplemente, por requerimientos del sistema debáis mantener estos puntos de entrada en el API durante un tiempo, existe la opción de re-activarlos temporalmente (hasta la v1.18) mediante los siguientes flags en la opción --runtime-config del API Server:
Podéis encontrar más detalles en:
Es posible que no tengáis muchos ficheros que cambiar, ya que como he comentado antes este es un cambio que se anunció en v1.14 y v.1.5, pero si no lo hacéis corréis el riesgo de que los recursos configurados en ellos dejen de funcionar.
En el caso de que no podáis cambiarlos, no estéis seguros de que están todos cambiados o simplemente, por requerimientos del sistema debáis mantener estos puntos de entrada en el API durante un tiempo, existe la opción de re-activarlos temporalmente (hasta la v1.18) mediante los siguientes flags en la opción --runtime-config del API Server:
- apps/v1beta1=true
- apps/v1beta2=true
- extensions/v1beta1/daemonsets=true,extensions/v1beta1/deployments=true,extensions/v1beta1/replicasets=true,extensions/v1beta1/networkpolicies=true,extensions/v1beta1/podsecuritypolicies=true
¿Cómo puedo probar la nueva versión del API de Kubernetes v1.16?
Como publicaron en el foro de Kubernetes, hay una versión de MicroK8s con v1.16-beta1. Esto os puede permitir probar configuraciones y despliegues para ver si todo sigue funcionando antes de mandarlo a producción.
Para instalarlo desde cero:
snap install microk8s --classic --channel 1.16/beta
O si tenéis ya una instalación de MicroK8s, podéis actualizar la versión:
snap refresh microk8s --channel 1.16/beta
No hay comentarios:
Publicar un comentario