Isolando recursos do Ingress nos nós de trabalho de borda

Se você quiser agendar pods do ALB para nós de trabalho de borda, é necessário criar ou usar um pool de trabalhadores já existente que tenha pelo menos dois nós de trabalho de borda por zona. Isso garante que sempre haja nós de borda disponíveis para o agendamento dos pods do ALB.

Quando você atualiza um pod do ALB, um novo pod é implantado para substituir o existente. Para manter o ALB disponível durante a atualização, uma atualização gradual substitui um pod de cada vez, de modo que pelo menos um pod do ALB permaneça sempre ativo. No entanto, os pods do ALB possuem regras de anti-afinidade que impedem que dois pods do ALB sejam executados no mesmo worker. Se houver pelo menos dois nós de borda em uma zona, o novo pod do ALB poderá ser substituído em um deles, enquanto o outro continua em operação.

Para garantir a alta disponibilidade do ALB, a etiqueta do nó de borda é ignorada quando não há nós de borda suficientes em cada região, e os pods do ALB também são agendados para nós que não sejam de borda.

As etapas para isolar cargas de trabalho do ALB em nós de borda são as mesmas tanto para a infraestrutura clássica quanto para a infraestrutura VPC. No entanto, a convenção de nomenclatura para o IP externo do ALB é diferente para cada tipo. Para ALBs em infraestrutura clássica, o IP externo é um endereço IP padrão, como 169.46.17.2. Para ALBs na infraestrutura VPC, o IP externo é um nome de host, como f3bee8b5-us-south.lb.appdomain.cloud.

Antes de Iniciar

Certifique-se de que você possui as seguintes funções do IAM:
- Qualquer função de acesso de plataforma para o cluster
- Função de acesso de serviço Gravador ou Gerenciador para todos os namespaces
Efetue login na sua conta. If applicable, target the appropriate resource group. Configure o contexto para o seu cluster.

Isolamento de cargas de trabalho nos nós de trabalho de borda

Para isolar sua carga de trabalho nos nós de trabalho de borda:

Crie um conjunto de trabalhadores com o rótulo “ dedicated=edge ” ou adicione esse rótulo a um dos seus conjuntos de trabalhadores já existentes.

Para criar um pool de trabalhadores Classic, você pode usar o comando worker-pool create classic .

    ibmcloud oc worker-pool create classic --name POOL_NAME --cluster CLUSTER --flavor FLAVOR --size-per-zone WORKERS_PER_ZONE --hardware ISOLATION --label dedicated=edge
    ```
* Para criar um pool de trabalhadores da VPC, você pode usar o [comando](/docs/containers?topic=containers-kubernetes-service-cli#worker-pool-create-vpc-gen2-cli) ` `worker-pool create vpc-gen2` `.
```sh {: pre}
    ibmcloud oc worker-pool create vpc-gen2 --name POOL_NAME --cluster CLUSTER --flavor FLAVOR --size-per-zone WORKERS_PER_ZONE --hardware ISOLATION --label dedicated=edge
    ```
* Para atribuir um nome a um pool de trabalhadores existente, você pode usar o [comando](/docs/containers?topic=containers-kubernetes-service-cli#worker-pool-label-set-cli) ` `worker-pool label set` `.
```sh {: pre}
    ibmcloud oc worker-pool label set --cluster CLUSTER --worker-pool POOL --label dedicated=edge
    ```

Verifique se o conjunto de trabalhadores e os nós do trabalhador têm o rótulo dedicated=edge.

Para verificar o conjunto de trabalhadores, use o comando get .

    ibmcloud ks worker-pool get --cluster CLUSTER_NAME_OR_ID --worker-pool WORKER_POOL_NAME_OR_ID
    ```
* Para verificar os nós do trabalhador individuais, revise o campo **Rótulos** da saída do comando a seguir.
```sh {: pre}
    kubectl describe node <worker_node_private_IP>
    ```

Recuperar todos os ALBs existentes no cluster. Revise a saída de comando. Para cada ALB cujo parâmetro “ Status ” esteja definido como “ ativado ”, anote os endereços ALB ID e Construir.

ibmcloud ks ingress alb ls --cluster CLUSTER_NAME_OR_ID

Exemplo de saída

ALB ID                                Enabled   State     Type      Load Balancer Hostname                      Zone         Build                                  Status
private-crc81nk5l10gfhdql4i3qg-alb1   true      enabled   private   e9dd35e6-us-south.lb.appdomain.cloud   us-south-3   3.7.4_348800920_iks   enabled
public-crc81nk5l10gfhdql4i3qg-alb1    true      enabled   public    38daf55c-us-south.lb.appdomain.cloud   us-south-3   3.7.4_348800920_iks   healthy

Usando a saída da etapa anterior, execute o comando ibmcloud ks ingress alb update para cada ALB ativado. Esse comando reimplementa o ALB para um nó do trabalhador de borda.

Ao executar esse comando para reimplementar o ALB em um nó do trabalhador de borda, o ALB também é atualizado para a versão mais recente. Se você não quiser atualizar o ALB para a versão mais recente, inclua a opção “ --version ” e especifique a versão listada em “Build” na saída da etapa anterior.
```
ibmcloud ks ingress alb update -c <cluster_name_or_ID> --alb <ALB_ID> [--version <build_version>]
```
Exemplo de saída
```
Updating ALB pods for private-crc81nk5l10gfhdql4i3qg-alb1 to version '3.7.4_348800920_iks' in cluster crc81nk5l10gfhdql4i3qg...
OK
```

Confirm that all ALB pods are deployed to edge nodes. Each public and private ALB that is enabled in your cluster has two pods.

kubectl describe nodes -l dedicated=edge | grep alb

Exemplo de saída

kube-system                private-crc81nk5l10gfhdql4i3qg-alb1-d5dd478db-27pv4    0 (0%)        0 (0%)      0 (0%)           0 (0%)
kube-system                private-crc81nk5l10gfhdql4i3qg-alb1-d5dd478db-7p9q6    0 (0%)        0 (0%)      0 (0%)           0 (0%)
kube-system                public-crc81nk5l10gfhdql4i3qg-alb1-5ff8cdff89-s77z6    0 (0%)        0 (0%)      0 (0%)           0 (0%)
kube-system                public-crc81nk5l10gfhdql4i3qg-alb1-5ff8cdff89-kvs9f    0 (0%)        0 (0%)      0 (0%)           0 (0%)

Confirme se nenhum pod do ALB é implementado em nós que não são de borda.
```
kubectl describe nodes -l dedicated!=edge | grep alb
```
Se os pods do ALB forem implementados corretamente em nós de borda, nenhum pod do ALB será retornado. Isso significa que seus ALBs foram reprogramados com sucesso apenas para nós de trabalho de borda.

Próximas etapas

Agora que você rotulou os nós de trabalho em um pool de trabalho com “ dedicated=edge ” e reimplantou todos os ALBs existentes nos nós de borda, todos os ALBs adicionados posteriormente ao cluster também serão implantados em um nó de borda do seu pool de trabalho de borda. Em seguida, você pode evitar outros impedir que as cargas de trabalho sejam executadas nos nós de trabalho de borda.