Melhores práticas de confiabilidade e implantação de cluster para o Serviço de Kubernetes do Azure (AKS)
Este artigo fornece as melhores práticas de confiabilidade do cluster implementadas em um nível de implantação e de cluster para suas cargas de trabalho do Serviço de Kubernetes do Azure (AKS). O artigo destina-se a operadores de cluster e desenvolvedores responsáveis por implantar e gerenciar aplicativos no AKS.
As melhores práticas neste artigo estão organizadas nas seguintes categorias:
Melhores práticas de nível de implantação
As melhores práticas de nível de implantação a seguir ajudam a garantir alta disponibilidade e confiabilidade para suas cargas de trabalho do AKS. Essas melhores práticas são configurações locais que você pode implementar nos arquivos YAML para seus pods e implantações.
Observação
Certifique-se de implementar essas melhores práticas sempre que implantar uma atualização em seu aplicativo. Caso contrário, você poderá enfrentar problemas com a disponibilidade e a confiabilidade do aplicativo, como tempo de inatividade não intencional no aplicativo.
Orçamentos de interrupção de pod (PDBs)
Orientação de melhor prática
Use orçamentos de interrupção de pod (PDBs) para garantir que um número mínimo de pods permaneça disponível durante interrupções voluntárias, como operações de atualização ou exclusões acidentais de pod.
Os orçamentos de interrupção de pod (PDBs) permitem definir como as implantações ou conjuntos de réplicas respondem durante interrupções voluntárias, como operações de atualização ou exclusões acidentais de pod. Usando PDBs, você pode definir uma contagem mínima ou máxima de recursos indisponíveis. Os PDBs afetam apenas a API de remoção para interrupções voluntárias.
Por exemplo, digamos que você precise executar uma atualização de cluster e já tem um PDB definido. Antes de executar a atualização do cluster, o agendador do Kubernetes garante que o número mínimo de pods definidos no PDB esteja disponível. Se a atualização fizer com que o número de pods disponíveis fique abaixo do mínimo definido nos PDBs, o agendador agenda pods extras em outros nós antes de permitir que a atualização prossiga. Se você não definir um PDB, o agendador não terá nenhuma restrição para o número de pods que podem ficar indisponíveis durante a atualização, o que pode levar à falta de recursos e possíveis interrupções de cluster.
No arquivo PDB de definição de exemplo a seguir, o campo minAvailable define o número mínimo de pods que devem permanecer disponíveis durante interrupções voluntárias. O valor pode ser um número absoluto (por exemplo, 3) ou um percentual do número desejado de pods (por exemplo, 10%).
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: mypdb
spec:
minAvailable: 3 # Minimum number of pods that must remain available during voluntary disruptions
selector:
matchLabels:
app: myapp
Para obter mais informações, confira Planejar a disponibilidade usando PDBs e Especificar um orçamento de interrupção para o seu aplicativo.
Limites de CPU e memória do pod
Orientação de melhor prática
Defina os limites de CPU e memória do pod para todos os pods para garantir que os pods não consumam todos os recursos em um nó e forneçam proteção durante ameaças de serviço, como ataques de DDoS.
Os limites de CPU e memória do pod definem a quantidade máxima de CPU e memória que um pod pode usar. Quando um pod excede seus limites definidos, ele é marcado para remoção. Para obter mais informações, confira Unidades de recursos da CPU no Kubernetes e Unidades de recurso de memória no Kubernetes.
Definir limites de CPU e memória ajuda você a manter a integridade do nó e minimiza o impacto para outros pods no nó. Evite configurar um limite de pod maior do que os nós podem suportar. Cada nó do AKS reserva uma quantidade definida de CPU e memória para os componentes principais do Kubernetes. Se você definir um limite de pod maior do que o nó pode dar suporte, seu aplicativo poderá tentar consumir muitos recursos e afetar negativamente outros pods no nó. Os administradores de cluster precisam definir cotas de recursos em um namespace que exija a definição de solicitações e limites de recursos. Para obter mais informações, confira Impor cotas de recursos no AKS.
No arquivo de definição de pod de exemplo a seguir, a seção resources define os limites de CPU e memória para o pod:
kind: Pod
apiVersion: v1
metadata:
name: mypod
spec:
containers:
- name: mypod
image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 250m
memory: 256Mi
Dica
Você pode usar o comando kubectl describe node para exibir a capacidade de CPU e memória de seus nós, conforme mostrado no exemplo a seguir:
kubectl describe node <node-name>
# Example output
Capacity:
cpu: 8
ephemeral-storage: 129886128Ki
hugepages-1Gi: 0
hugepages-2Mi: 0
memory: 32863116Ki
pods: 110
Allocatable:
cpu: 7820m
ephemeral-storage: 119703055367
hugepages-1Gi: 0
hugepages-2Mi: 0
memory: 28362636Ki
pods: 110
Para obter mais informações, confira Atribuir recursos de CPU a contêineres e pods e atribuir recursos de memória a contêineres e pods.
Ganchos de parada prévia
Orientação de melhor prática
Quando aplicável, use ganchos de parada prévia para garantir o encerramento normal de um contêiner.
Um gancho PreStop é chamado imediatamente antes de um contêiner ser encerrado devido a uma solicitação de API ou evento de gerenciamento, como preempção, contenção de recursos ou falha de investigação de ativação/inicialização. Uma chamada para o gancho PreStop falhará se o contêiner já estiver em um estado encerrado ou concluído e o gancho precisar ser concluído antes que o sinal TERM para interromper o contêiner seja enviado. A contagem regressiva do período de carência de término do pod começa antes do gancho PreStop ser executado, de modo que o contêiner eventualmente termina dentro do período de carência de término.
O arquivo de definição de pod de exemplo a seguir mostra como usar um gancho PreStop para garantir o encerramento normal de um contêiner:
apiVersion: v1
kind: Pod
metadata:
name: lifecycle-demo
spec:
containers:
- name: lifecycle-demo-container
image: nginx
lifecycle:
postStart:
exec:
command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
preStop:
exec:
command: ["/bin/sh","-c","nginx -s quit; while killall -0 nginx; do sleep 1; done"]
Para obter mais informações, confira Ganchos de ciclo de vida do contêiner e Encerramento de pods.
maxUnavailable
Orientação de melhor prática
Defina o número máximo de pods que podem ficar indisponíveis durante uma atualização sem interrupção usando o campo
maxUnavailableem sua implantação para garantir que um número mínimo de pods permaneça disponível durante a atualização.
O campo maxUnavailable especifica o número máximo de pods que podem ficar indisponíveis durante o processo de atualização. O valor pode ser um número absoluto (por exemplo, 3) ou um percentual do número desejado de pods (por exemplo, 10%). maxUnavailable refere-se à API de exclusão, que é usada durante atualizações sem interrupção.
O manifesto de implantação de exemplo a seguir usa o campo maxAvailable para definir o número máximo de pods que podem ficar indisponíveis durante o processo de atualização:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1 # Maximum number of pods that can be unavailable during the upgrade
Para obter mais informações, confira Máximo indisponível.
Restrições de distribuição da topologia de pods
Orientação de melhor prática
Use as restrições de distribuição da topologia de pods para garantir que os pods sejam distribuídos entre diferentes nós ou zonas de modo a aumentar a disponibilidade e a confiabilidade.
Você pode usar as restrições de distribuição da topologia de pods para controlar como os pods são distribuídos pelo seu cluster com base na topologia dos nós e distribuir os pods entre diferentes nós ou zonas para aumentar a disponibilidade e a confiabilidade.
O exemplo de arquivo de definição de pod a seguir mostra como usar o campo topologySpreadConstraints para distribuir os pods entre nós diferentes:
apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
# Configure a topology spread constraint
topologySpreadConstraints:
- maxSkew: <integer>
minDomains: <integer> # optional
topologyKey: <string>
whenUnsatisfiable: <string>
labelSelector: <object>
matchLabelKeys: <list> # optional
nodeAffinityPolicy: [Honor|Ignore] # optional
nodeTaintsPolicy: [Honor|Ignore] # optional
Para obter mais informações, confira Restrições de distribuição de topologia de pods.
Investigações de preparação, atividade e inicialização
Orientação de melhor prática
Configure investigações de preparação, atividade e inicialização quando aplicável para melhorar a resiliência para altas cargas e reduzir a reinicialização de contêineres.
Investigações de preparação
No Kubernetes, o kubelet usa investigações de preparação para saber quando um contêiner está pronto para começar a aceitar o tráfego. Um pod é considerado pronto quando todos os contêineres estão prontos. Quando um pod não está pronto, ele é removido dos balanceadores de carga de serviço. Para obter mais informações, confira Investigações de preparação no Kubernetes.
O arquivo de definição de pod de exemplo a seguir mostra uma configuração de investigação de preparação:
readinessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
Para obter mais informações, confira Configurar investigações de preparação.
Investigações de atividade
No Kubernetes, o kubelet usa investigações de atividade para saber quando reiniciar um contêiner. Se um contêiner falhar na investigação de atividade, o contêiner será reiniciado. Para obter mais informações, confira Investigações de atividade no Kubernetes.
O arquivo de definição de pod de exemplo a seguir mostra uma configuração de investigação de atividade:
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
Outro tipo de investigação de atividade usa uma solicitação HTTP GET. O arquivo de definição de pod de exemplo a seguir mostra uma configuração de investigação de atividade de solicitação HTTP GET:
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-http
spec:
containers:
- name: liveness
image: registry.k8s.io/liveness
args:
- /server
livenessProbe:
httpGet:
path: /healthz
port: 8080
httpHeaders:
- name: Custom-Header
value: Awesome
initialDelaySeconds: 3
periodSeconds: 3
Para obter mais informações, confira Configurar investigações de atividade e Definir uma solicitação HTTP de atividade.
Investigações de inicialização
No Kubernetes, o kubelet usa investigações de inicialização para saber quando um aplicativo de contêiner foi iniciado. Quando você configura uma investigação de inicialização, as investigações de preparação e de atividade não são iniciadas até que a investigação de inicialização seja bem-sucedida, garantindo que as investigações de preparação e de atividade não interfiram na inicialização do aplicativo. Para obter mais informações, confira Investigações de inicialização no Kubernetes.
O arquivo de definição de pod de exemplo a seguir mostra uma configuração de investigação de inicialização:
startupProbe:
httpGet:
path: /healthz
port: 8080
failureThreshold: 30
periodSeconds: 10
Aplicativos de várias réplicas
Orientação de melhor prática
Implante pelo menos duas réplicas do seu aplicativo para garantir alta disponibilidade e resiliência em cenários de nó inoperante.
No Kubernetes, você pode usar o campo replicas em sua implantação para especificar o número de pods que deseja executar. A execução de várias instâncias do aplicativo ajuda a garantir alta disponibilidade e resiliência em cenários de nó inoperante. Se você tiver zonas de disponibilidade habilitadas, poderá usar o campo replicas para especificar o número de pods que deseja executar em várias zonas de disponibilidade.
O seguinte arquivo de definição de pod de exemplo mostra como usar o campo replicas para especificar o número de pods que você deseja executar:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
Para obter mais informações, confira Visão geral da solução de alta disponibilidade ativo-ativo recomendada para o AKS e Réplicas em especificações de implantação.
Melhores práticas de nível de pool de nós e cluster
As melhores práticas de nível de pool de nós e cluster a seguir ajudam a garantir alta disponibilidade e confiabilidade para os seus clusters do AKS. Você pode implementar estas melhores práticas ao criar ou atualizar seus clusters do AKS.
Zonas de disponibilidade
Orientação de melhor prática
Use várias zonas de disponibilidade ao criar um cluster do AKS para garantir alta disponibilidade em cenários de zona inoperante. Tenha em mente que você não pode alterar a configuração da zona de disponibilidade depois de criar o cluster.
As zonas de disponibilidade são grupos separados de datacenters em uma região. Essas zonas estão próximas o suficiente para ter conexões de baixa latência entre si, mas distantes o suficiente para reduzir a probabilidade de que mais de uma zona seja afetada por interrupções locais ou clima. O uso de zonas de disponibilidade ajuda seus dados a permanecerem sincronizados e acessíveis em cenários de zona inoperante. Para obter mais informações, confira Executar em várias zonas.
Dimensionamento automático do cluster
Orientação de melhor prática
Use o dimensionamento automático do cluster para garantir que o cluster possa lidar com o aumento da carga e reduzir os custos durante a baixa carga.
Para acompanhar as demandas do aplicativo no AKS, talvez seja necessário ajustar o número de nós que executam suas cargas de trabalho. O componente dimensionador automático do cluster observa os pods em seu cluster que não podem ser agendados devido a restrições de recursos. Quando o dimensionador automático do cluster detecta problemas, ele aumenta o número de nós no pool de nós para atender à demanda do aplicativo. Ele também verifica regularmente os nós quanto à falta de pods em execução e reduz o número de nós conforme necessário. Para obter mais informações, confira Dimensionamento automático de cluster no AKS.
Você pode usar o parâmetro --enable-cluster-autoscaler ao criar um cluster do AKS para habilitar o dimensionador automático de cluster, conforme mostrado no exemplo a seguir:
az aks create \
--resource-group myResourceGroup \
--name myAKSCluster \
--node-count 2 \
--vm-set-type VirtualMachineScaleSets \
--load-balancer-sku standard \
--enable-cluster-autoscaler \
--min-count 1 \
--max-count 3 \
--generate-ssh-keys
Você também pode habilitar o dimensionador automático de cluster em um pool de nós existente e configurar detalhes mais granulares do dimensionador automático de cluster alterando os valores padrão no perfil de dimensionador automático em todo o cluster.
Para obter mais informações, confira Usar o dimensionador automático de cluster no AKS.
Standard Load Balancer
Orientação de melhor prática
Use o Standard Load Balancer para fornecer maior confiabilidade e recursos, suporte para várias zonas de disponibilidade, investigações HTTP e funcionalidade em vários data centers.
No Azure, o SKU do Standard Load Balancer foi projetado para ser equipado para balancear a carga do tráfego da camada de rede quando forem necessários alto desempenho e baixa latência. O Standard Load Balancer roteia o tráfego dentro de regiões e entre regiões e para zonas de disponibilidade para alta resiliência. O SKU Standard é o SKU padrão e recomendado a ser usado ao criar um cluster do AKS.
Importante
Em 30 de setembro de 2025, o Balanceador de Carga Básico será desativado. Para saber mais, confira o anúncio oficial. Recomendamos que você use o Standard Load Balancer para novas implantações e atualize as implantações existentes para o Standard Load Balancer. Para obter mais informações, confira Upgrade do balanceador de carga Básico.
O exemplo a seguir mostra um manifesto de serviço LoadBalancer que usa o Standard Load Balancer:
apiVersion: v1
kind: Service
metadata:
annotations:
service.beta.kubernetes.io/azure-load-balancer-ipv4 # Service annotation for an IPv4 address
name: azure-load-balancer
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: azure-load-balancer
Para obter mais informações, confira Usar um balanceador de carga Standard no AKS.
Dica
Você também pode usar um controlador de entrada ou uma malha ponto a ponto para gerenciar o tráfego de rede, com cada opção fornecendo recursos e recursos diferentes.
Pools de nós do sistema
Use pools de nós de sistema dedicados
Orientação de melhor prática
Use pools de nós do sistema para garantir que nenhum outro aplicativo de usuário seja executado nos mesmos nós, o que pode causar escassez de recursos e afetar os pods do sistema.
Use pools de nós do sistema dedicados para garantir que nenhum outro aplicativo de usuário seja executado nos mesmos nós, o que pode causar escassez de recursos e possíveis interrupções de cluster devido às condições de corrida. Para usar um pool de nós do sistema dedicado, você pode usar o taint CriticalAddonsOnly no pool de nós do sistema. Para obter mais informações, confira Usar pools de nós do sistema no AKS.
Dimensionamento automático para pools de nós do sistema
Orientação de melhor prática
Configure o dimensionador automático para pools de nós do sistema para definir limites mínimos e máximos de escala para o pool de nós.
Use o dimensionador automático em pools de nós para configurar os limites de escala mínimo e máximo para o pool de nós. O pool de nós do sistema sempre deve ser capaz de dimensionar para atender às demandas dos pods do sistema. Se o pool de nós do sistema não puder ser colocado em escala, o cluster fica sem recursos para ajudar a gerenciar o agendamento, o dimensionamento e o balanceamento de carga, o que pode levar a um cluster sem resposta.
Para obter mais informações, confira Usar o dimensionador automático de cluster em pools de nós.
Pelo menos três nós por pool de nós do sistema
Orientação de melhor prática
Certifique-se de que os pools de nós do sistema tenham pelo menos três nós para garantir a resiliência em cenários de congelamento/atualização, o que pode levar à reinicialização ou desligamento de nós.
Os pools de nós do sistema são usados para executar pods do sistema, como kube-proxy, coredns e o plug-in da CNI do Azure. É recomendável garantir que os pools de nós do sistema tenham pelo menos três nós para garantir a resiliência em cenários de congelamento/atualização, o que pode levar à reinicialização ou desligamento de nós. Para obter mais informações, confira Gerenciar pools de nós do sistema no AKS.
Rede Acelerada
Orientação de melhor prática
Use a rede acelerada para reduzir a latência, oscilação e utilização da CPU em suas VMs.
A rede acelerada permite a virtualização de E/S de raiz única (SR-IOV) nos tipos de VM com suporte, melhorando consideravelmente o desempenho da rede.
O diagrama a seguir ilustra como duas VMs se comunicam com e sem a Rede Acelerada:
Para obter mais informações, confira Visão geral da rede acelerada.
Versões da imagem
Orientação de melhor prática
As imagens não devem usar a marca
latest.
Marcas de imagem de contêiner
O uso da marca latest para imagens de contêiner pode levar a um comportamento imprevisível e dificulta o rastreamento de qual versão da imagem está em execução no cluster. Você pode minimizar esses riscos integrando e executando ferramentas de verificação e correção nos seus contêineres durante a criação e o runtime. Para obter mais informações, confira Práticas recomendadas para o gerenciamento de imagens de contêiner no AKS.
Atualizações da imagem do nó
O AKS fornece vários canais de atualização automática para atualizações de imagem do sistema operacional do nó. Você pode usar esses canais para controlar o momento em que as atualizações são executadas. Recomendamos unir esses canais de atualização automática para garantir que seus nós estejam executando os patches e atualizações de segurança mais recentes. Para obter mais informações, confira Atualização automática de imagens do sistema operacional do nó no AKS.
Camada Standard para cargas de trabalho de produção
Orientação de melhor prática
Use a camada Standard para cargas de trabalho de produto para maior confiabilidade e recursos de cluster, suporte para até 5.000 nós em um cluster e SLA de tempo de atividade habilitado por padrão. Se você precisar de LTS, considere usar a camada Premium.
A camada Standard do Serviço de Kubernetes do Azure (AKS) fornece um contrato de nível de serviço (SLA) de tempo de atividade de 99,9%, com suporte financeiro, para suas cargas de trabalho de produção. A camada Standard também fornece maior confiabilidade e recursos de cluster, suporte para até 5.000 nós em um cluster e SLA de tempo de atividade habilitado por padrão. Para obter mais informações, confira Tipos de preços para o gerenciamento de cluster do AKS.
CNI do Azure para alocação de IP dinâmico
Orientação de melhor prática
Configure a CNI do Azure para alocação de IP dinâmico para melhor utilização de IP e para evitar o esgotamento de IP para clusters do AKS.
A funcionalidade de alocação de IP dinâmico na CNI do Azure aloca IPs de pod de uma sub-rede separada da sub-rede que hospeda o cluster do AKS e oferece os seguintes benefícios:
- Melhor utilização de IPs: os IPs são alocados dinamicamente para os pods do cluster da sub-rede de pods. Isso leva a uma melhor utilização de IPs no cluster em comparação com a solução CNI tradicional, que faz a alocação estática de IPs para cada nó.
- Escalonável e flexível: as sub-redes de nó e de pods podem ser dimensionadas de forma independente. Uma única sub-rede de pods pode ser compartilhada entre vários pools de nós de um cluster ou em vários clusters do AKS implantados na mesma VNet. Você também pode configurar uma sub-rede de pods separada para um pool de nós.
- Alto desempenho: como pods são atribuídos a IPs de rede virtual, eles têm conectividade direta com outros recursos e pods de clusters na VNet. A solução dá suporte a clusters muito grandes sem degradação no desempenho.
- Políticas de VNet separadas para pods: como os pods têm uma sub-rede separada, você pode configurar para eles políticas de VNet separadas que são diferentes das políticas de nós. Isso permite muitos cenários úteis, como permitir a conectividade com a Internet apenas para pods e não para nós, corrigindo o IP de origem para o pod em um pool de nós usando um Gateway da NAT do Azure e usando NSGs para filtrar o tráfego entre pools de nós.
- Políticas de rede do Kubernetes: as políticas de rede do Azure e o Calico funcionam com esta solução.
Para obter mais informações, confira Configurar a rede CNI do Azure para alocação dinâmica de IPs e suporte aprimorado à sub-rede.
VMs de SKU v5
Orientação de melhor prática
Use SKUs de VM v5 para melhorar o desempenho durante e após as atualizações e oferecer menos impacto em geral e uma conexão mais confiável para seus aplicativos.
Para pools de nós no AKS, use VMs de SKU v5 com discos de SO efêmeros para fornecer recursos de computação suficientes para pods do sistema kube. Para obter mais informações, consulte Melhores práticas para desempenho e colocação em escala de grandes cargas de trabalho no AKS.
Não usar VMs da série B
Orientação de melhor prática
Não use VMs da série B para clusters do AKS porque elas são de baixo desempenho e não funcionam bem com o AKS.
As VMs da série B têm baixo desempenho e não funcionam bem com o AKS. Em vez disso, recomendamos o uso de VMs de SKU v5.
Discos Premium
Orientação de melhor prática
Use discos Premium para obter 99,9% de disponibilidade em uma máquina virtual (VM).
Os Discos Premium do Azure oferecem uma latência de disco de submilissegundo consistente e alta IOPS e taxa de transferência. Os discos Premium foram projetados para fornecer baixa latência, alto desempenho e desempenho de disco consistente para VMs.
O seguinte exemplo de manifesto YAML mostra uma definição de classe de armazenamento para um disco Premium:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: premium2-disk-sc
parameters:
cachingMode: None
skuName: PremiumV2_LRS
DiskIOPSReadWrite: "4000"
DiskMBpsReadWrite: "1000"
provisioner: disk.csi.azure.com
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
Para obter mais informações, confira Usar discos SSD Premium v2 do Azure no AKS.
Insights do contêiner
Orientação de melhor prática
Habilite os Insights de Contêiner para monitorar e diagnosticar o desempenho de seus aplicativos em contêineres.
Os Insights de contêiner são um recurso do Azure Monitor que coleta e analisa logs de contêiner do AKS. Você pode analisar os dados coletados com uma coleção de exibições e pastas de trabalho predefinidas.
Você pode habilitar o monitoramento dos Insights de Contêiner em seu cluster do AKS usando vários métodos. O exemplo a seguir mostra como habilitar o monitoramento dos Insights de Contêiner em um cluster existente usando a CLI do Azure:
az aks enable-addons -a monitoring --name myAKSCluster --resource-group myResourceGroup
Para obter mais informações, confira Habilitar o monitoramento para clusters do Kubernetes.
Azure Policy
Orientação de melhor prática
Aplique e imponha requisitos de segurança e conformidade para seus clusters do AKS usando o Azure Policy.
Você pode aplicar e impor políticas de segurança internas em seus clusters do AKS usando o Azure Policy. O Azure Policy ajuda a impor os padrões organizacionais e a avaliar a conformidade em escala. Depois de instalar o complemento do Azure Policy para AKS, você pode aplicar definições de política individuais ou grupos de definições de política chamadas iniciativas aos clusters.
Para obter mais informações, confira Proteger seus clusters do AKS com o Azure Policy.
Próximas etapas
Este artigo se concentrou nas melhores práticas de implantação e confiabilidade do cluster para clusters do Serviço de Kubernetes do Azure (AKS). Para ver mais melhores práticas, confira os seguintes artigos:
Azure Kubernetes Service