Kubernetes голые металлические ошибки NFS PVs с диаграммой эластичного поиска

Question

Я развернул Kubernetes на голом выделенном сервере, используя conjure-up kubernetes на Ubuntu 18.04 LTS. Это также означает, что узлы являются контейнерами LXD.

Мне нужны постоянные тома для Elasticsearch и MongoDB, и после некоторых исследований я решил, что самый простой способ заставить это работать в моем развертывании - это ресурс NFS. Я создал общий ресурс NFS в хост-системе со следующей конфигурацией:

/ srv / volume 127.0.0.1(rw) 10.78.69.*(rw,no_root_squash)

10.78.69.* Похоже, это мостовая сеть, используемая Kubernetes, по крайней мере, если посмотреть на ifconfig, то больше ничего нет.

Затем я приступил к созданию двух папок: / srv / volume /1 и / srv / volume /2. Я создал два PV из этих папок с этой конфигурацией для первой (вторая аналогична):

apiVersion: v1
kind: PersistentVolume
metadata:
  name: elastic-pv1
spec:
  capacity:
    storage: 30Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /srv/volumes/1
    server: 10.78.69.1

Затем я развертываю диаграмму руля Elasticsearch ( https://github.com/helm/charts/tree/master/incubator/elasticsearch), и она создает две заявки, которые успешно связываются с моими PV.

Проблема в том, что впоследствии контейнеры, похоже, сталкиваются с ошибками:

Ошибка: не удалось запустить контейнер "sysctl": Ответ об ошибке от демона: linux spec spec devices: lstat /dev/.lxc/proc/17848/fdinfo/24: нет такого файла или каталога Не удалось перезапустить перезапуск контейнера

Стручки вид

Представление "Постоянные объемные заявки"

Я вроде застрял здесь. Я попытался найти ошибку, но мне не удалось найти решение этой проблемы.

Ранее, прежде чем я установил разрешенный IP в /etc/exports в 10.78.69.* Kubernetes сказал бы мне, что он получил "отказано в доступе" от сервера NFS при попытке монтирования, поэтому я предполагаю, что теперь монтирование прошло успешно, поскольку эта ошибка исчезла.

РЕДАКТИРОВАТЬ:

Я решил очистить развертывание руля и повторить попытку, на этот раз с другим типом хранилища, томами локального хранилища. Я создал их, следуя руководству Canonical, и я знаю, что они работают, потому что я таким образом настроил его для MongoDB, и он отлично работает.

Конфигурация для развертывания шлема эластичного поиска изменилась, так как теперь мне нужно установить сходство для узлов, на которых были созданы постоянные тома:

values.yaml:

data:
    replicas: 1,
    nodeSelector:
        elasticsearch: data
master:
    replicas: 1,
    nodeSelector:
        elasticsearch: master
client:
    replicas: 1,
cluster:
    env: {MINIMUM_MASTER_NODES: "1"}

Я развернул с помощью

helm install --name site-search -f values.yaml инкубатор /asticsearch

Это единственные изменения, однако эластичный поиск все еще представляет те же проблемы.

Дополнительная информация:

kubectl version:

Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.3", GitCommit:"a4529464e4629c21224b3d52edfe0ea91b072862", GitTreeState:"clean", BuildDate:"2018-09-09T18:02:47Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.3", GitCommit:"a4529464e4629c21224b3d52edfe0ea91b072862", GitTreeState:"clean", BuildDate:"2018-09-09T17:53:03Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}

Изображение эластичного поиска - это изображение по умолчанию на рулевой диаграмме:

docker.elastic.co/elasticsearch/elasticsearch-oss:6.4.1

Журналы различных модулей (основной, клиент, данные) пусты. Ошибка такая же.

Answer 1

Я смог решить проблему, запустив sysctl -w vm.max_map_count=262144 я на хост-машине и удаляю контейнер инициализации "sysctl", который пытался сделать это безуспешно.

Answer 2

Это выглядит как частая проблема, и это наблюдается в различных средах и конфигурациях. Однако совершенно неясно, что именно является причиной этого. Не могли бы вы предоставить более подробную информацию о ваших версиях программного обеспечения, фрагментах журнала и т. Д.?