J'obtiens des erreurs HTTP 503 (service indisponible) lorsque je me connecte à Kubernetes Service qui s'exécute dans mon cluster Amazon Elastic Kubernetes Service (Amazon EKS).
Courte description
Les erreurs HTTP 503 sont des erreurs côté serveur. Elles s'affichent lorsque vous vous connectez à un pod Kubernetes Service situé dans un cluster Amazon EKS configuré pour un équilibreur de charge.
Pour résoudre les erreurs HTTP 504, consultez Comment résoudre les erreurs HTTP 504 dans Amazon EKS ?
Pour résoudre les erreurs HTTP 503, procédez comme suit.
Résolution
Vérifiez si l'étiquette du pod correspond à la valeur spécifiée dans le sélecteur Kubernetes Service
1. Exécutez la commande suivante pour obtenir la valeur du sélecteur :
$ kubectl describe service service_name -n your_namespace
Remarque : remplacez service_name par le nom de votre service et your_namespace par l’espace de noms de votre service.
Exemple de sortie :
Name: service-name
Namespace: pod-name
Labels: none
Annotations: none
Selector: app.kubernetes.io/name=namespace
Type: NodePort
IP Families: none
IP: 10.100.17.189
IPs: 10.100.17.189
Port: unset 80/TCP
TargetPort: 80/TCP
NodePort: unset 31560/TCP
Endpoints: none
Session Affinity: none
External Traffic Policy: Cluster
Events: none
Dans la sortie précédente, l'exemple de valeur de sélecteur est app.kubernetes.io/name=namespace.
2. Vérifiez s'il existe des pods portant l'étiquette app.kubernetes.io/name=namespace :
$ kubectl get pods -n your_namespace -l "app.kubernetes.io/name=namespace"
Exemple de sortie :
No resources found in your_namespace namespace.
Si aucune ressource n'est trouvée avec la valeur recherchée, une erreur HTTP 503 s'affiche.
Vérifiez que les pods définis pour Kubernetes Service sont en cours d'exécution
Utilisez l'étiquette dans le sélecteur Kubernetes Service pour vérifier que les pods existent et sont en état En cours d’exécution :
$ kubectl -n your_namespace get pods -l "app.kubernetes.io/name=your_namespace"
Sortie :
NAME READY STATUS RESTARTS AGE
POD_NAME 0/1 ImagePullBackOff 0 3m54s
Vérifiez que les pods peuvent réussir le test de préparation pour votre déploiement Kubernetes
1. Vérifiez que les pods d'application peuvent réussir le test de préparation. Pour plus d'informations, consultez Configurer les tests d'activité, de préparation et de démarrage (sur le site web de Kubernetes).
2. Vérifiez le test de préparation du pod :
$ kubectl describe pod pod_name -n your_namespace | grep -i readiness
Remarque : remplacez pod_name par le nom de votre pod et your_namespace par votre espace de noms.
Exemple de sortie :
Readiness: tcp-socket :8080 delay=5s timeout=1s period=2s #success=1 #failure=3
Warning Unhealthy 2m13s (x298 over 12m) kubelet Readiness probe failed:
Dans la sortie précédente, vous pouvez voir échec du test de préparation.
Remarque : cette étape fournit une sortie utile uniquement si l'application surveille le bon chemin et le bon port. Vérifiez la sortie curl à l'aide de la commande curl -Ivk et assurez-vous que le chemin défini au niveau du service reçoive une réponse valide. Par exemple, 200 ms est une bonne réponse.
Vérifiez la capacité de votre Classic Load Balancer
Si vous obtenez une erreur HTTP 503 intermittente, cela signifie que votre Classic Load Balancer n'a pas suffisamment de capacité pour traiter la demande. Pour résoudre ce problème, assurez-vous que votre Classic Load Balancer possède une capacité suffisante et que vos composants master peuvent gérer le taux de demandes.
Vérifiez que vos instances sont enregistrées
Vous obtenez également une erreur HTTP 503 s'il n'existe aucune instance enregistrée. Pour résoudre ce problème, essayez les solutions suivantes :
- Vérifiez que les groupes de sécurité pour le composant master disposent d'une règle de trafic entrant qui autorise l'accès au port du nœud vers les composants master. Vérifiez également qu'aucune règle NAT ne bloque le trafic réseau sur les plages de ports du nœud.
- Vérifiez que le groupe de sécurité personnalisé spécifié pour le Classic Load Balancer est autorisé à accéder au trafic entrant sur les composants master.
- Assurez-vous qu'il existe des composants master dans chaque zone de disponibilité spécifiée par les sous-réseaux.
Informations connexes
Pourquoi ai-je reçu une erreur HTTP 5xx lorsque je me suis connecté à des serveurs web fonctionnant sur des instances EC2 configurées pour utiliser Classic Load Balancer ?
HTTP 503 : Service indisponible
Contrôler votre Classic Load Balancer
Surveillance de vos équilibreurs Application Load Balancer
Résolution des problèmes d'un Classic Load Balancer : erreurs HTTP