1. top Shows Node Resource Usage Above 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% This is because usage is computed against allocatable resources by default, which excludes the portion reserved by Kubelet.

1. About JuiceFS Caching On a host, warmed cache is placed directly on the host. In a cluster, there are two levels of cache: Worker, which provides cache shared at the cluster level Fuse, which provides cache at the current node level only 2. Warming Data with the JuiceFS Client Note that warming at the Fuse layer is only effective for the current node; if you need to warm the whole cluster, you must warm at the Worker layer.

1. Symptoms Elasticsearch on Kubernetes was restarting frequently, leaving the service almost unusable. During data import, the Pod’s memory usage kept growing Once the Pod’s memory usage approached the Limit, continued importing triggered an abnormal Pod exit, with the error log ERROR: Elasticsearch exited unexpectedly The Pod’s memory usage did not drop; it stayed near the Limit, and before long the Pod exited abnormally again The Elasticsearch Pod’s memory limit was 64GB, while the JVM memory limit was 32GB.

1. Storage Options There are three storage approaches: Isolate by directory and share a single JuiceFS Elasticsearch nodes share one JuiceFS instance, mounting different Elasticsearch nodes through subdirectories. /0/ corresponds to node Node-0 /1/ corresponds to node Node-1 /2/ corresponds to node Node-2 The main advantage of this approach is that it is easy to scale and simple to configure.

1. Create the 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.