Introducción
No hace mucho tiempo, se ha tenido la suerte de poder afrontar el reto de hacer una POC para instalar Openshift Container Platform sobre vSphere 6.7.0 en una plataforma on-premise que necesitaba evidencias de que Openshift podría solventar necesidades de seguridad entre aplicaciones y entornos que actualmente tienen en su infraestructura y son requisitos fundamentales para el óptimo aseguramiento del dato.
El reto además se hizo más grande al tener que solventar algunas dificultades a la hora de poder instalar, gracias a varias peculiaridades en la infraestructura de red, por lo que ha sido necesario a realizar una instalación de OCP un poco distinta pero muy interesante y que se va a exponer a continuación.
En este artículo se refleja todos los problemas que hemos encontrado en esta instalación (y los que te podrías encontrar) y que nos hubiese gustado disponer como :
-
-
Configuración del HAProxy
-
Tipo DNSs necesarios
-
Gestión/administración certificados CSR de Kubernetes
-
Modificaciones necesarias de los ficheros yaml
-
Configuración de ficheros Ignition
-
Generación ISO modificada para RH CoreOS
-
Todos estos temas los verás resaltados con el símbolo
Empezando… lo primero saber qué necesitamos.
La primera decisión que nos encontramos fue elegir entre instalación IPI (Installer Provisioned Infrastructure) o UPI (User Provisioned Infrastructure) y para VMWare solo podíamos elegir UPI para la versión OCP 4.4.3 (versión estable en ese momento, a fecha de este post está disponible la versión 4.6 ). Además, nos vimos obligados a realizarla de tipo bare-metal, pero apoyada en vSphere 6.7.0u3. En términos generales, se ha seguido la documentación oficial de Red Hat.
Para este tipo de instalaciones OCP necesita 1 nodo de arranque temporal (bootstrap) , 3 nodos maestros (masters) y 2 nodos workers, en nuestro caso se han montado 4 workers.
Además, existen otros componentes necesarios para este tipo de instalación de OCP, como son un servidor de DHCP, un servidor que actuará como balanceador (HAProxy) y además contendrá un servidor web (Apache) para servir los ficheros de instalación. También se ha creado un servidor de apoyo (HAHelper) desde donde se ejecutarán todos los comandos y generación de la instalación.
DNS
Openshift Container Platform basa todo su funcionamiento en DNS, por lo que se necesita que se generen todos los DNS que se muestran en la Tabla 1. Es de vital importancia que estén verificados antes de continuar la instalación, o por lo contrario, la instalación fallará.
|
[atsistemas@hahelper ~]$ dig *.apps.openshift.atsistemas.at +short 10.52.153.200 [atsistemas@hahelper ~]$ dig api.openshift.atsistemas.at +short 10.52.153.200 [atsistemas@hahelper ~]$ dig api-int.openshift.atsistemas.at +short 10.52.153.200 [atsistemas@hahelper ~]$ dig master0.openshift.atsistemas.at +short 10.52.153.205 [atsistemas@hahelper ~]$ dig master1.openshift.atsistemas.at +short 10.52.153.206 [atsistemas@hahelper ~]$ dig master2.openshift.atsistemas.at +short 10.52.153.207 [atsistemas@hahelper ~]$ dig worker0.openshift.atsistemas.at +short 10.52.153.208 [atsistemas@hahelper ~]$ dig worker1.openshift.atsistemas.at +short 10.52.153.209 [atsistemas@hahelper ~]$ dig worker2.openshift.atsistemas.at +short 10.52.153.210 [atsistemas@hahelper ~]$ dig worker3.openshift.atsistemas.at +short 10.52.153.211 [atsistemas@hahelper ~]$ dig etcd-0.openshift.atsistemas.at +short 10.52.153.205 [atsistemas@hahelper ~]$ dig etcd-1.openshift.atsistemas.at +short 10.52.153.206 [atsistemas@hahelper ~]$ dig etcd-2.openshift.atsistemas.at +short 10.52.153.207 [atsistemas@hahelper ~]$ dig _etcd-server-ssl._tcp.openshift.atsistemas.at SRV +short 0 10 2380 etcd-2.openshift.atsistemas.at 0 10 2380 etcd-0.openshift.atsistemas.at 0 10 2380 etcd-1.openshift.atsistemas.at |
A continuación, se muestra una tabla con los componentes utilizados durante esta instalación de OPC.
Tabla 1.
|
Host |
IP |
DNS Tipo A |
DNS Tipo SRV |
Descripción |
|
haproxy.atsistemas.at |
10.000.000.200 |
api.openshift.atsistemas.at api-int.openshift.atsistemas.at *.apps.openshift.atsistemas.at |
MV HAProxy |
|
|
hahelper.atsistemas.at |
10.000.000.201 |
MV Instalación |
||
|
bootstrap |
10.000.000.202 |
bootstrap.openshift.atsistemas.at |
MV Bootstrap |
|
|
master0 master1 master2 |
10.000.000.205 10.000.000.206 10.000.000.207 |
master0.openshift.atsistemas.at master1.openshift.atsistemas.at master2.openshift.atsistemas.at etcd-0.openshift.atsistemas.at etcd-1.openshift.atsistemas.at etcd-2.openshift.atsistemas.at |
etcd-server-ssl._tcp.openshift.atsistemas.at etcd-server-ssl._tcp.openshift.atsistemas.at etcd-server-ssl._tcp.openshift.atsistemas.at |
MVs Control Plane |
|
worker0 worker1 worker2 worker3 |
10.000.000.208 10.000.000.209 10.000.000.210 10.000.000.211 |
worker0.openshift.atsistemas.at worker1.openshift.atsistemas.at worker2.openshift.atsistemas.at worker3.openshift.atsistemas.at |
MVs Worker |
HAProxy
Se ha elegido HAProxy como el balanceador de carga utilizado en esta instalación. Este componente será el encargado de redirigir y distribuir las peticiones que se realicen sobre el clúster de Openshift.
Para su instalación, se ha generado una MV con RH 7 con la configuración de red indicada en la tabla de la infraestructura. En dicha MV se ha instalado HAProxy y se ha configurado de la siguiente manera:
|
Atención a la configuración del HAProxy , es clave para que la instalación de OCP funcione. |
|
#--------------------------------------------------------------------- # Global settings #--------------------------------------------------------------------- global log /etc/haproxy/haproxy.log local0 info chroot /var/lib/haproxy pidfile /var/run/haproxy.pid maxconn 20000 user haproxy group haproxy daemon
# turn on stats unix socket stats socket /var/lib/haproxy/stats #--------------------------------------------------------------------- # common defaults that all the 'listen' and 'backend' sections will # use if not designated in their block #--------------------------------------------------------------------- defaults mode http log global option httplog option dontlognull option http-server-close option forwardfor except 127.0.0.0/8 option redispatch retries 3 timeout http-request 10000ms timeout http-keep-alive 10000ms timeout check 10000ms timeout connect 40000ms timeout client 300000ms timeout server 300000ms timeout queue 50000ms maxconn 20000 #--------------------------------------------------------------------- # stats cluster #--------------------------------------------------------------------- listen stats bind :9000 stats uri /stats #monitor-uri /healthz monitor-uri /readyz option httpchk GET /readyz HTTP/1.0 stats refresh 30000ms #--------------------------------------------------------------------- # frontend to OpenShift K8s API Server 1 #--------------------------------------------------------------------- frontend openshift-api-server bind *:6443 default_backend openshift-api-server mode tcp
#--------------------------------------------------------------------- # backend to OpenShift K8s API Server 1 #--------------------------------------------------------------------- backend openshift-api-server balance source mode tcp server bootstrap 10.000.000.202:6443 check server master0 10.000.000.205:6443 check server master1 10.000.000.206:6443 check server master2 10.000.000.207:6443 check
#--------------------------------------------------------------------- # frontend to OpenShift Machine Config Server 2 #--------------------------------------------------------------------- frontend machine-config-server bind *:22623 default_backend machine-config-server mode tcp
#--------------------------------------------------------------------- # backend to OpenShift Machine Config Server 2 #--------------------------------------------------------------------- backend machine-config-server balance source mode tcp server bootstrap 10.000.000.202:22623 check server master0 10.000.000.205:22623 check server master1 10.000.000.206:22623 check server master2 10.000.000.207:22623 check
frontend ingress-http 3 bind *:80 default_backend ingress-http mode tcp option tcplog
backend ingress-http 3 balance source mode tcp server worker0 10.000.000.208:80 check server worker1 10.000.000.209:80 check server worker2 10.000.000.210:80 check server worker3 10.000.000.211:80 check
frontend ingress-https 4 bind *:443 default_backend ingress-https mode tcp option tcplog
backend ingress-https 4 balance source mode tcp server worker0 10.000.000.208:443 check server worker1 10.000.000.209:443 check server worker2 10.000.000.210:443 check server worker3 10.000.000.211:443 check
|
En el fichero se pueden encontrar 4 bloques diferenciados (cada uno con su frontend y backend):
- Openshift-api-server (puerto 6443): utilizado por los masters y bootstrap para exponer la API de Kubernetes y realizar los health check
- Machine-config-server (puerto 22623): utilizado por los masters y bootstrap para realizar la inicialización del cluster
- Ingress-http (puerto 80): utilizado por los workers para habilitar el tráfico HTTP en los Pods
- Ingress-https (puerto 443): utilizado por los workers para habilitar el tráfico HTTPS en los Pods
Una vez configurado el HAProxy, se podrá acceder mediante URL al estado de los componentes y sus estadísticas. Será muy útil durante la instalación del clúster de Openshift, ya que se podrá comprobar el estado de los Control Plane y Workers accediendo a la URL 10.000.000.200:9000/stats
Servidor Web (Apache)
Otro componente utilizado durante esta instalación ha sido Apache. Este servidor web se utiliza para que, durante la instalación, tanto los Control Plane como los Worker puedan recibir los ficheros de configuración necesarios para su inicialización.
Se ha reutilizado la MV determinada para el HAProxy y se ha configurado para que desde los componentes que forman el clúster puedan descargarse los ficheros Ignition (ficheros de configuración del clúster) y además para que pueda descargar la imagen comprimida del SO Red Hat CoreOS.
Install-config & Manifest & Ignition
El siguiente paso es generar los ficheros Manifest de Kubernetes y los ficheros de Ignition para las configuraciones de encendido para cada nodo.
-
- install-config.yaml
|
La instalación de Openshift se basa en un fichero de instalación install-config.yaml donde se proporciona a Openshift todos los parámetros necesarios para la generación de los ficheros de Manifest y de Ignition. |
|
|
[ansiblebot@hahelper ~]$ cat install-config.yaml apiVersion: v1 ## The base domain of the cluster. All DNS records will be sub-domains of this base and will also include the cluster name. baseDomain: atsistemas.at 1 proxy: 2 httpProxy: http://{{URL_PROXY}} httpsProxy: http://{{URL_PROXY}} noProxy: {{URLS_NO_PROXY}} imageContentSources: 3 - mirrors: - registry.lab.variantweb.net/ocp/release source: quay.io/openshift-release-dev/ocp-v4.0-art-dev - mirrors: - registry.lab.variantweb.net/ocp/release source: registry.svc.ci.openshift.org/ocp/release - mirrors: - registry.svc.ci.openshift.org/ocp/release source: registry.svc.ci.openshift.org/ocp/release compute: - name: worker replicas: 4 4 controlPlane: name: master replicas: 3 metadata: ## The name for the cluster name: openshift platform: vsphere: 5 ## The hostname or IP address of the vCenter vCenter: {{NOMBRE_VCENTER}} ## The name of the user for accessing the vCenter username: {{USUARIO_VCENTER}} ## The password associated with the user password: {{PASSWORD_VCENTER}} ## The datacenter in the vCenter datacenter: {{NOMBRE_DATACENTER}} ## The default datastore to use. defaultDatastore: {{NOMBRE_DEFAULT_DATASTORE}} ## The pull secret that provides components in the cluster access to images for OpenShift components. pullSecret: '{"auths":{.....}}' 6 ## The default SSH key that will be programmed for `core` user.i sshKey: 'ssh-rsa AAAA......' 7 |
|
1.- Dominio base que tendrán todos los DNS
2.- Definición del proxy (si fuera necesario) y de las URLs o IPs que no quiera que acudan al proxy.
3.- Mirror para los ImageRegistry que quiera añadir
4.- Numero de Replicas workers (0 para no limitar) y master debe de tener 3 réplicas como mínimo
5.- Definición de los parámetros para vSphere
6.- Pull Secret que obtendremos de Red Hat al obtener la licencia de OCP.
7.- La clave SSH generada para conectarnos con usuario core en Red Hat Enterprise Linux CoreOS (RH CoreOS), del bootstrap y master.
|
Este fichero se destruye en la generación de los ficheros de Manifest, por lo que cópialo a la ruta donde vayas a ejecutar la instalación. |
-
- Ficheros de Manifest de Kubernetes
Para la generación de los ficheros de Manifest , se utiliza el ejecutable de Openshift openshift-install proporcionado para esta versión.
|
[atsistemas@hahelper ~]$ ./openshift-install create manifests WARNING There are no compute nodes specified. The cluster will not fully initialize without compute nodes. INFO Consuming "Install Config" from target directory |
|
|
|
Después de generar dichos ficheros de Manifest hay que modificar algunos de ellos y es aquí donde hay una de esas trampas que nosotros nos pegamos y que no se olvidan. |
Modificaremos los ficheros:
-
-
- cluster-scheduler-02-config.yml
-
cambiaremos la propiedad mastersSchedulable a False
-
-
- También editamos los ficheros
- openshift/99_openshift-machineconfig_99-master-ssh.yaml
- openshift/99_openshift-machineconfig_99-worker-ssh.yaml
- manifest/Cluster-config.yaml
- También editamos los ficheros
-
|
Aquí deberemos de comprobar y corregir los saltos de línea en las claves ssh-key añadidas en estos ficheros (si los hay). |
-
- Creación de los ficheros de ignition.
Después de crear y modificar los ficheros de Manifest estamos en predisposición de generar los ficheros de Ignition para la instalación, para ello se utiliza el mismo ejecutable de Openshift openshift-install, pero con distintos parámetros.
|
[atsistemas@hahelper ~]$ ./openshift-install create ignition-configs
|
Deberemos de ver que se ha generado una estructura similar a esta:
├── auth
│ ├── kubeadmin-password
│ └── kubeconfig
├── bootstrap.ign
├── master.ign
├── metadata.json
└── worker.ign
|
Guarda la carpeta auth porque será utilizada más tarde para poder conectarnos por el cliente. |
-
- Copia de los ficheros de ignition al servidor web apache
Ahora copiaremos los ficheros de Ignition generados al servidor web Apache para que las MV, en momentos de arranque, encuentren dichos ficheros e inicialicen los servers CoreOS.
|
[atsistemas@hahelper ~]$ scp *.ign haproxy:/var/www/html/ignition/
|
Imagen ISO Red Hat CoreOS.
Como se ha comentado a lo largo del documento, el SO utilizado por los componentes del clúster de Openshift es Red Hat CoreOS. RED
Al tratarse de una instalación en VMWare, se ha procedido a modificar la ISO que Red-Hat proporciona para que durante la instalación del SO dependiendo del componente a instalar se configure con sus ficheros Ignition correspondientes. Se esta manera, se utiliza el servidor Apache como servidor de ficheros para el clúster.
Para ello, se ha descargado de la web oficial de Red Hat la ISO de CoreOS y se ha realizado los siguientes pasos:
- Primero montamos la ISO en local:
|
[atsistemas@hahelper ~]$ sudo mount -o loop rhcos-installer.x86_64.iso rhcos-4.3.3 <directorio>
|
- En el directorio /isolinux se ha modificado el fichero isolinux.cfg. Se ha añadido un label por cada uno de los componentes del cluster de Openshift. En cada uno, según el tipo, irá al servidor Apache a descargarse sus ficheros correspondientes. Además, se ha establecido la configuración de red necesaria (IP, Gateway, NetMask , tarjeta de red, Hostname y servidor DNS). A continuación, se muestra como quedaría el label para instalar el bootstrap
|
Será necesario añadir un label por componente. Cada uno con su configuración específica. |
|
|
label bootstrap menu label ^Install bootstrap kernel /images/vmlinuz append initrd=/images/initramfs.img nomodeset rd.neednet=1 coreos.inst=yes coreos.inst.install_dev=sda coreos.inst.image_url=http://10.000.000.200:8080/install/rhcos-metal.x86_64.raw.gz coreos.inst.ignition_url=http://10.000.000.200:8080/ignition/bootstrap.ign ip=10.000.000.202::10.000.000.255:255 .255.255.128:bootstrap.openshift.atsistemas.at:ens192:none nameserver=10.52.157.2 nameserver=10.52.157.3 |
|
- Generamos la nueva ISO modificada
|
sudo mkisofs -U -A rhcos-4.4.3 -V rhcos-4.4.3 -volset rhcos-4.4.3 -J -joliet-long -r -v -T -x ./lost+found -o ~/rhcos-4.4.3.iso -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -eltorito-alt-boot -e images/efiboot.img -no-emul-boot .
|
- Por último, debemos de guardar la nueva ISO en el almacén de datos de VMWare, de esta manera, se podrá utilizar a la hora de la creación de las MV.
Creación de la MV en VMWARE
Ahora tenemos que generar las máquinas virtuales en VMWare. Para ello, es recomendable disponer de un Datacenter específico para el clúster de Openshift.
|
Previamente, se tiene que haber configurado el DCHP para la asignación de las IP´s de forma consecutiva, y así coincidan con las IPs indicadas en la Tabla 1. |
A continuación, se muestran los pasos a seguir para la creación de la MV bootstrap (para el resto de MV que componen el clúster será igual cambiando los requerimientos mínimos indicados por Red Hat).
Se procede a crear la MV con el asistente y ubicarla dentro del Datacenter creado para Openshift.
|
En la sección de S.O. deberemos de seleccionar Red Hat Enterprise Linux 7 (64 bits), aunque luego vayamos a montar un CoreOS. |
En el apartado de Hardware es necesario establecer los requisitos de CPU, RAM y Disco Duro siguiendo los parámetros recomendados por Red Hat. Es necesario configurar la MV para que utilice la ISO de CoreOS que ha debido ser cargada en almacén de datos de VMWare.
La imagen ISO, se encuentra en el almacén de datos. Debe ser seleccionada y deber ser habilitada la opción “Conectar al encender”
|
En el apartado de Hardware también debe añadirse un parámetro necesario para Kubernetes. Este parámetro permite disponer un UUID consistente para la MV. Se introduce en el apartado Opciones de Máquina Virtual -> Avanzado -> Editar Configuración |
|
El nombre del parámetro que se introduce es disk.EnableUUID y el valor será TRUE. |
Finalizada esta configuración ya se ha generado la MV bootstrap (Igual para el resto de MV). Una vez creadas todas las MV necesarias para el clúster de Openshift, se deben arrancar para instalar el SO RH CoreOS.
|
Se ha configurado la ISO para que al arrancar el SO se solicite al usuario qué tipo de instalación se va a realizar (bootstrap, master/control plane o worker). |
El menú es como el que se muestra a continuación:
Instalación.
Después de conseguir todas las tareas previas a la instalación, ahora se está en disposición de finalizar instalación inicializando el clúster de OCP.
Para ello ejecutaremos el siguiente comando:
|
[atsistemas@hahelper]$ ../openshift-install wait-for bootstrap-complete --log-level=debug DEBUG OpenShift Installer 4.4.3 DEBUG Built from commit 78b817ceb7657f81176bbe182cc6efc73004c841 INFO Waiting up to 30m0s for the Kubernetes API at https://api.openshift.atsistemas.at:6443... INFO API v.1.17.2 up INFO Waiting up to 30m0s for bootstrapping to complete... DEBUG Bootstrap status: complete INFO It is now safe to remove the bootstrap resources |
|
Ahora antes de terminar la instalación del OCP, tenemos que comprobar que todos los CSR están en Approved , por lo que comprobaremos con el comando.
Esta acción la deberemos de completar antes de 24h, sino el clúster de Kubernetes dejará de funcionar y será necesario volver a empezar la instalación. |
|
[atsistemas@hahelper ~]$ oc get csr
|
|
Si nos sale algún certificado como Pending, debemos aprobarlo con el comando. |
|
[atsistemas@hahelper ~]$ oc adm certificate approve <nombre_csr>
|
Además, comprobaremos que los nodos están Ready, para completar la instalación.
|
[atsistemas@hahelper ~]$ oc get nodes
|
|
NAME STATUS ROLES AGE VERSION master0.openshift.atsistemas.at Ready master 57d v1.17.1 master1.openshift.atsistemas.at Ready master 57d v1.17.1 master2.openshift.atsistemas.at Ready master 57d v1.17.1 worker0.openshift.atsistemas.at Ready worker 57d v1.17.1 worker1.openshift.atsistemas.at Ready worker 57d v1.17.1 worker2.openshift.atsistemas.at Ready worker 57d v1.17.1 worker3.openshift.atsistemas.at Ready worker 57d v1.17.1 |
Ahora finalizaremos la instalación del OCP con el comando:
|
[atsistemas@hahelper ~]$ openshift-install wait-for install-complete --log-level=debug
|
Deberá de devolver un mensaje parecido a este, con la URL de la consola y la pass del kubeadmin para poder acceder la primera vez:
|
[atsistemas@hahelper]$ ../openshift-install wait-for install-complete --log-level=debug DEBUG OpenShift Installer 4.4.3 DEBUG Built from commit 78b817ceb7657f81176bbe182cc6efc73004c841 DEBUG Fetching Install Config... DEBUG Loading Install Config... DEBUG Loading SSH Key... DEBUG Loading Base Domain... DEBUG Loading Platform... DEBUG Loading Cluster Name... DEBUG Loading Base Domain... DEBUG Loading Platform... DEBUG Loading Pull Secret... DEBUG Loading Platform... DEBUG Using Install Config loaded from state file DEBUG Reusing previously-fetched Install Config INFO Waiting up to 30m0s for the cluster at https://api.openshift.atsistemas.at:6443 to initialize... DEBUG Cluster is initialized INFO Waiting up to 10m0s for the openshift-console route to be created... DEBUG Route found in openshift-console namespace: console DEBUG Route found in openshift-console namespace: downloads DEBUG OpenShift console route is created INFO Install complete! INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/atsistemas/poc-install-ignition/auth/kubeconfig' INFO Access the OpenShift web-console here: https://console-openshift-console.apps.openshift.atsistemas.at INFO Login to the console with user: kubeadmin, password: N0h3-mu3rt0-3n3l-1nt3nt0
|
Ahora deberíamos de tener acceso a Openshift :
Ahora haremos login con el usuario kubeadmin y comprobaremos que el clúster está totalmente operativo.
Conclusión
En este articulo hemos visto que instalar Openshift Container Platform sobre VMWare no es una tarea imposible si eres metódico en los pasos que marca la documentación oficial de RedHat y además tienes conocimiento tanto de Linux, comunicaciones y Kubernetes.
Además, si sigues los trucos que se han comentado en este artículo, seguro que consigues finalizar la instalación con éxito.
Esperamos ( Roberto y Adolfo ) que os ayude en el reto de instalar OCP sobre VMWare.