Limitaciones de Alibaba slb como equilibrio de carga para k8s
Si lo construimos localmente, podemos usar haproxy keepalived para lograr fácilmente el equilibrio de carga en k8, pero los ecs de Alibaba no pueden usar keepalived, por lo que nos vemos obligados a usar slb de Alibaba.
Dado que no se puede utilizar el método keepalived, utilizaremos slb de Alibaba para el equilibrio de carga. Dado que no es necesario acceder a este equilibrio de carga desde el exterior y solo proporciona acceso a los nodos del clúster k8s, utilizaremos privado. red slb.
[Error en la carga de la imagen...(image-b02d7-1604545387128)]
Nos aseguramos de que los nodos del clúster slb y k8s pertenezcan a la misma LAN La configuración específica. es el siguiente
p>
El primer paso es escuchar el puerto 6443 del SLB. El grupo de servidores back-end de este puerto es el puerto 6443 de 3 ecs (servicio apiserver). Luego podemos ejecutar el siguiente comando en el nodo master1
Dado que el apiserver del grupo de servidores backend aún no se está ejecutando, se espera un error de conexión rechazada. Sin embargo, el tiempo de espera significa que el equilibrador de carga no puede comunicarse con los nodos del plano de control. Si se agota el tiempo de espera, reconfigure el equilibrador de carga para comunicarse con los nodos del plano de control.
Creamos el archivo kubeadm-config.yaml en el nodo master1 para inicializar el nodo del plano de control, de la siguiente manera.
Luego ejecutamos el siguiente comando en el nodo master1 para inicializar
El resultado final es el siguiente
Mirando el registro anterior, parece ser un problema con el kubelet. Primero confirmamos si el kubelet se está ejecutando y descubrimos que está en estado de ejecución.
Luego verifique el registro de Kubelet.
Encontré un problema extraño, https://192.168.4.11: 6443 indica tiempo de espera.
Luego, primero probamos si el puerto local 6443 está habilitado en el nodo master1.
Al ver que el puerto 6443 del nodo master1 ha estado ocupado, luego probamos el puerto 6443 de. slb en el servicio del nodo master1, es lógico que el servicio 6443 del nodo master1 esté habilitado, entonces el servicio 6443 de slb también debería estar disponible y ser conectable.
Desafortunadamente, el puerto 6443 de slb no está conectado. Conectamos el puerto 6443 de slb en los nodos master2 y master3 respectivamente y descubrimos que se agotó el tiempo de espera. Encontramos otro ecs en la misma LAN. Este ecs no pertenece al servidor back-end de slb, pero puede conectarse al puerto 6443 de slb. Ahora se encuentra el problema:
Con esto Cuando. Tuvimos preguntas, presentamos una orden de trabajo a Alibaba y el servicio de atención al cliente finalmente nos dio una conclusión.
La red privada SLB no se puede utilizar. Cambiamos a la red pública SLB y volvimos a ejecutar el procedimiento anterior. Finalmente, el nodo del plano de control se inicializó correctamente.
Antes de la inicialización, el servicio 6443 del grupo de servidores backend cargado con el puerto 6443 de slb no debe haberse iniciado.
Una vez que comienza la inicialización, las imágenes relevantes se extraen localmente y luego se inician apiserver y otros servicios, es decir, se inicia el servicio 6443 local.
Luego verifique la conectividad del 6443 de slb. Dado que se inició el servicio 6443 del nodo master1, el grupo de backend de slb encontrará que el puerto 6443 del nodo master1 se inició juntos durante la verificación de estado, por lo que el 6443 de slb El servicio portuario se iniciará normalmente.
A través de la descripción anterior, se deben cumplir los dos puntos siguientes en el nodo del plano de control para que se inicialice correctamente
Ventajas: puede copiar el archivo kubeconfig a su computadora portátil y luego Puede acceder al clúster localmente puede causar fugas de seguridad debido a este método.
Desventajas: la IP expuesta por un servidor es una IP pública. En primer lugar, la eficiencia de la comunicación entre nodos se vuelve baja y, en segundo lugar, existen problemas de seguridad.
Si la empresa debe utilizar una red privada, podemos adoptar este método. La topología aproximada es la siguiente
La capa superior es una red privada SLB y el servidor back-end. El grupo de SLB es Dos haproxy. El uso de dos haproxy puede evitar el único punto de falla de haproxy. El servidor back-end de haproxy son tres nodos maestros k8.
Se estima que algunas personas tendrán preguntas después de leer esto. El método SLB de la red privada presentado anteriormente hará que el servidor back-end del monitoreo de cuatro capas no pueda acceder al SLB de la red privada. ¿Entonces este método no tendrá este problema? Realizamos pruebas con preguntas en mente.
Preparamos 6 ecs, la configuración es la siguiente
SLB escucha el puerto 6443. El grupo de servidores back-end de este puerto son dos haproxy y escucha el puerto 8888.
haproxy escucha el puerto 8888. El grupo de servidores backend de este puerto consta de 3 nodos del plano de control y escucha el puerto 6443. El archivo haproxy.cfg es el siguiente.
Usamos la imagen haproxy:1.7 y realizamos las siguientes operaciones en los dos nodos haproxy:
El parámetro controlPlaneEndpoint en el archivo kubeadm-config debe ser el puerto slb 6443 de la red privada. El archivo de configuración es el siguiente
Realice la inicialización y descubra que la inicialización puede ser exitosa
Todas las siguientes pruebas se prueban en el nodo master1
Primero probamos el servicio apserver del nodo master1 para ver si se ha utilizado el puerto 6443.
El puerto 6443 del nodo master1 muestra que ha estado ocupado. Luego probamos si el puerto 8888 del nodo haproxy está. conectado.
Muestra que el puerto 8888 del nodo haproxy está conectado. Luego probamos si el puerto 6443 del slb está ocupado y encontramos que está conectado.
Esto muestra. que nuestra arquitectura de tres capas se ha conectado, lo que indica que esta solución se puede implementar.
Ya tenemos la respuesta a la pregunta que nos hicimos antes. Pero hay una cosa que requiere especial atención.
Ventajas: debido a que hay una capa adicional de haproxy en el medio, resuelve inteligentemente el problema que el servidor back-end de la red privada SLB que monitorea la capa cuatro no puede. acceder a la red privada SLB.
Desventajas: obviamente hay una capa adicional de proxy de reenvío haproxy en el medio, lo que también aumenta el costo.
Actualmente existen dos formas de lograr alta disponibilidad en k8s. Una es utilizar la red pública slb y la otra es utilizar el nodo haproxy de la red privada. Cada uno de estos dos métodos tiene sus propias ventajas y desventajas. , elija una solución adecuada según su situación real.