大魏爬坑记@EFK连锁阵！

EFK不稳定，这是大家都知道的秘密。如果不知道这个秘密，那说明容器云玩得太少。

在大魏的实验环境中：Kibana时而打开收不到内容，时而Index消失，时而搜索不到内容，时而es pod报如下错误：

cp: cannot create regular file '/etc/elasticsearch/elasticsearch.yml': Permission deniedcp: cannot create regular file '/etc/elasticsearch/log4j2.properties': Permission denied

此前大魏我遇到ES报错，也没有太好的方法，无非是重建索引，重建pod，删除PV对应NFS文件重建pod，最差结果重装。方法虽然治标不治本，但屡试不爽，EFK重装完撑个3天问题不大。

但直到出现了Permission denied的错误后，我发现重装都不好使了。

我先排除了两个问题：

• es pod pv对应目录权限的问题，依然有上面的报错。重装也不好使了。
  

• 排除scc问题。有KB描述是因为scc配置错误：https://access.redhat.com/solutions/5449091，但我的环境没这个问题。

在网上搜到别人遇到这个问题的终极方法，通过这个方法可以解决Permission denied这个报错（下文解决这段内容，是参考下面链接文章的内容做的，特此声明。https://vlambda.com/wz_7ix4jsaiHfE.html），也就是重做es镜像。

下面步骤的作用是重做es镜像。把es镜像里 /etc/elasticsearch/* 和其他几个目录文件的权限改成和用户一致（uid 1000 gid 1000），不能直接把es的运行用户改成root。

建个 Dockerfile，修改文件权限：

#mkdir /tmp/es-dockerfile#cd /tmp/es-dockerfile# cat DockerfileFROM registry.redhat.io/openshift4/ose-logging-elasticsearch6@sha256:88e6b0b164f8f798032b82f97c23c77756eead60a79764d2a15a449f8423c1b6USER rootRUN chown -R 1000:1000 /etc/elasticsearch/ && \    chown -R 1000:1000 /opt/app-root/src/ && \    chown -R 1000:1000 /usr/share/elasticsearch/USER 1000

构建并推送镜像：

#podman login registry.redhat.io#podman build -t bastion.ocp.ats.com:5000/openshift4/ose-logging-elasticsearch6:v1 .#podman login bastion.ocp.ats.com:5000#podman push bastion.ocp.ats.com:5000/openshift4/ose-logging-elasticsearch6:v1

查看es operator的名称，修改ES operator使用的镜像：

[root@bastion es-dockerfile]# oc get ClusterServiceVersion -n openshift-operators-redhatNAME                                           DISPLAY                             VERSION                 REPLACES   PHASEamqstreams.v1.6.1                              Red Hat Integration - AMQ Streams   1.6.1                              Succeededelasticsearch-operator.4.5.0-202012120433.p0   Elasticsearch Operator              4.5.0-202012120433.p0              Succeeded

[root@bastion es-dockerfile]# oc edit ClusterServiceVersion elasticsearch-operator.4.5.0-202012120433.p0 -n openshift-operators-redhat

修改如下问题，改成新构建的镜像。

此时再查看es pod的状态，已经从让人抓狂的 CrashLoopBackOff 变成了ImagePullBackOff了，说明我上面改镜像位置的做法生效了，只是可能镜像当时还没push完毕而已。

没关系，将所有内容删除，只留clusterlogging operator：

# oc delete -f clo-instance1.yaml

然后重建相关pod，将ES的存储设置为空。

ES+PV on NFS on SAS能绝对是一对很烂的CP。不仅是SAS磁盘性能不好，而是NFS性能更不好，正常使用都会造成诸多报错。至于生产上需要日志持久化怎么解决，我后面说。

apiVersion: logging.openshift.io/v1kind: ClusterLoggingmetadata:  name: instance  namespace: openshift-loggingspec:  managementState: Managed  logStore:    type: elasticsearch    elasticsearch:      resources:        limits:          memory: 2Gi        requests:          memory: 2Gi      nodeCount: 1      nodeSelector:        node-role.kubernetes.io/worker: ""      redundancyPolicy: ZeroRedundancy      storage: {}  visualization:    type: kibana    kibana:      replicas: 1      nodeSelector:        node-role.kubernetes.io/worker: ""  curation:    type: curator    curator:      schedule: 30 3 * * *      nodeSelector:        node-role.kubernetes.io/worker: ""  collection:    logs:      type: fluentd      fluentd: {}

查看pod，不再报错：

上文我们提到，ES+PV on NFS能绝对是一堆很烂的CP。那怎么解决？

1. PoC环境用空目录（如上面的配置）。PoC环境根本不用担心没法给客户展示Kibana的搜索功能，日志不是太少，而是太多。

2. 只能用NFS的话，让NFS所属的磁盘性能好一些，SAS要不得，要一定要用SSD，基于SSD做fs目录分享。。并且这个NFS Server最好不要再给别的pod提供服务了。
   

3. 用Local Storage Operator的方法，就是宿主机本地空间。但最好本地是高速磁盘，。解决方案：https://docs.openshift.com/container-platform/4.6/storage/persistent_storage/persistent-storage-local.html

4. 让EFK收集日志不要这么频繁。解决方案：https://access.redhat.com/solutions/4619431