OKD: Instalación – SADASERVICES

Requsitos

El sistema requiere

Equipos	Descripción	Sistema Operativo
1 máquina temporal bootstrap	Se utiliza para desplegar el clúster sobre los control plane nodes. Se elimina después de la instalación.	Fedora CoreOS (FCOS).
3 máquinas control plane	Ejecutan Kubernetes y los servicios de OKD.	Fedora CoreOS (FCOS).
2 workers	Ejecutan las cargas de trabajo de los usuarios.	pueden usar FCOS o Fedora ≥ 8.6.

Para alta disponibilidad, se recomienda que todas estas máquinas estén en hosts físicos separados.
Requisitos de Hardware

Requisitos de red

Todas las máquinas Fedora CoreOS (FCOS) requieren que la red esté configurada en initramfs durante el arranque para poder obtener sus archivos de configuración de Ignition.
Durante el arranque inicial, las máquinas necesitan una configuración de dirección IP que se establece ya sea mediante un servidor DHCP o de manera estática proporcionando las opciones de arranque necesarias. Una vez que se establece la conexión de red, las máquinas descargan sus archivos de configuración de Ignition desde un servidor HTTP o HTTPS. Los archivos de configuración de Ignition se utilizan posteriormente para establecer el estado exacto de cada máquina. El Machine Config Operator realiza más cambios en las máquinas, como la aplicación de nuevos certificados o claves, después de la instalación.
En las máquinas Fedora CoreOS (FCOS), el nombre de host se establece a través de NetworkManager. Por defecto, las máquinas obtienen su nombre de host mediante DHCP. Si el nombre de host no es proporcionado por DHCP, se establece de manera estática mediante argumentos del kernel u otro método, se obtiene a través de una búsqueda DNS inversa.

Puertos requeridos

Requisitos de DNS

En los despliegues de OKD, se requiere la resolución de nombres DNS para los siguientes componentes:

La API de Kubernetes
El comodín de aplicaciones de OKD
Las máquinas bootstrap, del plano de control y de cómputo

También se requiere resolución DNS inversa para la API de Kubernetes, la máquina bootstrap, las máquinas del plano de control y las máquinas de cómputo.

Se utilizan registros DNS A/AAAA o CNAME para la resolución de nombres y registros PTR para la resolución inversa de nombres. Los registros inversos son importantes porque Fedora CoreOS (FCOS) utiliza estos registros para establecer los nombres de host de todos los nodos, a menos que los nombres de host se proporcionen mediante DHCP. Además, los registros inversos se usan para generar las solicitudes de firma de certificados (CSR) que OKD necesita para funcionar.

Se recomienda usar un servidor DHCP para proporcionar los nombres de host a cada nodo del clúster. Consulte la sección Recomendaciones de DHCP para infraestructura aprovisionada por el usuario para más información.

Los siguientes registros DNS son requeridos para un clúster OKD aprovisionado por el usuario y deben estar configurados antes de la instalación. En cada registro, <cluster_name> es el nombre del clúster y <base_domain> es el dominio base que se especifica en el archivo install-config.yaml. Un registro DNS completo tiene la forma: <component>.<cluster_name>.<base_domain>.

Ejemplo de registros

$TTL 1W
@	IN	SOA	ns1.example.com.	root (
			2019070700	; serial
			3H		; refresh (3 hours)
			30M		; retry (30 minutes)
			2W		; expiry (2 weeks)
			1W )		; minimum (1 week)
	IN	NS	ns1.example.com.
	IN	MX 10	smtp.example.com.
;
;
ns1.example.com.		IN	A	192.168.1.5
smtp.example.com.		IN	A	192.168.1.5
;
helper.example.com.		IN	A	192.168.1.5
helper.ocp4.example.com.	IN	A	192.168.1.5
;
api.ocp4.example.com.		IN	A	192.168.1.5 
api-int.ocp4.example.com.	IN	A	192.168.1.5 
;
*.apps.ocp4.example.com.	IN	A	192.168.1.5 
;
bootstrap.ocp4.example.com.	IN	A	192.168.1.96 
;
control-plane0.ocp4.example.com.	IN	A	192.168.1.97 
control-plane1.ocp4.example.com.	IN	A	192.168.1.98 
control-plane2.ocp4.example.com.	IN	A	192.168.1.99 
;
compute0.ocp4.example.com.	IN	A	192.168.1.11 
compute1.ocp4.example.com.	IN	A	192.168.1.7 
;
;EOF

Dominio	Descripción
api.ocp4.example.com.	Proporciona resolución de nombres para la API de Kubernetes. El registro hace referencia a la dirección IP del balanceador de carga de la API.
api-int.ocp4.example.com.	Proporciona resolución de nombres para la API de Kubernetes. El registro hace referencia a la dirección IP del balanceador de carga de la API y se utiliza para comunicaciones internas dentro del clúster.
*.apps.ocp4.example.com.	Proporciona resolución de nombres para las rutas comodín. El registro hace referencia a la dirección IP del balanceador de carga de ingreso de aplicaciones. Este balanceador dirige el tráfico a las máquinas que ejecutan los pods del Ingress Controller, los cuales se ejecutan por defecto en las máquinas de cómputo. En el ejemplo, se utiliza el mismo balanceador de carga para la API de Kubernetes y para el tráfico de ingreso de aplicaciones. En escenarios de producción, se pueden desplegar los balanceadores de carga de la API y de ingreso de aplicaciones por separado, de modo que se pueda escalar la infraestructura de cada balanceador de manera independiente.
bootstrap.ocp4.example.com.	Proporciona resolución de nombres para la máquina bootstrap.
control-plane0.ocp4.example.com.	Proporciona resolución de nombres para las máquinas del plano de control.
compute1.ocp4.example.com.	Proporciona resolución de nombres para las máquinas de cómputo.

Dominios UNA

Dominio	IP
api.okd.una.ac.cr.	10.0.2.233
api-int.okd.una.ac.cr.	10.0.2.233
*.apps.okd.una.ac.cr.	10.0.2.233
bootstrap.okd.una.ac.cr.	10.0.2.234
control-plane1.okd.una.ac.cr.	10.0.2.235
control-plane2.okd.una.ac.cr.	10.0.2.236
control-plane3.okd.una.ac.cr.	10.0.2.237
compute1.okd.una.ac.cr.	10.0.2.241
compute2.okd.una.ac.cr.	10.0.2.242
compute3.okd.una.ac.cr.	10.0.2.243

Resolusiones inversas

Ejemplo

$TTL 1W
@	IN	SOA	ns1.example.com.	root (
			2019070700	; serial
			3H		; refresh (3 hours)
			30M		; retry (30 minutes)
			2W		; expiry (2 weeks)
			1W )		; minimum (1 week)
	IN	NS	ns1.example.com.
;
5.1.168.192.in-addr.arpa.	IN	PTR	api.ocp4.example.com. 
5.1.168.192.in-addr.arpa.	IN	PTR	api-int.ocp4.example.com. 
;
96.1.168.192.in-addr.arpa.	IN	PTR	bootstrap.ocp4.example.com. 
;
97.1.168.192.in-addr.arpa.	IN	PTR	control-plane0.ocp4.example.com. 
98.1.168.192.in-addr.arpa.	IN	PTR	control-plane1.ocp4.example.com. 
99.1.168.192.in-addr.arpa.	IN	PTR	control-plane2.ocp4.example.com. 
;
11.1.168.192.in-addr.arpa.	IN	PTR	compute0.ocp4.example.com. 
7.1.168.192.in-addr.arpa.	IN	PTR	compute1.ocp4.example.com. 
;
;EOF

Dominio	Descripcion
api.ocp4.example.com.	Proporciona resolución DNS inversa para la API de Kubernetes. El registro PTR hace referencia al nombre de registro del balanceador de carga de la API.
api-int.ocp4.example.com.	Proporciona resolución DNS inversa para la API de Kubernetes. El registro PTR hace referencia al nombre de registro del balanceador de carga de la API y se utiliza para comunicaciones internas dentro del clúster.
bootstrap.ocp4.example.com.	Proporciona resolución DNS inversa para la máquina bootstrap.
control-plane0.ocp4.example.com.	Proporciona resolución DNS inversa para las máquinas del plano de control.
compute0.ocp4.example.com.	Proporciona resolución DNS inversa para las máquinas de cómputo.

NOTA: Para el Wildcard no es necesario la resolusión PTR

Validar los DNS

Los pasos de validación detallados en esta sección deben completarse con éxito antes de instalar su clúster.
Desde su nodo de instalación, ejecute consultas DNS (lookups) contra los nombres de registro de la API de Kubernetes, las rutas comodín y los nodos del clúster. Valide que las direcciones IP contenidas en las respuestas correspondan a los componentes correctos.
Realice una consulta contra el nombre de registro de la API de Kubernetes. Verifique que el resultado apunte a la dirección IP del balanceador de carga de la API:

dig +noall +answer @<nameserver_ip> api.<cluster_name>.<base_domain>

Ejecutar

# apis
dig +noall +answer @10.0.98.101 api.okd.una.ac.cr
dig +noall +answer @10.0.98.101 api-int.okd.una.ac.cr

# comodin
dig +noall +answer @10.0.98.101 random.apps.okd.una.ac.cr

#bootstrap
dig +noall +answer @10.0.98.101 bootstrap.okd.una.ac.cr

dig +noall +answer @10.0.98.101 cp1.okd.una.ac.cr
dig +noall +answer @10.0.98.101 cp2.okd.una.ac.cr
dig +noall +answer @10.0.98.101 cp3.okd.una.ac.cr

dig +noall +answer @10.0.98.101 compute1.okd.una.ac.cr
dig +noall +answer @10.0.98.101 compute2.okd.una.ac.cr
dig +noall +answer @10.0.98.101 compute3.okd.una.ac.cr

NOTA: En los ejemplos, se usa el mismo balanceador para la API de Kubernetes y el tráfico de ingreso de aplicaciones. En producción, puede desplegar los balanceadores por separado para escalar cada infraestructura de manera independiente.

Verificar consultas inversas

Consultas Inversas

#api
dig +noall +answer @10.0.98.101 -x 10.0.2.233

#bootstrap
dig +noall +answer @10.0.98.101 -x 10.0.2.234

#control-plane1
dig +noall +answer @10.0.98.101 -x 10.0.2.235

#control-plane2
dig +noall +answer @10.0.98.101 -x 10.0.2.236

#control-plane3
dig +noall +answer @10.0.98.101 -x 10.0.2.237

#compute1
dig +noall +answer @10.0.98.101 -x 10.0.2.241

#compute2
dig +noall +answer @10.0.98.101 -x 10.0.2.242

#compute3
dig +noall +answer @10.0.98.101 -x 10.0.2.243

Requisitos de balanceo de carga para infraestructura aprovisionada por el usuario

Antes de instalar OKD, debes aprovisionar la infraestructura de balanceo de carga para la API y el Ingress de aplicaciones. En escenarios de producción, puedes implementar los balanceadores de carga de API y de Ingress de aplicaciones por separado, de modo que puedas escalar la infraestructura de balanceo de carga de cada uno de forma independiente.

Si deseas implementar los balanceadores de carga de API e Ingress de aplicaciones con una instancia de Fedora, debes adquirir la suscripción de Fedora por separado.

La infraestructura de balanceo de carga debe cumplir con los siguientes requisitos:

Balanceador de carga de API:

Proporciona un punto de acceso común para que los usuarios, tanto humanos como máquinas, interactúen y configuren la plataforma. Configura las siguientes condiciones:

Balanceo en Capa 4 solamente. Esto también se conoce como Raw TCP o SSL Passthrough mode.
Algoritmo de balanceo sin estado. Las opciones varían según la implementación del balanceador.
No configurar persistencia de sesión para un balanceador de carga de API. Hacerlo para el servidor API de Kubernetes podría generar problemas de rendimiento debido al exceso de tráfico de aplicaciones en tu clúster OKD y en la API de Kubernetes que se ejecuta dentro del clúster.

Debes configurar los siguientes puertos en la parte frontal y trasera de los balanceadores:

El balanceador debe estar configurado para tardar un máximo de 30 segundos desde el momento en que el servidor API desactiva el endpoint /readyz hasta la eliminación de esa instancia del pool. Durante este intervalo, después de que /readyz devuelva error o se recupere, el endpoint debe haberse eliminado o agregado. Probar cada 5 o 10 segundos, con dos solicitudes exitosas para marcar saludable y tres fallidas para marcar no saludable, son valores probados y recomendados.

Balanceador de carga de Ingress de aplicaciones:

Proporciona un punto de entrada para el tráfico de aplicaciones proveniente desde fuera del clúster. Se requiere una configuración funcional del router Ingress para un clúster OKD.

Configura las siguientes condiciones:

Balanceo en Capa 4 solamente (Raw TCP o SSL Passthrough mode).
Se recomienda persistencia basada en conexión o sesión, según las opciones disponibles y los tipos de aplicaciones que se hospedarán en la plataforma.
Si el balanceador puede ver la dirección IP real del cliente, habilitar la persistencia basada en IP de origen puede mejorar el rendimiento de aplicaciones que usen cifrado TLS de extremo a extremo.

Debes configurar los siguientes puertos en la parte frontal y trasera de los balanceadores:

Generación de un par de claves para acceso SSH a los nodos del clúster

Durante una instalación de OKD, puedes proporcionar una clave pública SSH al programa de instalación.
La clave se pasa a los nodos Fedora CoreOS (FCOS) a través de sus archivos de configuración Ignition y se utiliza para autenticar el acceso SSH a los nodos.

La clave se agrega a la lista ~/.ssh/authorized_keys del usuario core en cada nodo, lo que habilita la autenticación sin contraseña.

Después de que la clave se haya pasado a los nodos, puedes usar el par de claves para acceder a ellos vía SSH como el usuario core.
Para acceder a los nodos mediante SSH, la clave privada debe estar gestionada por SSH para tu usuario local.

Si deseas acceder vía SSH a los nodos del clúster para realizar depuración de la instalación o recuperación ante desastres, debes proporcionar la clave pública SSH durante el proceso de instalación.
El comando ./openshift-install gather también requiere que la clave pública SSH esté configurada en los nodos del clúster.

⚠️ No omitas este procedimiento en entornos de producción, donde la recuperación ante desastres y la depuración son necesarias.

En clústeres que ejecutan Fedora CoreOS (FCOS):

Las claves SSH especificadas en los archivos Ignition se escriben en el archivo /home/core/.ssh/authorized_keys.d/core.
Sin embargo, el Machine Config Operator administra las claves SSH en /home/core/.ssh/authorized_keys y configura sshd para que ignore el archivo /home/core/.ssh/authorized_keys.d/core.
Como resultado, los nodos recién aprovisionados no son accesibles por SSH hasta que el Machine Config Operator sincronice las configuraciones de máquina con el archivo authorized_keys.
Una vez que puedas acceder a los nodos mediante SSH, puedes eliminar el archivo /home/core/.ssh/authorized_keys.d/core.

Crear llaves

Ejecutar

ssh-keygen -t ed25519 -N '' -f <ruta>/<nombre_archivo>

ssh-keygen -t ed25519 -N '' -f ~/.ssh/id_ed25519_openshift

Si ya tienes un par de claves existente, asegúrate de que tu clave pública esté en el directorio ~/.ssh.
Ver tu clave pública SSH:

cat <ruta>/<nombre_archivo>.pub

cat ~/.ssh/id_ed25519.pub

Agregar la clave privada SSH al agente SSH de tu usuario local (si aún no está gestionada).
Si el proceso ssh-agent no está en ejecución, inícialo:

eval "$(ssh-agent -s)"

Agregar la clave privada al agente SSH:

ssh-add <ruta>/<nombre_archivo>

ssh-add ~/.ssh/id_ed25519_openshift

1. Instalación de MV Provisioner

Se crea una MV con las siguientes caracteristicas
- SO: Ubuntu Server 24.04
- CPU: 2
- RAM: 4GB
- HD: 35 GB
- IP: 10.0.2.244

Actualizar el servidor

Se actualiza el servidor

sudo apt update && sudo apt upgrade -y && sudo apt dist-upgrade -y && sudo apt autoremove -y && sudo apt clean

Obtener programas:

Página de descarga

Descargar el instalador desde
https://github.com/okd-project/okd/releases

1.openshift-install-linux 4.20

Buscamos la última version estable para este momento 4.20.0-okd-scos.0
https://github.com/okd-project/okd/releases/tag/4.20.0-okd-scos.0
Y descargamos el archivo openshift-install-linux-4.20.0-okd-scos.0.tar.gz

mkdir programas
cd programas/

wget https://github.com/okd-project/okd/releases/download/4.20.0-okd-scos.0/openshift-install-linux-4.20.0-okd-scos.0.tar.gz

2. openshift-client-linux

Descargamos el programa

wget https://github.com/okd-project/okd/releases/download/4.20.0-okd-scos.0/openshift-client-linux-4.20.0-okd-scos.0.tar.gz

3. Instalación

Los descomprimimos y los colocamos en /usr/local/bin

sudo tar xfvz openshift-install-linux-4.20.0-okd-scos.0.tar.gz -C /usr/local/bin

sudo tar xfvz openshift-client-linux-4.20.0-okd-scos.0.tar.gz -C /usr/local/bin

4. Eliminamos el archivo README

ejecutamos

sudo rm /usr/local/bin/README.md

5. Verificamos

Ejecutamos

which oc

which openshift-install

Versiones