我在Ubuntu 18.04 LTS上使用 conjure-up kubernetes 在裸机专用服务器上部署了Kubernetes . 这也意味着节点是LXD容器 .
我需要Elasticsearch和MongoDB的持久卷，经过一些研究后，我认为在我的部署中使用它的最简单方法是NFS共享 . 我在主机操作系统中创建了一个NFS共享，具有以下配置：
/ srv / volumes 127.0.0.1（rw）10.78.69 . *（rw，no_root_squash）
10.78.69.* 似乎是Kubernetes使用的桥接网络，至少在查看ifconfig没有别的 .
然后我继续创建两个文件夹，/ srv / volumes / 1和/ srv / volumes / 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运行时规范设备：lstat /dev/.lxc/proc/17848/fdinfo/24：没有此类文件或目录后退重新启动失败的容器
我有点被困在这里 . 我已经尝试搜索错误，但我无法找到解决此问题的方法 .
之前我在 /etc/exports 中将允许的IP设置为 10.78.69.* Kubernetes会告诉我在尝试安装时从NFS服务器获得"permission denied"，所以我假设现在安装成功，因为该错误消失了 .
EDIT:
我决定清除helm部署并再次尝试，这次使用不同的存储类型，本地存储卷 . 我按照Canonical的指南创建了它们，我知道它们有效，因为我以这种方式为MongoDB设置了一个并且它完美地工作 .
从现在起，我必须为创建持久卷的节点设置亲缘关系，从而更改了elasticsearch helm部署的配置：
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 incubator / elasticsearch
这些是唯一的变化，但是弹性搜索仍然存在同样的问题 .
附加信息：
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"}
elasticsearch图像是头盔图中的默认图像：
docker.elastic.co/elasticsearch/elasticsearch-oss:6.4.1
各种pod（主，客户端，数据）日志都是空的 . 错误是一样的 .
2 回答
我能够通过在主机上运行
sysctl -w vm.max_map_count=262144来解决问题，并删除尝试执行此操作的"sysctl" init容器失败 .它看起来像是一个经常出现的问题，可以在各种环境和配置中观察到 . 然而，目前尚不清楚究竟是什么导致它 . 您能否提供有关软件版本，日志片段等的更多详细信息？