Versiones

• 1: Kubernetes 1.36
• 2: Kubernetes 1.35
• 3: Kubernetes 1.34
• 4: Kubernetes 1.33
• 5: Kubernetes 1.32
• 6: Kubernetes 1.31
• 7: Kubernetes 1.30
• 8: Kubernetes 1.29
• 9: Kubernetes 1.28
• 10: Kubernetes 1.27
• 11: Kubernetes 1.26
• 12: Kubernetes 1.25
• 13: Kubernetes 1.24
• 14: Kubernetes 1.23
• 15: Kubernetes 1.22
• 16: Kubernetes 1.21
• 17: Kubernetes 1.20
• 18: Kubernetes 1.19
• 19: Kubernetes 1.18
• 20: Kubernetes 1.17
• 21: Kubernetes 1.16
• 22: Kubernetes 1.15
• 23: Kubernetes 1.14
• 24: Kubernetes 1.13
• 25: Kubernetes 1.12
• 26: Kubernetes 1.11
• 27: Kubernetes 1.10
• 28: Kubernetes 1.9
• 29: Kubernetes 1.8
• 30: Kubernetes 1.7
• 31: Kubernetes 1.6
• 32: Kubernetes 1.5
• 33: Kubernetes 1.4
• 34: Kubernetes 1.3
• 35: Kubernetes 1.2
• 36: Ciclo de lanzamientos de Kubernetes
• 37: Descargar Kubernetes
• 38: Lanzamientos de parches (Patch Releases)
• 39: Notas
• 40: Política de desfase de versiones (Version Skew Policy)
• 41: Release Managers

1 - Kubernetes 1.36

2 - Kubernetes 1.35

3 - Kubernetes 1.34

4 - Kubernetes 1.33

5 - Kubernetes 1.32

6 - Kubernetes 1.31

7 - Kubernetes 1.30

8 - Kubernetes 1.29

9 - Kubernetes 1.28

10 - Kubernetes 1.27

11 - Kubernetes 1.26

12 - Kubernetes 1.25

13 - Kubernetes 1.24

14 - Kubernetes 1.23

15 - Kubernetes 1.22

16 - Kubernetes 1.21

17 - Kubernetes 1.20

18 - Kubernetes 1.19

19 - Kubernetes 1.18

20 - Kubernetes 1.17

21 - Kubernetes 1.16

22 - Kubernetes 1.15

23 - Kubernetes 1.14

24 - Kubernetes 1.13

25 - Kubernetes 1.12

26 - Kubernetes 1.11

27 - Kubernetes 1.10

28 - Kubernetes 1.9

29 - Kubernetes 1.8

30 - Kubernetes 1.7

31 - Kubernetes 1.6

32 - Kubernetes 1.5

33 - Kubernetes 1.4

34 - Kubernetes 1.3

35 - Kubernetes 1.2

36 - Ciclo de lanzamientos de Kubernetes

Orientación de mejoras, Issues y PRs hacia los hitos de lanzamiento (Release Milestones)

Este documento está enfocado en los desarrolladores y colaboradores de Kubernetes que necesitan crear una mejora (enhancement), un issue o una solicitud de extracción (pull request o PR) que esté orientada a un hito de lanzamiento (release milestone) específico.

• TL;DR
  • Desarrollo Normal (Semanas 1-11)
  • Congelación de Código - Code Freeze (Semanas 12-14)
  • Post-Lanzamiento (Semanas 14+)
• Definiciones
• El ciclo de lanzamiento
• Eliminación de elementos del hito
• Añadir un elemento al hito
  • Mantenedores del Hito (Milestone Maintainers)
  • Adiciones de características
  • Adiciones de issues
  • Adiciones de PRs
• Otras etiquetas obligatorias
  • Etiqueta del SIG propietario
  • Etiqueta de prioridad
  • Etiqueta de tipo de Issue/PR (Kind Label)

El proceso para guiar las mejoras, issues y pull requests dentro de un lanzamiento de Kubernetes abarca a múltiples partes interesadas:

• el propietario o propietarios de la mejora, issue o pull request
• el liderazgo del SIG
• el Release Team

La información sobre los flujos de trabajo y las interacciones se describe a continuación.

Como propietario de una mejora, issue o pull request (PR), es tu responsabilidad asegurarse de que se cumplan los requisitos del hito de lanzamiento. La automatización y el Release Team se pondrán en contacto contigo si se requieren actualizaciones, pero la inacción puede dar lugar a que tu trabajo sea eliminado del hito. Existen requisitos adicionales cuando el hito de destino es un lanzamiento anterior (consulta el proceso de cherry pick para más información).

TL;DR

Si quieres que tu PR se fusione, necesita las siguientes etiquetas e hitos obligatorios, representados aquí por los comandos de Prow que se necesitarían para añadirlos:

Desarrollo Normal (Semanas 1-11)

• /sig {nombre}
• /kind {tipo}
• /lgtm
• /approved

Code Freeze (Semanas 12-14)

• /milestone {v1.y}
• /sig {nombre}
• /kind {bug, failing-test}
• /lgtm
• /approved

Post-Lanzamiento (Semanas 14+)

Regresar a los requisitos de la fase de 'Desarrollo Normal':

• /sig {nombre}
• /kind {tipo}
• /lgtm
• /approved

Las fusiones en la rama 1.y se realizan ahora a través de cherry picks, aprobados por los Release Managers.

En el pasado, existía el requisito de que una pull request orientada a un hito tuviera un issue de GitHub asociado abierto, pero este ya no es el caso. Las características o mejoras son efectivamente issues de GitHub o KEPs que conducen a PRs posteriores.

El proceso general de etiquetado debe ser consistente en todos los tipos de artefactos.

Definiciones

• propietarios del issue: Creador, asignados y el usuario que movió el issue a un hito de lanzamiento.

• Release Team: Cada lanzamiento de Kubernetes cuenta con un equipo que realiza las tareas de gestión de proyectos descritas aquí. La información de contacto del equipo asociado a cualquier lanzamiento dado se puede encontrar aquí.

• Días Y: Se refiere a días hábiles o comerciales.

• mejora (enhancement): consulta "¿Es mi propuesta una mejora?"

• Enhancements Freeze: la fecha límite en la que los KEPs deben completarse para que las mejoras formen parte del lanzamiento actual.

• Exception Request: El proceso de solicitar una extensión de la fecha límite para una mejora en particular.

• Code Freeze: El periodo de aproximadamente 4 semanas antes de la fecha de lanzamiento final, durante el cual solo se fusionan correcciones de errores (bugs) críticos en el código base del lanzamiento.

• Pruning (Poda): El proceso de eliminar una mejora de un hito de lanzamiento si no está completamente implementada o si se considera inestable.

• hito de lanzamiento (release milestone): cadena de versión semántica o hito de GitHub que se refiere a una versión MAJOR.MINOR vX.Y de un lanzamiento. Consulta también la ingeniería de versiones de lanzamiento.

• rama de lanzamiento (release branch): Rama de Git release-X.Y creada para el hito vX.Y. Se crea en el momento del lanzamiento de vX.Y-rc.0 y se mantiene después del lanzamiento durante aproximadamente 12 meses con lanzamientos de parches vX.Y.Z. Nota: los lanzamientos 1.19 y más recientes reciben 1 año de soporte para lanzamientos de parches, y los lanzamientos 1.18 y anteriores recibían 9 meses de soporte.

El ciclo de lanzamiento

Los lanzamientos de Kubernetes ocurren actualmente aproximadamente tres veces al año.

El proceso de lanzamiento se puede concebir como un proceso que consta de tres fases principales:

• Definición de mejoras
• Implementación
• Estabilización

Pero en realidad, este es un proyecto de código abierto y ágil, donde la planificación y la implementación de características ocurren en todo momento. Dada la escala del proyecto y la base de desarrolladores distribuida globalmente, es fundamental para la velocidad del proyecto no depender de una fase de estabilización tardía, sino contar con pruebas de integración continua que aseguren que el proyecto sea siempre estable, de modo que las confirmaciones (commits) individuales puedan marcarse si han roto algo.

Con la definición continua de características a lo largo del año, un conjunto de elementos se destacará como destinado a un lanzamiento determinado. Enhancements Freeze comienza aproximadamente en la semana 4 del ciclo de lanzamiento. Para este momento, todo el trabajo de características planificado para el lanzamiento en cuestión ya se ha definido en los artefactos de planificación adecuados junto con el Líder de Mejoras (Enhancements Lead) del Release Team.

Después del Enhancements Freeze, el seguimiento de los hitos en las PRs e issues es importante. Los elementos dentro del hito se utilizan como una lista de tareas pendientes para completar el lanzamiento. En los issues, los hitos deben aplicarse correctamente, mediante el triaje por parte del SIG, de modo que el Release Team pueda realizar el seguimiento de los errores y las mejoras (cualquier issue relacionado con una mejora necesita un hito).

Existe cierta automatización implementada para ayudar a asignar hitos automáticamente a las PRs.

Esta automatización se aplica actualmente a los siguientes repositorios:

• kubernetes/enhancements
• kubernetes/kubernetes
• kubernetes/release
• kubernetes/sig-release
• kubernetes/test-infra

Al momento de su creación, las PRs orientadas a la rama master necesitan que los humanos den una pista sobre qué hito desean que tenga como objetivo la PR. Una vez fusionadas, las PRs contra la rama master reciben hitos aplicados automáticamente, por lo que a partir de ese momento la gestión humana del hito de esa PR es menos necesaria. En las PRs contra ramas de lanzamiento, los hitos se aplican automáticamente cuando se crea la PR, por lo que nunca es necesaria la gestión humana del hito.

Cualquier otro esfuerzo que deba ser rastreado por el Release Team y que no caiga bajo ese paraguas de automatización debe tener un hito aplicado.

La implementación y la corrección de errores son continuas a lo largo del ciclo, pero culminan en un periodo de congelación de código (code freeze).

Code Freeze comienza aproximadamente en la semana 12 y continúa durante unas 2 semanas. Solo se aceptan correcciones de errores críticos en el código base del lanzamiento durante este tiempo.

Hay aproximadamente dos semanas consecutivas al Code Freeze, y precedentes al lanzamiento, durante las cuales se deben resolver todos los problemas críticos restantes antes del lanzamiento. Esto también da tiempo para la finalización de la documentación.

Cuando el código base es lo suficientemente estable, la rama master se reabre para el desarrollo general y comienza el trabajo allí para el próximo hito de lanzamiento. Cualquier modificación restante para el lanzamiento actual se traslada (cherry picked) desde master de vuelta a la rama de lanzamiento. El lanzamiento se construye a partir de la rama de lanzamiento.

Cada lanzamiento es parte de un ciclo de vida de Kubernetes más amplio:

Eliminación de elementos del hito

Antes de profundizar demasiado en el proceso para añadir un elemento al hito, ten en cuenta lo siguiente:

Los miembros del Release Team pueden eliminar issues del hito si ellos o el SIG responsable determinan que el problema no está bloqueando realmente el lanzamiento y es poco probable que se resuelva de manera oportuna.

Los miembros del Release Team pueden eliminar PRs del hito por cualquiera de las siguientes razones, o similares:

• La PR es potencialmente desestabilizadora y no es necesaria para resolver un problema bloqueante.
• La PR es una característica nueva y tardía que no ha pasado por el proceso de mejoras o el proceso de excepción.
• No hay un SIG responsable que esté dispuesto a asumir la propiedad de la PR y resolver cualquier problema posterior con ella.
• La PR no está correctamente etiquetada.
• El trabajo se ha detenido visiblemente en la PR y las fechas de entrega son inciertas o tardías.

Si bien los miembros del Release Team ayudarán con el etiquetado y el contacto con los SIGs, es responsabilidad del remitente categorizar las PRs y asegurar el apoyo del SIG pertinente para garantizar que cualquier ruptura causada por la PR se resuelva rápidamente.

Cuando se requiera una acción adicional, el Release Team intentará realizar una escalación de persona a persona a través de los siguientes canales:

• Comentario en GitHub mencionando al equipo del SIG y a los miembros del SIG según corresponda para el tipo de problema.
• Envío de un correo electrónico a la lista de correo del SIG:
  • configurada inicialmente con las direcciones de correo electrónico grupales de la lista de SIGs de la comunidad.
  • opcionalmente, dirigiéndose también directamente al liderazgo del SIG o a otros miembros del SIG.
• Envío de un mensaje al canal de Slack del SIG:
  • configurado inicialmente con el canal de slack y el liderazgo del SIG de la lista de SIGs de la comunidad.
  • opcionalmente, mencionando directamente con "@" al liderazgo del SIG u otros por su nombre de usuario.

Añadir un elemento al hito

Mantenedores del Hito (Milestone Maintainers)

Los miembros del equipo de GitHub milestone-maintainers tienen encomendada la responsabilidad de especificar el hito de lanzamiento en los artefactos de GitHub.

Este grupo es mantenido por SIG Release y cuenta con representación del liderazgo de los diversos SIGs.

Añadir el hito de lanzamiento en curso a las pull requests después del Code Freeze está estrictamente prohibido, ya que puede comprometer la estabilidad del lanzamiento. Antes de realizar dichos cambios, se debe obtener la aprobación tanto del Release Team Lead como del Emeritus Advisor(s).

Adiciones de características

La planificación y definición de características adopta muchas formas hoy en día, pero un ejemplo típico podría ser una gran pieza de trabajo descrita en un KEP, con issues de tareas asociadas en GitHub. Cuando el plan ha alcanzado un estado implementable y el trabajo está en marcha, la mejora o partes de la misma se orientan para un próximo hito creando issues en GitHub y marcándolos con el comando /milestone de Prow.

Durante las primeras ~4 semanas del ciclo de lanzamiento, el Líder de Mejoras del Release Team interactuará con los SIGs y los propietarios de características a través de GitHub, Slack y las reuniones de los SIGs para capturar todos los artefactos de planificación requeridos.

Si tienes una mejora para orientar a un próximo hito de lanzamiento, inicia una conversación con el liderazgo de tu SIG y con el Líder de Mejoras de ese lanzamiento.

Adiciones de issues

Los issues se marcan para orientarse a un hito mediante el comando /milestone de Prow.

El Líder de Triaje de Errores (Bug Triage Lead) del Release Team y la comunidad en general vigilan los issues entrantes y realizan el triaje de los mismos, tal como se describe en la sección de la guía del colaborador sobre triaje de issues.

Marcar los issues con el hito proporciona a la comunidad una mejor visibilidad respecto a cuándo se observó un problema y para cuándo la comunidad siente que debe resolverse. Durante el Code Freeze, se debe establecer un hito para poder fusionar una PR.

Ya no se requiere un issue abierto para una PR, pero los issues abiertos y las PRs asociadas deben tener etiquetas sincronizadas. Por ejemplo, es posible que una PR asociada a un error de alta prioridad no se fusione si la PR solo está marcada con una prioridad más baja.

Adiciones de PRs

Las PRs se marcan para orientarse a un hito mediante el comando /milestone de Prow.

Este es un requisito bloqueante durante el Code Freeze, tal como se describió anteriormente.

Otras etiquetas obligatorias

Aquí está la lista de etiquetas y su uso y propósito.

Etiqueta del SIG propietario

La etiqueta del SIG propietario define al SIG al que escalamos si un issue de hito está demorándose o necesita atención adicional. Si no hay actualizaciones después de la escalación, el issue puede ser eliminado automáticamente del hito.

Estas se añaden con el comando /sig de Prow. Por ejemplo, para añadir la etiqueta que indica que el SIG Storage es responsable, comenta con /sig storage.

Etiqueta de prioridad

Las etiquetas de prioridad se utilizan para determinar una ruta de escalación antes de mover los issues fuera del hito de lanzamiento. También se utilizan para determinar si un lanzamiento debe bloquearse o no debido a la resolución del problema.

• priority/critical-urgent: Nunca se mueve automáticamente fuera de un hito de lanzamiento; se escala continuamente al colaborador y al SIG a través de todos los canales disponibles.
  • considerado un problema que bloquea el lanzamiento (release blocking issue)
  • requiere actualizaciones diarias por parte de los propietarios del issue durante el Code Freeze
  • requeriría un lanzamiento de parche si no se descubre hasta después del lanzamiento menor
• priority/important-soon: Se escala a los propietarios del issue y al SIG propietario; se mueve fuera del hito después de varios intentos fallidos de escalación.
  • no se considera un problema que bloquee el lanzamiento
  • no requeriría un lanzamiento de parche
  • se moverá automáticamente fuera del hito de lanzamiento en el Code Freeze después de un periodo de gracia de 4 días
• priority/important-longterm: Se escala a los propietarios del issue; se mueve fuera del hito después de 1 intento.
  • aún menos urgente / crítico que priority/important-soon
  • se mueve fuera del hito de forma más agresiva que priority/important-soon

Etiqueta de tipo de Issue/PR (Kind Label)

El tipo de issue se utiliza para ayudar a identificar los tipos de cambios que van entrando en el lanzamiento a lo largo del tiempo. Esto puede permitir al Release Team desarrollar una mejor comprensión de qué tipos de problemas nos perderíamos con una cadencia de lanzamiento más rápida.

Para los issues destinados al lanzamiento, incluidas las pull requests, se debe establecer una de las siguientes etiquetas de tipo de hito:

• kind/api-change: Añade, elimina o cambia una API.
• kind/bug: Corrige un error recientemente descubierto.
• kind/cleanup: Añade pruebas, refactorización, corrección de errores antiguos.
• kind/design: Relacionado con el diseño.
• kind/documentation: Añade documentación.
• kind/failing-test: El caso de prueba de CI está fallando consistentemente.
• kind/feature: Nueva funcionalidad.
• kind/flake: El caso de prueba de CI muestra fallas intermitentes.

37 - Descargar Kubernetes

Kubernetes distribuye binarios para cada componente, así como un conjunto estándar de aplicaciones de cliente para realizar el arranque o interactuar con un cluster. Componentes como el API server son capaces de ejecutarse dentro de imágenes de contenedor dentro de un cluster. Esos componentes también se distribuyen en imágenes de contenedor como parte del proceso oficial de lanzamiento. Todos los binarios, así como las imágenes de contenedor, están disponibles para múltiples sistemas operativos y arquitecturas de hardware.

kubectl

La herramienta de línea de comandos de Kubernetes, kubectl, te permite ejecutar comandos contra clusters de Kubernetes.

Puedes usar kubectl para desplegar aplicaciones, inspeccionar y gestionar recursos del cluster, y ver logs. Para más información, incluyendo una lista completa de las operaciones de kubectl, consulta la documentación de referencia de kubectl.

kubectl se puede instalar en una variedad de plataformas Linux, macOS y Windows. Busca tu sistema operativo preferido a continuación.

• Instalar kubectl en Linux
• Instalar kubectl en macOS
• Instalar kubectl en Windows

Imágenes de contenedor

Todas las imágenes de contenedor de Kubernetes se despliegan en el registro de imágenes de contenedor registry.k8s.io.

Arquitecturas de imágenes de contenedor

Todas las imágenes de contenedor están disponibles para múltiples arquitecturas, por lo que el container runtime debería elegir la correcta basándose en la plataforma subyacente. También es posible descargar una arquitectura dedicada añadiendo un sufijo al nombre de la imagen de contenedor, por ejemplo registry.k8s.io/kube-apiserver-arm64:v1.36.0.

Firmas de imágenes de contenedor

Para Kubernetes v1.36, las imágenes de contenedor están firmadas utilizando firmas de sigstore:

El proyecto Kubernetes publica una lista de imágenes de contenedor de Kubernetes firmadas en formato SPDX 2.3. Puedes obtener esa lista utilizando:

curl -Ls "https://sbom.k8s.io/$(curl -Ls https://dl.k8s.io/release/stable.txt)/release" | grep "SPDXID: SPDXRef-Package-registry.k8s.io" |  grep -v sha256 | cut -d- -f3- | sed 's/-/\//' | sed 's/-v1/:v1/'

Para verificar manualmente las imágenes de contenedor firmadas de los componentes principales de Kubernetes, consulta Verificar imágenes de contenedor firmadas.

Si descargas una imagen de contenedor para una arquitectura específica, la imagen de arquitectura única está firmada de la misma manera que en las listas de manifests multi-arquitectura.

Binarios

38 - Lanzamientos de parches (Patch Releases)

Calendario e información de contacto del equipo para los lanzamientos de parches de Kubernetes.

Para obtener información general sobre el ciclo de lanzamientos de Kubernetes, consulta la [descripción del proceso de lanzamiento].

Cadencia

Nuestra cadencia habitual para los lanzamientos de parches es mensual. Por lo general, es un poco más rápida (de 1 a 2 semanas) para los primeros lanzamientos de parches después de una versión menor 1.X. Las correcciones de errores críticos pueden provocar un lanzamiento más inmediato fuera de la cadencia normal. También procuramos no realizar lanzamientos durante los principales periodos de vacaciones.

Contacto

Consulta la página de Release Managers para obtener los detalles completos de contacto del equipo de Patch Release.

Por favor, danos un día hábil para responder, ¡es posible que estemos en una zona horaria diferente!

Entre lanzamientos, el equipo revisa las solicitudes de cherry pick entrantes de forma semanal. El equipo se pondrá en contacto con los autores de las solicitudes a través de la PR de GitHub, los canales de SIG en Slack, mensajes directos en Slack y por correo electrónico si surgen preguntas sobre la PR.

Cherry picks

Por favor, sigue el proceso de cherry pick.

Los cherry picks deben estar listos para fusionarse en GitHub con las etiquetas adecuadas (por ejemplo, approved, lgtm, release-note) y haber superado las pruebas de CI antes de la fecha límite de cherry pick. Esto suele ser dos días antes del lanzamiento previsto, pero podría ser más. Es mejor tener la PR lista lo antes posible, ya que necesitamos tiempo para obtener la señal de CI después de fusionar tus cherry picks antes del lanzamiento real.

Las PR de cherry pick que no cumplan con los criterios de fusión se pospondrán y se les hará seguimiento para el próximo lanzamiento de parches.

Periodo de soporte

De acuerdo con el KEP de soporte anual, la comunidad de Kubernetes soportará las series activas de lanzamientos de parches por un periodo de aproximadamente catorce (14) meses.

Los primeros doce meses de este marco temporal se considerarán el periodo estándar.

Hacia el final del duodécimo mes, ocurrirá lo siguiente:

• Los Release Managers generarán un lanzamiento.
• La serie de lanzamientos de parches entrará en modo de mantenimiento.

Durante el periodo de dos meses en modo de mantenimiento, los Release Managers pueden generar lanzamientos de mantenimiento adicionales para resolver:

• Vulnerabilidades que tengan un ID de CVE asignado (bajo la asesoría del Security Response Committee).
• Problemas de dependencias (incluyendo actualizaciones de imágenes base).
• Problemas críticos de los componentes principales.

Al final del periodo de dos meses en modo de mantenimiento, la serie de lanzamientos de parches se considerará EOL (fin de vida útil) y los cherry picks hacia la rama asociada se cerrarán poco tiempo después.

Ten en cuenta que se eligió el día 28 del mes como fecha objetivo para el modo de mantenimiento y EOL por simplicidad (todos los meses lo tienen).

Próximos lanzamientos mensuales

Los cronogramas pueden variar según la gravedad de las correcciones de errores, pero para facilitar la planificación, nos fijaremos los siguientes puntos de lanzamiento mensuales. También pueden ocurrir lanzamientos críticos no planificados entre estos.

Historial de lanzamientos detallado para ramas activas

1.36

Next patch release is 1.36.2.

Kubernetes 1.36 enters maintenance mode on 28 abr. 2027; the End of Life date for Kubernetes 1.36 is 28 jun. 2027.

1.35

Next patch release is 1.35.6.

Kubernetes 1.35 enters maintenance mode on 28 dic. 2026; the End of Life date for Kubernetes 1.35 is 28 feb. 2027.

1.34

Next patch release is 1.34.9.

Kubernetes 1.34 enters maintenance mode on 27 ago. 2026; the End of Life date for Kubernetes 1.34 is 27 oct. 2026.

1.33

ℹ️ Kubernetes 1.33 entered maintenance mode on 28 abr. 2026.

The End of Life date for Kubernetes 1.33 is 28 jun. 2026.

Historial de ramas no activas

Estos lanzamientos ya no cuentan con soporte.

39 - Notas

Las notas de la versión se pueden consultar leyendo el Changelog que coincida con tu versión de Kubernetes. Consulta el changelog para 1.36 en GitHub.

Alternativamente, las notas de la versión se pueden buscar y filtrar en línea en: relnotes.k8s.io. Consulta las notas de la versión filtradas para 1.36 en relnotes.k8s.io.

40 - Política de desfase de versiones (Version Skew Policy)

Este documento describe el desfase máximo de versiones soportado entre los diferentes componentes de Kubernetes. Las herramientas específicas de despliegue de clusters pueden imponer restricciones adicionales sobre este desfase.

Versiones soportadas

Las versiones de Kubernetes se expresan como x.y.z, donde x es la versión mayor, y es la versión menor y z es la versión de parche, siguiendo la terminología de Alineación de Versiones Semánticas. Para más información, consulta Kubernetes Release Versioning.

El proyecto Kubernetes mantiene ramas de lanzamiento para las tres versiones menores más recientes (1.36, 1.35, 1.34). Kubernetes 1.19 y versiones posteriores reciben aproximadamente 1 año de soporte para parches. Kubernetes 1.18 y versiones anteriores recibían aproximadamente 9 meses de soporte para parches.

Las correcciones aplicables, incluidas las de seguridad, pueden adaptarse a esas tres ramas de lanzamiento, dependiendo de la gravedad y la viabilidad. Los lanzamientos de parches se generan desde esas ramas con una cadencia regular, además de lanzamientos urgentes adicionales cuando es necesario.

El grupo de Release Managers es el propietario de esta decisión.

Para más información, consulta la página de lanzamientos de parches de Kubernetes.

Desfase de versiones soportado

kube-apiserver

En clusters de alta disponibilidad (HA), las instancias de kube-apiserver más recientes y más antiguas deben estar dentro del rango de una versión menor.

Ejemplo:

• el kube-apiserver más reciente está en la versión 1.36
• las otras instancias de kube-apiserver están soportadas en las versiones 1.36 y 1.35

kubelet

• kubelet no debe ser más reciente que kube-apiserver.
• kubelet puede ser hasta tres versiones menores más antiguo que kube-apiserver (kubelet < 1.25 solo podía ser hasta dos versiones menores más antiguo que kube-apiserver).

Ejemplo:

• kube-apiserver está en la versión 1.36
• kubelet está soportado en las versiones 1.36, 1.35, 1.34 y 1.33

Ejemplo:

• las instancias de kube-apiserver están en las versiones 1.36 y 1.35
• kubelet está soportado en las versiones 1.35, 1.34, y 1.33 (la versión 1.36 no está soportada porque sería más reciente que la instancia de kube-apiserver que se encuentra en la versión 1.35)

kube-proxy

• kube-proxy no debe ser más reciente que kube-apiserver.
• kube-proxy puede ser hasta tres versiones menores más antiguo que kube-apiserver (kube-proxy < 1.25 solo podía ser hasta dos versiones menores más antiguo que kube-apiserver).
• kube-proxy puede ser hasta tres versiones menores más antiguo o más reciente que la instancia de kubelet con la que se ejecuta conjuntamente (kube-proxy < 1.25 solo podía ser hasta dos versiones menores más antiguo o más reciente que la instancia de kubelet con la que se ejecuta conjuntamente).

Ejemplo:

• kube-apiserver está en la versión 1.36
• kube-proxy está soportado en las versiones 1.36, 1.35, 1.34 y 1.33

Ejemplo:

• las instancias de kube-apiserver están en las versiones 1.36 y 1.35
• kube-proxy está soportado en las versiones 1.35, 1.34, y 1.33 (la versión 1.36 no está soportada porque sería más reciente que la instancia de kube-apiserver que se encuentra en la versión 1.35)

kube-controller-manager, kube-scheduler y cloud-controller-manager

kube-controller-manager, kube-scheduler y cloud-controller-manager no deben ser más recientes que las instancias de kube-apiserver con las que se comunican. Se espera que coincidan con la versión menor de kube-apiserver, pero pueden ser hasta una versión menor más antiguos (para permitir actualizaciones en vivo).

Ejemplo:

• kube-apiserver está en la versión 1.36
• kube-controller-manager, kube-scheduler y cloud-controller-manager están soportados en las versiones 1.36 y 1.35

Ejemplo:

• las instancias de kube-apiserver están en las versiones 1.36 y 1.35
• kube-controller-manager, kube-scheduler y cloud-controller-manager se comunican con un balanceador de carga que puede enrutar el tráfico a cualquier instancia de kube-apiserver
• kube-controller-manager, kube-scheduler y cloud-controller-manager están soportados en la versión 1.35 (la versión 1.36 no está soportada porque sería más reciente que la instancia de kube-apiserver que se encuentra en la versión 1.35)

kubectl

kubectl está soportado dentro del rango de una versión menor (más antiguo o más reciente) respecto a kube-apiserver.

Ejemplo:

• kube-apiserver está en la versión 1.36
• kubectl está soportado en las versiones 1.37, 1.36, y 1.35

Ejemplo:

• las instancias de kube-apiserver están en las versiones 1.36 y 1.35
• kubectl está soportado en las versiones 1.36 y 1.35 (otras versiones tendrían un desfase mayor a una versión menor respecto a alguno de los componentes de kube-apiserver)

Orden de actualización de componentes soportado

El desfase de versiones soportado entre los componentes tiene implicaciones en el orden en el que los componentes deben ser actualizados. Esta sección describe el orden en el que deben actualizarse los componentes para realizar la transición de un cluster existente desde la versión 1.35 hacia la versión 1.36.

Opcionalmente, al prepararse para una actualización, el proyecto Kubernetes recomienda que hagas lo siguiente para beneficiarte de la mayor cantidad posible de correcciones de errores y regresiones durante el proceso:

• Asegúrate de que los componentes se encuentren en la versión de parche más reciente de tu versión menor actual.
• Actualiza los componentes a la versión de parche más reciente de la versión menor que tienes como objetivo.

Por ejemplo, si estás ejecutando la versión 1.35, asegúrate de estar en su versión de parche más reciente. Luego, actualiza a la versión de parche más reciente de 1.36.

kube-apiserver

Prerrequisitos:

• En un cluster de una sola instancia, la instancia existente de kube-apiserver está en la versión 1.35.
• En un cluster HA, todas las instancias de kube-apiserver están en las versiones 1.35 o 1.36 (esto garantiza un desfase máximo de 1 versión menor entre la instancia de kube-apiserver más antigua y la más reciente).
• Las instancias de kube-controller-manager, kube-scheduler y cloud-controller-manager que se comunican con este servidor están en la versión 1.35 (esto garantiza que no sean más recientes que la versión del API server existente, y que estén dentro del rango de 1 versión menor respecto al nuevo API server).
• Las instancias de kubelet en todos los nodos están en las versiones **1.35 o 1.34 (esto garantiza que no sean más recientes que la versión del API server existente, y que estén dentro del rango de 2 versiones menores respecto al nuevo API server).
• Los webhooks de admisión registrados son capaces de manejar los datos que la nueva instancia de kube-apiserver les enviará:
  • Los objetos ValidatingWebhookConfiguration y MutatingWebhookConfiguration se actualizan para incluir cualquier versión nueva de los recursos REST añadidos en 1.36 (o utilizan la opción matchPolicy: Equivalent disponible en v1.15+).
  • Los webhooks son capaces de manejar cualquier versión nueva de los recursos REST que se les envíen, así como cualquier campo nuevo añadido a las versiones existentes en 1.36.

Actualiza kube-apiserver a la versión 1.36.

kube-controller-manager, kube-scheduler y cloud-controller-manager

Prerrequisitos:

• Las instancias de kube-apiserver con las que se comunican estos componentes están en la versión 1.36 (en clusters HA en los que estos componentes del plano de control pueden comunicarse con cualquier instancia de kube-apiserver en el cluster, todas las instancias de kube-apiserver deben actualizarse antes de actualizar estos componentes).

Actualiza kube-controller-manager, kube-scheduler, y cloud-controller-manager a la versión 1.36. No hay un orden de actualización requerido entre kube-controller-manager, kube-scheduler y cloud-controller-manager. Puedes actualizar estos componentes en cualquier orden, o incluso de forma simultánea.

kubelet

Prerrequisitos:

• Las instancias de kube-apiserver con las que se comunica kubelet están en la versión 1.36.

Opcionalmente, actualiza las instancias de kubelet a la versión 1.36 (o pueden dejarse en las versiones 1.35, 1.34 o 1.33).

kube-proxy

Prerrequisitos:

• Las instancias de kube-apiserver con las que se comunica kube-proxy están en la versión 1.36.

Opcionalmente, actualiza las instancias de kube-proxy a la versión 1.36 (o pueden dejarse en las versiones 1.35, 1.34 o 1.33).

41 - Release Managers

"Release Managers" es un término general que abarca al conjunto de colaboradores de Kubernetes responsables de mantener las ramas de lanzamiento y de crear los lanzamientos utilizando las herramientas proporcionadas por SIG Release.

Las responsabilidades de cada rol se describen a continuación.

• Contacto
  • [Política de Embargo de Seguridad](#política de embargo de seguridad)
• Manuales (Handbooks)
• Release Managers
  • Cómo convertirse en Release Manager
• Release Manager Associates
  • Cómo convertirse en Release Manager Associate
• Líderes de SIG Release (SIG Release Leads)
  • Chairs
  • Technical Leads

Contacto

Política de Embargo de Seguridad

Cierta información sobre los lanzamientos está sujeta a embargo y hemos definido una política sobre cómo se establecen dichos embargos. Por favor, consulta la Política de Embargo de Seguridad para obtener más información.

Manuales (Handbooks)

NOTA: El manual del Patch Release Team y el de Branch Managers se unificarán en un único documento más adelante.

• Patch Release Team
• Branch Managers

Release Managers

Nota: La documentación puede hacer referencia al Patch Release Team y al rol de Branch Management. Estos dos roles se consolidaron en el rol de Release Managers.

Los requisitos mínimos para los Release Managers y Release Manager Associates son:

• Familiaridad con comandos básicos de Unix y capacidad para depurar scripts de shell.
• Familiaridad con flujos de trabajo de código fuente basados en ramas mediante git y las invocaciones asociadas de la línea de comandos de git.
• Conocimiento general de Google Cloud (Cloud Build y Cloud Storage).
• Disposición para buscar ayuda y comunicarse con claridad.
• Membresía de la Comunidad de Kubernetes membership.

Los Release Managers son responsables de:

• Coordinar y generar los lanzamientos de Kubernetes:
  • Lanzamientos de parches (x.y.z, donde z > 0)
  • Lanzamientos menores (x.y.z, donde z = 0)
  • Prelanzamientos (alpha, beta y release candidates)
  • Trabajar junto con el Release Team a lo largo de cada ciclo de lanzamiento
  • Establecer el calendario y la cadencia para los lanzamientos de parches
• Mantener las ramas de lanzamiento:
  • Revisar cherry picks
  • Garantizar que la rama de lanzamiento permanezca saludable y que no se fusione ningún parche no intencionado
• Guiar y asesorar al grupo de Release Manager Associates
• Desarrollar activamente características y mantener el código en k/release
• Apoyar a los Release Manager Associates y colaboradores mediante la participación activa en el programa de acompañamiento (Buddy program)
  • Realizar revisiones mensuales con los Associates, delegar tareas, facultarlos para generar lanzamientos y actuar como mentor
  • Estar disponible para apoyar a los Associates en la incorporación de nuevos colaboradores, por ejemplo, respondiendo preguntas y sugiriendo tareas adecuadas para realizar

Este equipo trabaja en ocasiones en estrecha colaboración con el Security Response Committee y, por lo tanto, debe cumplir con las directrices establecidas en el Proceso de Lanzamiento de Seguridad.

Controles de acceso en GitHub: @kubernetes/release-managers

Menciones en GitHub: @kubernetes/release-engineering

• Adolfo García Veytia (@puerco)
• Cici Huang (@cici37)
• Carlos Panato (@cpanato)
• Jeremy Rickard (@jeremyrickard)
• Marko Mudrinić (@xmudrii)
• Nabarun Pal (@palnabarun)
• Sascha Grunert (@saschagrunert)
• Stephen Augustus (@justaugustus)
• Verónica López (@verolop)

Cómo convertirse en Release Manager

To convertirse en Release Manager, primero se debe haber desempeñado el rol de Release Manager Associate. Los Associates ascienden a Release Manager al trabajar activamente en los lanzamientos durante varios ciclos y al:

• demostrar la voluntad de liderar
• hacer equipo con los Release Managers en los parches, para eventualmente generar un lanzamiento de forma independiente
  • debido a que los lanzamientos tienen una función limitante, también consideramos las contribuciones sustanciales a la promoción de imágenes y otras tareas principales de Release Engineering
• cuestionar la forma en que trabajan los Associates, sugiriendo mejoras, recopilando comentarios y coordinando el cambio
• ser confiable y receptivo
• orientarse hacia trabajos avanzados que requieran acceso y privilegios de nivel de Release Manager para completarse.

Release Manager Associates

Los Release Manager Associates son aprendices de los Release Managers, anteriormente conocidos como "Release Manager shadows". Son responsables de:

• Trabajo relacionado con los lanzamientos de parches y revisión de cherry picks
• Contribuir a k/release: actualizar dependencias y familiarizarse con la base de código fuente
• Contribuir a la documentación: mantener los manuales y asegurar que los procesos de lanzamiento estén documentados
• Con la ayuda de un Release Manager: trabajar con el Release Team durante el ciclo de lanzamiento y generar lanzamientos de Kubernetes
• Buscar oportunidades para ayudar con la priorización y la comunicación
  • Enviar preanuncios y actualizaciones sobre los lanzamientos de parches
  • Actualizar el calendario, ayudando con las fechas de lanzamiento y los hitos del cronograma del ciclo de lanzamiento
• A través del programa Buddy, incorporar a nuevos colaboradores y trabajar en pareja con ellos en distintas tareas.

Menciones en GitHub: @kubernetes/release-engineering

• Arnaud Meukam (@ameukam)
• Jim Angel (@jimangel)
• Joseph Sandoval (@jrsapi)
• Xander Grzywinski(@salaxander)

Cómo convertirse en Release Manager Associate

Los colaboradores pueden convertirse en Associates demostrando lo siguiente:

• participación constante, incluyendo de 6 a 12 meses de trabajo activo relacionado con la ingeniería de lanzamientos
• experiencia desempeñando un rol de líder técnico (technical lead) en el Release Team durante un ciclo de lanzamiento
  • esta experiencia proporciona una base sólida para entender cómo funciona SIG Release en general, incluyendo nuestras expectativas sobre habilidades técnicas, comunicación/receptividad y confiabilidad
• trabajar en elementos de k/release que mejoren nuestras interacciones con Testgrid, limpiar bibliotecas, etc.
  • estos esfuerzos requieren interactuar y trabajar en pareja con los Release Managers y Associates.

Líderes de SIG Release (SIG Release Leads)

Los SIG Release Chairs y Technical Leads son responsables de:

• La gobernanza de SIG Release
• Dirigir sesiones de intercambio de conocimientos para Release Managers y Associates
• Ofrecer asesoría sobre liderazgo y priorización

Se mencionan explícitamente aquí ya que son los propietarios de los diversos canales de comunicación y grupos de permisos (equipos de GitHub, acceso a GCP) para cada rol. Como tales, son miembros de la comunidad altamente privilegiados y tienen acceso a algunas comunicaciones privadas, que en ocasiones pueden estar relacionadas con divulgaciones de seguridad de Kubernetes.

Equipo de GitHub: @kubernetes/sig-release-leads

Chairs

• Jeremy Rickard (@jeremyrickard)
• Sascha Grunert (@saschagrunert)
• Stephen Augustus (@justaugustus)

Technical Leads

• Adolfo García Veytia (@puerco)
• Carlos Panato (@cpanato)
• Verónica López (@verolop)

Los Branch Managers anteriores se pueden encontrar en el directorio de lanzamientos del repositorio kubernetes/sig-release dentro de release-x.y/release_team.md.

Ejemplo: 1.15 Release Team