Mecanismo de estouro de nuvem do CCE para CCI

Restrições

• Somente os clusters padrão do CCE que usam VPCs e clusters do CCE Turbo (usando virtual-kubelet 1.2.5 ou posterior) são compatíveis. Clusters de Arm não são suportados. As instâncias do complemento não serão implementadas nos nós de Arm, se houver, em execução no cluster.

• Os pods do CCE agendados para CCI oferecem suporte aos volumes de ConfigMap, Secret, EmptyDir, DownwardAPI, Projected e PersistentVolumeClaims, e os volumes de DownwardAPI e Projected só podem ser usados no virtual-kubelet 1.3.25 e versões posteriores.
  • emptyDir: subcaminhos não são suportados.
  • PersistentVolumeClaims: somente os tipos de armazenamento em nuvem do SFS e SFS Turbo e as classes de armazenamento CSI são compatíveis.
  • Projected: se uma origem do tipo serviceAccountToken estiver configurada, o token no segredo service-account-token correspondente será montado depois que o pod for agendado para a CCI. O token é válido por um longo tempo e não tem público esperado. Ou seja, as configurações de expirationSeconds e audience não têm efeito.
• DaemonSets e pods que usam o modo HostNetwork não podem ser agendados para CCI.
• Os pods implementados no CCE e na CCI só podem se comunicar por meio dos Serviços ClusterIP. Os Serviços do CCE ClusterIP não podem ser acessados no init-container.
• Não especifique a porta de verificação de integridade ao interconectar com um Serviço LoadBalancer ou ingress para cargas de trabalho executadas no CCE e na CCI.

  1. Em um cluster do CCE, os contêineres da CCI e os contêineres do CCE usam portas de back-end diferentes registradas no ELB. Se você especificar uma porta de verificação de integridade, algumas verificações de integridade do back-end serão anormais.

  2. Quando clusters diferentes usarem um serviço para se conectar ao ouvinte do mesmo balanceador de carga do ELB, verifique se o modo de verificação de integridade escolhido não afetará o acesso ao serviço.

  3. Permita acesso de 100.125.0.0/16 ao interconectar com um Serviço LoadBalancer compartilhado para cargas de trabalho executadas em CCE e CCI.

• A sub-rede onde o cluster está localizado não pode se sobrepor com 10.247.0.0/16. Caso contrário, a sub-rede entra em conflito com o bloco CIDR de serviço no espaço para nomes da CCI.
• Antes de usar o virtual-kubelet, vá para o console da CCI para conceder à CCI permissão para usar o CCE.
• Depois que o complemento virtual-kubelet é instalado, um namespace chamado "cce-burst-cluster ID" é criado na CCI e gerenciado pelo complemento. Não use esse namespace ao criar pods manualmente na CCI.
• O uso de recursos do complemento varia de acordo com o volume de serviço dimensionado para CCI. Os pods, segredos, congfigMaps, PVs e PVCs solicitados pelo serviço ocupam os recursos da VM. Recomendamos que você avalie o uso do serviço e se inscreva para VMs com base nas seguintes especificações: para 1.000 pods e 1.000 ConfigMaps (300 KB), nós com 2 vCPUs e 4 GiB de memória são recomendados. Para 2.000 pods e 2.000 ConfigMaps são recomendados nós com 4 vCPUs e 8 GiB de memória. Para 4.000 pods e 4.000 ConfigMaps são recomendados nós com 8 vCPUs e 16 GiB de memória.
• Se o agendamento dos recursos dimensionados para CCI falhar, o nó de virtual-kubelet será bloqueado por meia hora, durante a qual os recursos não poderão ser agendados para CCI. Você pode usar o kubectl para verificar o status do nó do virtual-kubelet no console do cluster do CCE. Se o nó tiver sido bloqueado, desbloqueie-o manualmente.

  

• As restrições ao uso do gerenciamento de logs para coletar os logs de pods dimensionados para CCI são as seguintes:
  • Somente logs em caminhos de arquivo de contêiner podem ser coletados.
  • A rede deve ser ativada quando o complemento é instalado porque a rede de Serviço do virtual-kubelet é necessária.
  • Os pods dimensionados para CCI não oferecem suporte à atualização a quente das políticas de log. Depois que uma política de log for atualizada, reimplemente os pods dimensionados para CCI para aplicar a modificação.
  • A coleta de logs consome memória de pod. É uma boa prática reservar 50 MB de memória para que um pod seja associado a uma política de log. Se o pod estiver associado a várias políticas de log, reserve 5 MB adicionais de memória sempre que uma política de log for associada.
  • Um log maior que 250 KB não pode ser coletado.
  • Os logs não podem ser coletados de diretórios de montagem especificados, como os diretórios system, device, cgroup e tmpfs.
  • Os nomes dos arquivos de log a serem coletados associados à mesma política de log no mesmo contêiner devem ser exclusivos. Se houver vários arquivos com o mesmo nome, o coletor coletará apenas o primeiro que detectar.
  • Se o nome de um arquivo de log exceder 190 caracteres, o arquivo de log não será coletado.

Cálculo e restrições nas especificações do pod

Restrições às especificações do pod:

• O número de vCPUs em um pod deve ser maior que 0.
• Após o ajuste automático de recursos, o número de vCPUs no pod é 48 ou 64, ou varia de 0,25 a 32, a memória é um múltiplo inteiro de 1 GiB e varia de 1 GiB a 512 GiB, e a relação entre CPU e memória varia de 1:2 a 1:8.

Ajuste automático de recursos

Se os pods a serem dimensionados para CCI não atenderem às especificações da CCI e as especificações configuradas não forem superiores a 32 vCPUs e 256 GiB de memória, o virtual-kubelet ajustará automaticamente os recursos do pod.

As regras são as seguintes:

1. Aumente o número de vCPUs de cada contêiner de aplicação e de inicialização (exceto contêineres BestEffort) no pod para um múltiplo inteiro de 0,25 e defina a memória para um valor maior ou igual a 0,2 GiB.
2. Ajuste continuamente os recursos do pod até que o número de vCPUs do pod seja maior que 32 ou a memória seja maior que 256 GiB.
3. Aumente a memória do pod para um múltiplo inteiro de 1 GiB.
4. Se a proporção de memória de pod/vCPUs for menor que 2, aumente a memória de pod para um valor maior ou igual ao dobro do número de vCPUs, bem como um múltiplo inteiro de 1 GiB. Se a proporção de memória de pod/vCPUs for maior que 8, aumente o número de vCPUs de pod para ser maior ou igual a 1/8 da memória, bem como um múltiplo inteiro de 0,25.
5. Os incrementos de vCPU e memória causados pelo ajuste são adicionados ao primeiro contêiner de aplicação não BestEffort.

Instalar o complemento

1. No console do CCE, clique no nome do cluster para acessar o cluster. Clique em Add-ons no painel de navegação, localize virtual-kubelet à direita e clique em Install.
2. Na página Install Add-on, selecione Networking para habilitar as comunicações de pod entre o CCE e a CCI por meio dos Serviços do Kubernetes.
   Figura 1 Selecionar rede
   

3. Clique em Install.
   

   Depois que a rede é selecionada, um sidecar é injetado no pod em execução na CCI para oferecer suporte ao acesso ao Serviço. O número de contêineres em execução consultados é um a mais do que o número definido, o que é normal.

Usar rótulos para definir políticas de dimensionamento

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test
  namespace: default
  labels:
					    virtual-kubelet.io/burst-to-cci: 'auto'    # Scale pods to CCI.
spec:
  replicas: 2
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
        - image: 'nginx:perl'
          name: container-0
          resources:
            requests:
              cpu: 250m
              memory: 512Mi
            limits:
              cpu: 250m
              memory: 512Mi
          volumeMounts: []
      imagePullSecrets:
        - name: default-secret

Adicione o seguinte campo aos labels de uma carga de trabalho ou pod no arquivo YAML:

virtual-kubelet.io/burst-to-cci: "auto"

Os seguintes valores são suportados:

• auto: o sistema determina automaticamente se os pods devem ser dimensionados para CCI com base no resultado de pontuação real do agendador. TaintToleration agenda preferencialmente os pods para os nós do CCE.
• localPrefer: os pods são agendados para a CCI quando os recursos do cluster são insuficientes.
• enforce: os pods são agendados à força para CCI.
• off: os pods não estão agendados para a CCI.

Usar perfis para gerenciar pods na nuvem e fora dela

Você pode usar perfis para configurar e gerenciar pods, associar perfis a pods usando labelSelector e configurar a política de alocação dos pods associados para alocar ou limitar o número de pods na e fora da nuvem.

Restrições

• Você pode usar o perfil para configurar e gerenciar a política de pods. burst-to-cci ainda é compatível e é anterior ao perfil.
• localPrefer não pode ser configurado para local e cci ao mesmo tempo.
• As políticas auto e localPrefer podem ser associadas a pods que não foram associados a perfis. A política de imposição não pode ser associada a pods que não foram associados a perfis.
• Atualmente, quando a política localPrefer é configurada no perfil, a configuração do número máximo de local pode se tornar inválida em cenários extremos para evitar problemas globais.
• Quando uma implantação está realizando atualização contínua, é recomendável definir maxSurge para um valor tão pequeno quanto possível (por exemplo, 0) para evitar que o volume de programação da região onde maxNum é limitado seja menor do que o esperado.
• Um pod pode ser associado a apenas um perfil, ou seja, o perfil com o maior grau de associação. Depois que um pod é criado, se o rótulo do pod for modificado, o pod não corresponde ao perfil original. Nesse caso, o pod seleciona o perfil com o maior grau de associação para associação. Você pode avaliar o grau de associação de acordo com as seguintes instruções:
  • Calcule a soma de matchLabels e matchExpressions em labelSelector com base em obejectLables no perfil. O perfil com a maior soma tem o maior grau de associação.
  • Se dois perfis forem filtrados, selecione aquele cujo nome tenha a menor ordem alfabética.

Descrição do uso

apiVersion: scheduling.cci.io/v1
kind: ScheduleProfile
metadata:
  name: test-cci-profile
  namespace: default
spec:
  objectLabels:
    matchLabels:
      app: nginx
					strategy: localPrefer
  location:
					local: 
					maxNum: 20 # Currently, maxNum cannot be configured for local and cci at the same time.
					scaleDownPriority: 10
    cci: {}
status:
  phase: initialized
  restrict:
					local: 20 # restrict is configured based on location. That is, local and cci do not appear at the same time.
  used:
    local: 20
    cci: 0

Configurar cci maxNum e scaleDownPriority

apiVersion: scheduling.cci.io/v1
kind: ScheduleProfile
metadata:
  name: test-cci-profile
  namespace: default
spec:
  objectLabels:
    matchLabels:
      app: nginx
				strategy: localPrefer
  location:
    local: {}
				cci:
				maxNum: 20 # Currently, maxNum cannot be configured for local and cci at the same time.
				scaleDownPriority: 10
status:
  phase: initialized
  restrict:
				cci: 20 # restrict is configured based on location. That is, local and cci do not appear at the same time.
  used:
    local: 0
    cci: 20

Impacto do virtual-kubelet no monitoramento de recursos disponíveis

Depois que o complemento virtual-kubelet é instalado, o sistema usa recursos da CCI como recursos de nó de cluster. É equivalente a um nó super-grande para monitoramento. Nesse caso, os recursos da CCI são calculados juntos nos recursos alocáveis na página de monitoramento de cluster do CCE. Conforme mostrado na figura a seguir, após a instalação do complemento virtual-kubelet, a taxa de alocação de CPU/memória diminui drasticamente.

Figura 2 Monitoramento do cluster

Você pode exibir a taxa de alocação de um nó específico na página Nodes ou no console do AOM.

Figura 3 Exibir recursos alocáveis de um nó no console do AOM