top of page

Computação multiarquitetura: gerenciando balanceadores de carga de infraestrutura provisionados pelo usuário com trabalhadores pós-instalação.

Atualizado: 12 de jul.


Multi-Arch Compute para Red Hat OpenShift Container Platform em sistemas IBM Power permite usar um par de arquiteturas de computação, como ppc64le e amd64, em um único cluster. Esse recurso abre novas possibilidades de versatilidade e otimização para soluções compostas que abrangem diversas arquiteturas. O proprietário do cluster pode adicionar um trabalhador adicional após a instalação.

Com a Infraestrutura Provisionada pelo Usuário (UPI), o proprietário do cluster pode ter usado automação ou configuração manual de balanceadores de carga front-end. A equipe IBM fornece automação PowerVS ocp4-upi-powervs , PowerVM ocp4-upi-powervm e HMC ocp4-upi-powervm-hmc .     

Ao instalar um cluster, o cluster é configurado com um balanceador de carga externo, como haproxy . O balanceador de carga externo roteia o tráfego para agrupar os pods do Ingress, o servidor API e o servidor MachineConfig. A configuração do haproxy é armazenada em .  /etc/haproxy/haproxy.cfg



Por exemplo, a configuração do balanceador de carga ingress-https seria semelhante a esta:


frontend ingress-https
        bind *:443
        default_backend ingress-https
        mode tcp
        option tcplog

backend ingress-https
        balance source
        mode tcp
        server master0 10.17.15.11:443 check
        server master1 10.17.19.70:443 check
        server master2 10.17.22.204:443 check
        server worker0 10.17.26.89:443 check
        server worker1 10.17.30.71:443 check
        server worker2 10.17.30.225:443 check

Ao adicionar um trabalhador pós-instalação a um cluster UPI, é necessário atualizar os arquivos e . S ingress-http  ingress-https


  1. Obtenha o IP e o nome do host

# oc get nodes -lkubernetes.io/arch=amd64 --no-headers=true -ojson | jq  -c '.items[].status.addresses'
[{"address":"10.17.15.11","type":"InternalIP"},{"address":"worker-amd64-0","type":"Hostname"}]
[{"address":"10.17.19.70","type":"InternalIP"},{"address":"worker-amd64-1","type":"Hostname"}]
  1. Edite o /etc/haproxy/haproxy.cfg


a. Encontre então, antes da primeira entrada, adicione os nomes de host e ips dos trabalhadores. backend ingress-http  server 

        server worker-amd64-0 10.17.15.11:80 check
        server worker-amd64-1 10.17.19.70:80 check

b. Encontre então, antes da primeira entrada, adicione os nomes de host e ips dos trabalhadores. backend ingress-https  server 

        server worker-amd64-0 10.17.15.11:443 check
        server worker-amd64-1 10.17.19.70:443 check

c. Salve o arquivo de configuração.


  1. Reinicie o haproxy

# systemctl restart haproxy

Agora você tem os trabalhadores adicionais incorporados ao haproxy e à medida que os pods de entrada são movidos do Power para o Intel e vice-versa. Você tem um ambiente totalmente funcional.


Você pode aprender mais sobre como ampliar o controlador de entrada em Scaling an Ingress Controller

$ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"replicas": 3}}' --type=merge

Se você estiver executando cenários muito avançados, poderá alterar o ingresscontroller para colocar a carga de trabalho em arquiteturas específicas. c


Consulte Configurando um controlador de ingresso spec.nodePlacement.nodeSelector  

nodePlacement:
 nodeSelector:
   matchLabels:
     kubernetes.io/arch: ppc64le

Escrito por: PAUL BASTIDE

Fonte: IBMPower

6 visualizações0 comentário

Posts recentes

Ver tudo

Comments


bottom of page