O que é um portão de funcionalidades e por que motivo o temos?
Alguns clientes de dispositivos isolados do Google Distributed Cloud (GDC) têm de concluir um processo de acreditação para satisfazer um conjunto de requisitos de conformidade. Estes clientes podem ter funcionalidades específicas que têm de passar por uma revisão de acreditação por parte de terceiros antes de poderem ser ativadas para cargas de trabalho de produção.
Determinadas funcionalidades podem exigir vários lançamentos para serem finalizadas e não devem ser expostas a todos os clientes até estarem estáveis e prontas. No entanto, outros clientes podem querer trabalhar com a Google para fazer testes de validação de conceito com a funcionalidade não lançada.
O GDC introduz vários conceitos para manter funcionalidades antes de estarem prontas:
Limite do nível de funcionalidade de implementação (limite de implementação): define o nível mínimo a usar para o dispositivo. Esta opção é definida no momento do arranque.
Recurso
FeatureGate: define a configuração de nível superior que acompanha o nível de maturidade predefinido por funcionalidade. O recurso também monitoriza quaisquer substituições de funcionalidades que o operador tenha adicionado.Nível da funcionalidade: acompanha o nível de maturidade para o qual uma determinada funcionalidade está definida. Uma funcionalidade é ativada quando é igual ou superior ao limite de implementação.
Os valores possíveis do nível de funcionalidade por ordem ascendente são: DEV, TEST, PREVIEW,
PRODUCTION e ACCREDITED.
Por exemplo, se o limite de implementação estiver definido como PRODUCTION, as funcionalidades definidas
com o nível de funcionalidade ACCREDITED ou PRODUCTION são ativadas. Se o limite de implementação estiver definido como ACCREDITED, apenas as funcionalidades com o nível ACCREDITED são ativadas.
Os níveis ou as funcionalidades não são o mesmo que os testes A/B que pode ver em produtos de consumo. As restrições de funcionalidades estão ativadas ou desativadas para todo o dispositivo GDC. As funcionalidades restritas são concebidas para serem ativadas após a conclusão da revisão da acreditação e permanecerem ativas.
As implementações com requisitos de acreditação têm de ter a sua própria FeatureGateconfiguração,FeatureGate que tem de corresponder ao que foi acreditado para essa ou versões anteriores.
Utilização ao nível da funcionalidade
Existem três definições de recursos personalizados relacionadas com a configuração de gates de funcionalidades e níveis:
Stage: define o limite de implementação para um cluster. Armazena o limite mínimo da fase de implementação, que é o que deve ser comparado com os gates de funcionalidades para determinar a ativação de funcionalidades.FeatureGate: armazena a fase predefinida de cada funcionalidade e monitoriza quaisquer substituições.SubcomponentOverride: usado pelo sistema de acesso restrito de funcionalidades para substituir a fase predefinida de uma funcionalidade para a ativar. Aparece noutro local em outros contextos.
O valor da fase é o limite mínimo de implementação armazenado em cada cluster. Esta opção só pode ser definida durante o arranque e nunca alterada após o arranque. Todas as funcionalidades com um valor de fase de funcionalidade igual ou superior estão ativadas. Para substituir a fase predefinida de um Feature Gate, consulte o artigo OOPS-P0072.
Os portais de funcionalidades são semelhantes a uma atualização. Não há alterações a imagens nem versões, mas é efetivamente o passo final de uma atualização para ativar as funcionalidades que foram adicionadas numa atualização anterior. A ativação desta funcionalidade pode ocorrer semanas ou meses após a atualização inicial, consoante o tempo que a acreditação demorar. Continue a fazer atualizações regularmente para aplicar correções e patches enquanto a acreditação estiver em curso.
Quando as funcionalidades são substituídas, o GDC aciona um reconciliador para reiniciar todos os pods que dependem da funcionalidade. Esta ação tem de ser realizada durante um período de manutenção, uma vez que algumas alterações podem exigir um período de inatividade.
Algumas funcionalidades têm um manual de serviço complementar que descreve quando têm de ser ativadas e o que procurar depois de a substituição ter sido aplicada. Isto pode ser para casos que requerem mais do que um reinício do pod ou tem de ser feito depois de outras funcionalidades serem ativadas.
Pode encontrar estes manuais de procedimentos de funcionalidades no manual de serviço anexado ao componente operacional relevante.
A lista de gates de funcionalidades ativos está disponível na documentação de Fases de funcionalidades.