Solucionar problemas do Armazenamento de Contêiner do Azure
O Armazenamento de Contêineres do Azure é um serviço de gerenciamento, implantação e orquestração de volumes 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 soluções para problemas.
Solucionar problemas de instalação
Falha na instalação do Armazenamento de Contêiner do Azure devido à configuração ausente
Depois de executar az aks createo , poderá ver a mensagem Falha na instalação do Armazenamento de Contentores do Azure. O cluster AKS é criado. Execute az aks update junto com --enable-azure-container-storage para habilitar o Armazenamento de Contêiner do Azure.
Esta mensagem significa que o Armazenamento de Contentores do Azure não foi instalado, mas o cluster AKS (Serviço 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 seguinte comando. Substitua <cluster-name> e <resource-group> com os seus próprios valores. Substitua <storage-pool-type> por azureDisk, ephemeraldiskou elasticSan.
az aks update -n <cluster-name> -g <resource-group> --enable-azure-container-storage <storage-pool-type>
Falha na instalação do Armazenamento de Contêiner do Azure devido a restrições da Política do Azure
O Armazenamento de Contêiner do Azure pode falhar na instalação se as restrições da Política do Azure estiverem em vigor. Especificamente, o Armazenamento de Contêineres do Azure depende de contêineres privilegiados. Você pode configurar a Política do Azure para bloquear contêineres privilegiados. Quando eles são bloqueados, a instalação do Armazenamento de Contêiner do Azure pode atingir o tempo limite ou falhar, e você pode ver erros nos gatekeeper-controller logs, 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 acstor namespace à lista de exclusão da sua Política do Azure. A Política do Azure é usada para criar e impor regras para gerenciar recursos no Azure, incluindo clusters AKS. Em alguns casos, as políticas podem bloquear a criação de pods e componentes do Armazenamento de Contêiner do Azure. Você pode encontrar mais detalhes sobre como trabalhar com a Política do Azure para Kubernetes consultando a Política do Azure para Kubernetes.
Para adicionar o acstor namespace à lista de exclusão, siga estas etapas:
- Crie seu cluster do Kubernetes do Azure.
- Habilite a Política do Azure para AKS.
- Crie uma política que você suspeita estar bloqueando a instalação do Armazenamento de Contêiner do Azure.
- Tente instalar o Armazenamento de Contêiner do Azure no cluster AKS.
- Verifique os logs do pod gatekeeper-controller para confirmar quaisquer violações de política.
- Adicione o namespace e
azure-extensions-usage-systemoacstornamespace à lista de exclusão da política. - Tente instalar o Armazenamento de Contêiner 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 manchas
Você pode configurar manchas de nó nos pools de nós para impedir que os pods sejam agendados nesses pools de nós. A instalação e habilitação do Armazenamento de Contêiner do Azure nesses pools de nós pode estar bloqueada porque os pods necessários não podem ser criados nesses pools de nós. O comportamento se aplica ao pool de nós do sistema ao instalar e aos pools de nós do usuário ao ativar.
Você pode verificar as manchas do nó com o seguinte exemplo:
$ az aks nodepool list -g $resourceGroup --cluster-name $clusterName --query "[].{PoolName:name, nodeTaints:nodeTaints}"
[
...
{
"PoolName": "nodepoolx",
"nodeTaints": [
"sku=gpu:NoSchedule"
]
}
]
Você pode remover essas manchas temporariamente para desbloqueá-las e configurá-las novamente depois de instalar e ativar com êxito. Você pode ir para Pools de nós de cluster > AKS do Portal > do Azure, clicar em seu pool de nós, remover as manchas na seção "Manchas e rótulos". Ou você pode usar o seguinte comando para remover manchas 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
}
]
Tente instalar ou ativar novamente depois de remover as manchas de nó com êxito. Depois que ele for concluído com êxito, você poderá configurar as manchas de nó de volta para retomar as restrições de agendamento do pod.
Não é 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 NVMe local em um cluster onde a SKU de máquina virtual (VM) 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 suportar disco NVMe efêmero.
Para corrigir, crie um pool de nós com uma SKU de VM que tenha unidades NVMe e tente novamente. Consulte VMs otimizadas para armazenamento.
Solucionar problemas do 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 SSD temporário ou discos NVMe locais pode não reivindicar capacidade desses discos se outros daemonsets estiverem usando-os.
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 por 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 82sEste exemplo mostra a capacidade zero reivindicada pelo
ephemeraldisk-nvmepool de armazenamento.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 …Este exemplo mostra que os dispositivos de bloco estão
Unclaimedstatus e há um sistema de arquivos existente no disco.Confirme que deseja usar o Armazenamento de Contêiner do Azure para gerenciar exclusivamente os discos de dados locais antes de continuar.
Pare e remova os daemonsets ou componentes que gerenciam discos de dados locais.
Faça login em cada nó que tenha discos de dados locais.
Remova os sistemas de arquivos existentes de todos os discos de dados locais.
Reinicie o ndm daemonset 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 de 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 4d16hEste exemplo mostra
ephemeraldisk-nvmeque o pool de armazenamento reivindica com êxito a capacidade de discos NVMe locais nos nós.
Erro ao tentar expandir um pool de armazenamento do Azure Disks
Se o pool de armazenamento existente for inferior a 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 o tamanho do disco ou limitações de tipo de cache. Pare sua VM ou desanexe o disco e tente novamente a operação."
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 Premium_LRS, Standard_LRS, StandardSSD_LRS, Premium_ZRSe StandardSSD_ZRS SKUs de disco.
Falha na criação do Elastic SAN
Se você estiver tentando criar um pool de armazenamento Elastic SAN, poderá ver a mensagem Falha na criação do Azure Elastic SAN: Número máximo possível de SAN elástica para a Assinatura já criada. Isso significa que você atinge o limite do número de recursos do Elastic SAN que podem ser implantados em uma região por assinatura. Você pode verificar o limite aqui: Metas de desempenho e escalabilidade do Elastic SAN. Considere excluir todos os recursos existentes do Elastic SAN na assinatura que não estão mais sendo usados ou tente criar o pool de armazenamento em uma região diferente.
Nenhum dispositivo de bloqueio encontrado
Se você vir essa mensagem, provavelmente está tentando criar um pool de armazenamento de disco efêmero em um cluster onde a 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. Consulte VMs otimizadas para armazenamento.
Tipo de pool de armazenamento já ativado
Se você tentar habilitar um tipo de pool de armazenamento que existe, receberá a seguinte mensagem: Valor inválido --enable-azure-container-storage . O Armazenamento de Contêiner do Azure já está habilitado para o tipo <storage-pool-type> de pool de armazenamento no cluster. Você pode verificar se tem algum pool de armazenamento existente criado executando kubectl get sp -n acstoro .
Desativando um tipo de pool de armazenamento
Ao desabilitar um tipo de pool de armazenamento por meio az aks update --disable-azure-container-storage <storage-pool-type> ou desinstalar o Armazenamento de Contêiner do Azure via az aks update --disable-azure-container-storage all, se houver um pool de armazenamento existente desse tipo, você receberá a seguinte mensagem:
A desativação do Armazenamento de Contêiner do Azure para o tipo <storage-pool-type> de pool de armazenamento exclui com força 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. Deseja validar se algum dos pools de armazenamento do tipo <storage-pool-type> está sendo usado antes de desabilitar o Armazenamento de Contêiner do Azure? (S/n)
Se você selecionar Y, uma validação automática será executada para garantir que não haja volumes persistentes criados a partir do pool de armazenamento. A seleção de n ignora essa validação e desabilita o tipo de pool de armazenamento, excluindo todos os pools de armazenamento existentes e potencialmente afetando seu aplicativo.
Solucionar problemas de volume
Pod pendente de criação devido ao tamanho do volume efêmero além da capacidade disponível
Um volume efêmero é alocado em um único nó. Quando você configura o tamanho dos volumes efêmeros para seus pods, o tamanho deve ser menor do que a capacidade disponível do disco efêmero de um único nó. Caso contrário, a criação do pod estará em status pendente.
Use o comando a seguir para verificar se a criação do pod está em status pendente.
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
fiopod 0/1 Pending 0 17s
Neste exemplo, o pod fiopod está em Pending status.
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 ao criar a declaração fiopod-ephemeralvolumede volume persistente.
Use o comando a seguir para verificar se a declaração de volume persistente não é provisionada devido à 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 de provisionamento de volume.
Execute o seguinte comando para verificar a capacidade disponível do disco efêmero de um único 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 do disco temporário para um único nó é 75031990272 de bytes ou 69 GiB.
Ajuste o tamanho do volume de armazenamento menor do que a capacidade disponível e reimplante seu pod. Consulte Implantar um pod com um volume efêmero genérico.
O volume não é anexado devido ao armazenamento de metadados offline
O Armazenamento de Contêineres do Azure usa etcdo , um armazenamento de chave-valor distribuído e confiável, para armazenar e gerenciar metadados de volumes para dar suporte a operações de orquestração de volumes. Para alta disponibilidade e resiliência, etcd funciona em três pods. Quando há menos de duas etcd instâncias em execução, o Armazenamento de Contêiner do Azure interrompe as operações de orquestração de volumes e, ao mesmo tempo, permite o acesso aos dados aos volumes. O Armazenamento de Contêiner do Azure deteta automaticamente quando uma etcd instância está offline e a recupera. No entanto, se você notar erros de orquestração de volume após reiniciar um cluster AKS, é possível que uma etcd instância não tenha conseguido recuperar automaticamente. Siga as instruções nesta seção para determinar o etcd status de integridade das instâncias.
Execute o seguinte comando 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, fiopod está no status ContainerCreating e o aviso FailedAttachVolume indica que a criação está pendente devido a uma falha de 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
Você também pode executar o seguinte comando para verificar o status das etcd instâncias:
kubectl get pods -n acstor | grep "^etcd"
Você deve 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 está offline e a recuperação automatizada falhou. Em caso afirmativo, registre um tíquete de suporte com o Suporte do Azure.