¿Cómo configurar correctamente la autenticación básica para readinessProbe de Kubernetes?
Si establece esta configuración para la sonda de readinessProbe de Kubernetes en el tipo de implementación.
readinessProbe: httpGet: path: /healthcheck port: 8080 httpHeaders: - name: Authorization value: Basic <real base64 encoded data>Implementarlo en GKE, la verificación de estado de GCP no puede pasar para acceder a la aplicación interna con el uso de autenticación básica.
Pero a partir de aquí , parece que debería usar esta sintaxis. ¿Por qué no puede pasar?
El lado del servidor usa la respuesta JSON en el punto /healthcheck. ¿También es necesario establecer Accept o Content-Type en httpHeaders ?
Y, ¿es bueno establecer esta verificación de salud en livenessProbe o readinessProbe?
Según el documento de kubernetes:
Si el proceso en su contenedor puede bloquearse por sí solo cada vez que encuentra un problema o se vuelve inestable, no necesariamente necesita una sonda de actividad; el kubelet realizará automáticamente la acción correcta de acuerdo con la política de reinicio del Pod. Si desea que su contenedor se elimine y se reinicie si falla una sonda, especifique una sonda de actividad y especifique una política de reinicio de Siempre o En caso de falla.
Si desea comenzar a enviar tráfico a un pod solo cuando una sonda se realiza correctamente, especifique una sonda de preparación. En este caso, la sonda de preparación podría ser la misma que la sonda de actividad, pero la existencia de la sonda de preparación en la especificación significa que el pod se iniciará sin recibir ningún tráfico y solo comenzará a recibir tráfico después de que la sonda comience a funcionar correctamente. Si su contenedor necesita cargar datos de gran tamaño, archivos de configuración o migraciones durante el inicio, especifique una sonda de preparación.
Por lo tanto, puede utilizar el control de salud según sus necesidades. Pero en el documento de Kubernetes, dan un ejemplo de verificación de estado como sonda de vivacidad.
Y es la mejor práctica usar Content-Type cuando envía una solicitud que no sea el navegador u otro cliente típico. Creo que usar Content-Type: application/json resolverá el problema si otras cosas van bien en el lado del servidor.