Computación multiarquitectura: administración de balanceadores de carga de infraestructura aprovisionados para usuarios con trabajadores posteriores a la instalación.

La computación de múltiples arcos para Red Hat OpenShift Container Platform en sistemas IBM Power le permite utilizar un par de arquitecturas de computación, como ppc64le y amd64, en un solo clúster. Esta característica abre nuevas posibilidades de versatilidad y optimización para soluciones compuestas que abarcan diversas arquitecturas. El propietario del clúster puede agregar un trabajador adicional después de la instalación.

Con la infraestructura proporcionada por el usuario (UPI), el propietario del clúster puede haber utilizado la automatización o la configuración manual de los balanceadores de carga de front-end. El equipo de IBM proporciona automatización PowerVS ocp4-upi-powervs, PowerVM ocp4-upi-powervm y HMC ocp4-upi-powervm-hmc.

Al instalar un clúster, el clúster se configura con un equilibrador de carga externo como haproxy. El equilibrador de carga externo enruta el tráfico para agrupar los pods de Ingress, el servidor API y el servidor MachineConfig. La configuración de haproxy se almacena en .  /etc/haproxy/haproxy.cfg

Por ejemplo, la configuración del balanceador de carga ingress-https se vería así:

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

Al agregar un trabajador posterior a la instalación a un clúster de UPI, debe actualizar el archivo . S ingress-http  ingress-https

1. Obtenga la IP y el nombre del ho

# 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"}]

2. Editar /etc/haproxy/haproxy.cfg

a. Busque luego, antes de la primera entrada, agregue los nombres de host y las ips de los trabajadores. backend del servidor ingress-http

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

b. Busque luego, antes de la primera entrada, agregue los nombres de host y las ips de los trabajadores. backend del servidor ingress-https  

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

c. Guarde el archivo de configuración.

3. Reiniciar haproxy

# systemctl restart haproxy

Ahora tiene los trabajadores adicionales integrados en haproxy y los módulos de entrada se mueven de Power a Intel y viceversa. Tienes un entorno completamente funcional.

Puede obtener más información sobre cómo escalar el controlador de ingreso en Scaling an Ingress Controller

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

Si está ejecutando escenarios muy avanzados, puede cambiar el controlador de ingreso para colocar la carga de trabajo en arquitecturas específicas.

Consulte Configuración de un controlador de ingreso spec.nodePlacement.nodeSelector  

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

Escrito por: PAUL BASTIDE

Fuente: IBMPower