Problemas conocidos de Google Distributed Cloud aislado 1.12.x
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
El clúster de almacenamiento para 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 extremos de almacenamiento de objetos a nivel de la organización. En la versión 1.12, el tráfico de respaldo requiere rutas nuevas para cada organización.
Solución alternativa:
Los IO deben actualizar el clúster de almacenamiento para habilitar la resolución de DNS a nivel de la organización y crear una ruta desde las interfaces lógicas (LIF) de replicación hasta los extremos de almacenamiento de objetos en cada organización. Copia y pega los siguientes comandos del programa de arranque.
Falla la ejecución de curl en la puerta de enlace de entrada del administrador de la organización desde los nodos de ONTAP porque no hay una ruta desde la subred de copia de seguridad a los planos de control de la organización.
Solución alternativa:
Los IO deben actualizar el clúster de almacenamiento para habilitar la resolución de DNS a nivel de la organización y crear una ruta desde las interfaces lógicas (LIF) de replicación hasta los extremos de almacenamiento de objetos en cada organización. Copia y pega los siguientes comandos del programa de arranque.
Si el repositorio de copias de seguridad no tiene ningún tipo de estado de error, pero se genera una alerta para él, es posible que la métrica de alerta del repositorio se haya generado por error. Este es un problema conocido en la versión 1.12.0 y se corrigió en la versión 1.12.4. La causa de este problema es que el repositorio de copias de seguridad
intenta conectarse periódicamente al almacenamiento de objetos como una verificación de estado
y entra en un estado no saludable si no logra conectarse. Sin embargo, si el repositorio de copias de seguridad se recupera, la métrica para indicar su estado no volverá a cambiar correctamente, lo que provocará que la alerta permanezca atascada en un estado de activación indefinida.
Para resolver este problema, puedes borrar y volver a crear manualmente el repositorio de copias de seguridad para restablecer su métrica de estado. Sigue los pasos del manual de ejecución 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 conciliar debido a trabajos obsoletos. billing-storage-system-init-job-628 y billing-storage-system-init-job-629 permanecen después de una finalización exitosa.
Solución alternativa:
Completa los siguientes pasos:
Realiza copias de seguridad de los trabajos de facturación inactivos:
Los Pods de Grafana en los espacios de nombres anthos-identity-service-obs-system y platform-obs-obs-system están atascados en el estado Init debido a errores de montaje de volumen. El mensaje de error en los registros de kubelet indica un problema de conexión múltiple. El problema se debe a un error en Trident, en el que no se puede identificar y verificar correctamente el dispositivo subyacente para las asignaciones de LUKS, lo que genera un error de conexión múltiple.
Solución alternativa:
Verifica si el PVC tiene un deletionTimestamp. Si no hay ningún deletionTimestamp (migración de Pod), sigue estos pasos:
Verifica el VolumeAttachment del PVC para identificar dónde está conectado actualmente el volumen.
Aísla el Nodes en el clúster que no coincide con este valor.
Borra el Pod que falla. Esto debería hacer que migre de nuevo al Node original.
Después de verificar, si hay un deletionTimestamp (borrado de volumen), sigue estos pasos:
Verifica el VolumeAttachment del PVC para identificar dónde está conectado actualmente el volumen.
En Node, genera 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 del resultado del archivo de seguimiento esté realmente cerrado. Esta ruta no debería existir en este punto:
statDEVICE_PATH
Valida si el número de serie está asignado actualmente a algún dispositivo de rutas múltiples.
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 valor nuevo, busca si la entrada de rutas múltiples aún existe:
multipath-ll|grepSERIAL_HEX
Si no existe, borra el archivo de seguimiento.
Si existe, verás un valor hexadecimal serial un poco más largo que el que buscaste, que se llamará multipathSerial. Ejecuta lo siguiente y busca los dispositivos de bloqueo:
multipath-llMULTIPATH_SERIAL
Luego, ejecuta los siguientes comandos, y el último solo para cada dispositivo de almacenamiento en bloques:
kubectl--kubeconfig=ADMIN_KUBECONFIGlogs-pkube-apiserver-{first_node_name}-nkube-system|grep"etcdmain: open /etc/kubernetes/pki/etcd/ca.crt: permission denied"
El resultado muestra un resultado no vacío.
Solución alternativa:
Activa o desactiva el permiso de /etc/kubernetes/pki/etcd/ca.crt. Esta es una operación muy sensible al tiempo. El cambio de permiso debe ocurrir después de la ejecución anterior del trabajo de machine-init, pero antes de la siguiente ejecución del trabajo de machine-init, ya que machine-init sobrescribe el permiso y lo restablece como raíz.
Reinicia etcd en el segundo nodo para recuperar etcd en el primer nodo del bucle de fallas.
Después de completar estos dos pasos, el kube-apiserver del primer nodo comienza a ejecutarse y el siguiente trabajo de machine-init se completa correctamente.
Después de que termines de configurar la exportación a un sistema SIEM externo, la entrada del 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.
Cuando se actualiza de la versión 1.12.2 a la 1.12.4, si se quita un nodo y, luego, se vuelve a agregar, es posible que falle el proceso de machine-init para ese nodo.
Esta falla se produce porque la política ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes rechaza el tráfico de red del nodo que se volvió a agregar a los servicios esenciales del plano de control.
Este error se destaca en los mensajes de estado de este ejemplo de resultado:
Obtén los CIDR de CIDRClaim/org-external-cidr -n root (específicamente el campo .status.ipv4AllocationStatus.allocatedCidrBlocks). Ejecuta el siguiente comando en el clúster de administrador raíz:
Agrega estos CIDR a ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes, específicamente al campo .spec.ingress.fromCIDR. Aplica este cambio en el clúster de administrador raíz con el siguiente comando:
Para el clúster de administrador de la organización:
Obtén los CIDR de la organización (p.ej., org-1) de CIDRClaim/org-external-cidr -n org-1 (específicamente, el campo .status.ipv4AllocationStatus.allocatedCidrBlocks). Este comando se ejecuta en el clúster de administrador raíz para obtener los CIDR de "org-1":
Agrega estos CIDR a ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes, específicamente 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 Bare Metal del clúster del sistema, no se pueden detener 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 atascan en podInit y containerd informa el siguiente mensaje de error:
Esto impide que se inicie la interfaz de red de contenedor (CNI) y que se programen otros pods.
Solución alternativa:
Realiza estas mitigaciones para evitar este estado del nodo:
No programes más de 10 PVC a la vez en un solo nodo. Espera a que se monten antes de programar más. Esto se notaba más cuando se intentaba crear VMs.
Actualiza el archivo /etc/lvm/lvm.conf en cada nodo 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 muestra tiempos de espera para las vinculaciones y los montajes de volúmenes, o no puede borrar un volumen, verifica la cantidad de procesos vgs pendientes en el nodo para identificar si se encuentra en este estado particularmente malo. La forma más confiable de corregir un nodo en este estado es reiniciarlo.
Existe otro modo de falla que se puede experimentar. Ese modo de falla tiene la siguiente firma en el intento de montaje: mount(2) system call failed: No space left on device. Es probable que se deba a la propagación del montaje en el nodo. Para verificarlo, ejecuta cat /proc/mounts | grep devtmpfs | awk '{ print $2 }' | sort -n | uniq -c. Si alguno de estos muestra un valor superior a uno, borra el Pod que lo usa, lo que debería activar el desmontaje. Si eso no funciona, desmonta manualmente esa ruta de acceso. Si sigues teniendo problemas, reinicia el dispositivo.
En ciertas situaciones, debido a condiciones de carrera, Google Distributed Cloud (GDC) aislado por aire no puede crear los recursos personalizados de Kubernetes de ACL de conmutador necesarios durante el proceso de arranque inicial de Distributed Cloud.
Cuando se aprovisiona Server durante la creación de cualquier clúster, existe la posibilidad de que el servidor se marque como aprovisionado, pero le falte la condición Provision-Ready. Como resultado, NodePool no puede consumir este servidor. Un ejemplo de mensaje de evento de error en NodePool podría verse así:
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 casos excepcionales, es posible que el procedimiento anterior de restablecimiento de iLO no resuelva el problema por completo, por lo que se requiere un nuevo aprovisionamiento del servidor. Consulta los manuales de procedimientos OS-P0002 y OS-P0003 para conocer los procedimientos detallados.
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 conmutador.
Solución alternativa:
En la máquina de arranque, completa los siguientes pasos. Debes
completar estos pasos mientras se lleva a cabo el proceso de instalación previa. Si hay varias carpetas /tmp/preinstall-bootstrap-, aplica los cambios a la carpeta actual que usa el proceso de instalación previa. Para ello, consulta los registros del proceso de instalación previa. Si necesitas reiniciar el comando de preinstalación, esta acción también crea una nueva carpeta /tmp/preinstall-bootstrap-.
Ve a la carpeta /tmp/preinstall-bootstrap-RANDOM_NUMBER.
Dentro de la carpeta, busca el archivo poap.py.
Quita por completo la línea con la suma de verificación md5 en este archivo para que head -n 4 poap.py se vea de la siguiente manera:
La actualización de la versión 1.11.x a la 1.12.1 falla porque el controlador de pnet no genera correctamente el recurso personalizado (CR) hairpinlink.
Solución alternativa:
Después de la actualización, en el clúster de administrador raíz, edita el archivo clusterroles/pnet-core-backend-controllers-role.
Busca hairpinlinks y agrega permisos de create,update,delete al recurso.
Verifica que se generen los CR de hairpinlinks y hairpinbgpsessions.
Este problema se debe a la limpieza incorrecta del trabajo de actualización. No se requiere ninguna acción, y el trabajo puede permanecer en el estado de bucle de bloqueo.
Esto es un problema para los servidores que no mantienen la hora sincronizada. La configuración no se aplica correctamente y debe cambiarse a un espacio de nombres diferente para que se aplique correctamente.
Solución alternativa:
Aplica los siguientes pasos a todos los clústeres:
Enumera las políticas de SO existentes:
kubectlgetospolicies-nntp-system
El resultado muestra admin-ntp-policy o worker-ntp-policy.
Según el 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 le sigue.
Aplica el archivo editado al clúster:
kubectlapply-fntp-ospolicy.yaml
Espera unos minutos para que el controlador aplique la política del SO.
Establece una conexión SSH a uno de los nodos a los que se aplica OSPolicy y ejecuta cat /etc/chrony.conf. El resultado muestra
un mensaje al comienzo del archivo que indica que Ansible lo administra y
que se quitaron los servidores nist.time.gov o ntp.pool
de la configuración.
Los usuarios no pueden iniciar el proceso de copia de seguridad y restablecimiento de la VM debido a una configuración incorrecta del control de acceso basado en roles (RBAC) y del esquema en el administrador de la VM.
Los nombres de los planes de copias de seguridad de VM no pueden contener más de 63 caracteres.
Por ejemplo, es posible que veas el siguiente mensaje de error:
Los nombres de los planes de copias de seguridad de VM son una concatenación del nombre VirtualMachineBackupPlanTemplate, el tipo de recurso (que puede ser vm o vm-disk) y el nombre de ese recurso. Esta cadena concatenada debe tener menos de 63 caracteres.
Para lograr esto, mantén los nombres de estos recursos cortos cuando los crees. Para obtener detalles sobre la creación de estos recursos, consulta Crea y, luego, inicia una instancia de VM y Crea un plan de copias de seguridad para las VMs.
Las cargas de trabajo del servicio de bases de datos se aprovisionan y configuran en proyectos separados en el clúster del sistema de Distributed Cloud. Si bien los proyectos se usan para aplicar límites administrativos en Distributed Cloud, no tienen ningún impacto en cómo y dónde se ejecuta una carga de trabajo. Por lo tanto, estas cargas de trabajo podrían compartir la infraestructura de procesamiento subyacente con otras instancias de bases de datos y varios sistemas del plano de control.
Solución alternativa:
Para las cargas de trabajo de bases de datos que requieren 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, garantiza que las cargas de trabajo de la base de datos se aprovisionen y ejecuten en una infraestructura de procesamiento 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. Obtén registros de PostgreSQL con el comando
Durante la implementación del cliente, el nombre de usuario del administrador del archivo secret.yaml debe ser admin. En cambio, el archivo contiene TO-BE-FILLED después de la primera creación. El nombre de usuario admin se debe usar para inicializar la primera configuración en el firewall y en la IP de bucle invertido admin\admin.
Solución alternativa:
Verifica que TO-BE-FILLED no esté presente en las siguientes credenciales de firewall:
CELL_ID/CELL_ID-secret.yaml
CELL_ID-ab-rack/CELL_ID-secret.yaml
CELL_ID-ac-rack/CELL_ID-secret.yaml
Verifica que todas las cuentas de administrador de firewall tengan el nombre de usuario admin.
Las políticas de firewall de IDPS predeterminadas no admiten las IPs personalizadas de la organización para la interconexión de Direct Connect (DX). Como resultado, falla la creación de la organización 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 objeto SecurityPolicyRule para las IPs personalizadas de la organización y, luego, implementa los firewalls del IDPS. Sigue los pasos del manual de operaciones FW-G0002 para completar los siguientes pasos:
1. Crea un SecurityPolicyRule de entrada en el sistema virtual de firewall raíz para permitir que las IPs personalizadas de la organización accedan a Harbor raíz.
2. Crea un objeto SecurityPolicyRule de entrada en el vsys del firewall de la organización para permitir que la raíz acceda al APIServer de la organización.
Debido a un problema conocido existente en CipherTrust Manager, las licencias de prueba desactivadas aún se pueden detectar y podrían activar advertencias de vencimiento falsas.
Solución alternativa:
Consulta HSM-R0003 para verificar las licencias normales activas y borrar las licencias de prueba desactivadas.
El módulo de seguridad de hardware (HSM) no funciona como se espera cuando se borra un CTMKey de KMS. Por ejemplo, es posible que el servicio de KMS no se inicie para la organización.
Solución alternativa:
Los usuarios pueden destruir criptográficamente los datos borrando las claves de KMS en lugar de la clave raíz de KMS, lo que se manifiesta como un CTMKey.
Sigue los pasos del manual de ejecución HSM T0016 para renovar los certificados del servidor si la fecha de Not After es dentro de los 30 días a partir de hoy.
Configurar el webhook de ServiceNow hace que Lifecycle Management (LCM) vuelva a conciliar y revierta los cambios realizados en el objeto ConfigMapmon-alertmanager-servicenow-webhook-backend y 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 realicen sin revertirse:
Obtén las rutas de acceso a los archivos kubeconfig de los clústeres de administrador raíz y de administrador de la organización. Guarda las rutas de acceso en las variables de entorno ROOT_ADMIN_KUBECONFIG y ORG_ADMIN_KUBECONFIG, respectivamente.
Pausa el subcomponente de LCM en uno de los siguientes clústeres:
Pausa el subcomponente de LCM en el clúster de administrador raíz:
No se recopilan algunas métricas de los clústeres de usuarios. Este problema afecta a los clústeres de VM del 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:"
Puedes 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 resolver el problema:
Obtén la ruta de acceso al archivo kubeconfig del clúster. Guarda la ruta de acceso en la variable de entorno KUBECONFIG.
Implementa un servicio de código auxiliar en los clústeres de VM del 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 las solicitudes de carga entre los límites del clúster, que tienen diferentes inquilinos predeterminados.
Solución alternativa:
La solución alternativa requiere acceso a la fuente de private-cloud y la capacidad de lanzar una actualización de componente. Debes cambiar la configuración de la malla para restringir el servicio cortex-tenant de modo que solo reciba tráfico del clúster local y, luego, lanzar el componente de ASM.
Abre el archivo manifests/plain/asm/1.19/asm-primary-cluster-operator.yaml.
Introduce el campo serviceSettings en el campo meshConfig.
Originalmente, el campo meshConfig se ve como en el siguiente ejemplo:
Cuando se actualiza de la versión 1.11.0 a la 1.11.3, falla la actualización del nodo para 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:
Accede a la máquina física que se está actualizando. Verifica si fstab tiene /boot/efi y si el directorio está activado:
Ejecuta mount -a y verifica si el directorio está montado:
# mount -a
root@mb-aa-bm04:~#ls/boot/efi/
EFI
Continúa con las verificaciones aquí. Ejecuta los siguientes 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 la máquina y repite las verificaciones.
La actualización del clúster se detuvo durante más de una hora. El estado y las especificaciones del modo de mantenimiento de la máquina de Bare Metal no coinciden. Por ejemplo:
Una tarea de reinicio de VM falla después de la solución 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
Solución alternativa:
Detener y reiniciar la VM resuelve el problema. Sigue las instrucciones para iniciar y detener una VM.
Cuando se actualiza 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 etapa del complemento con errores de Helm pull:
Durante una actualización, el subcomponente de OPA Gatekeeper no se instala en el clúster del sistema. Sin embargo, las restricciones y el webhook para aplicarlas están instalados.
Es posible que varios pods de un clúster del sistema se queden 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. De no ser así, espera aproximadamente 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, borra el pod problemático y verifica que vuelva a estar en funcionamiento. 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>.
Cuando se actualiza de la versión 1.11.1 a la 1.12.1, es posible que no se actualicen ValidatingWebhookConfigurations, MutatingWebhookConfigurations y MonitoringRules implementados por el componente Log.
Solución alternativa:
Asegúrate de tener kubectl y poder acceder al manual IAM-R0004 para obtener el KUBECONFIG del clúster de administrador raíz.
Borra ValidatingWebhookConfiguration root-admin-private-logging-validation-webhook del clúster de administrador raíz:
Borra 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 instalan los registros de auditoría ni los registros operativos de Loki, y no se recopilan registros.
Síntomas:
Es posible que veas un CrashLoopBackoff en el clúster del sistema:
Aumenta la memoria de cada ingester, incrementa la cantidad de ingesters o ambas. Para ello, implementa 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 en la verificación de 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:{}
2. HealthChecks muestra el error que falta netutil.
{"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:
Borra el trabajo de Kubernetes correspondiente a la verificación de estado fallida
Cuando se actualiza 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 bloquea el vaciado de un nodo de metal desnudo.
Cuando se actualiza de la versión 1.11.x a la 1.12.1, NodeUpgrade contiene varias versiones para el mismo modelo de hardware, lo que bloquea la verificación de la actualización del firmware.
Solución alternativa:
Sigue estos pasos para modificar el CR NodeUpgradespec:
Si la actualización es para servidores HPE Gen10 (GDC-4D), quita el firmware del modelo ilo6. De lo contrario, quita el firmware del modelo ilo5.
Sección para conservar la entrada con el redfishVersion más reciente para cada descripción.
Por ejemplo, si existen las dos entradas siguientes, conserva solo la que tiene 2.98 Oct 10 2023:
Si el interruptor está encendido, el resultado muestra "On".
Solución alternativa:
Quita el bloqueo image de los servidores problemáticos y espera hasta que vuelvan al estado disponible. Cuando estén disponibles, vuelve a agregar el bloque image.
Este problema se produce cuando se ignoran los errores de iLO y se lee la respuesta HTTP en lugar de devolverla de inmediato, lo que genera 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 está configurado de forma incorrecta 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 supervisión.
El problema se produce porque el reconciliador ObservabilityPipeline solo establece este valor en la primera instalación, y el reconciliador ObsProjectInfra observa 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 resolver el problema.
El subcomponente mon-common debe implementar un objeto de telemetría de Istio en el clúster de administrador de la organización para evitar que se registren todas las solicitudes de Cortex en el registro de auditoría. 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 completa a medida que se registra cada sondeo.
Sigue el manual de ejecución MON-R2009 para silenciar la alerta MON-A0001, Blackbox monitoring metrics pipeline down, ya que esta alerta seguirá activándose.
Cuando se actualiza de la versión 1.11.x a la 1.12.x, es posible que un Pod de descarga de imágenes de conmutación se detenga en el estado ErrImagePull con la siguiente advertencia:
Cuando se actualiza de la versión 1.11.x a la 1.12.1, el firewall del host bloquea la descarga de la imagen del conmutador debido a una falta de coincidencia de las interfaces que usa el firewall del host.
Solución alternativa:
Aplica la siguiente solución alternativa antes de actualizar, solo si actualizas de la versión 1.11.x a la 1.12.x.
Actualiza los clústeres de administrador raíz y de administrador de la organización.
Obtén el nombre y el espacio de nombres del grupo de nodos para los nodos de metal desnudo del administrador raíz y los nodos de metal desnudo del administrador de la organización. Para el clúster de administrador raíz, usa el kubeconfig de administrador raíz. El siguiente comando enumera un inventario
de las máquinas y filtra la lista por máquinas de metal desnudo:
Los campos NODEPOOL_NAME y NODEPOOL_NAMESPACE se propagan con la lista de todos los grupos de nodos del clúster respectivo cuando se implementa el archivo YAML anterior.
Un ejemplo de un archivo YAML 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 verse de la siguiente manera:
Los conmutadores de red precargados con una versión inferior a la 9.3.10 no pueden iniciar el proceso de arranque, ya que la versión esperada del conmutador es 10.3(4a).
Solución alternativa:
Actualiza manualmente el firmware del conmutador de 9.3.5 a 9.3.10 y, luego, de 9.3.10 a 10.3.4a.
El subcomponente de Linux Unified Key Setup (LUKS) no se vuelve a implementar durante la actualización. Para verificar el subcomponente file-netapp-trident, haz lo siguiente:
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, fallaron dos clases de almacenamiento: standard-rwo
y standard-block.
Solución alternativa:
Borra el StorageClasses que el trabajo no pudo crear, como standard-rwo, standard-block, standard-rwo-non-luks y standard-block-non-luks.
Reinicia el oclcm-backend-controller de tu clúster para volver a crear el StorageClasses (controlador de administrador raíz para clústeres de administrador raíz y de organización, controlador de administrador de organización para clústeres de sistema y de usuario).
En la versión 1.12.4, confirma que las clases de almacenamiento instaladas tengan la anotación disk.gdc.goog/luks-encrypted: establecida como verdadera (excepto las clases de almacenamiento que no son de LUKS). Si la anotación no está establecida como verdadera, 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 de PersistentVolumeClaim (PVC). Cada PVC debe tener un secreto en el formato g-luks-$pvc_name.
Verifica que el subcomponente file-netapp-trident no tenga errores en el estado.
Es posible que no se inicialicen los grupos de nodos dentro de los clústeres de usuario que ejecutan la versión 1.27.x de Kubernetes, lo que provoca que el clúster de usuario no controle las cargas de trabajo de contenedores.
Solución alternativa:
No crees un clúster de usuario 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 de 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 (podría ser un clúster de administrador o del sistema) tiene el estado de VMRuntime.ready = false y network-controller-manager en el espacio de nombres kube-system está pendiente.
Borrar la implementación network-controller-manager debería volver a crearla automáticamente con los certificados requeridos por el operador de VMM. La implementación debería alcanzar el estado Running y, luego, el estado de VMRuntime debería cambiar a ready=true.
Los Pods del importador de VMs entran en un bucle de fallas y el volumen de datos se atasca en el estado de importación durante más de 90 minutos. El estado de los pods podría verse de la siguiente manera:
El mensaje de error podría verse de la siguiente manera:
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 el administrador raíz, en los siguientes pasos, reemplaza KUBECONFIG por el kubeconfig del administrador raíz.
Si el error se produce en la organización, en los siguientes pasos, reemplaza KUBECONFIG por el archivo kubeconfig del administrador de la organización.
Durante o después de la actualización de la versión 1.11.x a la 1.12.2, es posible que los trabajos con el nombre bm-system-add-ons-* fallen con el siguiente error:
Es posible que el archivo tenga 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:
Verifica el espacio de nombres file-system para asegurarte de que no finalice en org-admin cluster:
Pausa el subcomponente file-observability hasta que se muestre el subcomponente mon-admin. Para ello, agrega las siguientes anotaciones al subcomponente:
Ejecuta ksctl system info get --url=https://HSM_MANAGEMENT_IP para verificar que todas las versiones del HSM se hayan actualizado a .Spec.TargetVersion de ctmclusterupgraderequest:
Actualiza el campo Status.FirmwareVersion de cada HSM a la versión actualizada que obtuviste en el paso anterior:
Por ejemplo:
kubectledit-statushsmHSM_NAME-ngpc-system
Actualiza el estado de la última condición ctmclusterupgraderequest.status.conditions de False a True. Después, el estado de la última condición hsmupgraderequest.status.conditions también se vuelve verdadero.
Durante una actualización, la IP de administración de un servidor no está disponible, en especial después de una actualización del SO del conmutador.
Con Rocky Linux, cuando se agregan rutas estáticas, se debe poder acceder a la IP de destino que se usa para llegar a las rutas estáticas antes de agregarlas. Si el conmutador se reinicia después de una actualización del SO, es posible que no se pueda acceder a esa IP de administración de forma temporal.
Solución alternativa:
Establece una conexión SSH al servidor con la dirección IP de datos y reinicia el servicio de redes para volver a crear las rutas estáticas faltantes:
Cuando se implementa la organización gdchservices de forma manual, el sistema de tickets no tiene un upstream en buen estado, no se crean VMs y el pod de midserver no está en buen estado en el clúster gdchservices-system en el espacio de nombres support.
Solución alternativa:
Crea un nuevo recurso personalizado TicketingSystem con la imagen de VM correcta en el clúster gdchservices-admin:
Si el error se produce durante las verificaciones posteriores al vuelo y todas las demás verificaciones se completan sin errores, omite las verificaciones posteriores al vuelo. Cuando se reinicie la actualización, también debes omitir las verificaciones previas con el kubeconfig de administrador raíz:
Si el error se produce durante las comprobaciones previas y todas las demás comprobaciones previas se completan sin errores, omite las comprobaciones previas:
El esquema de Portfolio cambió en la versión 1.12 de GDC. Se refactorizó el campo portfolioName a portfolioID. Busca el archivo YAML que contiene el recurso personalizado de la cartera mencionado en el mensaje de error. Cambia el nombre del campo portfolioName a portfolioID.
Estos son los posibles motivos por los que no se crea un trabajo en ejecución para un trabajo de parche que solo completó trabajos de verificación previa:
Si falla el NTP, no se ejecutarán los demás trabajos de parches.
El nodo se encuentra en mal estado.
El agente de configuración del SO no se está ejecutando.
El agente de OS Config no puede comunicarse con el servicio de OS Config.
Hay un problema con el servicio de OS Config.
Solución alternativa:
Verifica el CR de `NodeTargetPolicy` del nodo.
Busca `.spec.osPolicies` del CR de `NodeTargetPolicy` que tiene `ref.name=admin-ntp-policy` y `type: Ready` con el estado falso:
# Enter the node InventoryMachine name.NAME=kubectlgetnodetargetpolicy-ngpc-system$NAME-ojsonpath="{.spec.osPolicies}"|jq
Los trabajos siem-*-preinstall en el espacio de nombres raíz y org-1 del clúster de administrador raíz fallan de forma reiterada.
Solución alternativa:
Se espera que los trabajos fallen cuando la puerta de la función SIEMComponent esté inhabilitada. Las fallas no indican que el componente esté roto. La reconciliación del componente del SIEM se puede pausar si el ruido es perjudicial, pero, en general, se recomienda dejar el componente habilitado si es posible. Si se pausa la conciliación de componentes, se debe volver a habilitar manualmente cuando la instalación del componente del SIEM ya no esté restringida en futuras actualizaciones.
Es posible que haya problemas con vgs, blkid y gather_facts de Ansible que no responden. Este problema afecta a los SO Rocky y Ubuntu.
Realiza estos pasos si los nodos ya se actualizaron. El proceso para actualizar el archivo lvm.conf consta de los siguientes pasos:
Obtén una lista de todos los nodos para que se pueda aplicar esta corrección a todos ellos.
Crea un archivo de política de SO y un playbook de Ansible.
Aplica la corrección a los nodos.
Comprueba si se aplicó la corrección.
Requisitos previos:
Sigue los pasos del manual 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 manual 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 separada. Corrige un clúster a la vez. El resultado podría verse de la siguiente manera:
NAME
bm-2bca8e3f
bm-4caa4f4e
Crea un archivo de política y una guía:
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 completarse como en este ejemplo.
Agrega un párrafo por cada nodo que se encuentre en el paso 1. Harás un clúster a la vez, así que completa la sección de inventario con nodos para un clúster.
Este problema ocurre si el entorno se implementó anteriormente con la versión 1.11 y, luego, se actualizó a la versión 1.12. Cuando se crea un clúster o una organización nuevos en una versión 1.12.x, se selecciona el SO Rocky en lugar del SO Ubuntu para el aprovisionamiento de nodos de máquina virtual y equipos físicos debido a la versión del SO Rocky especificada en los CR ReleaseMetadata y Userclustermetadata.
Solución alternativa:
Aplica la siguiente solución alternativa antes de crear una organización nueva:
Comprueba si hay CR OrganizationUpgrade 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 caso al equipo de ingeniería antes de continuar con los siguientes pasos.
Quita todos los CR de OrganizationUpgrade existentes 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 organización nueva. Debe haber un objeto ReleaseMetadata correspondiente a esta versión de destino:
TARGET_RELEASE=
Identifica la CR de OSImageMetadata más reciente para el 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. De lo contrario, deriva el caso al equipo de ingeniería antes de continuar con los próximos pasos.
Actualiza el ReleaseMetadata de destino para usar el OS_VERSION de Ubuntu en el clúster de administrador raíz:
Actualiza el UserclusterMetadata de destino para usar el OS_VERSION de Ubuntu en el clúster de administrador raíz y en el clúster de administrador de la organización para cada organización. Ejecuta el siguiente comando para cada clúster:
Cuando se importan imágenes de VM locales con la CLI de gdcloud compute images import, el estado de importación se queda atascado en WaitingForTranslationVM o ImportJobNotCreated. Esto se debe a que el disco temporal creado para la traducción o la importación usa el tamaño exacto que la imagen qcow2 o sin procesar, pero LUKS agrega una sobrecarga de algunos MiB que provoca que falle el aprovisionamiento del disco.
Solución alternativa:
Crea un nuevo VirtualMachineImageImport de forma manual con el mismo nombre de imagen, pero con un spec.minimumDiskSize más grande. Por ejemplo, si este fue el comando que se usó para importar la imagen:
Si el VirtualMachineImageImport original 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 debería reemplazarse por 21 Gi.
Reemplaza los valores de marcador de posición según la forma en que se llamó a la CLI.
Si el objeto no está presente, vuelve a activar el comando gdcloud compute images import .... Después de que la salida de la consola cambie de Uploading image to ... a Image import has started for ..., presiona CTRL + C para que la imagen local se suba al almacenamiento de objetos y se conserve el VirtualMachineImageImport para crear uno nuevo.
Crea un nuevo VirtualMachineImageImport con un minimumDiskSize más grande:
El Pod importer-image-import-$VMII en el espacio de nombres del proyecto del clúster del sistema falla con 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 de VMII tiene el tipo de condición Ready con el estado False y el motivo TranslationInProgress después de 2 h 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 borrar y aplicar el ValidatingWebhookConfiguration, necesitas el kubeconfig del administrador del clúster para el clúster de administrador de la organización. Puedes obtener el siguiente manual de ejecución IAM-R0004.
Si usas gdcloud para iniciar la importación, ten en cuenta que no hay forma de proporcionar el parámetro minimumDiskSize. Debes crear un objeto VMII y modificarlo como se muestra en el comando anterior.
El proceso de VirtualMachineImageImport continúa, pero se vuelve a detener en un paso posterior. En el espacio de nombres del proyecto en el clúster del sistema, verás que el trabajo 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 imágenes. La imagen final se sube al almacenamiento de objetos, pero falta el VirtualMachineImage. Puedes crear un objeto VirtualMachineImage de forma manual 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" o "rhel-8", y 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 del Pod muestran un error Back-off pulling image "auto" de kubelet.
Para diagnosticar el problema, verifica si el mutatingwebhookconfiguration llamado istio-revision-tag-default existe en el mismo clúster que la implementación de la puerta de enlace atascada.
Modifica el configMap cortex-config en el clúster del sistema y configura el tiempo de espera para memcached dentro de index_cache en dos segundos, de modo que la configuración de index_cache se vea de la siguiente manera:
El nodo de metal desnudo aparece como NotReady y el servidor se queda atascado en la pantalla de inicio con el último mensaje que dice Retrieving encryption keys.
Solución alternativa:
Reinicia iLO.
Una vez que iLO vuelva a estar en funcionamiento, reinicia el servidor.
La ubicación del instalador de fluent-bit cambió 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, ya que ese patrón ya no coincide.
La ubicación del instalador de Nessus se cambió a operations_center\bin\NessusAgent-x64.msi.
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, ya que ese patrón ya no coincide.
Este problema se debe a la falta de configuración del extremo de S3 para la organización nueva.
Solución alternativa:
Crea manualmente un grupo de HA para la nueva organización.
A través del procedimiento de emergencia, adquiere un kubeconfig del clúster de administrador raíz que tenga acceso de lectura a los siguientes recursos:
Recupera las credenciales de acceso a la IU de administración de StorageGRID del secreto gpc-system/objectstorage-breakglass-root-level1 en el clúster root-admin.
Accede a la IU de administració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 de detalles de cada grupo de HA y anota su dirección IP virtual (VIP).
Crea un nuevo grupo de HA:
Nombre del grupo: El patrón de nombres es ORGANIZATION_NAME-ha.
En este caso, es org-2-ha.
Descripción del grupo: Usa grupos de HA existentes para el patrón de descripción.
Interfaces: Selecciona todas las eth2.
El orden de prioridad: La interfaz principal debe tener la prioridad más alta.
SubnetCIDR: StorageGRID completa este campo automáticamente.
Verifica que la subred coincida con status.ipv4SubnetStatus.cidrBlock en SubnetClaimexternal-objectstorage-client-lif-cidr.
IP virtual: Es la siguiente IP en el rango de IP disponible. La IP no puede entrar en conflicto con la IP reservada, la IP del cliente del nodo de administrador ni las VIP de los grupos de HA existentes.
Rota las credenciales de emergencia de StorageGRID.
Cuando se actualiza 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 reconciliación en curso.
Para diagnosticar el problema, verifica los registros de Prometheus, por ejemplo:
Si este problema ocurre durante la actualización, borra el trabajo de migración, ya que tiene un tiempo de espera de 3,600 s, y, luego, 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.
Observa el Pod que no tiene todos los contenedores listos. En este caso, POD_NAME es iam-authzpdp-backend-server-6875654c4b-pvscg, que tiene uno de los dos contenedores no listos, como se muestra en el estado 1/2. Si hay más de un pod como este, repite el siguiente paso para cada pod afectado.
Borra el pod que no está completamente en buen estado:
kubectldeletepod-nNAMESPACEPOD_NAME>
Vuelve a ejecutar el comando del paso 2. Observa que todos los Pods deberían estar en buen estado ahora. Este paso puede tardar unos minutos.
Si el pod borrado no se reemplaza por uno en buen estado, abre un ticket de asistencia.
Durante la actualización de la organización del arrendatario de la versión 1.12.2 a la 1.12.4, la actualización del subcomponente opa gatekeeper falla con un ReconciliationError.
Solución alternativa:
Edita el objeto mutatingwebhookconfigurationedr-sidecar-injector-webhook-cfg del clúster de usuario afectado. Si hay más de un clúster de usuario afectado, repite los pasos para cada uno de ellos:
Edita la sección webhooks > (edr-sidecar-injector.gpc-system.internal) > namespaceSelector > matchExpressions > (key: kubernetes.io/metadata.name) > values para agregarle los siguientes dos valores:
opa-system
cert-manager
El objeto actualizado debería verse de la siguiente manera:
Cuando se actualiza 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 ansibleplaybook no se aplican y bloquean la política del SO que ejecuta la versión anterior de ansibleplaybook.
Solución alternativa:
Borra el trabajo de Kubernetes create-ansible-playbooks:
Cuando crees una organización nueva, es posible que veas que el subcomponente core-dns agota el tiempo de espera 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 agrega tus nuevos rangos de IP en los rangos de origen del balanceador de cargas.
Si se anulan los cambios de CR, detén el subcomponente dns-core con la anotación lcm.private.gdc.goog/paused="true".
Cuando se actualiza de la versión 1.12.2 a la 1.12.4, el subcomponente file-netapp-trident se detiene en el borrado de 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
Borra el StorageClasses que el trabajo no pudo crear, como standard-rwo, standard-block, standard-rwo-non-luks y standard-block-non-luks:
Para activar la recreación de StorageClasses, reinicia el oclcm-backend-controller de tu clúster
(controlador root-admin para clústeres de administrador raíz y de organización, controlador org-admin para clústeres de sistema y de usuario):
Verifica que se haya creado el secreto de LUKS para tus recursos de PersistentVolumeClaim (PVC). Cada PVC debe tener un secreto en el formato g-luks-$pvc_name.
kubectlgetsecret-n$pvc_namespaceg-luks-$pvc_name
Verifica que el subcomponente file-netapp-trident no tenga errores en el estado:
Los Pods primary-prometheus-shardX-replicaX son visibles en los espacios de nombres obs-system y 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, se trata de un problema desconocido diferente y no se debe realizar la solución alternativa.
El comportamiento previsto es que primary-prometheus-shardX-replicaX solo exista en el espacio de nombres mon-system después de que se complete la actualización a la versión 1.12.
Solución alternativa:
Borra manualmente los StatefulSets de primary-prometheus-shardX-replicaX en el espacio de nombres obs-system.
No borres los StatefulSets primary-prometheus-shardX-replicaX en el espacio de nombres mon-system.
Un objeto ClusterCIDRConfig es obligatorio para asignar PodCIDRs. A pesar de que se creó el ClusterCIDRConfig, no se asignó el PodCIDRs. Este problema ocurre si se crea un ClusterCIDRConfig al mismo tiempo que se inicializan los Pods de ipam-controller. La creación del clúster está atascada en el estado de conciliación:
Verifica si se creó el objeto ClusterCIDRConfig 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 verifica si hay un evento CIDRNotAvailable en el objeto de nodo:
El MonitoringTarget muestra un estado Not Ready cuando se crean clústeres de usuarios, lo que hace que las APIs previamente entrenadas muestren continuamente un estado Enabling en la interfaz de usuario.
Solución alternativa:
Abre el menú en tu navegador Chrome (ícono 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 Response en una solicitud ai-service-status para mostrar el contenido de esa solicitud.
Verifica que todo se vea listo, excepto los componentes MonitoringTarget y LoggingTarget.
Cuando actualices 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:
Verifica que cada nodo tenga las credenciales de SSH correspondientes almacenadas en un secreto.
Durante las actualizaciones, se vuelve a crear el clúster de la base de datos de Translation, lo que provoca que la clave secreta secret-store del clúster del sistema de ODS quede desactualizada y sin sincronizar. Por este motivo, fallan la inicialización del servicio y el pod de frontend de Translation.
El servidor no se puede conectar al administrador de claves, lo que impide que el estado del servidor esté disponible. Este problema provoca que falle el trabajo server-encrypt-and-create-logical-drive y que el clúster de administrador no esté listo. Es posible que veas un error en los registros de trabajo como el siguiente:
Loki tiene solo 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 se puede conectar al bucket de almacenamiento durante horas. Si el PV no tiene espacio disponible, Loki no puede recuperarse, a menos que borres 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 borrar el PV sin espacio restante.
Sigue estos pasos para recuperar el pod de Loki:
Asegúrate de que el contenedor de IO Tool esté instalado en la estación de trabajo. Para obtener más detalles, consulta el manual de operaciones OOPS-P0065.
Para obtener los permisos que necesitas para editar recursos, pídele a tu administrador de seguridad que te otorgue los siguientes roles:
observability-viewer
observability-admin
Configura la variable de entorno KUBECONFIG con la ruta de acceso al archivo kubeconfig en el clúster de administrador raíz. Para obtener más detalles, consulta el manual IAM-R0004.
Establece 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:
Establece la variable de entorno KUBECONFIG con la ruta de acceso al archivo kubeconfig en el clúster en el que se ejecuta el pod de Loki afectado. Para obtener más detalles, consulta el manual IAM-R0004.
Establece la variable de entorno LOKI_POD_NAME con el nombre del pod de Loki afectado.
Configura la variable de entorno KUBECONFIG con la ruta de acceso al archivo kubeconfig en el clúster de administrador de la organización afectada. Para obtener más detalles, consulta el manual IAM-R0004.
Edita el contenido del archivo YAML log-admin-overrides.yaml de la siguiente manera:
Los trabajos se programan de forma continua. En cuanto finaliza un trabajo, se programa uno nuevo. Los trabajos que se programan de forma continua 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 haya un cambio en el secreto de fleet-info en el clúster de administrador raíz. Este problema se produce cuando hay un cambio en los conmutadores de administración de la instancia, como kr get managementswitches -A, o un cambio en cualquier cidrclaim en el espacio de nombres de la organización.
Reanuda los subcomponentes cada vez que haya un cambio en algún recurso de NodePool en el clúster de administrador de la organización. Quita la pausa de los subcomponentes antes de comenzar.
Cuando se actualiza de 1.12.2 a 1.12.4, no hay disponible un upstream en buen estado 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. La asociación de volumen indica que el PVC está habilitado para LUKS.
El reconciliador busca un secreto con las contraseñas de LUKS. Dado que la conexión 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 valor de Kubeconfig para el clúster raíz o de administrador de la organización en el que aparece el problema:
exportKUBECONFIG=${ROOT_OR_ORG_ADMIN_KUBECONFIG}
Borra la clase de almacenamiento system-performance-rwo y vuelve a crearla:
Cuando se actualiza de la versión 1.12.2 a la 1.12.4, la actualización de la organización se detiene en la etapa NodeUpgrade y la tarea de actualización del nodo muestra el siguiente error:
Obtén el Kubeconfig para el clúster raíz o de administrador de la organización en el que falla la actualización del nodo y verifica si falló nodeupgradetask:
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 runc init está inactivo, lo que impide que kubelet borre el pod cgroup.
Solución alternativa:
Usa la siguiente secuencia de comandos para encontrar el proceso que bloquea el borrado 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
Verifica el estado del congelador con cat freezer.state. El estado debe ser FROZEN.
Echo "THAWED" > freezer.state
Se borró correctamente el cgroup. Kubelet deja de enviar spam al registro.
PTaaS se implementa en la organización gdchservices.
Inspecciona las anotaciones y las etiquetas del proyecto gdch-perftest y el bucket perftest-bucket-reports de PTaaS en el espacio de nombres gdch-perftest de perftest. Es posible que falte la etiqueta del bucket: 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.
Agrega estas etiquetas y anotaciones de forma manual:
Inspecciona las anotaciones del proyecto de PTaaS gdch-perftest. Es posible 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:
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-23 (UTC)"],[],[]]
