OKD: Actualización

  • Ingresamos a okd-provisioner
  • primero definimos el estado del cluster
# 1. Todos los ClusterOperators sanos (AVAILABLE=True, DEGRADED=False)
oc get clusteroperators

Notar: node-tuning

  • Vamos a corregir
oc -n openshift-cluster-node-tuning-operator get profiles.tuned.openshift.io
oc get co node-tuning -o jsonpath='{.status.conditions}' | jq .
  • cp1 es el del problema
# 1. Estado del pod tuned en compute1 (¿Running? ¿Ready? ¿restarts?)
oc -n openshift-cluster-node-tuning-operator get pods -o wide | grep -E 'NAME|compute1'

# 2. Detalle del Profile de compute1 — por qué tiene status vacío
oc -n openshift-cluster-node-tuning-operator get profile compute1.okd.una.ac.cr -o yaml
  • revisar certificados
oc get csr | grep -i pending
  • Los aprobamos
oc get csr -o name | xargs oc adm certificate approve
  • Verificamos
oc get csr | grep -i pending
  • Ahora reiniciamos el tuned
oc -n openshift-cluster-node-tuning-operator delete pod tuned-6plbk
  • listo cp1 ya lo reporta
oc -n openshift-cluster-node-tuning-operator get profiles.tuned.openshift.io
  • verificamos
oc get co node-tuning

Continua actualización

# 2. Que no haya MachineConfigPools a medio aplicar (UPDATED=True, DEGRADED=False)
oc get mcp
# 3. Nodos todos Ready
oc get nodes
# 4. EL PASO CLAVE: qué actualizaciones ve tu clúster
oc adm upgrade

Upgrade de 4.21 a 4.22 -> Determinar si tenemos algo que lo impida

  • APIS
oc get apirequestcounts -o json | jq -r '.items[] | select(.status.removedInRelease != null and .status.removedInRelease != "") | "\(.metadata.name)  removed-in:\(.status.removedInRelease)  last24h:\(.status.requestCount)"'

Cómo lo vamos a leer:

  • Sale vacío → ningún workload está usando APIs en vías de remoción; muy buena señal para el salto.
  • Aparecen APIs con removed-in: 1.35 (o equivalente de 4.22) y last24h > 0 → eso es exactamente lo que se rompería; identificaríamos qué las usa y habría que migrarlas antes.
  • Aparecen pero con last24h: 0 → están definidas pero nadie las llama; riesgo bajo, aunque conviene confirmar.
  • Operadores OLM
oc get csv -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,VERSION:.spec.version,PHASE:.status.phase | sort -u
  • Con esto saltan dos
    • kubeVirt (que versiona 2 versiones a tras del k8s)
    • cgroups
  • Ambos deben ser actualizados

KubeVirt: Actualizar

  • Determinamos los datos
oc get csv kubevirt-hyperconverged-operator.v1.16.0 -n kubevirt-hyperconverged -o jsonpath='{.metadata.annotations.containerImage}{"\n"}'

oc get kubevirt -n kubevirt-hyperconverged -o jsonpath='{.items[0].status.operatorVersion}{"\n"}'

Y acá está el problema serio: KubeVirt no permite saltarse versiones minor. Igual que con OKD, hay que ir escalón por escalón. Para llegar a una versión que soporte 1.35 (la línea v1.8), desde v1.6.2 tendrías que pasar por:

v1.6.2 → v1.7 → v1.8

Respaldo de etcd

  • Ingresamos a cp1.okd.una.ac.cr
ssh core@cp1.okd.una.ac.cr
  • Respaldamos
sudo /usr/local/bin/cluster-backup.sh /home/core/etcd-backup-$(date +%Y%m%d)
  • Cambiamos el dueño
sudo chown -R core:core /home/core/etcd-backup-20260616/
  • En el provisioner lo descargamos para respaldarlo
mkdir -p /home/cgi/respaldos
  • descargamos
scp core@cp1.okd.una.ac.cr:/home/core/etcd-backup-20260616/snapshot_2026-06-16_104320.db .

Paso 1: salir del engineering candidate hacia 4.21 promovido

  • Antes de disparar el upgrade necesito confirmar que el release destino existe, es pulleable y es más nuevo que tu ec.13.
cgi@okd-provisioner-nodo01:~/respaldos$ oc adm release info quay.io/okd/scos-release:4.22.0-okd-scos.3 -o json 2>/dev/null | jq '{version: .metadata.version, created: .config.created, digest: .digest}'

Tenemos el candidato de 4.22 confirmado: versión 4.22.0-okd-scos.3, del 11 de junio 2026 (muy reciente, hace 5 días), digest en mano. Es el destino correcto para tu objetivo de quedar al día.

Pero antes de disparar, hay una verificación que no podemos saltarnos dada la lección que acabamos de aprender. Recién vimos que el CVO rechaza rutas que no están en su grafo de upgrade. Necesito confirmar que 4.22.0-okd-scos.3 acepta tu ec.13 como origen válido — si no, nos va a frenar igual que con el .11, pero esta vez por «ruta no soportada».

oc adm release info quay.io/okd/scos-release:4.22.0-okd-scos.3 -o json 2>/dev/null | jq '.metadata.previous'