Red Hat OpenShift: proyectos, Routes, SCC, acceso por grupos y actualizaciones por canal

Qué vas a conseguir

Un clúster OpenShift en el que cada equipo tiene su proyecto, entra con su cuenta corporativa y despliega sin pedirte permiso para cada cosa; una aplicación interna publicada con una Route; un procedimiento de actualización que no te pilla por sorpresa, y los dos tickets que más llegan resueltos en minutos.

Antes de empezar

• Un clúster OpenShift Container Platform 4.x ya instalado (en vSphere, Nutanix, bare metal o en la nube) y acceso de cluster-admin.
• El cliente oc de la misma versión menor que el clúster (se descarga desde la propia consola: icono de ayuda › Herramientas de línea de comandos).
• Saber qué es un Pod, un Deployment y un Service: la guía de Kubernetes lo cuenta. Aquí se habla de lo que OpenShift pone encima.

1. Lo que OpenShift añade a Kubernetes

Lo que más cambia en el día a día es la SCC: una imagen que en un Kubernetes cualquiera arranca como root, aquí no lo hace. Es intencionado y es la causa del primer ticket de la sección 6.

2. Entrar con oc y crear el proyecto

En la consola, menú de usuario › Copy login command da el token de la sesión. Con él:

oc login --token=sha256~XXXXXXXX --server=https://api.ocp01.contoso.example.com:6443

Después, oc new-project finanzas-informes --display-name="Finanzas · Informes" crea el proyecto y lo deja como activo, y oc whoami --show-console devuelve la URL de la consola.

• Todo lo que se crea a partir de aquí va al proyecto activo; oc project dice cuál es y oc get projects lista los tuyos.

3. Desplegar una aplicación interna

La forma rápida es oc new-app, que crea el Deployment y el Service a partir de una imagen:

›oc new-app --name=informes registry.contoso.example.com/finanzas/informes:1.4.2--> Creating resources ...    deployment.apps "informes" created    service "informes" created--> Success›oc create route edge informes --service=informes --hostname=informes.apps.ocp01.contoso.example.comroute.route.openshift.io/informes created›oc get pods,routeNAME                            READY   STATUS    RESTARTS   AGEpod/informes-6d9c7b9f5c-2kqzl   1/1     Running   0          48sNAME                                HOST/PORT                                  SERVICES   PORT       TERMINATIONroute.route.openshift.io/informes   informes.apps.ocp01.contoso.example.com    informes   8080-tcp   edge

• Para producción, guarda los manifiestos (Deployment, Service, Route) en Git y aplícalos con oc apply -f o con OpenShift GitOps (Argo CD). new-app sirve para empezar; lo que no está en Git no se puede reconstruir.
• edge termina TLS en el router con el certificado comodín de *.apps; re-encrypt vuelve a cifrar hasta el pod; passthrough deja el TLS al pod.
• Añade readiness y liveness probes: sin ellas el router manda tráfico a pods que aún no responden.

4. Acceso de un equipo: proveedor de identidad y RoleBindings

Tras la instalación solo existe kubeadmin. Lo primero es conectar el proveedor de identidad. Con Entra ID se usa OpenID Connect: registra una aplicación en Entra ID con la URL de retorno https://oauth-openshift.apps.ocp01.contoso.example.com/oauth2callback/entra-id, guarda su secreto en openshift-config y añádela al recurso OAuth:

• Con LDAP / Active Directory el proveedor es de tipo LDAP y los grupos se traen con oc adm groups sync y un fichero de configuración, programado como CronJob.
• Los permisos se dan a grupos, nunca a personas:

oc adm policy add-role-to-group edit grp-ocp-finanzas -n finanzas-informes

• Roles predefinidos: view (solo lectura), edit (desplegar), admin (además gestionar permisos del proyecto). cluster-admin solo para el equipo de plataforma, y mejor con un grupo dedicado.
• Cuando el proveedor funciona y hay al menos un cluster-admin de grupo, elimina kubeadmin: oc delete secrets kubeadmin -n kube-system.

Antes de borrar kubeadmin, entra con una cuenta del grupo de administradores en otra ventana. Si el proveedor falla después, el acceso de emergencia es el kubeconfig de la instalación: guárdalo en la caja fuerte de credenciales.

5. Actualizar el clúster por canales

OpenShift se actualiza entero (sistema operativo de los nodos incluido) desde el Cluster Version Operator. El canal decide qué versiones se ofrecen: stable-4.x para producción, fast-4.x cuando quieres la versión antes, eus-4.x en las versiones pares para saltar de EUS a EUS.

›oc get clusterversionNAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUSversion   4.20.14   True        False         23d     Cluster version is 4.20.14›oc adm upgradeCluster version is 4.20.14Channel: stable-4.20Recommended updates:  VERSION     IMAGE  4.20.18     quay.io/openshift-release-dev/ocp-release@sha256:...›oc adm upgrade --to=4.20.18Requested update to 4.20.18›oc get clusteroperators | grep -v "True        False         False"NAME                 VERSION   AVAILABLE   PROGRESSING   DEGRADEDmachine-config       4.20.14   True        True          False

• Antes: todos los clusteroperators en Available y sin Degraded, los MachineConfigPool actualizados (oc get mcp) y las notas de la versión leídas, sobre todo las APIs retiradas (el clúster pide un admin-ack cuando hay alguna).
• Los nodos se reinician de uno en uno. Los PodDisruptionBudget mal puestos (mínimo disponible igual al número de réplicas) bloquean el drenado: es la causa más habitual de una actualización parada.
• Para controlar el ritmo en los workers, pausa su pool (oc patch mcp worker --type merge -p '{"spec":{"paused":true}}') y reanúdalo en la ventana.

6. El ticket: "el pod no arranca: permission denied"

Una imagen de nginx publicada en Docker Hub entra en CrashLoopBackOff:

›oc logs deploy/portalnginx: [emerg] mkdir() "/var/cache/nginx/client_temp" failed (13: Permission denied)›oc get pod portal-7f8d6c5b4-xk2vp -o jsonpath='{.metadata.annotations.openshift\.io/scc}{"\n"}'restricted-v2›oc get pod portal-7f8d6c5b4-xk2vp -o jsonpath='{.spec.containers[0].securityContext.runAsUser}{"\n"}'1000680000

El pod corre con un UID del rango del proyecto, no como root, y la imagen espera escribir en carpetas de root. Por orden de preferencia:

1. Usar una imagen preparada para UID arbitrario (las UBI de Red Hat o las variantes unprivileged), o ajustar el Dockerfile para que las carpetas de escritura pertenezcan al grupo 0 con permisos de grupo.
2. Montar un emptyDir en las rutas donde escribe.
3. Solo si no hay otra salida, una cuenta de servicio propia con la SCC nonroot-v2 o anyuid (oc adm policy add-scc-to-user anyuid -z sa-portal), documentada como excepción. Nunca a la cuenta default ni con privileged.

La variante: "la Route devuelve 503 Application is not available". El router no encuentra un pod sano detrás del Service. Revisa en este orden: oc get endpoints portal (si está vacío, el selector del Service no coincide con las etiquetas de los pods, o los pods no están Ready); oc describe route portal (¿apunta al Service y al puerto correctos?), y el targetPort del Service frente al puerto en el que escucha realmente el contenedor.

7. Lo que revisas cada mes

• Actualizaciones pendientes del canal y el fin de soporte de la versión menor en uso.
• Alertas activas en Observar › Alertas, certificados próximos a caducar y uso de disco de etcd.
• Excepciones de SCC concedidas: quién, para qué y si siguen haciendo falta.
• Proyectos sin propietario o sin cuota, y RoleBindings a usuarios individuales que deberían ser de grupo.

Siguientes pasos

• La guía de Kubernetes para lo que comparte con OpenShift: Deployments, probes, recursos y almacenamiento.
• Terraform para crear la infraestructura del clúster y los registros DNS de api y *.apps.
• La guía de Entra ID: SSO/SAML para el registro de aplicaciones y los grupos en el token.
• Azure Monitor y Log Analytics o Grafana si quieres llevar las métricas y logs fuera del clúster.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.