¿Qué es una puerta de funciones y por qué la tenemos?
Algunos clientes de Google Distributed Cloud (GDC) aislado deben completar un proceso de acreditación para cumplir una serie de requisitos. Es posible que estos clientes tengan funciones específicas que deban someterse a una revisión de acreditación por parte de un tercero antes de que se puedan habilitar para cargas de trabajo de producción.
Para finalizar algunas funciones, puede que se necesiten varias versiones, por lo que no deberían mostrarse a todos los clientes hasta que sean estables y estén listas. Sin embargo, otros clientes pueden querer colaborar con Google para hacer pruebas de prueba de concepto con la función no lanzada.
GDC introduce varios conceptos para mantener las funciones antes de que estén listas:
Umbral del nivel de la función de implementación (umbral de implementación): define el nivel mínimo que se debe usar en el universo. Se define en el momento del arranque.
Recurso
FeatureGate: define la configuración de nivel superior que monitoriza el nivel de madurez predeterminado por función. El recurso también registra las anulaciones de funciones que haya añadido el operador.Nivel de función: registra el nivel de madurez de una función determinada. Una función se habilita cuando es mayor o igual que el umbral de implementación.
Los valores posibles del nivel de función en orden ascendente son: DEV, TEST, PREVIEW, PRODUCTION y ACCREDITED.
Por ejemplo, si el umbral de implementación es PRODUCTION, se habilitarán las funciones con el nivel ACCREDITED o PRODUCTION. Si el umbral de implementación se define como ACCREDITED, solo se habilitarán las funciones con el nivel ACCREDITED.
Las puertas o los niveles de funciones no son lo mismo que las pruebas A/B que puede ver en los productos de consumo. Las puertas de funciones están activadas o desactivadas en todo el universo de GDC. Las puertas de funciones se han diseñado para activarse una vez que se haya completado la revisión de la acreditación y permanecer activadas. No se trata de una configuración para personalizar tu zona de GDC.
Las implementaciones con requisitos de acreditación deben tener su propia FeatureGateconfiguración por organización,
que debe coincidir con lo que se ha acreditado para esa versión o versiones anteriores.
Uso a nivel de función
Hay tres definiciones de recursos personalizados relacionadas con la configuración de puertas y niveles de funciones:
Stage: define el umbral de despliegue de un clúster. Almacena el umbral mínimo de la fase de implementación, que es el valor con el que se comparan las puertas de funciones para determinar si se habilitan o no.FeatureGate: almacena la fase predeterminada de cada función y registra cualquier sustitución.SubcomponentOverride: el sistema de puertas de funciones lo usa para anular la fase predeterminada de una función y habilitarla en la zona. Aparece en otros contextos.
El valor de la fase es el umbral mínimo de implementación almacenado en cada clúster. Este valor solo se debe definir durante el arranque y no se debe cambiar después. Todas las funciones con un valor de fase de función igual o superior están habilitadas. El operador puede habilitar o inhabilitar funciones de varias formas principales. No todas se aplican a todas las funciones.
- Definir la fase en el momento del arranque: para obtener más información, consulta el paso para definir el umbral de la fase de la función para la implementación general.
- Modificar una fase de función mediante la infraestructura como código (IaC) en el clúster de administrador raíz:
Consulta
IAC-R0004
para obtener información sobre el flujo de trabajo y la estructura de directorios. Modificas un archivo en el directorio de un componente operativo. Por ejemplo, para modificar la función
PGMigration, que es una función del componente operabledbs, debes actualizar el archivoinfrastructure/zonal/zones/ZONE_NAME/root-admin/components/dbs/dbs-common-override.yaml. - Modificar una fase de una función mediante IaC en el clúster de la organización:
En función del tipo de organización, el clúster es el clúster de infraestructura o el clúster de administrador de la organización. Consulta el artículo IAC-R0004 para obtener información sobre el flujo de trabajo y la estructura de directorios. Modificas un archivo en el directorio de un componente operativo. Por ejemplo, para modificar la función
PGMigration, que es una función del componente operabledbs, debes actualizar el archivoinfrastructure/zonal/zones/ZONE_NAME/ORG_NAME/components/dbs/dbs-sub-override.yaml. - Actualización de GDC: en cada lanzamiento, el valor de la fase predeterminado por función puede cambiar en función de las nuevas evaluaciones de madurez. Ten en cuenta que los valores predeterminados no afectan a las anulaciones que ya se hayan definido en IaC para una función determinada.
Las puertas de funciones son similares a una actualización. No se modifica ninguna imagen ni versión, pero es el paso final de una actualización para habilitar las funciones que se añadieron en una actualización anterior. Esta función puede habilitarse semanas o meses después de la actualización inicial, en función del tiempo que se tarde en obtener la acreditación. Sigue realizando actualizaciones periódicamente para incorporar correcciones y parches mientras se lleva a cabo la acreditación.
Cuando se anulan funciones, como al seguir el proceso de IaC, GDC activa un reconciliador para reiniciar todos los pods que dependen de la función. Esto debe hacerse durante una ventana de mantenimiento, ya que algunos cambios pueden requerir un tiempo de inactividad.
Algunas funciones tienen un manual de servicio que describe cuándo se deben habilitar y qué se debe buscar después de aplicar la anulación. Esto puede deberse a que se requiere algo más que reiniciar un pod o a que debe realizarse después de habilitar otras funciones.
Puedes encontrar estos runbooks de funciones en el manual de servicio adjunto al componente operativo correspondiente.
Puedes consultar la lista de feature gates activos en la documentación de Fases de las funciones.