Solucionar problemas do Armazenamento de Contêineres do Azure
O Armazenamento de Contêineres do Azure é um serviço de gerenciamento de volume, implantação e orquestração baseado em nuvem criado nativamente para contêineres. Use este artigo para solucionar problemas comuns com o Armazenamento de Contêiner do Azure e encontrar resoluções para problemas.
Solucionar problemas de instalação
O Armazenamento de contêineres do Azure falha ao instalar devido à configuração ausente
Depois de executar az aks create, talvez você veja a mensagem Falha na instalação do Armazenamento de Contêiner do Azure. O cluster do AKS é criado. Execute az aks update juntamente com --enable-azure-container-storage para habilitar o Armazenamento de Contêiner do Azure.
Esta mensagem significa que o Armazenamento de Contêiner do Azure não foi instalado, mas o cluster do AKS (Serviço de Kubernetes do Azure) foi criado corretamente.
Para instalar o Armazenamento de Contêiner do Azure no cluster e criar um pool de armazenamento, execute o comando a seguir. Substitua <cluster-name> e <resource-group> pelos seus próprios valores. Substitua <storage-pool-type> por azureDisk, ephemeraldisk ou elasticSan.
az aks update -n <cluster-name> -g <resource-group> --enable-azure-container-storage <storage-pool-type>
O Armazenamento de contêineres do Azure falha ao instalar devido a restrições da Azure Policy
O Armazenamento de Contêineres do Azure pode falhar na instalação se houver restrições do Azure Policy. Especificamente, o Armazenamento de Contêiner do Azure depende de contêineres com privilégios. Você pode configurar o Azure Policy para bloquear contêineres com privilégios. Quando eles estão bloqueados, a instalação do Armazenamento de Contêiner do Azure pode expirar ou falhar e você poderá ver erros nos logs gatekeeper-controller, como:
$ kubectl logs -n gatekeeper-system deployment/gatekeeper-controller
...
{"level":"info","ts":1722622443.9484184,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: prereq, securityContext: {\"privileged\": true, \"runAsUser\": 0}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-prereq-gt58x","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}
{"level":"info","ts":1722622443.9839077,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: metrics-exporter, securityContext: {\"privileged\": true}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-metrics-exporter-286np","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}
{"level":"info","ts":1722622444.0515249,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: csi-node, securityContext: {\"privileged\": true}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-csi-node-7hcd7","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}
{"level":"info","ts":1722622444.0729053,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: io-engine, securityContext: {\"privileged\": true}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-io-engine-84hwx","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}
{"level":"info","ts":1722622444.0742755,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: ndm, securityContext: {\"privileged\": true}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-ndm-x6q5n","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}
{"level":"info","ts":1722622449.2412128,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: ndm, securityContext: {\"privileged\": true}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-ndm-b5nfg","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}
Para resolver o bloqueio, você precisa adicionar o namespace acstor à lista de exclusão do Azure Policy. O Azure Policy é usado para criar e aplicar regras de gerenciamento de recursos no Azure, incluindo clusters do AKS. Em alguns casos, as políticas podem bloquear a criação de pods e componentes do Armazenamento de contêineres do Azure. Você pode encontrar mais detalhes sobre como trabalhar com o Azure Policy for Kubernetes consultando Azure Policy for Kubernetes.
Para adicionar o namespace acstor à lista de exclusão, siga essas etapas:
- Crie seu cluster do Azure Kubernetes.
- Habilitar a Azure Policy para AKS.
- Crie uma política que você suspeite estar bloqueando a instalação do Armazenamento de contêineres do Azure.
- Tente instalar o Armazenamento de contêineres do Azure no cluster AKS.
- Verifique os logs do pod gatekeeper-controller para confirmar quaisquer violações de política.
- Adicione o namespace
acstore o namespaceazure-extensions-usage-systemà lista de exclusão da política. - Tente instalar o Armazenamento de contêineres do Azure no cluster AKS novamente.
Não é possível instalar e habilitar o Armazenamento de Contêiner do Azure em pools de nós com taints
Você pode configurar taints de nós nos pools de nós para restringir o agendamento de pods nesses pools de nós. A instalação e habilitação do Armazenamento de Contêiner do Azure nesses pools de nós pode ser bloqueada porque os pods necessários não podem ser criados nesses pools de nós. O comportamento se aplica tanto ao pool de nós do sistema durante a instalação quanto aos pools de nós do usuário ao habilitar.
Você pode verificar as taints de nós com o exemplo a seguir:
$ az aks nodepool list -g $resourceGroup --cluster-name $clusterName --query "[].{PoolName:name, nodeTaints:nodeTaints}"
[
...
{
"PoolName": "nodepoolx",
"nodeTaints": [
"sku=gpu:NoSchedule"
]
}
]
Você pode remover essas taints temporariamente para desbloqueá-los e configurá-los novamente após a instalação e habilitação bem-sucedidas. Você pode ir para Portal do Azure > cluster do AKS > Pools de nós, clicar no pool de nós, remover as marcas na seção "Taints e rótulos". Ou você pode usar o seguinte comando para remover taints e confirmar a alteração.
$ az aks nodepool update -g $resourceGroup --cluster-name $clusterName --name $nodePoolName --node-taints ""
$ az aks nodepool list -g $resourceGroup --cluster-name $clusterName --query "[].{PoolName:name, nodeTaints:nodeTaints}"
[
...
{
"PoolName": "nodepoolx",
"nodeTaints": null
}
]
Repita a instalação ou habilitação após remover os taints de nós com êxito. Depois de concluído com êxito, você poderá reconfigurar os taints de nós para retomar as restrições de agendamento do pod.
Não foi possível definir o tipo de pool de armazenamento como NVMe
Se você tentar instalar o Armazenamento de Contêiner do Azure com disco efêmero, especificamente com o NVMe local em um cluster em que o SKU da VM (máquina virtual) não tem unidades NVMe, você receberá a seguinte mensagem de erro: Não é possível definir --storage-pool-option como NVMe, pois nenhum dos pools de nós pode dar suporte ao disco NVMe efêmero.
Para corrigir, crie um pool de nós com uma SKU de VM que tenha unidades NVMe e tente novamente. Confira VMs otimizadas para armazenamento.
Solucionar problemas de pool de armazenamento
Para verificar o status dos pools de armazenamento, execute kubectl describe sp <storage-pool-name> -n acstor. Aqui estão alguns problemas que você pode encontrar.
O pool de armazenamento efêmero não reivindica a capacidade quando os discos efêmeros são usados por outros daemonsets
Habilitar um pool de armazenamento efêmero em um pool de nós com discos SSD temporários ou NVMe locais pode não reivindicar capacidade desses discos se outros daemonsets os estiverem usando.
Execute as seguintes etapas para habilitar o Armazenamento de Contêiner do Azure para gerenciar esses discos locais exclusivamente:
Execute o seguinte comando para ver a capacidade reivindicada pelo pool de armazenamento efêmero:
$ kubectl get sp -A NAMESPACE NAME CAPACITY AVAILABLE USED RESERVED READY AGE acstor ephemeraldisk-nvme 0 0 0 0 False 82sEsse exemplo mostra zero capacidade reivindicada pelo pool de armazenamento
ephemeraldisk-nvme.Execute o seguinte comando para confirmar o estado não reivindicado desses dispositivos de bloco locais e verificar o sistema de arquivos existente nos discos:
$ kubectl get bd -A NAMESPACE NAME NODENAME SIZE CLAIMSTATE STATUS AGE acstor blockdevice-1f7ad8fa32a448eb9768ad8e261312ff aks-nodepoolnvme-38618677-vmss000001 1920383410176 Unclaimed Active 22m acstor blockdevice-9c8096fc47cc2b41a2ed07ec17a83527 aks-nodepoolnvme-38618677-vmss000000 1920383410176 Unclaimed Active 23m $ kubectl describe bd -n acstor blockdevice-1f7ad8fa32a448eb9768ad8e261312ff Name: blockdevice-1f7ad8fa32a448eb9768ad8e261312ff … Filesystem: Fs Type: ext4 …Esse exemplo mostra que os dispositivos de bloco estão com status
Unclaimede há um sistema de arquivos existente no disco.Confirme que você deseja usar o Armazenamento de Contêiner do Azure para gerenciar os discos de dados locais exclusivamente antes de continuar.
Interrompa e remova os daemonsets ou componentes que gerenciam discos de dados locais.
Faça logon em cada nó que tenha discos de dados locais.
Remova os sistemas de arquivos existentes de todos os discos de dados locais.
Reinicie o daemonset ndm para descobrir discos de dados locais não utilizados.
$ kubectl rollout restart daemonset -l app=ndm -n acstor daemonset.apps/azurecontainerstorage-ndm restarted $ kubectl rollout status daemonset -l app=ndm -n acstor --watch … daemon set "azurecontainerstorage-ndm" successfully rolled outAguarde alguns segundos e verifique se o pool de armazenamento efêmero reivindica a capacidade dos discos de dados locais.
$ kubectl wait -n acstor sp --all --for condition=ready storagepool.containerstorage.azure.com/ephemeraldisk-nvme condition met $ kubectl get bd -A NAMESPACE NAME NODENAME SIZE CLAIMSTATE STATUS AGE acstor blockdevice-1f7ad8fa32a448eb9768ad8e261312ff aks-nodepoolnvme-38618677-vmss000001 1920383410176 Claimed Active 4d16h acstor blockdevice-9c8096fc47cc2b41a2ed07ec17a83527 aks-nodepoolnvme-38618677-vmss000000 1920383410176 Claimed Active 4d16h $ kubectl get sp -A NAMESPACE NAME CAPACITY AVAILABLE USED RESERVED READY AGE acstor ephemeraldisk-nvme 3840766820352 3812058578944 28708241408 26832871424 True 4d16hEsse exemplo mostra que o pool de armazenamento
ephemeraldisk-nvmereivindica com êxito a capacidade dos discos NVMe locais nos nós.
Erro ao tentar expandir um pool de armazenamento dos Discos do Azure
Se o pool de armazenamento existente for menor que 4 TiB (4.096 GiB), você só poderá expandi-lo até 4.095 GiB. Se você tentar expandir além do limite, o PVC interno mostrará uma mensagem de erro sobre as limitações de tamanho do disco ou tipo de cache. Pare a VM ou desanexe o disco e experimente a operação novamente."
Para evitar erros, não tente expandir seu pool de armazenamento atual além de 4.095 GiB se ele for inicialmente menor que 4 TiB (4.096 GiB). Pools de armazenamento maiores que 4 TiB podem ser expandidos até a capacidade máxima de armazenamento disponível.
Essa limitação só se aplica ao usar os SKUs de disco Premium_LRS, Standard_LRS, StandardSSD_LRS, Premium_ZRS e StandardSSD_ZRS.
Falha na criação do Elastic SAN
Se você estiver tentando criar um pool de armazenamento do Elastic SAN, poderá ver a mensagem A criação do Azure Elastic SAN falhou: número máximo possível de Elastic SAN para a Assinatura já criado. Isso significa que você atingiu o limite de recursos Elastic SAN que podem ser implantados em uma região por assinatura. Confira o limite aqui: Metas de desempenho e escalabilidade do Elastic SAN. Considere excluir qualquer recurso existente do Elastic SAN na assinatura que não esteja sendo usado ou tente criar o pool de armazenamento em uma região diferente.
Nenhum dispositivo de bloco encontrado
Quando essa mensagem é exibida, isso significa que você provavelmente está tentando criar um pool de armazenamento de discos efêmeros em um cluster em que o SKU da VM não tem unidades NVMe.
Para corrigir, crie um pool de nós com uma SKU de VM que tenha unidades NVMe e tente novamente. Confira VMs otimizadas para armazenamento.
Tipo de pool de armazenamento já habilitado
Se você tentar habilitar um tipo de pool de armazenamento que já existe, receberá a seguinte mensagem: Valor --enable-azure-container-storage inválido. O Armazenamento de Contêiner do Azure já está habilitado para o tipo de pool de armazenamento <storage-pool-type> no cluster. Você pode verificar se tem pools de armazenamento existentes criados executando kubectl get sp -n acstor.
Desabilitar um tipo de pool de armazenamento
Ao desabilitar um tipo de pool de armazenamento por meio de az aks update --disable-azure-container-storage <storage-pool-type> ou desinstalar o Armazenamento de Contêiner do Azure por meio de az aks update --disable-azure-container-storage all, se houver um pool de armazenamento existente desse tipo, você receberá a seguinte mensagem:
Desabilitar o Armazenamento de Contêiner do Azure para o tipo de pool de armazenamento <storage-pool-type> exclui forçadamente todos os pools de armazenamento do mesmo tipo e afeta os aplicativos que usam esses pools de armazenamento. A exclusão forçada de pools de armazenamento também pode levar ao vazamento de recursos de armazenamento que estão sendo consumidos. Quer verificar se algum dos pools de armazenamento do tipo <storage-pool-type> está sendo usado antes de desabilitar o Armazenamento de Contêiner do Azure? (Y/n)
Se você selecionar Y, uma validação automática será executada para garantir que não haja volumes persistentes criados no pool de armazenamento. Selecionar n ignora essa validação e desabilita o tipo de pool de armazenamento, excluindo todos os pools de armazenamento existentes e possivelmente afetando seu aplicativo.
Solucionar problemas de volume
Pod pendente de criação devido a tamanho de volume efêmero além da capacidade disponível
Um volume efêmero é alocado em um único nó. Ao configurar o tamanho dos volumes efêmeros para seus pods, o tamanho deve ser menor do que a capacidade disponível do disco efêmero do nó único. Caso contrário, a criação do pod estará no status pendente.
Use o comando a seguir para verificar se a criação do pod está no status pendente.
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
fiopod 0/1 Pending 0 17s
Neste exemplo, o pod fiopod está no status Pending.
Use o comando a seguir para verificar se o pod tem o evento de aviso para a criação de persistentvolumeclaim.
$ kubectl describe pod fiopod
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 40s default-scheduler 0/3 nodes are available: waiting for ephemeral volume controller to create the persistentvolumeclaim "fiopod-ephemeralvolume". preemption: 0/3 nodes are available: 3 Preemption is not helpful for scheduling..
Neste exemplo, o pod mostra o evento de aviso na criação da declaração de volume persistente fiopod-ephemeralvolume.
Use o comando a seguir para verificar se a declaração de volume persistente não foi provisionada devido a capacidade insuficiente.
$ kubectl describe pvc fiopod-ephemeralvolume
...
Warning ProvisioningFailed 107s (x13 over 20m) containerstorage.csi.azure.com_aks-nodepool1-29463073-vmss000000_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx failed to provision volume with StorageClass "acstor-ephemeraldisk-temp": rpc error: code = Internal desc = Operation failed: GenericOperation("error in response: status code '507 Insufficient Storage', content: 'RestJsonError { details: \"Operation failed due to insufficient resources: Not enough suitable pools available, 0/1\", message: \"SvcError :: NotEnoughResources\", kind: ResourceExhausted }'")
Neste exemplo, Insufficient Storage é mostrado como o motivo da falha no provisionamento de volume.
Execute o comando a seguir para verificar a capacidade disponível do disco efêmero para apenas um nó.
$ kubectl get diskpool -n acstor
NAME CAPACITY AVAILABLE USED RESERVED READY AGE
ephemeraldisk-temp-diskpool-jaxwb 75660001280 75031990272 628011008 560902144 True 21h
ephemeraldisk-temp-diskpool-wzixx 75660001280 75031990272 628011008 560902144 True 21h
ephemeraldisk-temp-diskpool-xbtlj 75660001280 75031990272 628011008 560902144 True 21h
Neste exemplo, a capacidade disponível de disco efêmero para apenas um nó é 75031990272 bytes ou 69 GiB.
Ajuste o tamanho do armazenamento do volume para menos que a capacidade disponível e reimplante o pod. Confira Implantar um pod com um volume efêmero genérico.
O volume falha ao anexar devido ao repositório de metadados offline
O Armazenamento de Contêineres do Azure usa etcd, um repositório de chave-valor confiável e distribuído para armazenar e gerenciar metadados de volumes para dar suporte a operações de orquestração de volume. Para alta disponibilidade e resiliência, etcd é executado em três pods. Quando houver menos de duas instâncias etcd em execução, o Armazenamento de Contêiner do Azure interromperá as operações de orquestração de volumes, mas ainda permitirá o acesso aos dados dos volumes. O Armazenamento de Contêineres do Azure detecta automaticamente quando uma instância de etcd está offline e a recupera. No entanto, se você notar erros de orquestração de volumes após reiniciar um cluster do AKS, é possível que uma instância etcd não tenha sido recuperada automaticamente. Siga as instruções nesta seção para determinar o status de integridade das instâncias de etcd.
Execute o comando a seguir para obter uma lista de pods.
kubectl get pods
Você pode ver uma saída semelhante à seguinte.
NAME READY STATUS RESTARTS AGE
fiopod 0/1 ContainerCreating 0 25m
Descreva o pod:
kubectl describe pod fiopod
Normalmente, você verá mensagens de falha de volume se o repositório de metadados estiver offline. Neste exemplo, o fiopod está no status ContainerCreating e o aviso FailedAttachVolume indica que a criação está pendente devido a uma falha na anexação de volume.
Name: fiopod
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 25m default-scheduler Successfully assigned default/fiopod to aks-nodepool1-xxxxxxxx-vmss000009
Warning FailedAttachVolume 3m8s (x6 over 23m) attachdetach-controller AttachVolume.Attach failed for volume "pvc-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" : timed out waiting for external-attacher of containerstorage.csi.azure.com CSI driver to attach volume xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Execute o seguinte comando para verificar o status das instâncias de etcd:
kubectl get pods -n acstor | grep "^etcd"
Você deverá ver uma saída semelhante à seguinte, com todas as instâncias no estado Em execução:
etcd-azurecontainerstorage-bn89qvzvzv 1/1 Running 0 4d19h
etcd-azurecontainerstorage-phf92lmqml 1/1 Running 0 4d19h
etcd-azurecontainerstorage-xznvwcgq4p 1/1 Running 0 4d19h
Se menos de duas instâncias estiverem em execução, o volume não será anexado porque o repositório de metadados estará offline e a recuperação automática terá falhado. Se for o caso, registre um tíquete de suporte com o Suporte do Azure.