Ganadero: Kubernetes en 5 minutos sobre metal desnudo.

En el cruce, la orquesta no cambia.

Después de estar completamente cansado de Docker Swarm debido a su pseudo-simplicidad y acabado constante, no es un trabajo muy conveniente con sistemas de archivos distribuidos, una interfaz web ligeramente húmeda y una funcionalidad estrecha, así como la falta de soporte de integración GitLab "lista para usar", se decidió implementar su clúster Kubernetes en su propio hardware, es decir, mediante la implementación de Rancher Management Server 2.0.

Experiencia de instalación, esquema de tolerancia a fallas, trabajo con haProxy y dos paneles debajo del gato:

Datos de entrada:

Servidor host HP Proliant DL320e Gen8 - 2 piezas
VM Ubuntu Server 16.04, 2Gb RAM, 2vCPU, 20Gb HDD - 1 PC. en cada host (VM-haProxy).
VM Ubuntu Server 16.04, 4Gb RAM, 4vCPU, 40Gb HDD, 20 Gb SSD - 3 piezas. en cada host (VM - * - Cluster).
VM Ubuntu Server 16.04, 4Gb RAM, 4vCPU, 100Gb HDD - 1 PC. en cualquier host (VM-NFS).

Diagrama de red:

Fig. 1


Comenzando:

VM-haProxy tiene reglas haProxy, fail2ban, iptables a bordo. Actúa como una puerta de entrada para todas las máquinas detrás de él. Tenemos dos puertas de enlace y todas las máquinas en caso de pérdida de la comunicación de la puerta de enlace en su host cambiarán a otra.

La tarea principal de estos nodos (VM-haProxy) es distribuir el acceso al backend, equilibrar, reenviar puertos y recopilar estadísticas.

Mi elección recayó en haProxy, como una herramienta más centrada en el equilibrio y la comprobación de estado. Por todo esto, me gusta la sintaxis de las directivas de configuración y trabajar con listas blancas y negras de IP, así como trabajar con conexión SSL multidominio.

Configuración de HaProxy:

haproxy.conf con comentarios
########################################################## #Global # ########################################################## global log 127.0.0.1 local0 notice maxconn 2000 user haproxy group haproxy tune.ssl.default-dh-param 2048 defaults log global mode http option httplog option dontlognull retries 3 option redispatch timeout connect 5000 timeout client 10000 timeout server 10000 option forwardfor option http-server-close ########################################################## #TCP # ########################################################## #    API  Kubernetes listen kube-api-tls bind *:6443 mode tcp option tcplog server VM-Master-Cluster Master:6443 ########################################################## #HTTP/HTTPS - Frontend and backend # ########################################################## #      "  ", frontend  backend. frontend http-in bind *:80 acl network_allowed src -f /path/allowed-ip #     IP.     . http-request deny if !network_allowed #       IP  . reqadd X-Forwarded-Proto:\ http mode http option httpclose acl is_haproxy hdr_end(host) -i haproxy.domain.ru acl is_rancher hdr_end(host) -i rancher.domain.ru acl is_kubernetes hdr_end(host) -i kubernetes.domain.ru use_backend kubernetes if is_kubernetes use_backend rancher if is_rancher use_backend haproxy if is_haproxy frontend https-in bind *:443 ssl crt-list /path/crt-list #    .        . acl network_allowed src -f /path/allowed-ip http-request deny if !network_allowed reqadd X-Forwarded-Proto:\ https acl is_rancher hdr_end(host) -i rancher.etraction.ru acl is_kubernetes hdr_end(host) -i kubernetes.etraction.ru use_backend kubernetes if is_kubernetes { ssl_fc_sni kubernetes.domain.ru } use_backend rancher if is_rancher { ssl_fc_sni rancher.domain.ru } # Backend  haProxy.    . backend haproxy stats enable stats uri /haproxy?stats stats realm Strictly\ Private stats auth login:passwd cookie SERVERID insert nocache indirect #  , , backend   dashboard rancher  kubernetes. backend rancher acl network_allowed src -f /path/allowed-ip http-request deny if !network_allowed mode http redirect scheme https if !{ ssl_fc } server master master:443 check ssl verify none backend kubernetes acl network_allowed src -f /path/allowed-ip http-request deny if !network_allowed mode http balance leastconn redirect scheme https if !{ ssl_fc } server master master:9090 check ssl verify none 


Importante: Todas las máquinas deben "conocerse" entre sí por nombre de host.

manifiesto de marioneta add-host-entry.pp para agregar nombres de host en / etc / hosts
 class host_entries { host { 'proxy01': ip => '10.10.10.11', } host { 'proxy02': ip => '10.10.10.12', } host { 'master': ip => '10.10.10.100', } host { 'node01': ip => '10.10.10.101', } host { 'node02': ip => '10.10.10.102', } host { 'node03': ip => '10.10.10.103', } host { 'node04': ip => '10.10.10.104', } host { 'node05': ip => '10.10.10.105', } host { 'nfs': ip => '10.10.10.200', } } 


VM-Master-Cluster es la máquina de control principal. Se diferencia de otros nodos a bordo por Puppet Master, GlusterFS Server, Rancher Server (contenedor), etcd (contenedor), control manager (contenedor). En caso de desconexión de este host, los servicios de producción continúan funcionando.
VM-Node-Cluster - Nodos, trabajadores. Máquinas de trabajo cuyos recursos se combinarán en un entorno tolerante a fallas. Nada interesante

VM-NFS : servidor NFS (nfs-kernel-server). La tarea principal es proporcionar espacio de almacenamiento intermedio. Almacena archivos de configuración y todo. No almacena nada importante. Su caída puede corregirse lentamente, mientras toma café.

Importante: Todas las máquinas de entorno deben tener a bordo: docker.io, nfs-common, gluster-server.

Manifiesto de títeres must-have-packages.pp para instalar el software adecuado
 class musthave { package { 'docker.io': ensure => 'installed', } package { 'nfs-common': ensure => 'installed', } package { 'gluster-server': ensure => 'installed', } } 


No describiré la instalación de nfs-volume y la configuración de GlusterFS, ya que se describe generosamente en grandes cantidades.

Si observa que hay discos SSD en la descripción de la especificación, están preparados para el funcionamiento del sistema de archivos distribuido Gluster. Cree particiones y almacenamiento en discos de alta velocidad.

Nota De hecho, ejecutar un Rancher no requiere un entorno de espejo. Todo lo anterior es mi visión del clúster y una descripción de las prácticas que sigo.

Para ejecutar Rancher, una máquina es suficiente, con 4CPU, 4Gb RAM, 10Gb HDD.

5 minutos para el ranchero.

En VM-Master-Cluster hacemos:

 sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 rancher/rancher 

Consultar disponibilidad:

 curl -k https://localhost 

Si vio la API, lo felicito exactamente a la mitad del camino.

Mirando nuevamente el diagrama de red, recordamos que trabajaremos desde afuera, a través de haProxy, en la configuración en la que hemos publicado el enlace rancher.domain.ru , adelante , establezca su contraseña.

La siguiente página es la página de creación de clústeres de Kubernetes.

Fig.2


En el menú Opciones de clúster, seleccione Franela. No trabajé con otros proveedores de la red. No puedo aconsejar

Vale la pena prestar atención al hecho de que instalamos las casillas de verificación, etcd y Control Plane, la casilla de verificación de trabajador no está instalada, en caso de que no planee usar el administrador en modo de trabajador.
Trabajamos dentro de la red local, con la misma dirección en la NIC, por lo que en los campos de Dirección pública e interna se indica la misma IP.

Copie el código resultante anterior, ejecútelo en la consola.

Después de un tiempo, en la interfaz web verá un mensaje sobre cómo agregar un nodo. Y después de un tiempo, iniciará el clúster de Kubernetes.

Fig.3


Para agregar un trabajador, vaya a editar el clúster en la interfaz web de Rancher, verá el mismo menú que genera el comando de conexión.

Establezca la casilla de verificación solo en la posición del trabajador, especifique la IP del futuro trabajador, copie el comando y ejecútelo en la consola del nodo que necesita.

Después de un tiempo, la potencia del clúster aumentará, al igual que la cantidad de nodos.

Instale el panel de Kubernetes:

Vaya al menú Proyectos / Espacios de nombres.

Después de la instalación, verá que los espacios de nombres relacionados con Kubernetes estarán contenidos fuera de los proyectos. Para trabajar completamente con estos espacios de nombres, deben colocarse en el proyecto.

Agregue un proyecto, asígnele el nombre que desee. Mueva los espacios de nombres (sistema de ganado, ingress-nginx, kube-public, kube-system) al proyecto que creó utilizando el menú contextual "Mover". Debería ser así:

Fig. 4


Haga clic directamente en el nombre del proyecto, será llevado al panel de control de la carga de trabajo. Es aquí donde discutiremos cómo crear un servicio simple.

Fig.5


Haga clic en "Importar YAML" en la esquina superior derecha. Copie y pegue el contenido de este archivo en el cuadro de texto de la ventana que se abre, seleccione el espacio de nombres "kube-system", haga clic en "Importar".

Después de un tiempo, se iniciará el pod kubernetes-dashboard.

Vaya a edición de pod, abra el menú de publicación de puertos, establezca los siguientes valores:

Fig.6


Verifique el acceso en el nodo en el que se ejecuta el pod.

 curl -k https://master:9090 

¿Ves la respuesta? La publicación se completa, queda por llegar a la parte administrativa.

En la página principal de administración de clústeres en Rancher, hay herramientas muy convenientes, como kubectl, la consola de administración de clústeres y el archivo Kubeconfig, el archivo de configuración que contiene la dirección API, ca.crt, etc.

Entramos en kubectl y ejecutamos:

 kubectl create serviceaccount cluster-admin-dashboard-sa kubectl create clusterrolebinding cluster-admin-dashboard-sa --clusterrole=cluster-admin --serviceaccount=default:cluster-admin-dashboard-sa 

Creamos una cuenta de servicio con los más altos privilegios, ahora necesitamos un token para acceder al Tablero.

Encuentra el secreto de la cuenta creada:

 kubectl get secret | grep cluster-admin-dashboard-sa 

Veremos el nombre de la cuenta con un cierto hash al final, cópielo y ejecute:

 kubectl describe secret cluster-admin-dashboard-sa-$( ) 

Nuevamente, recordamos que todo ha sido publicado con éxito a través de haProxy.

Seguimos el enlace kubernetes.domain.ru . Ingrese el token recibido.

Alegrarse

Fig. 7


PS
El resultado general sería agradecer a Rancher por crear una interfaz intuitiva, una instancia fácil de implementar, documentación simple, la capacidad de moverse rápidamente y la escalabilidad a nivel de clúster. Tal vez hablé demasiado bruscamente al comienzo de la publicación de que Swarm estaba cansado, más bien, las tendencias de desarrollo obvias, que me hicieron mirar a un lado y no terminar la aburrida rutina. Docker creó una era de desarrollo. Y juzgar este proyecto ciertamente no es para mí.

Source: https://habr.com/ru/post/es418691/


All Articles