Práticas recomendadas de implantação e confiabilidade de cluster para o Serviço Kubernetes do Azure (AKS)
Este artigo fornece práticas recomendadas para confiabilidade de cluster implementadas em nível de implantação e cluster para suas cargas de trabalho do Serviço Kubernetes do Azure (AKS). O artigo destina-se a operadores de cluster e desenvolvedores que são responsáveis pela implantação e gerenciamento de aplicativos no AKS.
As práticas recomendadas neste artigo estão organizadas nas seguintes categorias:
Práticas recomendadas de nível de implantação
As seguintes práticas recomendadas de nível de implantação ajudam a garantir alta disponibilidade e confiabilidade para suas cargas de trabalho do AKS. Essas práticas recomendadas são configurações locais que você pode implementar nos arquivos YAML para seus pods e implantações.
Nota
Certifique-se de implementar essas práticas recomendadas sempre que implantar uma atualização em seu aplicativo. Caso contrário, você pode ter problemas com a disponibilidade e a confiabilidade do seu aplicativo, como tempo de inatividade não intencional do aplicativo.
Orçamentos de interrupção de pod (PDBs)
Orientações sobre boas práticas
Use Pod Disruption Budgets (PDBs) para garantir que um número mínimo de pods permaneça disponível durante interrupções voluntárias, como operações de upgrade ou exclusões acidentais de pods.
Os PDBs (Pod Disruption Budgets) 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 pods. Usando PDBs, você pode definir uma contagem mínima ou máxima de recursos indisponíveis. Os PDBs só afetam a API de despejo para interrupções voluntárias.
Por exemplo, digamos que você precise executar uma atualização de cluster e já tenha um PDB definido. Antes de executar a atualização do cluster, o agendador do Kubernetes garante que o número mínimo de pods definido 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 agendará pods extras em outros nós antes de permitir que a atualização continue. Se você não definir um PDB, o agendador não terá restrições sobre 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 de definição PDB de exemplo a seguir, o minAvailable campo 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 uma percentagem do número desejado de vagens (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, consulte Planejar a disponibilidade usando PDBs e Especificando um orçamento de interrupção para seu aplicativo.
Limites de CPU e memória do pod
Orientações sobre boas práticas
Defina limites de CPU e memória para todos os pods para garantir que os pods não consumam todos os recursos em um nó e para fornecer proteção durante ameaças de serviço, como ataques 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, consulte Unidades de recursos de CPU no Kubernetes e Unidades de recursos de memória no Kubernetes.
A definição de limites de CPU e memória ajuda a manter a integridade do nó e minimiza o impacto em outros pods no nó. Evite definir um limite de pod mais alto do que seus nós podem suportar. Cada nó 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 suportar, seu aplicativo pode 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, consulte Impor cotas de recursos no AKS.
No seguinte exemplo de arquivo de definição de pod, a resources seção 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
Gorjeta
Você pode usar o kubectl describe node comando para exibir a CPU e a capacidade de memória dos 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, consulte Atribuir recursos de CPU a contêineres e pods e Atribuir recursos de memória a contêineres e pods.
Ganchos pré-parada
Orientações sobre boas práticas
Quando aplicável, use ganchos de pré-parada para garantir a terminação normal de um recipiente.
Um PreStop gancho é 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 teste de ativação/inicialização. Uma chamada para o PreStop gancho falhará se o contêiner já estiver em um estado encerrado ou concluído, e o gancho deve ser concluído antes que o sinal TERM para parar o contêiner seja enviado. A contagem regressiva do período de carência de término do pod começa antes que o PreStop gancho seja executado, de modo que o contêiner eventualmente termina dentro do período de carência de rescisão.
O seguinte exemplo de arquivo de definição de pod mostra como usar um PreStop gancho 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, consulte Ganchos de ciclo de vida do contêiner e Encerramento de pods.
maxIndisponível
Orientações sobre boas práticas
Defina o número máximo de pods que podem ficar indisponíveis durante uma atualização contínua usando o
maxUnavailablecampo em sua implantação para garantir que um número mínimo de pods permaneça disponível durante a atualização.
O maxUnavailable campo especifica o número máximo de pods que podem estar indisponíveis durante o processo de atualização. O valor pode ser um número absoluto (por exemplo, 3) ou uma percentagem do número desejado de vagens (por exemplo, 10%). maxUnavailable pertence à API de exclusão, que é usada durante atualizações contínuas.
O exemplo de manifesto de implantação a seguir usa o maxAvailable campo para definir o número máximo de pods que podem estar 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, consulte Max indisponível.
Restrições de propagação da topologia do pod
Orientações sobre boas práticas
Use restrições de propagação de topologia de pod para garantir que os pods estejam espalhados por diferentes nós ou zonas para melhorar a disponibilidade e a confiabilidade.
Você pode usar restrições de propagação de topologia de pod para controlar como os pods são distribuídos pelo cluster com base na topologia dos nós e pods espalhados por diferentes nós ou zonas para melhorar a disponibilidade e a confiabilidade.
O seguinte exemplo de arquivo de definição de pod mostra como usar o topologySpreadConstraints campo para espalhar pods por diferentes nós:
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, consulte Pod Topology Spread Constraints.
Prontidão, vivacidade e sondas de arranque
Orientações sobre boas práticas
Configure sondas de prontidão, vivacidade e inicialização quando aplicável para melhorar a resiliência para cargas altas e reinicializações de contêineres mais baixas.
Sondas de prontidão
No Kubernetes, o kubelet usa testes de prontidão para saber quando um contêiner está pronto para começar a aceitar tráfego. Um pod é considerado pronto quando todos os seus recipientes estiverem prontos. Quando um pod não está pronto, ele é removido dos balanceadores de carga de serviço. Para obter mais informações, consulte Testes de preparação no Kubernetes.
O seguinte exemplo de arquivo de definição de pod mostra uma configuração de teste de preparação:
readinessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
Para obter mais informações, consulte Configurar testes de preparação.
Sondas de vivacidade
No Kubernetes, o kubelet usa sondas de vivacidade para saber quando reiniciar um contêiner. Se um contêiner falhar em sua sonda de vivacidade, ele será reiniciado. Para obter mais informações, consulte Liveness Probes no Kubernetes.
O seguinte exemplo de arquivo de definição de pod mostra uma configuração de sonda liveness:
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
Outro tipo de teste de vivacidade usa uma solicitação HTTP GET. O seguinte exemplo de arquivo de definição de pod mostra uma configuração de teste de vivacidade 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, consulte Configurar testes de vivacidade e Definir uma solicitação HTTP de vivacidade.
Sondas de arranque
No Kubernetes, o kubelet usa testes de inicialização para saber quando um aplicativo de contêiner foi iniciado. Quando você configura um teste de inicialização, os testes de prontidão e vivacidade não são iniciados até que o teste de inicialização seja bem-sucedido, garantindo que os testes de prontidão e vivacidade não interfiram na inicialização do aplicativo. Para obter mais informações, consulte Sondas de inicialização no Kubernetes.
O seguinte exemplo de arquivo de definição de pod mostra uma configuração de teste de inicialização:
startupProbe:
httpGet:
path: /healthz
port: 8080
failureThreshold: 30
periodSeconds: 10
Aplicativos com várias réplicas
Orientações sobre boas práticas
Implante pelo menos duas réplicas do seu aplicativo para garantir alta disponibilidade e resiliência em cenários de nó inativo.
No Kubernetes, você pode usar o replicas campo em sua implantação para especificar o número de pods que deseja executar. A execução de várias instâncias do seu aplicativo ajuda a garantir alta disponibilidade e resiliência em cenários de nó para baixo. Se você tiver zonas de disponibilidade habilitadas, poderá usar o replicas campo para especificar o número de pods que deseja executar em várias zonas de disponibilidade.
O seguinte exemplo de arquivo de definição de pod mostra como usar o replicas campo 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, consulte Visão geral da solução de alta disponibilidade ativa-ativa recomendada para AKS e réplicas em Especificações de implantação.
Práticas recomendadas no nível do pool de clusters e nós
As seguintes práticas recomendadas de nível de cluster e pool de nós ajudam a garantir alta disponibilidade e confiabilidade para seus clusters AKS. Você pode implementar essas práticas recomendadas ao criar ou atualizar seus clusters AKS.
Zonas de disponibilidade
Orientações sobre boas práticas
Use várias zonas de disponibilidade ao criar um cluster AKS para garantir alta disponibilidade em cenários de zone-down. Lembre-se de que não é possível alterar a configuração da zona de disponibilidade depois de criar o cluster.
As zonas de disponibilidade são grupos separados de datacenters dentro de uma região. Essas zonas sã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 pelo clima. O uso de zonas de disponibilidade ajuda seus dados a permanecerem sincronizados e acessíveis em cenários de zone-down. Para obter mais informações, consulte Executando em várias zonas.
Dimensionamento automático de cluster
Orientações sobre boas práticas
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 carga baixa.
Para acompanhar as demandas de aplicativos no AKS, talvez seja necessário ajustar o número de nós que executam suas cargas de trabalho. O componente autoscaler do cluster procura pods no cluster que não podem ser agendados devido a restrições de recursos. Quando o autoscaler do cluster deteta 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, consulte Dimensionamento automático de cluster no AKS.
Você pode usar o --enable-cluster-autoscaler parâmetro ao criar um cluster AKS para habilitar o autoscaler 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 autoscaler de cluster em um pool de nós existente e configurar detalhes mais granulares do autoscaler de cluster alterando os valores padrão no perfil de autoscaler em todo o cluster.
Para obter mais informações, consulte Usar o autoscaler de cluster no AKS.
Balanceador de Carga Standard
Orientações sobre boas práticas
Use o Standard Load Balancer para fornecer maior confiabilidade e recursos, suporte para várias zonas de disponibilidade, sondas HTTP e funcionalidade em vários data centers.
No Azure, a SKU do Balanceador de Carga Padrão foi projetada para ser equipada para o tráfego da camada de rede de balanceamento de carga quando são necessários alto desempenho e baixa latência. O Standard Load Balancer encaminha o tráfego dentro e entre regiões e para zonas de disponibilidade para alta resiliência. O SKU padrão é o SKU recomendado e padrão a ser usado ao criar um cluster AKS.
Importante
Em 30 de setembro de 2025, o Basic Load Balancer será aposentado. Para obter mais informações, veja 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, consulte Atualizando do Basic Load Balancer.
O exemplo a seguir mostra um LoadBalancer manifesto de serviço 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, consulte Usar um balanceador de carga padrão no AKS.
Gorjeta
Você também pode usar um controlador de entrada ou uma malha de serviço para gerenciar o tráfego de rede, com cada opção fornecendo recursos e capacidades diferentes.
Conjuntos de nós de sistema
Usar pools de nós do sistema dedicados
Orientações sobre boas práticas
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 de 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 CriticalAddonsOnly taint no pool de nós do sistema. Para obter mais informações, consulte Usar pools de nós do sistema no AKS.
Dimensionamento automático para pools de nós do sistema
Orientações sobre boas práticas
Configure o autoscaler para pools de nós do sistema para definir limites de escala mínimos e máximos para o pool de nós.
Use o autoscaler em pools de nós para configurar os limites de escala mínima e máxima para o pool de nós. O pool de nós do sistema deve sempre ser capaz de ser dimensionado para atender às demandas dos pods do sistema. Se o pool de nós do sistema não puder ser dimensionado, o cluster ficará sem recursos para ajudar a gerenciar o agendamento, o dimensionamento e o balanceamento de carga, o que pode levar a um cluster que não responde.
Para obter mais informações, consulte Usar o autoscaler de cluster em pools de nós.
Pelo menos três nós por pool de nós do sistema
Orientações sobre boas práticas
Certifique-se de que os pools de nós do sistema tenham pelo menos três nós para garantir resiliência contra cenários de congelamento/atualização, o que pode levar à reinicialização ou desligamento dos nós.
Os pools de nós do sistema são usados para executar pods do sistema, como o kube-proxy, coredns e o plug-in CNI do Azure. Recomendamos que você garanta que os pools de nós do sistema tenham pelo menos três nós para garantir a resiliência contra cenários de congelamento/atualização, o que pode levar à reinicialização ou desligamento dos nós. Para obter mais informações, consulte Gerenciar pools de nós do sistema no AKS.
Redes Aceleradas
Orientações sobre boas práticas
Use a Rede Acelerada para fornecer menor latência, menor desvio e menor utilização da CPU em suas VMs.
A rede acelerada permite a virtualização de E/S de raiz única (SR-IOV) em tipos de VM suportados, melhorando consideravelmente o desempenho da rede.
O diagrama a seguir ilustra como duas VMs se comunicam com e sem rede acelerada:
Para obter mais informações, consulte Visão geral da rede acelerada.
Versões de imagem
Orientações sobre boas práticas
As imagens não devem usar a
latesttag .
Etiquetas de imagem de contentor
O uso da latest tag para imagens de contêiner pode levar a um comportamento imprevisível e dificulta o rastreamento de qual versão da imagem está sendo executada no cluster. Você pode minimizar esses riscos integrando e executando ferramentas de verificação e correção em seus contêineres na compilação e no tempo de execução. Para obter mais informações, consulte Práticas recomendadas para gerenciamento de imagens de contêiner no AKS.
Atualizações de imagem de 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 tempo das atualizações. Recomendamos aderir a 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, consulte Imagens do sistema operacional do nó de atualização automática no AKS.
Nível padrão para cargas de trabalho de produção
Orientações sobre boas práticas
Use a camada Standard para cargas de trabalho de produtos 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 o nível Premium.
A camada Standard para o Serviço Kubernetes do Azure (AKS) fornece um contrato de nível de serviço (SLA) de 99,9% de tempo de atividade com suporte financeiro para suas cargas de trabalho de produção. A camada padrão 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, consulte Níveis de preços para gerenciamento de cluster AKS.
Azure CNI para alocação dinâmica de IP
Orientações sobre boas práticas
Configure o Azure CNI para alocação dinâmica de IP para melhor utilização de IP e para evitar o esgotamento de IP para clusters AKS.
O recurso de alocação de IP dinâmico no Azure CNI aloca IPs de pod de uma sub-rede separada da sub-rede que hospeda o cluster AKS e oferece os seguintes benefícios:
- Melhor utilização de IP: os IPs são alocados dinamicamente para Pods de cluster a partir da sub-rede do Pod. Isso leva a uma melhor utilização de IPs no cluster em comparação com a solução CNI tradicional, que faz alocação estática de IPs para cada nó.
- Escalável e flexível: as sub-redes de nós e pods podem ser dimensionadas de forma independente. Uma única sub-rede de pod pode ser compartilhada entre vários pools de nós de um cluster ou entre vários clusters AKS implantados na mesma VNet. Você também pode configurar uma sub-rede de pod separada para um pool de nós.
- Alto desempenho: Como os pods recebem IPs de rede virtual, eles têm conectividade direta com outros pods de cluster e recursos na rede virtual. A solução suporta clusters muito grandes sem qualquer degradação no desempenho.
- Políticas de VNet separadas para pods: como os pods têm uma sub-rede separada, você pode configurar políticas de VNet separadas para eles que são diferentes das políticas de nó. Isso permite muitos cenários úteis, como permitir conectividade com a Internet apenas para pods e não para nós, corrigir o IP de origem para pod em um pool de nós usando um Gateway NAT do Azure e usar 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, consulte Configurar a rede CNI do Azure para alocação dinâmica de IPs e suporte aprimorado a sub-redes.
VMs SKU v5
Orientações sobre boas práticas
Use SKUs de VM v5 para melhorar o desempenho durante e após as atualizações, menos impacto geral e uma conexão mais confiável para seus aplicativos.
Para pools de nós no AKS, use VMs SKU v5 com discos de sistema operacional efêmeros para fornecer recursos de computação suficientes para pods do sistema kube. Para obter mais informações, consulte Práticas recomendadas para desempenho e dimensionamento de grandes cargas de trabalho no AKS.
Não use VMs da série B
Orientações sobre boas práticas
Não use VMs da série B para clusters AKS porque elas são de baixo desempenho e não funcionam bem com o AKS.
As VMs da série B são de baixo desempenho e não funcionam bem com o AKS. Em vez disso, recomendamos o uso de VMs SKU v5.
Discos Premium
Orientações sobre boas práticas
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 submilissegundos consistente e IOPS altas e por toda parte. Os discos Premium são projetados para fornecer baixa latência, alto desempenho e desempenho de disco consistente para VMs.
O exemplo de manifesto YAML a seguir 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, consulte Usar discos SSD Premium v2 do Azure no AKS.
Container Insights
Orientações sobre boas práticas
Habilite o Container Insights para monitorar e diagnosticar o desempenho de seus aplicativos em contêineres.
O Container Insights é 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 pré-criadas.
Você pode habilitar o monitoramento do Container Insights em seu cluster AKS usando vários métodos. O exemplo a seguir mostra como habilitar o monitoramento do Container Insights 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, consulte Habilitar monitoramento para clusters Kubernetes.
Azure Policy
Orientações sobre boas práticas
Aplique e imponha requisitos de segurança e conformidade para seus clusters AKS usando a Política do Azure.
Você pode aplicar e impor políticas de segurança internas em seus clusters AKS usando a Política do Azure. A Política do Azure ajuda a impor padrões organizacionais e a avaliar a conformidade em escala. Depois de instalar o complemento Política do Azure para AKS, você pode aplicar definições de política individuais ou grupos de definições de política chamadas iniciativas aos seus clusters.
Para obter mais informações, consulte Proteger seus clusters AKS com a Política do Azure.
Próximos passos
Este artigo concentrou-se nas práticas recomendadas para implantação e confiabilidade de cluster para clusters do Serviço Kubernetes do Azure (AKS). Para obter mais práticas recomendadas, consulte os seguintes artigos:
Azure Kubernetes Service