Почему стручок завершает это сам? - PullRequest
0 голосов
/ 13 марта 2020

Я пытаюсь установить fluend сasticsearch и kibana, используя чат bitnami helm.

Я следую нижеприведенной статье

Интеграция ведения журнала Kubernetes Kibana ElasticSearch Fluentd

Но когда я использую эластичный поиск, его стручок переходит в состояние Terminating или Back-off.

Я застрял в этом с 3 днями, любая помощь приветствуется.

События:

  Type     Reason            Age                From               Message
  ----     ------            ----               ----               -------
  Warning  FailedScheduling  41m (x2 over 41m)  default-scheduler  error while running "VolumeBinding" filter plugin for pod "elasticsearch-master-0": pod has unbound immediate PersistentVolumeClaims
  Normal   Scheduled         41m                default-scheduler  Successfully assigned default/elasticsearch-master-0 to minikube
  Normal   Pulling           41m                kubelet, minikube  Pulling image "busybox:latest"
  Normal   Pulled            41m                kubelet, minikube  Successfully pulled image "busybox:latest"
  Normal   Created           41m                kubelet, minikube  Created container sysctl
  Normal   Started           41m                kubelet, minikube  Started container sysctl
  Normal   Pulling           41m                kubelet, minikube  Pulling image "docker.elastic.co/elasticsearch/elasticsearch-oss:6.8.6"
  Normal   Pulled            39m                kubelet, minikube  Successfully pulled image "docker.elastic.co/elasticsearch/elasticsearch-oss:6.8.6"
  Normal   Created           39m                kubelet, minikube  Created container chown
  Normal   Started           39m                kubelet, minikube  Started container chown
  Normal   Created           38m                kubelet, minikube  Created container elasticsearch
  Normal   Started           38m                kubelet, minikube  Started container elasticsearch
  Warning  Unhealthy         38m                kubelet, minikube  Readiness probe failed: Get http://172.17.0.7:9200/_cluster/health?local=true: dial tcp 172.17.0.7:9200: connect: connection refused
  Normal   Pulled            38m (x2 over 38m)  kubelet, minikube  Container image "docker.elastic.co/elasticsearch/elasticsearch-oss:6.8.6" already present on machine
  Warning  FailedMount       32m                kubelet, minikube  MountVolume.SetUp failed for volume "config" : failed to sync configmap cache: timed out waiting for the condition
  Normal   SandboxChanged    32m                kubelet, minikube  Pod sandbox changed, it will be killed and re-created.
  Normal   Pulling           32m                kubelet, minikube  Pulling image "busybox:latest"
  Normal   Pulled            32m                kubelet, minikube  Successfully pulled image "busybox:latest"
  Normal   Created           32m                kubelet, minikube  Created container sysctl
  Normal   Started           32m                kubelet, minikube  Started container sysctl
  Normal   Pulled            32m                kubelet, minikube  Container image "docker.elastic.co/elasticsearch/elasticsearch-oss:6.8.6" already present on machine
  Normal   Created           32m                kubelet, minikube  Created container chown
  Normal   Started           32m                kubelet, minikube  Started container chown
  Normal   Pulled            32m (x2 over 32m)  kubelet, minikube  Container image "docker.elastic.co/elasticsearch/elasticsearch-oss:6.8.6" already present on machine
  Normal   Created           32m (x2 over 32m)  kubelet, minikube  Created container elasticsearch
  Normal   Started           32m (x2 over 32m)  kubelet, minikube  Started container elasticsearch
  Warning  Unhealthy         32m                kubelet, minikube  Readiness probe failed: Get http://172.17.0.6:9200/_cluster/health?local=true: dial tcp 172.17.0.6:9200: connect: connection refused
  Warning  BackOff           32m (x2 over 32m)  kubelet, minikube  Back-off restarting failed container

Ответы [ 2 ]

1 голос
/ 13 марта 2020

Проблема здесь в том, что у модуля есть несвязанные немедленные PersistentVolumeClaims. Вы можете установить master.persistence.enabled в false, когда используете helm для его развертывания. В качестве альтернативы вам нужно проверить, существует ли класс хранения по умолчанию в кластере, и если он не существует, то создайте класс хранения и установите его по умолчанию.

0 голосов
/ 13 марта 2020

Краткий ответ: он разбился. Вы можете проверить объект состояния Pod на наличие некоторых подробностей, таких как состояние выхода и if oomkill, а затем посмотреть журналы контейнера, чтобы увидеть, показывают ли они что-нибудь.

...