If an Elasticsearch node does not start up, it is probably because Kubernetes cannot schedule the associated Pod.
First, check the StatefulSets to see if the current number of replicas match the desired number of replicas.
kubectl get statefulset NAME DESIRED CURRENT AGE elasticsearch-sample-es-default 1 1 4s
Then, check the Pod status. If a Pod fails to reach the
Running status after a few seconds, something is preventing it from being scheduled or starting up:
kubectl get pods -l elasticsearch.k8s.elastic.co/statefulset-name=elasticsearch-sample-es-default NAME READY STATUS RESTARTS AGE elasticsearch-sample-es-66sv6dvt7g 0/1 Pending 0 3s elasticsearch-sample-es-9xzzhmgd4h 1/1 Running 0 42s elasticsearch-sample-es-lgphkv9p67 0/1 Pending 0 3s kibana-sample-kb-5468b8685d-c7mdp 0/1 Running 0 4s
elasticsearch-sample-es-lgphkv9p67 isn’t scheduled. Run this command to get more insights:
kubectl describe pod elasticsearch-sample-es-lgphkv9p67 (...) Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 1m (x6 over 1m) default-scheduler pod has unbound immediate PersistentVolumeClaims (repeated 2 times) Warning FailedScheduling 1m (x6 over 1m) default-scheduler pod has unbound immediate PersistentVolumeClaims Warning FailedScheduling 1m (x11 over 1m) default-scheduler 0/3 nodes are available: 1 node(s) had no available volume zone, 2 Insufficient memory. Normal NotTriggerScaleUp 4s (x11 over 1m) cluster-autoscaler pod didn't trigger scale-up (it wouldn't fit if a new node is added)
If you see an error with unbound persistent volume claims (PVCs), it means there is not currently a persistent volume that can satisfy the claim. If you are using automatically provisioned storage (e.g. Amazon EBS provisioner), sometimes the storage provider can take a few minutes to provision a volume, so this may resolve itself in a few minutes. You can also check the status by running
kubectl describe persistentvolumeclaims to see events of the PVCs.