Update von 4.15 auf 4.17+

• Cluster auf 4.15.0-0.okd-2024-03-10-010116 bringen
• Update auf 4.16.0-okd-scos.1 https://github.com/okd-project/okd/releases/tag/4.16.0-okd-scos.1
• Update auf 4.17
• Update auf 4.17+

Es muss von 4.15 (FCOS) auf 4.16 (FCOS) upgedated werden. Anschließend erfolgt gleich ein Update auf 4.17 (siehe auch: https://okd.io/docs/project/upgrade-notes/from-4-15/known-issues-4-16/).

Vorbereitung

• Release hash für 4.16.0-okd-scos.1 holen unter: https://github.com/okd-project/okd/releases/tag/4.16.0-okd-scos.1
  Pull From: quay.io/okd/scos-release@sha256:0de353901f9ab5ecb14c2583d16d24561df23d1bf46fe03f218f2ffb8f134096

• hyperkube Referenz holen mit:

  $ oc adm release info \
   --image-for=hyperkube quay.io/okd/scos-release@sha256:0de353901f9ab5ecb14c2583d16d24561df23d1bf46fe03f218f2ffb8f134096
  quay.io/okd/scos-content@sha256:5c9128668752a9b891a24a9ec36e0724d975d6d49e6e4e2d516b5ba80ae2fb23
  

• cluster-kube-apiserver-operator Referenz:

  $ oc adm release info \
  --image-for=cluster-kube-apiserver-operator quay.io/okd/scos-release@sha256:0de353901f9ab5ecb14c2583d16d24561df23d1bf46fe03f218f2ffb8f134096
  quay.io/okd/scos-content@sha256:37d6b6c13d864deb7ea925acf2b2cb34305333f92ce64e7906d3f973a8071642
  

Upgrade Part I

• oc adm upgrade --allow-explicit-upgrade --force --to-image quay.io/okd/scos-release@sha256:0de353901f9ab5ecb14c2583d16d24561df23d1bf46fe03f218f2ffb8f134096

• nach ca. 1 Minute kommt ein Fehler:

  Could not update customresourcedefinition "infrastructures.config.openshift.io" (47 of 903): the object is invalid, possibly due to local cluster configuration
  

  Am besten zu finden auf der Console unter Administration -> Cluster Settings.

• cluster-version-operator anhalten. Der sollte uns jetzt nicht dazwischenpfuschen:
  oc scale --replicas=0 deployments/cluster-version-operator -n openshift-cluster-version

• Editieren vom kube-apiserver-operator im Namespace openshift-kube-apiserver-operator:
  oc edit -n openshift-kube-apiserver-operator deployments/kube-apiserver-operator

  • das image:austauschen mit dem Image von oben: hyperkube
    = quay.io/okd/scos-content@sha256:37d6b6c13d864deb7ea925acf2b2cb34305333f92ce64e7906d3f973a8071642
  • die env Definition für IMAGE austauschen mit dem oben gefundenen Image für hyperkube
    = quay.io/okd/scos-content@sha256:5c9128668752a9b891a24a9ec36e0724d975d6d49e6e4e2d516b5ba80ae2fb23
  • die env Definition für OPERATOR_IMAGE austauschen mit dem oben gefundenen Image für cluster-kube-apiserver-operator
    = quay.io/okd/scos-content@sha256:37d6b6c13d864deb7ea925acf2b2cb34305333f92ce64e7906d3f973a8071642 (ja, das ist ident zum oberene image:)
  • die env Definition für OPERAND_IMAGE_VERSION auf 1.29.6 setzen

  (geht auch mit Hilfe von ./patch-kube-apiserver-operator.sh)

• Warten, bis der Pod vom kube-apiserver-operator wieder Ready ist.

• cluster-version-operator wieder hochfahren. Der kann jetzt weitermachen:
  oc scale --replicas=1 deployments/cluster-version-operator -n openshift-cluster-version

• in Administration -> Cluster Settings kann man jetzt den Update verfolgen, ...

Update Part II

• Update Channel: stable-4 ist im Graph wohl als Stream 4-scos-stable verzeichnet

• Zur Info: Link zum Release Graph https://origin-release.ci.openshift.org/graph?format=svg auf der Release Seite

• Nächster Step: 4.17.0-okd-scos.3

• Step: 4.18.0-okd-scos.10

  • der wirft einen Error mit "unable to verify", wenn das passiert:
  • oc adm upgrade --to-latest --force

• Step: 4.19.0-okd-scos.19

  • hier gibt es Breaking Changes. D.h. es besteht die Gefahr, das etwas nicht mehr geht: https://access.redhat.com/articles/7112216
  • Das betrifft hauptsächlich: flowschemas.flowcontrol.apiserver.k8s.io/v1beta3 + prioritylevelconfigurations.flowcontrol.apiserver.k8s.io/v1beta3
  • Wennn alles OK ist:
  • oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.18-kube-1.32-api-removals-in-4.19":"true"}} --type=merge
  • dann den normalen Upgrade starten

• Step: 4.20.0-okd-scos.5

  • die große Änderung ist hier, das crun anstelle von runc verwendet wird.
  • es muss daher dringend vor dem Update die beiden ContainerRuntimeConfig machine-master.yaml und machine-worker.yaml installiert werden.
  • danach sollte der Update laufen.

  Erklärung:
  Früher (d.h. bis 4.18) wurde runc zum Ansprechen der Container Runtime verwendet. Das hat sich geändert in 4.19. Allerdings wurde in SCOS9 (bis 4.19) weiterhin runc mitinstalliert, daher ist nix aufgefallen. Mit SCOS10 wird nun runc nicht mehr installiert und das Problem taucht auf. Die besagten 2 ContainerRuntimeConfigs müssen daher nur bei einem Update von älteren Clustern mitinstalliert werden, bei neuen Clustern ist das nicht notwendig (siehe auch: https://okd.io/blog/2025/09/30/2025-4.20-release-issues/ und https://github.com/okd-project/okd/issues/2255)!

Notiz: Es passiert immer wieder, das bei einem der Updates ein Error auftritt auf einem der Nodes mit Cannot taint node, aborting.
Die schnelle Lösung ist:

• ca. eine Viertelstunde warten
• betroffene Node einfach Hard Resetten
• warten, der Prozess startet dann meist wieder von selbst.
• Dies sollte man aber immer nur mit einer Node gleichzeitig machen, um eine Schieflage im Cluster zu vermeiden