Problemas conocidos de Google Distributed Cloud con air gap 1.12.x
Organízate con las colecciones
Guarda y clasifica el contenido según tus preferencias.
El clúster de almacenamiento de la copia de seguridad del volumen usa el servidor DNS externo en lugar del reenviador, lo que impide que la copia de seguridad del volumen resuelva los endpoints de almacenamiento de objetos a nivel de organización. En la versión 1.12, el tráfico de copia de seguridad requiere
nuevas rutas para cada organización.
Solución alternativa:
Los IOs deben actualizar el clúster de almacenamiento para habilitar la resolución de DNS a nivel de organización y crear una ruta desde las interfaces lógicas (LIFs) de replicación hasta los endpoints de almacenamiento de objetos de cada organización. Copia y pega los siguientes comandos del bootstrapper.
No se puede hacer un curl en la puerta de enlace de entrada del administrador de la organización desde los nodos de ONTAP porque no hay ninguna ruta de la subred de copia de seguridad a los planos de control de la organización.
Solución alternativa:
Los IOs deben actualizar el clúster de almacenamiento para habilitar la resolución de DNS a nivel de organización y crear una ruta desde las interfaces lógicas (LIFs) de replicación hasta los endpoints de almacenamiento de objetos de cada organización. Copia y pega los siguientes comandos del bootstrapper.
Si el repositorio de copias de seguridad no tiene ningún tipo de estado de error, pero se genera una alerta, es posible que la métrica de alerta del repositorio se genere por error. Se trata de un problema conocido en la versión 1.12.0, que se ha corregido en la 1.12.4. La causa de este problema es que el repositorio de copias de seguridad
intenta periódicamente conectarse al almacenamiento de objetos como comprobación de estado
y pasa a un estado incorrecto si no consigue conectarse. Sin embargo, si se recupera el repositorio de copias de seguridad, la métrica que indica su estado no volverá a cambiar correctamente, lo que provocará que la alerta se quede en un estado de activación indefinido.
Para resolver este problema, puedes eliminar y volver a crear manualmente el repositorio de copias de seguridad para restablecer su métrica de estado. Sigue los pasos que se indican en el runbook BACK-R0003 para volver a crear el repositorio de copias de seguridad.
Mensaje de error: bil-storage-system-cluster - Reconciliation error: E0121- rollback chart: no Job with the name "billing-storage-system-init-job-628" found
El subcomponente bil-storage-system-cluster no se puede reconciliar debido a trabajos obsoletos. El billing-storage-system-init-job-628 y el billing-storage-system-init-job-629 permanecen después de completar la tarea correctamente.
Solución alternativa:
Este agente debe seguir estos pasos:
Crea copias de seguridad de las tareas de facturación obsoletas:
Los pods de Grafana de los espacios de nombres anthos-identity-service-obs-system y platform-obs-obs-system están en estado Init debido a errores de montaje de volumen. El mensaje de error de los registros de kubelet indica que hay un problema de conexión múltiple. El problema se debe a un error en Trident, que no identifica ni verifica correctamente el dispositivo subyacente de las asignaciones LUKS, lo que provoca un error de conexión múltiple.
Solución alternativa:
Comprueba si el PVC tiene un valor de deletionTimestamp. Si no hay ningún valor de deletionTimestamp (migración de pods), sigue estos pasos:
Consulta el VolumeAttachment de PVC para identificar dónde está conectado el volumen.
Aísla los Nodes del clúster que no coincidan con este valor.
Elimina el Pod que falla. De esta forma, debería migrar de nuevo al Node original.
Después de comprobarlo, si hay un valor de deletionTimestamp (eliminación de volumen), sigue estos pasos:
Consulta el VolumeAttachment de PVC para identificar dónde está conectado el volumen.
En Node, muestra el contenido de su archivo de seguimiento:
cat/var/lib/trident/tracking/PVC_NAME.json
Valida que el dispositivo LUKS que se encuentra en el campo devicePath de la salida del archivo de seguimiento esté cerrado. Esta ruta no debería existir en este punto:
statDEVICE_PATH
Valida si el número de serie está asignado a algún dispositivo de multipath.
Copia el valor del campo iscsiLunSerial del archivo de seguimiento.
Convierte este valor en el valor hexadecimal esperado:
echo'iISCSILUNSERIAL>'|xxd-l12-ps
Con este nuevo valor, comprueba si la entrada multipath sigue existiendo:
multipath-ll|grepSERIAL_HEX
Si no existe, elimina el archivo de seguimiento.
Si existe, verás un valor hexadecimal de serie ligeramente más largo que el que has buscado, que se llamará multipathSerial. Ejecuta lo siguiente y busca los dispositivos de bloque:
multipath-llMULTIPATH_SERIAL
A continuación, ejecuta los siguientes comandos. El último se ejecuta de forma única para cada dispositivo de bloque:
kubectl--kubeconfig=ADMIN_KUBECONFIGlogs-pkube-apiserver-{first_node_name}-nkube-system|grep"etcdmain: open /etc/kubernetes/pki/etcd/ca.crt: permission denied"
El resultado no está vacío.
Solución alternativa:
Cambia el permiso de /etc/kubernetes/pki/etcd/ca.crt. Esta es una operación que requiere
mucho tiempo. El cambio de permiso debe producirse después de la ejecución anterior de la tarea machine-init, pero antes de la siguiente, ya que machine-init sobrescribe el permiso y lo devuelve a la raíz.machine-init
Reinicia etcd en el segundo nodo para recuperar etcd en el primer nodo de un bucle de fallos.
Después de completar estos dos pasos, el kube-apiserver del primer nodo empieza a ejecutarse y el siguiente trabajo machine-init se completa correctamente.
Una vez que hayas terminado de configurar la exportación a un sistema SIEM externo, la entrada SIEM no se incluirá en la canalización de procesamiento de Fluent Bit y los registros del servidor de la API de Kubernetes no estarán presentes en este SIEM.
Al actualizar de la versión 1.12.2 a la 1.12.4, si se elimina un nodo y, posteriormente, se vuelve a añadir, es posible que falle el proceso machine-init de ese nodo.
Este error se produce porque la política ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes deniega el tráfico de red del nodo que se ha vuelto a añadir a los servicios esenciales del plano de control.
Este error se destaca en los mensajes de estado de este ejemplo de salida:
Obtén CIDRs de CIDRClaim/org-external-cidr -n root (en concreto, del campo .status.ipv4AllocationStatus.allocatedCidrBlocks). Ejecuta el siguiente comando en el clúster de administrador raíz:
Añade estos CIDRs a ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes, concretamente al campo .spec.ingress.fromCIDR. Aplica este cambio en el clúster de administrador raíz con el siguiente comando:
En el clúster de administradores de la organización:
Obtener CIDRs de la organización (por ejemplo, org-1) de CIDRClaim/org-external-cidr -n org-1 (en concreto, el campo .status.ipv4AllocationStatus.allocatedCidrBlocks). Este comando se ejecuta en el clúster de administrador raíz para obtener los CIDR de "org-1":
Añade estos CIDRs a ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes, concretamente al campo .spec.ingress.fromCIDR. Aplica este cambio en el clúster de administrador de la organización correspondiente con el siguiente comando:
En un nodo de hardware desnudo del clúster del sistema, no se pueden terminar dos contenedores anetd. Después de detener el proceso de forma forzada y reiniciar kubelet y containerd, se vuelve a crear el pod anetd, pero todos los contenedores se quedan bloqueados en podInit y containerd muestra el siguiente mensaje de error:
De esta forma, se impide que se inicie la interfaz de red de contenedores (CNI) y que se programen otros pods.
Solución alternativa:
Aplica estas medidas para evitar que se produzca este estado del nodo:
No programes más de 10 PVCs a la vez en un solo nodo. Espera a que se monten antes de programar más. Esto se notaba más al intentar crear máquinas virtuales.
Actualiza el archivo /etc/lvm/lvm.conf en todos los nodos para incluir la línea filter = [ "r|/dev/dm.|", "r|/dev/sg.|" ] en el bloque devices{}.
Si el nodo entra en un estado en el que se muestran tiempos de espera para las conexiones y los montajes de volúmenes, o no puede eliminar un volumen, comprueba el número de procesos vgs colgados en el nodo para identificar si el nodo se encuentra en este estado particularmente incorrecto. La forma más fiable de corregir un nodo en este estado es reiniciarlo.
Puede que se produzca otro tipo de fallo. Este modo de fallo tiene la siguiente firma en el intento de montaje: mount(2) system call failed: No space left on device. Probablemente se deba a la propagación del montaje en el nodo. Para comprobarlo, ejecuta cat /proc/mounts | grep devtmpfs | awk '{ print $2 }' | sort -n | uniq -c. Si alguno de estos valores es superior a uno, elimina el pod que lo esté usando. De esta forma, se debería activar el desmontaje. Si no funciona, desmonta manualmente esa ruta. Si sigues sin poder acceder, reinicia el dispositivo.
En determinadas situaciones, debido a las condiciones de carrera, no se pueden crear los recursos personalizados de Kubernetes de las ACLs de switch necesarias durante el bootstrapping inicial de Distributed Cloud.
Síntomas:
Lista de respuestas predefinidas de LCA de switch:
Al aprovisionar Server durante la creación de un clúster, es posible que el servidor se marque como aprovisionado, pero que le falte la condición Provision-Ready. Por lo tanto, el
NodePool no puede consumir este servidor. Un ejemplo de mensaje de evento de error en NodePool podría tener este aspecto:
Restablece ILO ejecutando la siguiente secuencia de comandos:
SERVER_NAME=ROOT_ADMIN_KUBECONFIG=ILO_IP=$(kubectlgetservers${SERVER_NAME}-ngpc-system--template={{.spec.bmc.ip}}--kubeconfig=${ROOT_ADMIN_KUBECONFIG})SECRET_NAME=$(kubectlgetsecrets-ogo-template='{{range $index,$pod := .items}}{{.metadata.name}}{{"\n"}}{{end}}'-ngpc-system--kubeconfig=${ROOT_ADMIN_KUBECONFIG}|grepbmc|grep${SERVER_NAME})ILO_USER=$(kubectlgetsecrets${SECRET_NAME}-ngpc-system--template={{.data.username}}--kubeconfig=${ROOT_ADMIN_KUBECONFIG}|base64-d)ILO_PASS=$(kubectlgetsecrets${SECRET_NAME}-ngpc-system--template={{.data.password}}--kubeconfig=${ROOT_ADMIN_KUBECONFIG}|base64-d)# Perform iLO Resetcurl-k-u${ILO_USER}:${ILO_PASS}-H"Content-Type: application/json"-H"OData-Version: 4.0"https://${ILO_IP}/redfish/v1/Managers/1/Actions/Manager.Reset--data'{"ResetType":"ForceRestart"}'-XPOST|jq
# Perform server power cycle, start with power off target servercurl-k-u${ILO_USER}:${ILO_PASS}-H"Content-Type: application/json"-H"OData-Version: 4.0"-XPOSThttps://${ILO_IP}/redfish/v1/Systems/1/Actions/ComputerSystem.Reset--data'{"ResetType":"ForceOff"}'|jq.
# Verify target server powered off successfullycurl-kqs-u${ILO_USER}:${ILO_PASS}https://${ILO_IP}/redfish/v1/Systems/1|jq'.PowerState'# Power server backcurl-k-u${ILO_USER}:${ILO_PASS}-H"Content-Type: application/jsonls "-H"OData-Version: 4.0"-XPOSThttps://${ILO_IP}/redfish/v1/Systems/1/Actions/ComputerSystem.Reset--data'{"ResetType":"On"}'|jq.
En contadas ocasiones, es posible que el procedimiento de restablecimiento de iLO anterior no resuelva el problema por completo, por lo que será necesario volver a aprovisionar el servidor. Consulta los manuales de procedimientos OS-P0002 y OS-P0003 para obtener información detallada.
No puedes encontrar nxos.10.3.1.bin, pero sí algo similar, como nxos64-cs.10.3.1.F.bin, en el directorio bootflash del switch.
Solución alternativa:
En el equipo de arranque, sigue estos pasos. Debes
completar estos pasos mientras se lleva a cabo el proceso de preinstalación. Si hay varias carpetas /tmp/preinstall-bootstrap-, aplica los cambios a la carpeta actual que esté usando el proceso de preinstalación. Para ello, consulta los registros del proceso de preinstalación. Si necesitas reiniciar el comando preinstall, esta acción también crea una nueva carpeta /tmp/preinstall-bootstrap-.
Ve a la carpeta /tmp/preinstall-bootstrap-RANDOM_NUMBER.
En la carpeta, busca el archivo poap.py.
Elimina por completo la línea con la suma de comprobación md5 de este archivo para que
head -n 4 poap.py tenga este aspecto:
Este problema se debe a que no se ha limpiado correctamente el trabajo de actualización. No es necesario hacer nada y el trabajo se puede dejar en el estado de bucle de fallos.
Este es un problema para los servidores que no mantienen la hora sincronizada. La configuración no se ha aplicado correctamente y debe cambiarse a otro espacio de nombres para que se aplique correctamente.
Solución alternativa:
Sigue estos pasos en todos los clústeres:
Lista las políticas de SO que ya tienes:
kubectlgetospolicies-nntp-system
El resultado muestra admin-ntp-policy o worker-ntp-policy.
En función del nombre de la política, guárdala en un archivo .yaml:
Edita el archivo cambiando metadata.namespace de
ntp-system a gpc-system y quitando
status: line y todo lo que haya después.
Aplica el archivo editado al clúster:
kubectlapply-fntp-ospolicy.yaml
Espera unos minutos a que el controlador aplique la política del SO.
Establece una conexión SSH con uno de los nodos a los que se aplica el OSPolicy y ejecuta cat /etc/chrony.conf. El resultado muestra
un mensaje al principio del archivo que indica que Ansible lo gestiona y
que se han eliminado los servidores nist.time.gov o ntp.pool
de la configuración.
Los usuarios no pueden iniciar el proceso de copia de seguridad y restauración de VMs debido a que el control de acceso basado en roles (RBAC) y la configuración del esquema del gestor de VMs no son correctos.
Los nombres de los planes de copia de seguridad de VMs no pueden tener más de 63 caracteres.
Por ejemplo, puede que veas este mensaje de error:
Los nombres de los planes de copia de seguridad de VMs son una concatenación del nombre VirtualMachineBackupPlanTemplate, el tipo de recurso (que es vm o vm-disk) y el nombre de ese recurso. Esta cadena concatenada no debe superar los 63 caracteres.
Para ello, pon nombres cortos a estos recursos al crearlos. Para obtener información sobre cómo crear estos recursos, consulta los artículos Crear e iniciar una instancia de VM y Crear un plan de copias de seguridad para VMs.
Las cargas de trabajo de Database Service se aprovisionan y configuran en proyectos independientes del clúster del sistema de Distributed Cloud. Aunque los proyectos se usan para aplicar límites administrativos en Distributed Cloud, no influyen en cómo ni dónde se ejecuta una carga de trabajo. Por lo tanto, estas cargas de trabajo pueden compartir la infraestructura de computación subyacente con otras instancias de bases de datos y varios sistemas del plano de control.
Solución alternativa:
En el caso de las cargas de trabajo de bases de datos que requieran aislamiento adicional, los usuarios pueden solicitar la creación de un grupo de nodos en el clúster del sistema. Este grupo de nodos, al que se debe hacer referencia durante la creación del proyecto, asegura que las cargas de trabajo de la base de datos se aprovisionen y se ejecuten en una infraestructura de computación dedicada. El operador de infraestructura debe completar la configuración del grupo de nodos aislado.
En la versión 15.2.1 de AlloyDB Omni, cuando se crean varios clústeres de AlloyDB Omni en el mismo nodo, el último clúster creado se queda en estado de conciliación. Obtener registros de PostgreSQL con un comando
Durante la implementación del cliente, el nombre de usuario del administrador de archivos secret.yaml debe ser admin. En su lugar, el archivo contiene TO-BE-FILLED después de la primera creación. El nombre de usuario admin debe usarse para inicializar la primera configuración en el cortafuegos y en la IP de bucle de retorno admin\admin.
Solución alternativa:
Comprueba que TO-BE-FILLED no esté presente en las siguientes credenciales de cortafuegos:
CELL_ID/CELL_ID-secret.yaml
CELL_ID-ab-rack/CELL_ID-secret.yaml
CELL_ID-ac-rack/CELL_ID-secret.yaml
Comprueba que todas las cuentas de administrador del cortafuegos tengan el nombre de usuario admin.
Las políticas de cortafuegos de IDPS predeterminadas no admiten las IPs personalizadas de la organización para Direct Connect (DX) Interconnect. Por lo tanto, no se pueden crear organizaciones con IPs personalizadas porque estas no se pueden conectar a Harbor en el administrador raíz.
Solución alternativa:
Para desbloquear el tráfico, crea manualmente un SecurityPolicyRule para las IPs personalizadas de la organización e impleméntalo en los firewalls de IDPS. Sigue los pasos del runbook FW-G0002 para completar los siguientes pasos:
1. Crea un SecurityPolicyRule de entrada en el sistema virtual del cortafuegos raíz para permitir que las IPs personalizadas de la organización accedan a la raíz de Harbor.
2. Crea un SecurityPolicyRule de entrada en el vsys del cortafuegos de la organización para permitir que la raíz acceda al APIServer de la organización.
Debido a un problema conocido de CipherTrust Manager, las licencias de prueba desactivadas siguen siendo detectables y pueden activar falsas advertencias de vencimiento.
Solución alternativa:
Consulta HSM-R0003 para verificar las licencias normales activas y eliminar las licencias de prueba desactivadas.
El módulo de seguridad de hardware (HSM) se comporta de forma inesperada al eliminar un CTMKey de KMS. Por ejemplo, es posible que el servicio KMS no se inicie en la organización.
Solución alternativa:
Los usuarios pueden destruir criptográficamente los datos eliminando las claves de KMS en lugar de la clave raíz de KMS, lo que se manifiesta como un CTMKey.
Configurar el webhook de ServiceNow provoca que la gestión del ciclo de vida (LCM) vuelva a conciliar y revierta los cambios realizados en el objeto ConfigMapmon-alertmanager-servicenow-webhook-backend y en el objeto Secretmon-alertmanager-servicenow-webhook-backend en el espacio de nombres mon-system.
Solución alternativa:
Pausa el subcomponente LCM para que los cambios se apliquen sin revertirse:
Obtén las rutas a los archivos kubeconfig de los clústeres de administrador raíz y de administrador de organización. Guarda las rutas en las variables de entorno ROOT_ADMIN_KUBECONFIG y ORG_ADMIN_KUBECONFIG, respectivamente.
Pausa el subcomponente LCM en uno de los siguientes clústeres:
Pausa el subcomponente LCM en el clúster de administrador raíz:
No se recogen algunas métricas de los clústeres de usuarios. Este problema afecta a los clústeres de VMs de usuario, pero no al clúster del sistema.
Puedes ver los siguientes registros del servidor de Prometheus:
prometheus-serverts=2024-02-21T16:07:42.300Zcaller=dedupe.go:112component=remotelevel=warnremote_name=cortex-remote-writeurl=http://cortex-tenant.mon-system.svc:9009/pushmsg="Failed to send batch, retrying"err="server returned HTTP status 500 Internal Server Error: 2 errors occurred:"
Puede ver los siguientes registros del arrendatario de Cortex:
cortex-tenanttime="2024-02-23T18:03:44Z"level=errormsg="proc: src=127.0.0.6:55021 lookup cortex.mon-system.svc on 172.25.38.10:53: no such host"
Solución alternativa:
Sigue estos pasos para solucionar el problema:
Obtén la ruta al archivo kubeconfig del clúster. Guarda la ruta en la variable de entorno KUBECONFIG.
Despliega un servicio de stub en los clústeres de VMs de usuario:
Las métricas destinadas a la instancia de Grafana del operador de infraestructura pueden estar en la instancia de Grafana del administrador de la plataforma, y viceversa. El problema se debe a que ASM balancea la carga de las solicitudes entre los límites de los clústeres, que tienen diferentes inquilinos predeterminados.
Solución alternativa:
Para aplicar la solución alternativa, se necesita acceso a la fuente de private-cloud y poder implementar una actualización de componentes. Debes cambiar la configuración de la malla para restringir el servicio cortex-tenant de forma que solo reciba tráfico del clúster local e implementar el componente ASM.
Abre el archivo manifests/plain/asm/1.19/asm-primary-cluster-operator.yaml.
Introduce el campo serviceSettings en el campo meshConfig.
Al actualizar de la versión 1.11.0 a la 1.11.3, no se puede actualizar el nodo NodeOSInPlaceUpgradeCompleted.
kalogs-ngpc-systemos-policy-preflight-os-upgrade-bm-86efcc8en8sh2-6h5cn|grepGDCH-OS-ANSIBLE-CHECK-A50[GDCH-OS-ANSIBLE-CHECK]{"syntax":{"success":true,
"msg":""},
"apply":{"reachablity":{"success":true,
"msg":""},
"execution":{"success":false,
"msg":"errors found when simluating play execution on host: 10.3.20.9",
"tasks":[{"task":"os/upgrade : Copy GRUB file to BOOT location",
"error":"Source /boot/efi/EFI/ubuntu/grubx64.efi not found"}]}},
"diff":null
}
Solución alternativa:
Inicia sesión en el equipo físico que se va a actualizar. Comprueba si fstab tiene /boot/efi y si el directorio está montado:
Ejecuta mount -a y comprueba si el directorio está montado:
# mount -a
root@mb-aa-bm04:~#ls/boot/efi/
EFI
Continúa con las comprobaciones aquí. Ejecuta estos comandos:
C
# Ensure all three cmds prints `Files are identical`if["$(sha256sum/boot/efi/EFI/ubuntu/shimx64.efi|awk'{ print $1 }')"=="$(sha256sum/boot/efi/EFI/BOOT/BOOTX64.EFI|awk'{ print $1 }')"];thenecho"Files are identical.";elseecho"Files are different.";fiif["$(sha256sum/boot/efi/EFI/ubuntu/grubx64.efi|awk'{ print $1 }')"=="$(sha256sum/boot/efi/EFI/BOOT/grubx64.efi|awk'{ print $1 }')"];thenecho"Files are identical.";elseecho"Files are different.";fiif["$(sha256sum/boot/efi/EFI/ubuntu/grub.cfg|awk'{ print $1 }')"=="$(sha256sum/boot/efi/EFI/ubuntu/grub.cfg|awk'{ print $1 }')"];thenecho"Files are identical.";elseecho"Files are different.";fi
Si no todos los archivos son idénticos, ejecuta este comando en el ordenador y repite las comprobaciones.
La actualización del clúster se ha bloqueado durante más de una hora. El estado y las especificaciones del modo de mantenimiento de la máquina Bare Metal no coinciden. Por ejemplo, el comando:
Una tarea de reinicio de una VM falla después de la solución alternativa manual para el pod os-policy. Se muestra el siguiente mensaje:
kologsos-policy-preflight-os-reboot-vm-b1fb94147x8r9-nqmvp-ngpc-system
playbook:server-reboot.yaml
{"custom_stats":{},
"global_custom_stats":{},
"plays":[{"play":{"duration":{"end":"2024-01-12T03:50:52.749714Z",
"start":"2024-01-12T03:50:42.694226Z"},
"id":"5251f140-5a01-5cce-6150-000000000006",
"name":"Run OS Upgrade Tasks"},
"tasks":[{"hosts":{"172.20.128.10":{"action":"setup",
"changed":false,
"msg":"Failed to connect to the host via ssh: ssh: connect to host 172.20.128.10 port 22: Connection timed out",
"unreachable":true}},
"task":{"duration":{"end":"2024-01-12T03:50:52.749714Z",
"start":"2024-01-12T03:50:42.704562Z"},
"id":"5251f140-5a01-5cce-6150-00000000000b",
"name":"os/reboot : Gather OS distribution information"}}]}],
"stats":{"172.20.128.10":{"changed":0,
"failures":0,
"ignored":0,
"ok":0,
"rescued":0,
"skipped":0,
"unreachable":1}}}[GDCH-OS-ANSIBLE-CHECK]{"syntax":{"success":true,
"msg":""},
"apply":{"reachablity":{"success":false,
"msg":"Failed to connect to the host via ssh: ssh: connect to host 172.20.128.10 port 22: Connection timed out"},
"execution":{"success":false,
"msg":"",
"tasks":null
}},
"diff":null
}[GDCH-OS-ANSIBLE-CHECK]
Error:reachabilityerr:Failedtoconnecttothehostviassh:ssh:connecttohost172.20.128.10port22:Connectiontimedout
Al actualizar una organización raíz de la versión 1.11.1 a la 1.12.1, es posible que la actualización falle en la fase de complementos con errores de extracción de Helm:
Durante una actualización, el subcomponente de OPA Gatekeeper no se instala en el clúster del sistema. Sin embargo, las restricciones se instalan y se instala el webhook para aplicarlas.
Es posible que varios pods de un clúster de sistema se queden atascados en el estado TaintToleration:
El pod con el nombre de contenedor istio-proxy no está listo y tiene el estado ImagePullBackOff con el evento Back-off pulling image "auto".
Solución alternativa:
Verifica que el webhook de mutación istio-revision-tag-default esté presente en el clúster. Si no es así, espera unos 10 minutos para ver si el sistema se recupera automáticamente. Si no es así, deriva el problema.
Si el webhook de mutación está presente, elimina el pod problemático y comprueba que vuelve a estar activo. El .spec.containers[].image no debe ser auto, sino que debe parecer una imagen real similar a la siguiente: gcr.io/gke-release/asm/proxyv2:<image version>.
Al actualizar de la versión 1.11.1 a la 1.12.1, es posible que no se puedan actualizar ValidatingWebhookConfigurations, MutatingWebhookConfigurations y MonitoringRules implementados por el componente Log.
Solución alternativa:
Asegúrate de que tienes kubectl y de que puedes acceder al runbook IAM-R0004 para obtener el KUBECONFIG del clúster de administrador raíz.
Elimina ValidatingWebhookConfiguration root-admin-private-logging-validation-webhook del clúster de administrador raíz:
Elimina MonitoringRules audit-logs-alerts, audit-logs-sli-syslog-prober, audit-logs-sli-filelog-prober, audit-logs-sli-fluentbit-to-loki, audit-logs-sli-fluentbit-to-splunk, audit-logs-sli-fluentbit-backlog, audit-logs-sli-loki-ingester-failed-rate, audit-logs-sli-loki-io-up y audit-logs-sli-loki-pa-up de infra-obs namespace en el clúster de administrador raíz:
Debido a un problema en el trabajo log-infra-backend-preinstall,
no se han instalado los registros de auditoría ni los registros operativos de Loki y no se han
recopilado registros.
Síntomas:
Es posible que veas un error CrashLoopBackoff en el clúster del sistema:
Aumenta la memoria de cada ingester, incrementa el número de ingesters o ambas cosas. Para ello, puedes implementar un SubcomponentOverride en el clúster de administrador de la organización, como se muestra en el siguiente ejemplo:
apiVersion:lcm.private.gdc.goog/v1
kind:SubcomponentOverride
metadata:
name:mon-cortex-ingester-override
namespace:org-1-system-cluster
spec:
backend:
operableParameters:
ingester:
resourcesLimit:
memory:"6Gi"# 6Gi is the default, increase to add more memory to each ingesterreplicas:4# 4 is the default, increase to create more ingester instances.subComponentRef:mon-cortex
addOn:{}anthosBareMetal:
conditions:
-lastTransitionTime:"2024-09-12T12:10:55Z"message:'UPG1300: ABM upgrade expected to finish within 2h0m0s but hasn''t after 39h18m50.606521473s, last message was: Cluster upgrade for root-admin cluster: in-progress'observedGeneration:1reason:ABMUpgradeTimeout
status:Unknown
type:Succeeded
startTime:"2024-09-12T12:10:55Z"node:{}
2. El estado de Baremetalmachine muestra un error de comprobación check_registry_mirror_reachability_pass.
kubectl--kubeconfig=${ROOT_ADMIN_OR_ORG_ADMIN_KUBECONFIG}getbaremetalmachines-A-ojson|jq'.items[] | select(.status.underMaintenace != .spec.maintenanceMode) | .metadata.name as $name | .status.underMaintenace as $statm | .spec.maintenanceMode as $specm | .status.conditions[] | select(.status == "False") | select(.type == "MaintenaceModeHealthCheckReady")'
addOn:{}anthosBareMetal:
conditions:
-lastTransitionTime:"2024-09-12T12:10:55Z"message:'UPG1300: ABM upgrade expected to finish within 2h0m0s but hasn''t after 39h18m50.606521473s, last message was: Cluster upgrade for root-admin cluster: in-progress'observedGeneration:1reason:ABMUpgradeTimeout
status:Unknown
type:Succeeded
startTime:"2024-09-12T12:10:55Z"node:{}
{"lastHealthcheck":{"error":{"code":"500",
"reason":"[Errno 2] No such file or directory: /usr/local/bin/abm-tools10.5.23.4/netutil"},
"lastCompletedTime":"2024-09-14T05:11:39Z",
"lastStatus":"Error",
"monitoredComponentVersion":"1.28.900-gke.112",
"version":"1.28.900-gke.112"},
"lastScheduledTime":"2024-09-14T05:26:00Z"}
Solución alternativa:
Elimina el trabajo de Kubernetes correspondiente a la comprobación de estado fallida.
Al actualizar de la versión 1.11.x a la 1.12.x, es posible que una VM no esté lista debido a que hay demasiados pods, lo que impide que se vacíe un nodo de Bare Metal.
Al actualizar de la versión 1.11.x a la 1.12.1, NodeUpgrade contiene varias versiones del mismo modelo de hardware, lo que impide verificar la actualización del firmware.
Solución alternativa:
Sigue estos pasos para modificar el NodeUpgrade CR spec:
Si la actualización es para servidores HPE Gen10 (GDC-4D), elimina el firmware del modelo ilo6. Si no, quita el firmware del modelo ilo5.
Sección para conservar la entrada con el redfishVersion más reciente de cada descripción.
Por ejemplo, si existen las dos entradas siguientes, conserve solo la que tenga 2.98 Oct 10 2023:
Ironic ha alcanzado el tiempo de espera mientras esperaba que se encendiera un servidor. El estado cambia de cleaning a clean failed y, después, a available:
Si el interruptor está activado, el resultado será "On".
Solución alternativa:
Elimina el bloqueo image de los servidores problemáticos y espera hasta que vuelvan a estar disponibles. Cuando estén disponibles, vuelve a añadir el bloque image.
Este problema se produce cuando se ignoran los errores de iLO y se lee la respuesta HTTP en lugar de devolverla inmediatamente, lo que provoca una desreferencia de puntero nulo.
Se espera que los nodos estén en modo de mantenimiento durante una actualización. Si un nodo está en mantenimiento, es posible que no tengas suficientes recursos para programar harbor-db.
El objeto StatefulSet de Prometheus se ha configurado incorrectamente con la clase de almacenamiento standard en lugar de standard-rwo. Este problema provoca que falle el inicio del objeto StatefulSet de Anthos Prometheus desde el componente de monitorización.
El problema se produce porque el reconciliador ObservabilityPipeline solo define este valor en la primera instalación, y el reconciliador ObsProjectInfra monitoriza los recursos personalizados del clúster.
Solución alternativa:
Reinicia la implementación de fleet-admin-controller en el clúster de administrador de la organización para solucionar el problema.
El subcomponente mon-common debe implementar un objeto Istio Telemetry en el clúster de administrador de la organización para evitar que se registren todas las solicitudes de Cortex. Sin embargo, el archivo de manifiesto no se incluye en el archivo de compilación.
Solución alternativa:
Sigue estos pasos para implementar el objeto de telemetría de Istio en el clúster de administrador de la organización:
Crea un archivo YAML que defina el recurso personalizado (CR) de telemetría de Istio en el espacio de nombres mon-system del clúster de administrador de la organización:
# Disable access logging from workloads internal to GDCH.# Telemetry CR to disable Istio access logs from obs-system namespace.
apiVersion:telemetry.istio.io/v1alpha1
kind:Telemetry
metadata:
name:disable-audit-logging
namespace:mon-system
spec:
accessLogging:
-providers:
-name:otel
disabled:true
Aplica el archivo de manifiesto al clúster de administrador de la organización en el espacio de nombres mon-system:
El ConfigMap de Prober se rellena a medida que se registra cada sonda.
Sigue el runbook MON-R2009 para silenciar la alerta MON-A0001, Blackbox monitoring metrics pipeline down, ya que esta alerta se activará continuamente.
Al actualizar de la versión 1.11.x a la 1.12.x, es posible que un pod de descarga de imágenes de interruptor se quede bloqueado en el estado ErrImagePull con la siguiente advertencia:
Al actualizar de la versión 1.11.x a la 1.12.1, el cortafuegos del host bloquea la descarga de la imagen del interruptor debido a una incompatibilidad de las interfaces que utiliza el cortafuegos del host.
Solución alternativa:
Aplica la siguiente solución alternativa antes de actualizar, solo si vas a pasar de la versión 1.11.x a la 1.12.x.
Actualiza los clústeres de administrador raíz y de administrador de organización.
Obtén el nombre del grupo de nodos y el espacio de nombres de los nodos de metal desnudo del administrador raíz
y de los nodos de metal desnudo del administrador de la organización. En el clúster root-admin, usa el archivo kubeconfig root-admin. El siguiente comando muestra un inventario de las máquinas y filtra la lista por máquinas físicas:
Los campos NODEPOOL_NAME y NODEPOOL_NAMESPACE se rellenan con la lista de todos los nodepools del clúster correspondiente cuando se implementa el archivo YAML anterior.
Un archivo YAML de ejemplo para el clúster de administrador raíz con los nombres reales del grupo de nodos de administrador raíz y del grupo de nodos de administrador de la organización podría tener este aspecto:
El subcomponente de configuración unificada de claves de Linux (LUKS) no se vuelve a implementar durante la actualización. Para comprobar el subcomponente file-netapp-trident, sigue estos pasos:
conditions:
-lastTransitionTime:"2024-03-28T01:37:20Z"message:'Reconciliation error: E0100 - deploy: failed to install chart: release file-netapp-trident-backend failed, and has been uninstalled due to atomic being set: cannot patch "standard-rwo" with kind StorageClass: StorageClass.storage.k8s.io "standard-rwo" is invalid: parameters: Forbidden: updates to parameters are forbidden. && cannot patch "standard-block" with kind StorageClass: StorageClass.storage.k8s.io "standard-block" is invalid: parameters: Forbidden: updates to parameters are forbidden.'observedGeneration:1reason:ReconciliationError
status:"True"type:Reconciling
En este ejemplo, no se han podido crear dos clases de almacenamiento: standard-rwo
y standard-block.
Solución alternativa:
Elimina el StorageClasses que no se haya podido crear, como standard-rwo, standard-block, standard-rwo-non-luks y standard-block-non-luks.
Activa la recreación del StorageClasses reiniciando el controlador oclcm-backend de tu clúster
(controlador root-admin para clústeres root y org-admin, controlador org-admin para clústeres system y user).
En la versión 1.12.4, confirma que las clases de almacenamiento instaladas tienen la anotación disk.gdc.goog/luks-encrypted: definida como true (excepto las clases de almacenamiento que no sean LUKS). Si la anotación no tiene el valor true, repite los pasos 1 y 2.
Reinicia la implementación de netapp-trident y netapp-trident DaemonSet en el clúster.
Verifica que se haya creado el secreto de LUKS para tus recursos PersistentVolumeClaim (PVC). Cada PVC debe tener un secreto con el formato g-luks-$pvc_name.
Compruebe que el subcomponente file-netapp-trident no tenga ningún error en el estado.
Después de actualizar la organización raíz de la versión 1.12.1 a la 1.12.x, la validación posterior a la actualización falla y se muestra el siguiente error:
Es posible que los grupos de nodos de los clústeres de usuario que ejecutan la versión 1.27.x de Kubernetes no se inicialicen, lo que provocará que el clúster de usuario no gestione las cargas de trabajo de los contenedores.
Solución alternativa:
No cree un clúster de usuarios con la versión 1.27.x de Kubernetes.
La importación de imágenes de VM falla en el paso de traducción de imágenes si una imagen de origen de Ubuntu contiene fuentes APT predeterminadas en sources.list.
Solución alternativa:
Asegúrate de que el directorio /var/lib/apt/lists/ esté vacío en la imagen de origen.
VMRuntime en el clúster de destino (puede ser el clúster de administrador o el clúster del sistema) tiene el estado VMRuntime.ready = false y network-controller-manager en el espacio de nombres kube-system está pendiente.
Al eliminar el despliegue network-controller-manager, el operador de VMM debería volver a crearlo automáticamente con los certificados necesarios. La implementación debería pasar al estado Running y, posteriormente, el estado de VMRuntime debería cambiar a ready=true.
Los pods del importador de VMs entran en un bucle de fallos y el volumen de datos se queda en el estado de importación durante más de 90 minutos. El estado de los pods podría ser el siguiente:
El mensaje de error podría ser similar al siguiente:
message:'Reconciliation error: E0111 - upgrade chart: release unet-nodenetworkpolicy-infra-assets failed, and has been rolled back due to atomic being set: cannot patch "mgmt-network" with kind Network: admission webhook "vnetwork.networking.gke.io" denied the request: Network.networking.gke.io "mgmt-network" is invalid: Spec.NodeInterfaceMatcher: Forbidden: Field is immutable'observedGeneration:2
Solución alternativa:
Si el error se produce en la raíz, en los pasos siguientes sustituye KUBECONFIG por el archivo kubeconfig del administrador raíz.
Si el error se produce en la organización, sustituye KUBECONFIG por el archivo kubeconfig del administrador de la organización en los pasos siguientes.
Durante o después de la actualización de la versión 1.11.x a la 1.12.2, es posible que las tareas con el nombre bm-system-add-ons-* fallen y se produzca el siguiente error:
El archivo puede tener el siguiente mensaje en la sección backendStatus.
message:'E0100 - deploy: failed to install chart: release file-observability-backend failed, and has been uninstalled due to atomic being set: deployments.apps "file-observability-backend-controller" not found'
Solución alternativa:
Comprueba el espacio de nombres file-system para verificar que no termina en org-admin cluster:
Ejecuta ksctl system info get --url=https://HSM_MANAGEMENT_IP para verificar que todas las versiones de HSM se han actualizado a .Spec.TargetVersion de ctmclusterupgraderequest:
Actualiza el campo Status.FirmwareVersion de cada HSM a la versión actualizada que has obtenido en el paso anterior:
Por ejemplo:
kubectledit-statushsmHSM_NAME-ngpc-system
Actualiza el estado de la última condición de ctmclusterupgraderequest.status.conditions de False a True. Después, el estado de la hsmupgraderequest.status.conditions última condición también se convierte en verdadero.
Durante una actualización, no se puede acceder a la IP de gestión de un servidor, sobre todo después de actualizar el sistema operativo de un switch.
En Rocky Linux, cuando se añaden rutas estáticas, la IP de destino utilizada para acceder a las rutas estáticas debe ser accesible antes de añadir las rutas estáticas. Si el switch se reinicia después de una actualización del SO, es posible que no se pueda acceder temporalmente a esa IP de gestión.
Solución alternativa:
Establece una conexión SSH con el servidor mediante la dirección IP de datos.
Reinicia el servicio de red para volver a crear las rutas estáticas que faltan:
Al implementar la organización gdchservices manualmente, el sistema de asistencia no tiene un upstream correcto, no se crean máquinas virtuales y el pod de midserver no está en buen estado en el clúster gdchservices-system del espacio de nombres support.
Solución alternativa:
Crea un recurso personalizado TicketingSystem con la imagen de VM correcta en el clúster gdchservices-admin:
Si el error se produce durante las comprobaciones posteriores al vuelo y todas las demás comprobaciones se completan sin errores, omite las comprobaciones posteriores al vuelo. Cuando se reinicie la actualización, también debes omitir las comprobaciones previas con el archivo kubeconfig del administrador raíz:
Si el error se produce durante las comprobaciones preparatorias y todas las demás comprobaciones preparatorias se completan sin errores, omite las comprobaciones preparatorias:
El esquema Portfolio ha cambiado en la versión 1.12 de GDC. El campo portfolioName se ha refactorizado a portfolioID. Busca el archivo YAML que contiene el recurso personalizado de cartera mencionado en el mensaje de error. Cambia el nombre del campo portfolioName por portfolioID.
Estos son los posibles motivos por los que no se crea un trabajo en ejecución para un trabajo de parche que solo ha completado trabajos de comprobación preliminar:
Si falla el NTP, no se podrán ejecutar los demás trabajos de parche.
El nodo no está en buen estado.
El agente de configuración del SO no se está ejecutando.
El agente de configuración del SO no puede comunicarse con el servicio de configuración del SO.
Hay un problema con el servicio de configuración del SO.
Solución alternativa:
Comprueba el CR `NodeTargetPolicy` del nodo.
Busca `.spec.osPolicies` del CR `NodeTargetPolicy` que tenga `ref.name=admin-ntp-policy` y `type: Ready` con el estado false:
# Enter the node InventoryMachine name.NAME=kubectlgetnodetargetpolicy-ngpc-system$NAME-ojsonpath="{.spec.osPolicies}"|jq
El NodeUpgrade CR menciona version: rocky-86-xyz en su especificación, aunque el nodo que se está actualizando sea Ubuntu.
Solución alternativa:
No necesitas ninguna solución alternativa porque esta información no es perjudicial. El nodo se actualiza correctamente a una versión más reciente de Ubuntu.
Los trabajos siem-*-preinstall de los espacios de nombres root y org-1 del clúster de administrador raíz fallan repetidamente.
Solución alternativa:
Es normal que los trabajos fallen cuando el feature gate de SIEMComponent esté inhabilitado. Los errores no indican que el componente esté roto. La conciliación del componente SIEM se puede pausar si el ruido es molesto, pero, por lo general, se recomienda dejar el componente habilitado si es posible. Si la conciliación de componentes está en pausa, debe volver a habilitarse manualmente cuando la instalación del componente SIEM ya no esté restringida en futuras actualizaciones.
Puede que haya problemas con vgs, blkid y gather_facts de Ansible no responda. Este problema afecta a los sistemas operativos Rocky y Ubuntu.
Sigue estos pasos si los nodos ya se han actualizado. El proceso para actualizar el archivo lvm.conf consta de los siguientes pasos:
Obtén una lista de todos los nodos para que esta corrección se pueda aplicar a todos ellos.
Crea un playbook de Ansible y un archivo de política de SO.
Aplica la corrección a los nodos.
Comprueba si se ha aplicado la corrección.
Requisitos:
Sigue los pasos del runbook IAM-R0004 para generar el ROOTCONFIG
del clúster de administrador raíz y el ORGCONFIG del clúster de administrador de la organización.
Sigue los pasos del runbook IAM-R0005 para obtener los siguientes roles de la organización.
Solución alternativa:
Identifica los InventoryMachines que corresponden a los clústeres:
Mantén la salida por separado. Corrija los clústeres de uno en uno. La salida podría tener este aspecto:
NAME
bm-2bca8e3f
bm-4caa4f4e
Crea un archivo de guía y de política:
apiVersion:system.private.gdc.goog/v1alpha1
kind:AnsiblePlaybook
metadata:
name:lvm-conf-device-filter-node-update
namespace:gpc-system
spec:
playbook:|-name:Addadevicefilterto/etc/lvm/lvm.conf
hosts:all
gather_facts:no
tasks:
# Change lvm.conf-name:Configurelvmforfilteringout"dm"and"sg"devices
ansible.builtin.lineinfile:
path:/etc/lvm/lvm.conf
insertafter:'^(\s+|)devices(\s+|)\{'line:' filter = [ \"r|/dev/dm.|\", \"r|/dev/sg.|\" ]'---
apiVersion:system.private.gdc.goog/v1alpha1
kind:OSPolicy
metadata:
name:lvm-conf-device-filter-node-update
namespace:gpc-system
spec:
interval:
period:1m
inventory:
# this is the inventory from step 1 above,# see the syntex belowpolicy:
installPlaybook:
name:lvm-conf-device-filter-node-update
La sección de inventario anterior debe rellenarse como en este ejemplo.
Añade un párrafo por cada nodo que hayas encontrado en el paso 1. Solo podrás crear un clúster a la vez, así que rellena la sección de inventario con los nodos de un clúster.
Este problema se produce si el entorno se desplegó anteriormente con la versión 1.11
y, a continuación, se actualizó a la versión 1.12. Cuando se crea un clúster o una organización en una versión 1.12.x, se selecciona Rocky OS en lugar de Ubuntu OS para el aprovisionamiento de nodos de hardware desnudo y de máquinas virtuales debido a la versión de Rocky OS especificada en los CRs ReleaseMetadata y Userclustermetadata.
Solución alternativa:
Aplica la siguiente solución alternativa antes de crear una organización:
Comprueba si hay OrganizationUpgrade CRs que no estén en el estado Succeeded: true:
foritemin$(kubectl--kubeconfig=KUBECONFIGgetOrganizationUpgrade-A-ocustom-columns=NAME:.metadata.name,NAMESPACE:.metadata.namespace--no-headers);doNAME=$(echo$item|awk'{print $1}')NAMESPACE=$(echo$item|awk'{print $2}')STATUS=$(kubectl--kubeconfig=KUBECONFIGgetorganizationupgrade${NAME}-n${NAMESPACE}-ojson|jq'.status.conditions[] | select(.type=="Succeeded") | .status')if[["$STATUS"!="True"]];thenecho"Not in Succeeded: true state, stop following operations"fidone
Si es así, deriva el problema al equipo de ingeniería antes de continuar con los pasos siguientes.
Quita todos los OrganizationUpgrade CRs para evitar
actualizaciones accidentales del SO del nodo:
foritemin$(kubectl--kubeconfig=KUBECONFIGgetOrganizationUpgrade-A-ocustom-columns=NAME:.metadata.name,NAMESPACE:.metadata.namespace--no-headers);doNAME=$(echo$item|awk'{print $1}')NAMESPACE=$(echo$item|awk'{print $2}')echo"Deleting OrganizationUpgrade $NAME in namespace $NAMESPACE"kubectl--kubeconfig=KUBECONFIGdeleteOrganizationUpgrade$NAME-n$NAMESPACEdone
Define la versión de GDC de destino para la creación de la nueva organización. Debe haber un ReleaseMetadata correspondiente a esta versión de destino:
TARGET_RELEASE=
Identifica la OSImageMetadata CR más reciente del SO Ubuntu de destino
en el clúster de administrador raíz y define la variable OS_VERSION:
Asegúrate de que la variable use la misma versión principal.secundaria.parche, como 1.12.4, que TARGET_RELEASE. Si no es así, deriva el problema al equipo de ingeniería antes de continuar con los pasos siguientes.
Actualiza el ReleaseMetadata de destino para usar Ubuntu
OS_VERSION en el clúster de administrador raíz:
Actualiza el UserclusterMetadata de destino para que use Ubuntu
OS_VERSION en el clúster de administrador raíz y en el clúster de administrador de la organización
de cada organización. Ejecuta el siguiente comando en cada clúster:
Cuando se importan imágenes de VM locales mediante la
CLI de gdcloud compute images import, el estado de importación se
queda bloqueado en WaitingForTranslationVM o
ImportJobNotCreated. Esto se debe a que el disco temporal creado para traducir o importar usa el mismo tamaño que la imagen qcow2 o raw, pero LUKS añade una sobrecarga de unos pocos MiBs que provoca que falle el aprovisionamiento del disco.
Solución alternativa:
Crea un nuevo VirtualMachineImageImport manualmente con el mismo nombre de imagen, pero con un spec.minimumDiskSize más grande. Por ejemplo, si este fuera el comando usado para importar la imagen:
Si el VirtualMachineImageImport creado automáticamente por
la CLI tiene minimumDiskSize como X Gi, crea uno nuevo con
X+1 Gi. El valor se basa en el tamaño de la imagen que se importa. En el caso de qcow2, sería el tamaño virtual. Por ejemplo, 20 Gi se debe sustituir por 21 Gi.
Sustituye los valores de marcador de posición en función de cómo se haya llamado a la CLI.
Si el objeto no está presente, vuelve a activar el comando gdcloud compute images import .... Cuando la salida de la consola pase de
Uploading image to ... a Image import has started for ...,
pulsa CTRL + C para que la imagen local se suba al almacenamiento de objetos y
se conserve el VirtualMachineImageImport para poder
crear uno nuevo.
Crea un nuevo VirtualMachineImageImport con un minimumDiskSize más grande:
El pod importer-image-import-$VMII del espacio de nombres del proyecto del clúster del sistema falla y muestra el siguiente error: Unable to process data: Unable to transfer source data to target file: unable to write to file: stream error: stream ID 1; NO_ERROR; received from peer`). El objeto VirtualMachineImageImport VMII tiene el tipo de condición Ready con el estado False y el motivo TranslationInProgress después de 2 horas de iniciar la importación.
Solución alternativa:
Para mejorar la velocidad, modifica el tamaño mínimo del disco de la imagen a 200 Gi de la siguiente manera:
Ten en cuenta que, para eliminar y aplicar el ValidatingWebhookConfiguration, necesitas el archivo kubeconfig del clúster de administrador del clúster de administrador de la organización. Puedes obtener el siguiente runbook: IAM-R0004.
Si usas gdcloud para iniciar la importación, ten en cuenta que no hay forma de proporcionar el parámetro minimumDiskSize. Debe crear un objeto VMII y modificarlo como se muestra en el comando anterior.
El proceso de VirtualMachineImageImport continúa, pero vuelve a quedarse bloqueado en un paso posterior. En el espacio de nombres del proyecto del clúster del sistema, verás que la tarea image-import-$VMII falla continuamente con el error error: stream error: stream ID x; NO_ERROR; received from peer. En este punto, se completa la importación de la imagen. La imagen final se sube al almacenamiento de objetos, pero falta el VirtualMachineImage. Puedes crear un VirtualMachineImage manualmente de la siguiente manera:
`$NAME` debe coincidir con `VMII.ImageMetadata.Name`, y `$OS_NAME` puede ser uno de los siguientes valores: [`ubuntu-2004`, `ubuntu-2204`, `windows-2019`, `rhel-8`]. Además, debe coincidir con el tipo de imagen importada.
La implementación de istio-eastwestgateway en el espacio de nombres istio-system está bloqueada y los eventos de pod muestran un error Back-off pulling image "auto" de kubelet.
Para diagnosticar el problema, comprueba si el mutatingwebhookconfiguration llamado istio-revision-tag-default existe en el mismo clúster que la implementación de la pasarela bloqueada.
Modifica el cortex-config configMap en el clúster del sistema
y define el tiempo de espera de memcached en index_cache en dos segundos para
que la configuración de index_cache tenga este aspecto:
El nodo de hardware desnudo se muestra como NotReady y el servidor se queda bloqueado en la pantalla de arranque con el último mensaje Retrieving encryption keys.
Solución alternativa:
Reinicia iLO.
Cuando iLO vuelva a estar operativo, reinicia el servidor.
La ubicación del instalador de fluent-bit ha cambiado a operations_center\bin\fluent-bit-win64.msi.
El Copy-ConfigHostFiles.ps1 espera que el instalador del cliente fluent-bit
coincida con el patrón fluent-bit-*-win64.*.
El instalador no encuentra el instalador porque ese patrón ya no coincide.
La ubicación del instalador de Nessus ha cambiado a operations_center\bin\NessusAgent-x64.msi.
El Copy-ConfigHostFiles.ps1 espera que el instalador del cliente
coincida con el nombre de archivo /NessusAgent-10.4.1-x64.msi.
El instalador no encuentra el instalador porque ese patrón ya no coincide.
Este problema se debe a que falta la configuración del endpoint de S3 para la nueva organización.
Solución alternativa:
Crea manualmente un grupo de alta disponibilidad para la nueva organización.
Mediante el procedimiento de acceso de emergencia, obtén un archivo kubeconfig del clúster de administrador raíz que tenga acceso de lectura a los siguientes recursos:
Obtén las credenciales de inicio de sesión de la interfaz de gestión de StorageGRID del secreto gpc-system/objectstorage-breakglass-root-level1 en el clúster root-admin.
Inicia sesión en la interfaz de gestión de StorageGRID con las credenciales del paso anterior. La URL tiene el estado ObjectStorageSite:
Ve a la pestaña Configuración y haz clic en Grupos de alta disponibilidad.
Abre la vista detallada de cada grupo de alta disponibilidad y anota su dirección IP virtual (VIP).
Crea un grupo de alta disponibilidad:
Nombre del grupo: el patrón de nombre es ORGANIZATION_NAME-ha
. En este caso, es org-2-ha.
Descripción del grupo: usa grupos de alta disponibilidad para el patrón de descripción.
Interfaces: selecciona todos los eth2.
Orden de prioridad: la interfaz principal debe tener la prioridad más alta.
SubnetCIDR StorageGRID rellena este campo automáticamente.
Verifica que la subred coincida con la status.ipv4SubnetStatus.cidrBlock
en el SubnetClaimexternal-objectstorage-client-lif-cidr.
IP virtual: la siguiente IP del intervalo de IPs disponibles. La IP no puede coincidir con la IP reservada, la IP de cliente del nodo de administrador ni las IPs virtuales de los grupos de alta disponibilidad.
Rota las credenciales de emergencia de StorageGRID.
Al actualizar la organización raíz de la versión 1.12.2 a la 1.12.4, el subcomponente iac-gitlab tiene un estado de conciliación en curso.
Para diagnosticar el problema, consulta los registros de Prometheus. Por ejemplo:
Si este problema se produce durante la actualización, elimina la tarea de migración, ya que tiene un tiempo de espera de 3600 segundos, y, a continuación, continúa con la actualización:
Consulta el mensaje de error anterior y anota el espacio de nombres y el nombre de la implementación. En este ejemplo, NAME es
iam-authzpdp-backend-server y NAMESPACE es
iam-system.
Tenga en cuenta el pod que no tiene todos los contenedores listos. En este caso,
el POD_NAME es iam-authzpdp-backend-server-6875654c4b-pvscg
que tiene uno de los dos contenedores no preparado, como se muestra en el estado 1/2. Si hay más de un pod de este tipo, repite el paso siguiente con cada uno de los pods afectados.
Elimina el pod que no esté completamente correcto:
kubectldeletepod-nNAMESPACEPOD_NAME>
Vuelve a ejecutar el comando del paso 2. Observa que todos los pods deberían estar en buen estado. Este paso puede tardar unos minutos.
Si el pod eliminado no se sustituye por un pod correcto, abre una incidencia.
Durante la actualización de la organización del cliente de la versión 1.12.2 a la 1.12.4, se produce un error ReconciliationError al actualizar el subcomponente opa gatekeeper.
Solución alternativa:
Edita el objeto mutatingwebhookconfigurationedr-sidecar-injector-webhook-cfg del clúster de usuarios afectado. Si hay más de un clúster de usuarios afectados, repite los pasos con cada uno de ellos:
Edita la sección webhooks > (edr-sidecar-injector.gpc-system.internal) > namespaceSelector > matchExpressions > (key: kubernetes.io/metadata.name) > values para añadirle los dos valores siguientes:
Al actualizar de la versión 1.12.2 a la 1.12.4, ansibleplaybook no se actualiza como parte de la actualización del clúster. Las correcciones actualizadas en la ansibleplaybook no se aplican y bloquean la política del SO que ejecuta la versión anterior de la ansibleplaybook.
Solución alternativa:
Elimina el trabajo de Kubernetes create-ansible-playbooks:
Cuando crees una organización, es posible que veas que el subcomponente core-dns se agota en los registros:
[INFO]192.0.2.0:60741-40400"A IN objectstorage-tenant-mgmt.gdch.example.com. udp 72 false 1232"--02.000828817s
[ERROR]plugin/errors:2objectstorage-tenant-mgmt.gdch.example.com.A:readudp10.244.4.184:59927->192.0.2.1:53:i/otimeout
[INFO]192.0.2.0:51401-5813"AAAA IN objectstorage-tenant-mgmt.gdch.example.com. udp 72 false 1232"--02.000585231s
[ERROR]plugin/errors:2objectstorage-tenant-mgmt.gdch.example.com.AAAA:readudp10.244.4.184:48542->192.0.2.1:53:i/otimeout
Solución alternativa:
Actualiza los servicios gpc-coredns-forwarder-udp
y gpc-coredns-forwarder-tcp del clúster de administrador raíz
y añade los nuevos intervalos de IPs en los intervalos de origen del balanceador de carga.
Si se anulan los cambios de CR, pausa el dns-core
subcomponente con la anotación lcm.private.gdc.goog/paused="true".
Al actualizar de la versión 1.12.2 a la 1.12.4, el subcomponente file-netapp-trident se queda bloqueado al eliminar StorageClasses. Se muestra el siguiente estado:
status:
backendStatus:
conditions:
-lastTransitionTime:"2024-05-02T06:04:14Z"message:'E0121 - rollback chart: no StorageClass with the name "standard-rwo-non-luks" found'observedGeneration:2reason:ReconciliationError
status:"True"type:Reconciling
-lastTransitionTime:"2024-04-08T00:12:53Z"message:Successfullypulledchart
observedGeneration:2reason:ChartPullDone
status:"True"type:ChartPull
-lastTransitionTime:"2024-05-01T10:10:08Z"message:Fetchedparametersfromdefault,runtime
observedGeneration:2reason:ParametersDone
status:"True"type:Parameters
-lastTransitionTime:"2024-05-02T06:04:04Z"message:'E0121 - rollback chart: no StorageClass with the name "standard-rwo-non-luks" found'observedGeneration:2reason:DeployError
status:"False"type:Deployed
-lastTransitionTime:"2024-04-23T06:50:12Z"message:Readinesscheckjobpassed
observedGeneration:1reason:ReadinessCheckDone
status:"True"type:Ready
deploymentFinished:falselastDeployTimestamp:"2024-05-02T06:03:16Z"readyAfterDeploy:trueversion:""conditions:
-lastTransitionTime:"2024-05-02T06:04:14Z"message:'Reconciliation error: E0121 - rollback chart: no StorageClass with the name "standard-rwo-non-luks" found'observedGeneration:2reason:ReconciliationError
status:"True"type:Reconciling
crdsStatus:
conditions:
-lastTransitionTime:"2024-04-07T08:02:33Z"message:Successfullypulledchart
observedGeneration:2reason:ChartPullDone
status:"True"type:ChartPull
-lastTransitionTime:"2024-04-07T08:02:33Z"message:Noparameterstofetch
observedGeneration:2reason:ParametersDone
status:"True"type:Parameters
-lastTransitionTime:"2024-04-07T08:02:34Z"message:Readinesssourceisempty
observedGeneration:2reason:ReadinessCheckSkipped
status:"True"type:Ready
-lastTransitionTime:"2024-05-01T18:37:52Z"message:Ready
observedGeneration:2reason:ReconciliationCompleted
status:"False"type:Reconciling
deploymentFinished:truelastDeployTimestamp:"2024-05-02T06:04:03Z"readyAfterDeploy:trueversion:1.12.3-gdch.312
Solución alternativa:
Pausa el subcomponente file-netapp-trident:
## Set KUBECONFIG to root-admin KUBECONFIGexportKUBECONFIG=ROOT_ADMIN_KUBECONFIGkubectlannotatesubcomponentfile-netapp-trident-n$cluster_namespacelcm.private.gdc.goog/paused=true
Elimina el StorageClasses que no se haya podido crear, como standard-rwo, standard-block, standard-rwo-non-luks y standard-block-non-luks:
Activa la recreación del StorageClasses reiniciando el oclcm-backend-controller de tu clúster.
(controlador root-admin para clústeres root y org-admin, controlador org-admin para clústeres system y user):
Verifica que se haya creado el secreto de LUKS para tus recursos PersistentVolumeClaim (PVC). Cada PVC debe tener un secreto con el formato g-luks-$pvc_name.
kubectlgetsecret-n$pvc_namespaceg-luks-$pvc_name
Compruebe que el subcomponente file-netapp-trident no tenga ningún error en el estado:
Los pods primary-prometheus-shardX-replicaX están visibles en el espacio de nombres obs-system y en el espacio de nombres mon-system. Si primary-prometheus-shardX-replicaX solo
existe en el espacio de nombres obs-system después de una actualización a la versión 1.12, entonces
se trata de otro problema desconocido y no se debe aplicar la solución alternativa.
El comportamiento previsto es que
primary-prometheus-shardX-replicaX solo exista en el
mon-system espacio de nombres una vez que se haya completado la actualización a la versión 1.12.
Solución alternativa:
Elimina manualmente los primary-prometheus-shardX-replicaX
StatefulSets del espacio de nombres obs-system.
No elimines los primary-prometheus-shardX-replicaX
StatefulSets del espacio de nombres mon-system.
Un ClusterCIDRConfig es un objeto obligatorio para asignar PodCIDRs. A pesar de que se ha creado el ClusterCIDRConfig, no se ha asignado el PodCIDRs. Este problema se produce si se crea un ClusterCIDRConfig al mismo tiempo que se inician los pods de ipam-controller. La creación del clúster se queda bloqueada en el estado de conciliación:
Comprueba si el objeto ClusterCIDRConfig se ha creado en el clúster:
Ejecuta la descripción de uno de los objetos de nodo del clúster que está atascado en la reconciliación y comprueba si hay un evento CIDRNotAvailable en el objeto de nodo:
El MonitoringTarget muestra el estado Not Ready cuando se están creando clústeres de usuarios, lo que provoca que las APIs preentrenadas muestren continuamente el estado Enabling en la interfaz de usuario.
Solución alternativa:
Abre el menú de tu navegador Chrome (icono de tres puntos).
Haz clic en Más herramientas > Herramientas para desarrolladores para abrir la consola.
Haz clic en la pestaña Red de la consola.
Busca las solicitudes de ai-service-status.
Haz clic en la pestaña Respuesta de una solicitud ai-service-status para ver el contenido de esa solicitud.
Comprueba que todo esté listo, excepto los componentes MonitoringTarget y LoggingTarget.
Al actualizar el almacenamiento de objetos, es posible que veas una advertencia como esta:
TypeReasonAgeFromMessage
-------------------------
WarningReconcileError55m(x2over55m)ObjectStorageAdminNodeReconcilerReconcileerror,retrying:errorstoringthesshcreds:500InternalServerError:ErrorMessage:{"text":"The GDU service is currently busy. Try again later. Contact technical support if the issue persists.","key":"maintenance.gdu.gdu_server_locked
Solución alternativa:
Comprueba que cada nodo tenga las credenciales SSH correspondientes almacenadas en un secreto.
Durante las actualizaciones, se vuelve a crear el clúster de la base de datos de traducciones, lo que provoca que el secreto secret-store del clúster del sistema ODS quede obsoleto y desincronizado. Por este motivo, el pod y el servicio del frontend de traducción no se inicializan.
El servidor no puede conectarse al gestor de claves, lo que impide que el estado del servidor esté disponible. Este problema provoca que la tarea server-encrypt-and-create-logical-drive falle y que el clúster de administrador no esté listo. Es posible que veas un error como este en los registros de trabajos:
Loki solo tiene un volumen persistente (PV) para los registros de escritura anticipada (WAL) y los índices. El WAL puede llenar el PV si un pod de Loki no puede conectarse al bucket de almacenamiento durante horas. Si el PV no tiene espacio disponible, Loki no podrá recuperarse a menos que elimines el PV y reinicies el StatefulSet.
Solución alternativa:
Para recuperar un pod de Loki de este estado, debes reducir la escala del StatefulSet correspondiente y eliminar el PV sin espacio disponible.
Sigue estos pasos para recuperar el pod Loki:
Asegúrate de que el contenedor de herramientas de E/S esté instalado en la estación de trabajo. Para obtener más información, consulta el manual de operaciones OOPS-P0065.
Para obtener los permisos que necesitas para editar recursos, pide a tu administrador de seguridad que te conceda los siguientes roles:
observability-viewer
observability-admin
Define la variable de entorno KUBECONFIG con la ruta al archivo kubeconfig del clúster de administrador raíz. Para obtener más información, consulta el runbook IAM-R0004.
Define la variable de entorno ORG_NAME con el nombre de la organización afectada.
Guarda el siguiente contenido en un archivo YAML llamado log-admin-overrides.yaml:
Define la variable de entorno KUBECONFIG con la ruta al archivo kubeconfig del clúster en el que se ejecuta el pod de Loki afectado. Para obtener más información, consulta el runbook IAM-R0004.
Define la variable de entorno LOKI_POD_NAME con el nombre del pod de Loki afectado.
Define la variable de entorno KUBECONFIG con la ruta al archivo kubeconfig del clúster de administrador de la organización afectada. Para obtener más información, consulta el runbook IAM-R0004.
Edita el contenido del archivo YAML log-admin-overrides.yaml de la siguiente manera:
Las tareas se programan de forma continua. En cuanto se termina un trabajo, se programa otro. Los trabajos que se programan continuamente son los siguientes:
unet-networkpolicy-assets-parameter
unet-nodenetworkpolicy-assets-parameter
unet-nodenetworkpolicy-assets-readiness
unet-userclusterpolicy-assets-parameter
unet-clustermesh-backend-parameter
unet-clustermesh-backend-readiness
Solución alternativa:
Pausa los siguientes subcomponentes:
unet-networkpolicy
unet-nodenetworkpolicy
unet-nodenetworkpolicy
unet-userclusterpolicy
unet-clustermesh
Reanuda los subcomponentes cada vez que se modifique el secreto de información de la flota en el clúster de administrador raíz. Este problema se produce cuando hay un cambio en los interruptores de gestión de la instancia, como kr get managementswitches -A, o cuando se modifica cualquier cidrclaim en el espacio de nombres de la organización.
Reanuda los subcomponentes siempre que se produzca un cambio en cualquier recurso NodePool del clúster de administrador de la organización. Reanuda los subcomponentes antes de empezar.
Al actualizar de la versión 1.12.2 a la 1.12.4, no hay un upstream correcto para ServiceNow. Es posible que veas el siguiente mensaje: failed to stage volume: LUKS passphrase cannot be empty.
La clase de almacenamiento system-performance-rwo no está habilitada para LUKS. El archivo adjunto de volumen indica que el PVC tiene habilitado LUKS.
El reconciliador busca un secreto con las contraseñas de LUKS. Como el archivo adjunto de volumen indica que LUKS está habilitado y la clase de almacenamiento no lo está, no se crea la contraseña secreta.
Solución alternativa:
Obtén el Kubeconfig del clúster raíz o del clúster de administrador de organización en el que se produce el problema:
exportKUBECONFIG=${ROOT_OR_ORG_ADMIN_KUBECONFIG}
Elimina la clase de almacenamiento system-performance-rwo y vuelve a crearla:
Al actualizar de la versión 1.12.2 a la 1.12.4, la actualización de la organización se queda bloqueada en la fase NodeUpgrade y la tarea de actualización del nodo muestra el siguiente error:
Obtén el Kubeconfig del clúster raíz o del clúster de administrador de organización en el que se produce un error al actualizar el nodo y comprueba si nodeupgradetask ha fallado:
kubelet sigue imprimiendo el siguiente registro de spam:
May2223:08:00control-1--f1c6edcdeaa9e08-e387c07294a9d3ab.lab.anthoskubelet[3751]:time="2024-05-22T23:08:00Z"level=warningmsg="Failed to remove cgroup (will retry)"error="rmdir /sys/fs/cgroup/freezer/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy"
……
May2223:09:04control-1kubelet[3751]:time="2024-05-22T23:09:04Z"level=warningmsg="Failed to remove cgroup (will retry)"error="rmdir /sys/fs/cgroup/net_cls,net_prio/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy"
El proceso de runc init está bloqueado, lo que impide que kubelet elimine el pod cgroup.
Solución alternativa:
Usa la siguiente secuencia de comandos para encontrar el proceso que bloquea la eliminación de cgroup:
# Find matching cgroup directoriesMATCHING_CGROUPS=$(find/sys/fs/cgroup-typed-name"*74353c*")if[-z"$MATCHING_CGROUPS"];thenecho"No cgroups found containing 'd06aac'."exit0fiecho"Matching cgroups:"forcgroupin$MATCHING_CGROUPS;doecho"- $cgroup"# Print cgroup path# Check if cgroup.procs existsif[-f"$cgroup/cgroup.procs"];thenecho" Processes:"# List PIDs in cgroup.procsforpidin$(cat"$cgroup/cgroup.procs");do# Get process detailsps-opid,comm,cmd--no-headers$pid2>/dev/null# Suppress errors if process doesn't existdoneelseecho" No cgroup.procs file found."# Handle cases where cgroup.procs is missingfiecho# Add a newline for better readabilitydone
Comprueba el estado del congelador con cat freezer.state. El estado debe ser FROZEN.
Echo "THAWED" > freezer.state
El cgroup se ha eliminado correctamente. Kubelet deja de enviar spam al registro.
PTaaS se ha implementado en la organización gdchservices.
Inspecciona las anotaciones y las etiquetas del proyecto gdch-perftest y del bucket perftest-bucket-reports de PTaaS en el espacio de nombres perftest gdch-perftest. Puede que falten la etiqueta app.kubernetes.io/managed-by=Helm y las anotaciones meta.helm.sh/release-name=perf-ptaas-assets y meta.helm.sh/release-namespace=gdch-perftest en el contenedor.
Añade estas etiquetas y anotaciones manualmente:
Inspecciona las anotaciones del proyecto de PTaaS gdch-perftest. Puede que el proyecto esté mal configurado con la anotación meta.helm.sh/release-name=perf-ptaas-assets.
Cambia esta anotación a meta.helm.sh/release-name=perf-ptaas-backend:
[[["Es fácil de entender","easyToUnderstand","thumb-up"],["Me ofreció una solución al problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Es difícil de entender","hardToUnderstand","thumb-down"],["La información o el código de muestra no son correctos","incorrectInformationOrSampleCode","thumb-down"],["Me faltan las muestras o la información que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-23 (UTC)."],[],[]]
