Red Hat OpenShift Container Platform es una potente plataforma diseñada para proporcionar a las organizaciones y desarrolladores de TI una plataforma de aplicaciones de nube híbrida. Con esta plataforma segura y escalable, puede implementar aplicaciones en contenedores con una mínima sobrecarga de configuración y administración. En este artículo, aprenderemos cómo realizar la actualización de OpenShift 4.8 a OpenShift 4.9.
Red Hat Enterprise Linux CoreOS (RHCOS) 4.9 y Red Hat Enterprise Linux (RHEL) 8.4 y 7.9 son compatibles con OpenShift Container Platform 4.9. Red Hat recomienda ejecutar la máquina RHCOS en el nodo del plano de control y ejecutar RHCOS o RHEL 8.4+/7.9 en la computadora.
La versión de Kubernetes utilizada en OpenShift Container Platform 4.9 es 1.22. En Kubernetes 1.22, se eliminaron una gran cantidad de API v1beta1 obsoletas. Se introdujo un requisito en OpenShift Container Platform 4.8.14, que requiere que el administrador proporcioneConfirmación manualAntes de poder actualizar el clúster de OpenShift Container Platform 4.8 a 4.9. Esto ayuda a evitar problemas después de actualizar a OpenShift Container Platform 4.9, cuando las cargas de trabajo y los componentes del clúster todavía utilizan la API eliminada.
La API de Kubernetes se eliminó en OpenShift 4.9
A continuación se muestra la lista obsoletav1beta1API en OpenShift Container Platform 4.9 usando Kubernetes 1.22:
APIService |
apiregistration.k8s.io/v1beta1 |
No |
CertificateSigningRequest |
certificates.k8s.io/v1beta1 |
Sí |
ClusterRole |
rbac.authorization.k8s.io/v1beta1 |
No |
ClusterRoleBinding |
rbac.authorization.k8s.io/v1beta1 |
No |
CSIDriver |
storage.k8s.io/v1beta1 |
No |
CSINode |
storage.k8s.io/v1beta1 |
No |
CustomResourceDefinition |
apiextensions.k8s.io/v1beta1 |
Sí |
Ingress |
extensions/v1beta1 |
Sí |
Ingress |
networking.k8s.io/v1beta1 |
Sí |
IngressClass |
networking.k8s.io/v1beta1 |
No |
Lease |
coordination.k8s.io/v1beta1 |
No |
LocalSubjectAccessReview |
authorization.k8s.io/v1beta1 |
Sí |
MutatingWebhookConfiguration |
admissionregistration.k8s.io/v1beta1 |
Sí |
PriorityClass |
scheduling.k8s.io/v1beta1 |
No |
Role |
rbac.authorization.k8s.io/v1beta1 |
No |
RoleBinding |
rbac.authorization.k8s.io/v1beta1 |
No |
SelfSubjectAccessReview |
authorization.k8s.io/v1beta1 |
Sí |
StorageClass |
storage.k8s.io/v1beta1 |
No |
SubjectAccessReview |
authorization.k8s.io/v1beta1 |
Sí |
TokenReview |
authentication.k8s.io/v1beta1 |
No |
ValidatingWebhookConfiguration |
admissionregistration.k8s.io/v1beta1 |
Sí |
VolumeAttachment |
storage.k8s.io/v1beta1 |
No |
v1beta1API eliminada de la tabla Kubernetes 1.22
Debe migrar el manifiesto y el cliente API para utilizarv1Versión de API. Para obtener más información sobre la migración de API obsoletas, consulteDocumentación oficial de Kubernetes.
1) Evalúe el clúster de OpenShift 4.8 con la API eliminada
Es responsabilidad de los administradores de Kubernetes/OpenShift evaluar adecuadamente todas las cargas de trabajo y otras integraciones para determinar dónde utilizar la API eliminada en Kubernetes 1.22.
Antes de intentar actualizar a 4.9, asegúrese de estar utilizando OpenShift Cluster 4.8. Los siguientes comandos pueden ayudarle a identificar la versión de OCP
$ oc get clusterversions.config.openshift.io
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS
version 4.8.15 True False 5h45m Cluster version is 4.8.15Entonces puedes usarAPIRequestCount APIRealice un seguimiento de las solicitudes de API, si alguna solicitud utiliza una de las API eliminadas.
Los siguientes comandos se pueden utilizar para identificar las API que se eliminarán en una versión futura pero que actualmente están en uso.REMOVEDINRELEASEColumna de salida.
$ oc get apirequestcounts
NAME REMOVEDINRELEASE REQUESTSINCURRENTHOUR REQUESTSINLAST24H
ingresses.v1beta1.extensions 1.22 2 364Los resultados se pueden filtrar aún más utilizando-o jsonpathOpciones:
oc get apirequestcounts -o jsonpath='{range .items[?(@.status.removedInRelease!="")]}{.status.removedInRelease}{"t"}{.metadata.name}{"n"}{end}'Salida de muestra:
$ oc get apirequestcounts -o jsonpath='{range .items[?(@.status.removedInRelease!="")]}{.status.removedInRelease}{"t"}{.metadata.name}{"n"}{end}'
1.22 ingresses.v1beta1.extensionsUna vez identificada la API, puede consultar el recurso APIRequestCount para una versión de API determinada para ayudar a determinar qué cargas de trabajo están utilizando la API.
oc get apirequestcounts <resource>.<version>.<group> -o yamlEjemploingresses.v1beta1.extensionsInterfaz del programa de aplicación:
$ oc get apirequestcounts ingresses.v1beta1.extensions
NAME REMOVEDINRELEASE REQUESTSINCURRENTHOUR REQUESTSINLAST24H
ingresses.v1beta1.extensions 1.22 3 365Migrar instancias donde se han eliminado las API
Puede obtener más información sobre cómo migrar la API de Kubernetes eliminada, consulteGuía de migración de API obsoletaEn la documentación de Kubernetes.
2) Confirme la actualización a OpenShift Container Platform 4.9
Una vez completadas la evaluación de la API de Kubernetes eliminada y la migración a v1, como administrador de OpenShift, puede proporcionar la confirmación necesaria para continuar.
Advertencia: Es responsabilidad del administrador asegurarse de que todos los usos de la API eliminada se resuelvan y realicen la migración necesaria antes de proporcionar estaConfirmación del administrador.
Ejecute el siguiente comando para confirmar que ha completado la evaluación y que el clúster se puede actualizar a OpenShift Container Platform 4.9:
oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.8-kube-1.22-api-removals-in-4.9":"true"}}' --type=mergeSalida de comando esperada:
configmap/admin-acks patched3) Comience a actualizar de OpenShift 4.8 a 4.9
Inicie sesión en la consola web de OpenShift y navegue hastaadministrativo?Configuración del clúster>detalle
Hacer clic"canal“Y actualice el canal a fast-4.9 o stable-4.9.
elegirRápido 4.9oEstable-4.9De la lista de canales disponibles.
También puede cambiar el canal desde la línea de comando usando la siguiente sintaxis de comando:
oc adm upgrade channel clusterversion version --type json -p '[{"op": "add", "path": "/spec/channel", "value": "<channel>?}]'Dónde<channel>Es reemplazado por uno de ellos;
- Estable-4.9
- Rápido 4.9
- Candidato-4.9
Ahora debería ver la nueva actualización del clúster. usar"renovar“Enlace para iniciar la actualización de OpenShift 4.8 a OpenShift 4.9.
Seleccione la nueva versión de OpenShift 4.9 a la que desea actualizar.
El proceso de actualización de OpenShift Container Platform 4.9 debería comenzar pronto.
También puede verificar el estado de la actualización desde la CLI:
$ oc get clusterversions.config.openshift.io
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS
version 4.8.15 True True 2m26s Working towards 4.9.0: 71 of 735 done (9% complete)Salida después de completar todas las actualizaciones. Ahora tiene una versión del clúster OpenShift4.9.
Listar todos los disponiblesComprobación del estado de la máquinaPara asegurarse de que todo esté en un estado saludable.
$ oc get machinehealthcheck -n openshift-machine-api
NAME MAXUNHEALTHY EXPECTEDMACHINES CURRENTHEALTHY
machine-api-termination-handler 100%Verifique los componentes del clúster:
$ oc get cs
W1110 20:39:28.838732 2592723 warnings.go:70] v1 ComponentStatus is deprecated in v1.19+
NAME STATUS MESSAGE ERROR
scheduler Healthy ok
controller-manager Healthy ok
etcd-3 Healthy {"health":"true","reason":""}
etcd-1 Healthy {"health":"true","reason":""}
etcd-0 Healthy {"health":"true","reason":""}
etcd-2 Healthy {"health":"true","reason":""}Enumere todos los operadores de clúster y vea la versión actual.
$ oc get co
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE
authentication 4.9.5 True False False 32h
baremetal 4.9.5 True False False 84d
cloud-controller-manager 4.9.5 True False False 20d
cloud-credential 4.9.5 True False False 84d
cluster-autoscaler 4.9.5 True False False 84d
config-operator 4.9.5 True False False 84d
console 4.9.5 True False False 37d
csi-snapshot-controller 4.9.5 True False False 84d
dns 4.9.5 True False False 84d
etcd 4.9.5 True False False 84d
image-registry 4.9.5 True False False 84d
ingress 4.9.5 True False False 84d
insights 4.9.5 True False False 84d
kube-apiserver 4.9.5 True False False 84d
kube-controller-manager 4.9.5 True False False 84d
kube-scheduler 4.9.5 True False False 84d
kube-storage-version-migrator 4.9.5 True False False 8d
machine-api 4.9.5 True False False 84d
machine-approver 4.9.5 True False False 84d
machine-config 4.9.5 True False False 8d
marketplace 4.9.5 True False False 84d
monitoring 4.9.5 True False False 20d
network 4.9.5 True False False 84d
node-tuning 4.9.5 True False False 8d
openshift-apiserver 4.9.5 True False False 20d
openshift-controller-manager 4.9.5 True False False 7d8h
openshift-samples 4.9.5 True False False 8d
operator-lifecycle-manager 4.9.5 True False False 84d
operator-lifecycle-manager-catalog 4.9.5 True False False 84d
operator-lifecycle-manager-packageserver 4.9.5 True False False 20d
service-ca 4.9.5 True False False 84d
storage 4.9.5 True False False 84dCompruebe si todos los nodos están disponibles y en buen estado.
$ oc get nodesen conclusión
En esta publicación de blog, pudimos actualizar OpenShift de la versión 4.8 a la versión 4.9. Asegúrese de que todos los operadores instalados previamente a través de Operator Lifecycle Manager (OLM) estén actualizados a la última versión en el último canal seleccionado durante la actualización. También asegúrese de que todos los grupos de configuración de máquinas (MCP) estén ejecutándose y no suspendidos. Para cualquier problema encontrado durante el proceso de actualización, puede contactarnos a través de nuestra sección de comentarios.
