1. top 查看节点资源使用率超过 100% 1 2 3 4 5 6 kubectl top node NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% master-1 995m 16% 13760Mi 118% master-2 827m 13% 10672Mi 92% master-3 889m 14% 10244Mi 88% 这是由于在计算使用率时，默认使用的是可分配的资源，排除了 Kubelet 保留的部分。在 kubectl 源码中可以看到: 1 2 3 4 5 6 7 for _, n := range nodes { if !o.ShowCapacity { availableResources[n.Name] = n.Status.Allocatable } else { availableResources[n.Name] = n.Status.Capacity } } 如果需要

1. 关于 JuiceFS 的缓存 在主机上，预热的缓存是直接放在主机上的。 在集群中，分为两级缓存: Worker，提供集群级别共享的缓存 Fuse，提供仅当前节点级别的缓存 2. 使用 JuiceFS 客户端预热数据 需要注意的是在 Fuse 层预热，仅对当前节点有效，如果需要预热整个集群，需要在

1. 现象 基于 Kubernetes 的 Elasticsearch 频繁重启，导致服务几乎不可用。 在导入数据过程中，Pod 的内存使用持续增长 Pod 内存使用接近 Limit 之后，继续导入就会触发 Pod 异常退出，错误日志 ERROR: Elasticsearch exited unexpectedly Pod 内存使用率并不会下降，而是维持在 Limit 附近，不久又异常退出 Elasticsearch Pod 内存限制在 64GB，而 JVM 内

1. 存储方案 三种存储方案： 基于目录隔离公用一个 JuiceFS Elasticsearch 的节点共用一个 JuiceFS，通过子目录挂载不同的 Elasticsearch 节点。 /0/ 对应节点 Node-0 /1/ 对应节点 Node-1 /2/ 对应节点 Node-2 这种方式的好处主要是，易于扩展、配置方便。 基于 JuiceFS 隔离节点数据 Elasticsearch 每个节点都对接一个独立的 JuiceF

1. 创建 Dataset 1 2 3 4 5 6 7 8 9 10 kubectl apply -f - <<EOF apiVersion: v1 kind: Secret metadata: name: my-s3 type: Opaque stringData: aws.accessKeyId: xxx aws.secretKey: xxx EOF 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 kubectl apply -f - <<EOF apiVersion: data.fluid.io/v1alpha1 kind: Dataset metadata: name: my-s3 spec: mounts: - mountPoint: s3://BUCKET/ name: s3 options: alluxio.underfs.s3.endpoint: ks3-cn-beijing-internal.ksyun.com alluxio.underfs.s3.disable.dns.buckets: "false" encryptOptions: - name: aws.accessKeyId valueFrom: secretKeyRef: name: my-s3 key: aws.accessKeyId - name: aws.secretKey valueFrom: secretKeyRef: name: my-s3 key: aws.secretKey accessModes: - ReadWriteMany EOF 2. 创建 Runtime 1 2 3 4 5 6 7 8 9