Usar as Salvaguardas de Implantação para aplicar as práticas recomendadas no Serviço Kubernetes do Azure (AKS)

Aplica-se a: ✔️ AKS Automatic ✔️ AKS Standard

Este artigo mostra como usar as Salvaguardas de Implantação para impor práticas recomendadas em um cluster do Serviço Kubernetes do Azure (AKS).

Descrição geral

O Deployment Safeguards no AKS aplica as melhores práticas do Kubernetes no seu cluster AKS através dos controlos do Azure Policy.

As Salvaguardas de Implantação oferecem dois níveis de configuração:

• Warn: Exibe mensagens de aviso no terminal de código para alertá-lo sobre quaisquer configurações de cluster não compatíveis, mas ainda permite que a solicitação seja atendida.
• Enforce: Impõe configurações compatíveis negando e mutando implantações se elas não seguirem as práticas recomendadas.

O comportamento varia consoante o modo do seu cluster AKS:

• AKS Automatic: As proteções de implementação e as Normas de Segurança de Pods de referência estão ativadas por predefinição no modo Enforce. Podes excluir namespaces, mas não podes mudar o nível de salvaguarda em todo o cluster para Warn. Para mais informações, consulte Excluir espaços de nomes da carga de trabalho.
• Norma AKS: As salvaguardas de implantação são opcionais e podem ser definidas para Warn ou Enforce.

Depois de configurar as Salvaguardas de Implementação, ele avalia programaticamente os seus recursos Kubernetes na altura da criação ou atualização para conformidade. As Salvaguardas de Implantação também exibem informações de conformidade agregadas em suas cargas de trabalho em um nível por recurso por meio do painel de conformidade da Política do Azure no portal do Azure ou em sua CLI ou terminal. Executar uma carga de trabalho não compatível indica que o seu cluster não está a seguir as melhores práticas e que as cargas de trabalho no cluster estão em risco de sofrer problemas causados pela configuração do cluster.

Predefinições automáticas do AKS e opções do AKS Standard

A tabela seguinte resume o comportamento específico de cada modo para as Salvaguardas de Implementação:

Capacidade	AKS Automático	Padrão AKS
Estado predefinido das salvaguardas de implementação	Ativado por padrão	Opcional
Nível de salvaguardas	Enforce por defeito	Warn ou Enforce
Alterar o nível de salvaguardas	Geralmente não suportado (podes excluir namespaces, mas não podes mudar o nível de salvaguarda a nível do cluster para Warn)	Supported
Normas de Segurança de Pods predefinidas	Linha de base	Privileged
Definir o nível PSS	Exclusões de espaços de nomes suportadas; a predefinição de base mantém-se	Suportado com Baseline, Restrito ou Privilegiado
Exclusões de espaço de nomes	Supported	Supported

Para uma comparação geral dos modos AKS, veja a comparação de características AKS Automatic e AKS Standard.

Pré-requisitos

Nota

Os administradores de cluster não precisam de permissões da Política do Azure para habilitar ou desabilitar as Salvaguardas de Implantação. No entanto, é necessário ter o complemento Azure Policy instalado.

• Você precisa habilitar o complemento Azure Policy para AKS. Para obter mais informações, consulte Habilitar a Política do Azure em seu cluster AKS. Isso inclui registar o Microsoft.PolicyInsights fornecedor de recursos na sua subscrição.

Políticas de Salvaguardas de Implantação

A tabela a seguir lista as políticas que se tornam ativas e os recursos do Kubernetes que elas visam quando você habilita as Salvaguardas de Implantação. Você pode exibir as Salvaguardas de Implantação atualmente disponíveis no portal do Azure como uma definição de Política do Azure ou em Definições internas da Política do Azure para o Serviço Kubernetes do Azure. A intenção por trás desta coleção é criar uma lista comum e genérica de melhores práticas aplicáveis à maioria dos usuários e casos de uso.

Política de salvaguarda da implantação	Resultado da mutação, se disponível
Não é possível editar nós individuais	N/A
Os pedidos de recursos de CPU e memória dos contentores dos clusters Kubernetes devem ser definidos.	Define os pedidos padrão de CPU e memória e aplica mínimos. Para mais informações, consulte Mutador de pedidos de recursos.
Deve ter regras de antiafinidade ou topologySpreadConstraintsSet	Adiciona regras de anti-afinidade para pods e restrições de dispersão topológica para melhorar a distribuição da carga de trabalho. Para mais informações, veja mutador de propagação de antiafinidade e topologia.
Sem rótulos específicos do AKS	N/A
Os contêineres de cluster do Kubernetes só devem usar imagens permitidas	N/A
Manchas reservadas no pool do sistema	Remove a CriticalAddonsOnly mancha de um pool de nós de usuário se não estiver definido. O AKS usa o CriticalAddonsOnly taint para manter os pods dos clientes afastados do pool de sistema. Esta configuração garante uma separação clara entre os componentes do AKS e os pods do cliente, e evita a expulsão dos pods do cliente que não toleram a CriticalAddonsOnly contaminação.
Garantir que os contentores do cluster tenham sondas de prontidão ou de atividade configuradas	N/A
Os clusters do Kubernetes devem usar a StorageClass do driver CSI (Container Storage Interface)	N/A
Os serviços de cluster do Kubernetes devem usar seletores exclusivos	N/A
As imagens de contêiner de cluster do Kubernetes não devem incluir a tag de imagem mais recente	N/A

Se você quiser enviar uma ideia ou solicitação de Salvaguardas de Implantação, abra um problema no repositório AKS GitHub e adicione [Deployment Safeguards request] ao início do título.

Modificador de pedidos de recursos

Quando o Deployment Safeguards está definido ao Enforce nível, o mutador de pedidos de recursos define automaticamente os pedidos de CPU e memória e limites para contentores que não os têm definidos ou que têm valores abaixo dos limiares mínimos.

Valores padrão

Quando nenhum recurso é especificado, o mutador define os seguintes valores padrão:

Resource	Solicitação	Limite
CPU	500m	500m
Memory	2048Mi (2Gi)	2048Mi (2Gi)

Aplicação mínima

Quando os recursos são especificados mas estão abaixo dos limiares, o mutador impõe os seguintes valores mínimos:

Resource	Valor mínimo
CPU	100 metros
Memory	100Mi

Compreensão das unidades de recursos

Unidades de CPU:

• m = milicores (1m = 1/1.000 de um núcleo de CPU)
• 1000m = 1 núcleo CPU completo
• 500m = 0,5 núcleos de CPU (meio núcleo)
• 100m = 0,1 núcleos de CPU (10% de um núcleo)

Unidades de memória:

• Mi = Mebibytes (binário: 1 Mi = 1.024 × 1.024 bytes)
• Gi = Gibibytes (binário: 1 Gi = 1.024 Mi)
• 2048Mi = 2Gi
• 100Mi ≈ 105 MB

Regras de mutação da CPU

O mutador aplica a seguinte lógica para os recursos da CPU:

Scenario	Ação
Tanto o pedido da CPU como o limite estão em falta	Defina ambos para 500m (por defeito)
O pedido de CPU existe, mas é inferior a 100m	Definir o pedido para 100m (mínimo)
O limite de CPU existe, mas é inferior a 100m	Defina o limite para 100m (mínimo)
Só existe o pedido da CPU	Definir pedido igual ao limite
Só existe limite de CPU	Definir pedido igual ao limite

Regras de mutação de memória

O mutador aplica a seguinte lógica para os recursos de memória:

Scenario	Ação
Tanto o pedido de memória como o limite estão em falta	Defina ambos para 2048Mi (por defeito)
O pedido de memória existe, mas é menor que 100Mi	Definir o pedido para 100Mi (mínimo)
O limite de memória existe, mas é inferior a 100Mi	Defina o limite para 100Mi (mínimo)
Só existe pedido de memória	Deixar como está (sem limite adicionado)
Só existe limite de memória	Deixar como está (sem pedido adicionado)

Correção da classe de Qualidade de Serviço (QoS) do Kubernetes

Após a aplicação das mutações da CPU e da memória, se o valor do pedido exceder o limite para o mesmo tipo de recurso, o mutador limita o pedido para corresponder ao limite. Esta correção mantém configurações válidas da classe Kubernetes de Qualidade de Serviço (QoS).

Casos que sofrem mutações

O mutador de pedidos de recursos aplica alterações nos seguintes cenários:

• Recursos vazios: Contentores sem pedidos ou limites de CPU ou memória recebem valores predefinidos (500m CPU, 2048Mi memória).
• Abaixo dos limiares mínimos: os pedidos ou limites da CPU abaixo 100m são aumentados para 100m. Os pedidos de memória ou os limites abaixo 100Mi são aumentados para 100Mi.
• Cenários de QoS inválidos: Quando os pedidos ultrapassam os limites, os pedidos são reduzidos para corresponder aos limites.
• Especificações parciais de recursos: Contentores com apenas pedidos ou apenas limites (mas não ambos) têm mínimos aplicados onde especificados.
• Recipientes múltiplos: Todos os recipientes numa cápsula são processados e mutados adequadamente.
• Namespaces ativados: Apenas as cargas de trabalho em namespaces onde a salvaguarda foi ativada são modificadas.

Casos que não foram alterados geneticamente

O mutador de pedidos de recursos não aplica alterações nos seguintes cenários:

• Namespaces excluídos: As cargas de trabalho nos namespaces onde a salvaguarda está excluída permanecem inalteradas.
• Recursos já compatíveis: Contentores que já têm solicitações e limites acima dos limiares mínimos permanecem inalterados.
• Configurações válidas de QoS: Quando os pedidos são inferiores ou iguais aos limites e ambos os valores estão acima dos mínimos, não ocorrem alterações.

Modificador de distribuição de antiafinidade e topologia

Quando o Deployment Safeguards está definido ao Enforce nível, o mutador de anti-afinidade e distribuição topológica adiciona automaticamente regras de anti-afinidade de pod e restrições de distribuição topológica para melhorar a distribuição da carga de trabalho entre nós.

Quando o mutador funciona

O mutador só funciona quando todas as seguintes condições são cumpridas:

• As restrições de anti-afinidade dos pods e as de dispersão de topologia não existem ainda na carga de trabalho.
• O namespace não está excluído das Salvaguardas de Desdobramento.
• As Salvaguardas de Implantação estão em modo Enforce.
• A carga de trabalho não tem o kubernetes.azure.com/managedby=aks rótulo.

O que o mutador acrescenta

Identificação da etiqueta: O mutador identifica os pods usando a seguinte prioridade de etiqueta:

• app Rótulo (primeira prioridade)
• app.kubernetes.io/name Rótulo (segunda prioridade)
• Cria um default-antiaffinity-applabel=<workload-name> rótulo (alternativa)

Anti-afinidade de pods: Adiciona uma regra de anti-afinidade de pod preferencial com peso 100 que prefere agendar pods com etiquetas correspondentes em diferentes nós. Usa a chave topológica kubernetes.io/hostname.

Restrições de dispersão topológica: Adiciona uma restrição com as seguintes definições:

Configuração	Valor
MaxSkew	1 (permite uma diferença máxima de 1 pod por nó)
Quando Inatingível	ScheduleAnyway (melhor esforço, não bloqueia o agendamento)
Chave topológica	kubernetes.io/hostname

Casos que sofrem mutações

O mutador de anti-afinidade e de propagação de topologia aplica alterações nos seguintes cenários:

• Cargas de trabalho com app label: Utiliza o valor de app label para seletores de anti-afinidade e de distribuição de topologia.
• Cargas de trabalho com app.kubernetes.io/name rótulo: Quando não existe um app rótulo, utiliza este rótulo para os seletores.
• Cargas de trabalho sem etiquetas de aplicação: Cria uma etiqueta padrão usando o nome da carga de trabalho e adiciona regras de anti-afinidade e de distribuição de topologia.
• Cargas de trabalho limpas: Cargas de trabalho sem restrições existentes de afinidade ou dispersão de topologia recebem ambas as configurações.
• Afinidade parcial: Cargas de trabalho com afinidade de nó existente (mas sem anti-afinidade de pod) recebem regras de anti-afinidade de pod e de distribuição de topologia.
• Espaços de nomes ativados: As mutações só ocorrem em espaços de nomes onde a salvaguarda está ativada.

Casos que não foram alterados geneticamente

O mutador de anti-afinidade e propagação de topologia não aplica alterações nos seguintes cenários:

• Restrições de espalhamento topológico existentes: Cargas de trabalho que já têm quaisquer restrições de espalhamento topológico são completamente ignoradas.
• Anti-afinidade de pod existente: Tarefas com regras obrigatórias ou preferenciais de anti-afinidade de pod são totalmente ignoradas.
• Namespaces excluídos: As cargas de trabalho nos namespaces onde a salvaguarda está excluída permanecem inalteradas.
• Cargas de trabalho sem nomes ou rótulos identificáveis: Casos extremos em que nenhum nome de aplicação pode ser determinado são facilmente ignorados.

Mensagens de erro das Salvaguardas de Implementação

Esta secção descreve as mensagens de erro que poderá encontrar quando o Deployment Safeguards detetar configurações não compatíveis, juntamente com correções recomendadas.

Mensagens de erro de salvaguarda geral

A tabela seguinte lista mensagens de erro para as políticas gerais de Salvaguardas de Implementação:

Policy	Mensagem de erro	Corrigir
Aplicar Sondas	Container <container_name> in your Pod <pod_name> has no livenessProbe. Required probes: readinessProbe, livenessProbe	Adicione sondas de vivacidade e prontidão a cada contentor.
Sem Imagem "Mais Recente"	Please specify an explicit, versioned image tag such as '1.0' for container %v. Using explicit version tags is a best practice to ensure reproducibility, prevent unintended updates, and facilitate easier debugging and rollbacks. Avoid using the 'latest' tag because it can change over time without notice.	Use uma tag de imagem explícita diferente de latest ou em branco. Por exemplo, nginx não é permitido, mas nginx:v1.0.0 é permitido.
Aplicar o Driver CSI	Storage class <class_name> use intree provisioner kubernetes.io/azure-file is not allowed ou Storage class <class_name> use intree provisioner kubernetes.io/azure-disk is not allowed	Use disk.csi.azure.com ou file.csi.azure.com em vez disso. Para mais informações, consulte drivers CSI no AKS.
Solicitações de recursos	container <container_name> has no resource requests	Adiciona pedidos de CPU e memória ao teu contentor.
Regras de anti-afinidade	Deployment with 2 replicas should have either podAntiAffinity or topologySpreadConstraints set to avoid disruptions due to nodes crashing	Defina podAntiAffinity ou topologySpreadConstraints sobre a carga de trabalho.
Rótulos Restritos	Label kubernetes.azure.com is reserved for AKS use only	Remove o rótulo da tua carga de trabalho.
Edições de Nós Restringidos	Tainting or labeling individual nodes is not recommended. Please use Azure CLI to taint/label node pools instead	Utilize a CLI do Azure para manchar ou rotular pools de nós em vez de nós individuais.
Manchas Restritas	Taint with key CriticalAddonsOnly is reserved for the system pool only	Não contamine o pool de nós do utilizador com CriticalAddonsOnly.

Mensagens de erro das Normas de Segurança do Pod

Nota

Os Padrões de Segurança Baseline para Pods agora estão ativados por padrão no AKS Automatic. Os Pod Security Standards básicos no AKS Automatic não podem ser desativados.

As Salvaguardas de Implementação também suportam a capacidade de ativar os Padrões de Segurança Baseline, Restritos e Privilegiados para Pods. Para garantir que as suas cargas de trabalho sejam implementadas com sucesso, certifique-se de que cada manifesto cumpre os requisitos de Segurança Baseline ou Restrita de Pods. Por padrão, o Serviço Azure Kubernetes utiliza os Padrões de Segurança de Pods com Privilégios.

Policy	Mensagem de erro	Corrigir
AppArmor	AppArmor annotation values must be undefined/nil, runtime/default, or localhost/* ou AppArmor profile type must be one of: undefined/nil, RuntimeDefault, or Localhost	Remova qualquer especificação do AppArmor. O Kubernetes, por defeito, aplica definições do AppArmor. Nos hosts suportados, o perfil RuntimeDefault AppArmor é aplicado por defeito.
Espaços de Nome do Host	Host network namespaces are disallowed: spec.hostNetwork is set to true ou Host PID namespaces are disallowed: spec.hostPID is set to true ou Host IPC namespaces are disallowed: spec.hostIPC is set to true	Defina esses valores para false, ou remova a especificação dos campos.
Contentores privilegiados	Privileged [ephemeral\|init\|N/A] containers are disallowed: spec.containers[*].securityContext.privileged is set to true	Defina o campo apropriado securityContext.privileged para false, ou remova o campo.
Capabilities	A mensagem começa com Disallowed capabilities detected	Remova a capacidade mostrada do manifesto do contêiner.
HostPath Volumes	HostPath volumes are forbidden under restricted security policy unless containers mounting them are from allowed images	Remova o volume e a montagem de volume do HostPath.
Portas de host	HostPorts are forbidden under baseline security policy	Remova a especificação da porta do host do contêiner ofensivo.
SELinux	SELinux type must be one of: undefined/empty, container_t, container_init_t, container_kvm_t, or container_engine_t	Defina o campo do securityContext.seLinuxOptions.type contentor para um dos valores permitidos.
/proc Tipo de Montagem	ProcMount must be undefined/nil or 'Default' in spec.containers[*].securityContext.procMount	Defina spec.containers[*].securityContext.procMount para Default ou deixe-o indefinido.
Seccomp	Seccomp profile must not be explicitly set to Unconfined. Allowed values are: undefined/nil, RuntimeDefault, or Localhost	Defina securityContext.seccompProfile.type no pod ou contêineres para um dos valores permitidos.
Parâmetros de sistema	Disallowed sysctl detected. Only baseline Kubernetes pod security standard sysctls are permitted	Remova os sysctls proibidos. Para a lista específica, consulte a especificação de normas de segurança dos pods Kubernetes.
Tipos de Volume (Apenas PSS Restrito)	Only the following volume types are allowed under restricted policy: configMap, csi, downwardAPI, emptyDir, ephemeral, persistentVolumeClaim, projected, secret	Remova quaisquer volumes que não sejam dos tipos permitidos.
Escalada de Privilégios (Apenas PSS Restrito)	Privilege escalation must be set to false under restricted policy	Defina spec.containers[*].securityContext.allowPrivilegeEscalation para false em cada contentor, initContainer e ephemeralContainer.
Executar como não root (apenas PSS restrito)	Containers must not run as root user in spec.containers[*].securityContext.runAsNonRoot	Defina spec.containers[*].securityContext.runAsNonRoot para true em cada contentor, initContainer e ephemeralContainer.
Executar como utilizador não root (apenas PSS restrito)	Containers must not run as root user: spec.securityContext.runAsUser is set to 0	Definir securityContext.runAsUser para um valor diferente de zero, ou deixá-lo indefinido para o nível do pod e para cada contentor, initContainer e ephemeralContainer.
Seccomp (PSS Apenas Restrito)	Seccomp profile must be "RuntimeDefault" or "Localhost" under restricted policy	Defina securityContext.seccompProfile.type no pod ou contêineres para um dos valores permitidos. Isto difere da linha base porque a apólice restrita não permite um valor indefinido.
Capacidades (apenas PSS restrito)	All containers must drop ALL capabilities under restricted policy ou Only NET_BIND_SERVICE may be added to capabilities under restricted policy	Todos os contentores devem remover ALL capacidades e só podem adicionar NET_BIND_SERVICE.

Habilitar salvaguardas de implantação

Nota

Usar o nível de Salvaguardas de Implantação Enforce significa que você está aceitando que as implantações sejam bloqueadas e mutadas. Considere como estas políticas podem funcionar com o seu cluster AKS antes de ativar Enforce.

Habilitar salvaguardas de implantação em um cluster existente

Ative as proteções de implementação num cluster existente que tenha o suplemento do Azure Policy ativado, usando o comando az aks safeguard create com o sinalizador --level. Se desejar receber avisos de não conformidade, defina o --level como Warn. Se você quiser negar ou mutar todas as implantações não compatíveis, defina-o como Enforce.

az aks safeguards create --resource-group <resource-group-name> --name <cluster-name> --level Enforce 

Você também pode habilitar as Salvaguardas de Implantação usando o --cluster sinalizador e especificando a ID do recurso do cluster.

az aks safeguards create --cluster <ID> --level Enforce

Se desejar atualizar o nível de Salvaguardas de Implantação de um cluster existente, execute o seguinte comando com o novo valor para --level.

az aks safeguards update --resource-group <resource-group-name> --name <cluster-name> --level Warn 

Excluindo namespaces

Também pode excluir determinados namespaces das Salvaguardas de Implantação e das Normas de Segurança dos Pods. Quando você exclui um namespace, a atividade nesse namespace não é afetada pelos avisos ou imposição das Salvaguardas de Implantação.

Nota

Nos clusters automáticos do AKS, pode excluir namespaces das Salvaguardas de Implementação e dos Padrões de Segurança de Pod, mas não pode alterar o modo de Enforce para Warn. Esta restrição garante que as melhores práticas continuam a ser aplicadas nos clusters automáticos.

Por exemplo, para excluir os namespaces ns1 e ns2, use uma lista separada por espaço de namespaces com o --excluded-ns sinalizador, conforme mostrado no exemplo a seguir:

az aks safeguards update --resource-group <resource-group-name> --name <cluster-name> --level Enforce --excluded-ns ns1 ns2 

Ativar os Padrões de Segurança dos Pods

Nota

Nos clusters Standard do AKS, os Pod Security Standards têm, por predefinição, o nível Privileged, que não impõe quaisquer restrições. Para aplicar os Padrões de Segurança dos Pods, use a --pss-level flag para definir o nível para Baseline ou Restricted. Para reverter ao padrão, defina --pss-level para Privileged.

Nos clusters automáticos do AKS, os Padrões de Segurança dos Pods são, por predefinição, definidos ao nível Baseline.

az aks safeguards update --resource-group <resource-group-name> --name <cluster-name> --level Warn --pss-level <Baseline|Restricted|Privileged>

Atualize a versão do seu Deployment Safeguard

As Salvaguardas de Implementação seguem o esquema de versionamento adicional do AKS. Cada nova versão de um Deployment Safeguard será disponibilizada como uma nova versão menor no AKS. Essas atualizações serão comunicadas através das notas de versão do AKS GitHub e refletidas na tabela "Políticas de Salvaguardas de Implantação" em nossa documentação.

Para saber mais sobre versionamento e add-ons do AKS, consulte a seguinte documentação: versões de componentes do AKS e versioning do AKS para add-ons.

Verificar a conformidade entre clusters

Depois de implantar seu manifesto do Kubernetes, você verá avisos ou uma possível mensagem de negação em sua CLI ou terminal se o cluster não estiver em conformidade com as Salvaguardas de Implantação, conforme mostrado nos exemplos a seguir:

Avise

$ kubectl apply -f deployment.yaml
Warning: [azurepolicy-k8sazurev1antiaffinityrules-ceffa082711831ebffd1] Deployment with 2 replicas should have either podAntiAffinity or topologySpreadConstraints set to avoid disruptions due to nodes crashing
deployment.apps/simple-web created

Fazer cumprir

Com as mutações Deployment Safeguard, o Enforce nível muta os teus recursos Kubernetes quando aplicável. No entanto, seus recursos do Kubernetes ainda precisam passar por todas as proteções para serem implantados com êxito. Se alguma política de salvaguarda falhar, seu recurso será negado e não será implantado.

$ kubectl apply -f deployment.yaml 
Error from server (Forbidden): error when creating "deployment.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [azurepolicy-k8sazurev1antiaffinityrules-ceffa082711831ebffd1] Deployment with 2 replicas should have either podAntiAffinity or topologySpreadConstraints set to avoid disruptions due to nodes crashing

Se os seus recursos Kubernetes cumprirem as salvaguardas de mutação aplicáveis e cumprirem todos os outros requisitos de salvaguarda, serão implementados com sucesso, como mostrado no exemplo seguinte:

$ kubectl apply -f deployment.yaml
deployment.apps/simple-web created

Verificar a conformidade entre clusters usando o painel da Política do Azure

Para verificar se as Salvaguardas de Implantação foram aplicadas e verificar a conformidade do cluster, navegue até a página do portal do Azure do cluster e selecione Políticas e, em seguida, selecione Ir para a Política do Azure.

Na lista de políticas e iniciativas, selecione a iniciativa associada às Salvaguardas de Implantação. Você vê um painel mostrando o estado de conformidade em todo o cluster AKS.

Nota

Para avaliar corretamente a conformidade em todo o cluster AKS, a iniciativa Política do Azure deve ter como escopo o grupo de recursos do cluster.

Desativar salvaguardas de implantação

Para desabilitar as Salvaguardas de Implantação no cluster, use o delete comando.

az aks safeguards delete --resource-group <resource-group-name> --name <cluster-name>

FAQ

Posso criar as minhas próprias mutações?

N.º Se você tiver uma ideia para uma salvaguarda, abra um problema no repositório AKS GitHub e adicione [Deployment Safeguards request] ao início do título.

Posso escolher quais mutações quero no Enforcement?

N.º As Salvaguardas de Implementação são uma questão de tudo ou nada. Assim que ativares Aviso ou Aplicar, todas as salvaguardas estarão ativas.

Por que meu recurso de implantação foi admitido mesmo não seguindo as práticas recomendadas?

As Salvaguardas de Implantação impõem padrões de práticas recomendadas por meio de controles de Política do Azure e têm políticas que validam em relação aos recursos do Kubernetes. Para avaliar e impor componentes de cluster, a Política do Azure estende o Gatekeeper. Atualmente, a aplicação do Gatekeeper também opera em um fail-open modelo. Como não há garantia de que o Gatekeeper responde à nossa chamada de rede, garantimos que, nesse caso, a validação é ignorada para que a recusa não bloqueie as suas implementações.

Para saber mais, consulte Validação de carga de trabalho no Gatekeeper.

Conteúdo relacionado

• Saiba mais sobre as práticas recomendadas para operar um cluster AKS.
• O que é AKS Automatic?