Observações e restrições

Clusters e nós

• Depois que um cluster é criado, os seguintes itens não podem ser alterados:
  • Tipo do cluster. Por exemplo, altere um cluster de Kunpeng para um cluster do CCE.
  • Número de nós principais no cluster.
  • AZ de um nó principal.
  • Configuração de rede do cluster, como a VPC, sub-rede, bloco CIDR de container, bloco CIDR de serviço, configurações IPv6 e configurações kube-proxy (encaminhamento).
  • Modelo de rede. Por exemplo, altere a rede de túneis para a rede da VPC.
• As aplicações não podem ser migrados entre namespaces diferentes.
• Atualmente, as instâncias (nós) do ECS criadas são compatíveis com os modos de pagamento por uso e modo de cobrança anual/mensal. Outros recursos (como balanceadores de carga) são compatíveis com o modo de cobrança de pagamento por uso. Você pode alterar o modo de cobrança de pagamento por uso para anual/mensal no console de gerenciamento para as instâncias do ECS criadas.
• Os nós criados durante a criação do cluster oferecem suporte aos modos de pagamento por uso e modos de cobrança anual/mensal, mas com as seguintes restrições:
  • Se o cluster a ser criado for pay-per-use, os nós criados no cluster também deverão ser pay-per-use.
  • Se o cluster a ser criado for cobrado anualmente/mensalmente, os nós no cluster são pagos por uso ou cobrados anualmente/mensalmente.
  • Se os nós adicionados após a criação do cluster forem cobrados anualmente/mensalmente, eles precisarão ser renovados separadamente do cluster.

  Observação: se você comprar um nó depois que um cluster for criado, o modo de cobrança do nó não será restringido pelo do cluster.

• Os recursos subjacentes, como ECSs (nós), são limitados por cotas e seu inventário. Portanto, apenas alguns nós podem ser criados com êxito durante a criação do cluster, o escalonamento do cluster ou o dimensionamento automático.
• As especificações do ECS (nó) devem ter mais de 2 núcleos e 4 GB de memória.
• Para acessar um cluster do CCE por meio de uma VPN, certifique-se de que o bloco CIDR da VPN não entre em conflito com o bloco CIDR da VPC em que o cluster reside e o bloco CIDR do container.

Redes

• Por padrão, um serviço NodePort é acessado dentro de uma VPC. Se você precisar usar um EIP para acessar um serviço NodePort por meio de redes públicas, vincule um EIP ao nó do cluster com antecedência:
• Os Serviços LoadBalancer permitem que as cargas de trabalho sejam acessadas de redes públicas por meio do ELB. Este modo de acesso tem as seguintes restrições:
  • Balanceadores de carga criados automaticamente não devem ser usados por outros recursos. Caso contrário, esses balanceadores de carga não poderão ser completamente excluídos.
  • Não altere o nome do ouvinte do balanceador de carga em clusters v1.15 e anteriores. Caso contrário, o balanceador de carga não poderá ser acessado.
• Restrições nas políticas de rede:
  • Apenas os clusters que usam o modelo de rede de túnel suportam políticas de rede. As políticas de rede são classificadas nos seguintes tipos:
    • Ingress: todas as versões suportam este tipo.
    • Egress: este tipo de regra não pode ser definido atualmente.
  • O isolamento de rede não é suportado para endereços IPv6.

Volumes

• Restrições em volumes do EVS:
  • Os discos EVS não podem ser conectados em AZs e não podem ser usados por várias cargas de trabalho, vários pods da mesma carga de trabalho ou várias tarefas. O compartilhamento de dados de um disco compartilhado não é suportado entre nós em um cluster do CCE. Se um disco EVS for atacado a vários nós, podem ocorrer conflitos de I/O e conflitos de cache de dados. Portanto, crie apenas um pod ao criar uma Implementação que use discos EVS.
  • Para clusters anteriores à v1.19.10, se uma política HPA for usada para expandir uma carga de trabalho com discos EVS anexados, os pods existentes não poderão ser lidos ou gravados quando um novo pod for agendado para outro nó.

    Para clusters de v1.19.10 e posterior, se uma política HPA for usada para expandir uma carga de trabalho com discos EVS anexados, um novo pod não poderá ser iniciado porque os discos EVS não podem ser anexados.

• Restrições em volumes do SFS:
  • Vários PVs podem usar o mesmo sistema de arquivos do SFS ou SFS Turbo com as seguintes restrições:
    • Não monte todos as PVCs/PVs que usam o mesmo sistema de arquivos do SFS ou SFS Turbo subjacente em um pod. Isso leva a uma falha de inicialização do pod porque nem todos as PVCs podem ser montados no pod devido aos mesmos valores de volumeHandle desses PVs.
    • Sugere-se que o parâmetro persistentVolumeReclaimPolicy nos PVs seja definido como Retain. Caso contrário, quando um PV for excluído, o volume subjacente associado poderá ser excluído. Neste caso, outros PVs associados ao mau funcionamento do volume subjacente.
    • Quando o volume subjacente é usado repetidamente, ative o isolamento e a proteção de ReadWriteMany na camada da aplicação para evitar a substituição e a perda de dados.
• Restrições em volumes do OBS:
  • Se forem utilizados volumes do OBS, o grupo proprietário e a permissão do ponto de montagem não podem ser modificados.
  • O CCE permite que sistemas de arquivos paralelos sejam montados usando SDKs ou PVCs do OBS. Se for usada montagem em PVC, a ferramenta obsfs fornecida pelo OBS deve ser usada. Um processo residente de obsfs é gerado cada vez que um volume de armazenamento de objetos gerado a partir de um sistema de arquivos paralelo é montado em um nó.
    Figura 1 Processo residente do obsfs
    

    Reserve 1 GiB de memória para cada processo de obsfs. Por exemplo, para um nó com 4 vCPUs e 8 GiB de memória, um sistema de arquivos paralelo obsfs deve ser montado em no máximo oito pods.

    

    • Um processo residente do obsfs é executado em um nó. Se a memória consumida exceder o limite superior do nó, o nó funciona mal. Em um nó com 4 vCPUs e 8 GiB de memória, se mais de 100 pods forem montados em um sistema de arquivos paralelo, o nó não estará disponível. Controle o número de pods montados em um sistema de arquivos paralelo em um único nó.
    • Ao usar obsfs, cumpra com as Restrições de obsfs.
  • Os contêineres de Kata não suportam volumes do OBS.
• Restrições em snapshots e backups:
  • A função snapshot está disponível apenas para clusters v1.15 ou posterior e requer o complemento everest baseado em CSI.
  • O subtipo (I/O comum, I/O alta ou I/O ultra-alta), modo de disco (SCSI ou VBD), criptografia de dados, estado de partilha, e a capacidade de um disco EVS criado a partir de um snapshot deve ser a mesma do disco associado ao snapshot. Esses atributos não podem ser modificados após serem consultados ou definidos.
  • Snapshots podem ser criados apenas para discos EVS disponíveis ou em uso, e um máximo de sete snapshots podem ser criados para um único disco EVS.
  • Snapshots só podem ser criados para PVCs criadas usando a classe de armazenamento (cujo nome começa com csi) fornecida pelo complemento everest. Não é possível criar instantâneos para PVCs criadas usando a classe de armazenamento Flexvolume cujo nome é ssd, sas ou sata.
  • Os dados de snapshot de discos criptografados são armazenados criptografados, e os de discos não criptografados são armazenados não criptografados.

Serviços

Um Serviço é um objeto de recurso do Kubernetes que define um conjunto lógico de pods e uma política pela qual acessá-los.

Um máximo de 6.000 Serviços podem ser criados em cada namespace.

Recursos do cluster do CCE

Há cotas de recursos para seus clusters do CCE em cada região.

Recursos dependentes da nuvem subjacente