GKE集群Vespa部署中DefaultContainerThreadPool加载失败求助

背景信息 #

在GKE集群的3个节点上通过Kubernetes部署Vespa，基于Vespa 7.351.32版本构建自定义Docker镜像，添加了GCloud SDK、日志备份至GCS的脚本，以及包含部署所需.xml等文件的workspace目录。

执行以下部署及重启配置服务器步骤后：

/opt/vespa/bin/vespa-deploy prepare /workspace && /opt/vespa/bin/vespa-deploy activate

# 等待5分钟

vespa-stop-services
vespa-stop-configserver

# 等待15分钟

vespa-start-configserver
vespa-start-services

vespa-get-cluster-state
vespa-config-status

出现错误：Vespa: Failed to fetch json: Connection error: socket write error。经日志排查（使用vespa-logfmt -l error），发现com.yahoo.container.handler.threadpool.threadpool.DefaultContainerTHreadpool bundle加载失败，手动重启配置服务器及Vespa服务可解决该问题。

咨询问题 #

1. 该bundle加载前是否需要依赖其他运行中的服务？
2. 是否存在路径问题？若存在，该bundle的位置在哪里？
3. 是否因内存问题导致（当前配置2G，推荐配置为4G）？
4. Vespa加载此类bundle的机制是怎样的？

附相关配置 #

Dockerfile #

FROM vespaengine/vespa:7.351.32

#Copy Neccessary Files
RUN mkdir -p workspace
COPY workspace /workspace
RUN yum install python3
COPY backup-pod.sh /

# Downloading gcloud package
RUN curl https://dl.google.com/dl/cloudsdk/release/google-cloud-sdk.tar.gz > /tmp/google-cloud-sdk.tar.gz

# Installing the package
RUN mkdir -p /usr/local/gcloud \
  && tar -C /usr/local/gcloud -xvf /tmp/google-cloud-sdk.tar.gz \
  && /usr/local/gcloud/google-cloud-sdk/install.sh

# Adding the package path to local
ENV PATH $PATH:/usr/local/gcloud/google-cloud-sdk/bin

Kubernetes StatefulSet清单 #

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: vespa
  namespace: vespa
  labels:
    app: vespa
spec:
  replicas: 3
  #serviceName: vespa
  selector:
    matchLabels:
      app: vespa
      name: vespa-internal
  serviceName: vespa-internal
  template:
    metadata:
      labels:
        app: vespa
        name: vespa-internal
    spec:
      serviceAccount: vespa-sa
#     nodeSelector:
#       iam.gke.io/gke-metadata-server-enabled: "true"
      containers:
      - name: vespa
        image: asia-south1-docker.pkg.dev/aurum-projec/vespa/vespa:latest
        imagePullPolicy: Always
        securityContext:
          privileged: true
        ports:
        - containerPort: 8080
          protocol: TCP
        readinessProbe:
          httpGet:
            path: /ApplicationStatus
            port: 19071
            scheme: HTTP
        volumeMounts:
        - name: vespa-var
          mountPath: /opt/vespa/var
        - name: vespa-logs
          mountPath: /opt/vespa/logs
        resources:
          requests:
            memory: "2G"
          limits:
            memory: "2G"
  volumeClaimTemplates:
  - metadata:
      name: vespa-var
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi
  - metadata:
      name: vespa-logs
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi

同时已提供2181端口连通性截图、错误截图及相关日志截图。

问题解答 #

1. 该bundle加载前是否需要依赖其他运行中的服务？ #

是的，DefaultContainerThreadPool作为容器核心组件，依赖以下服务：

• 配置服务器（Config Server）：必须完全启动并同步完成集群配置，bundle的加载配置、依赖关系都从配置服务器获取。
• ZooKeeper集群：Vespa的配置元数据、集群状态依赖ZooKeeper，若ZooKeeper未就绪，配置服务器无法正常提供配置，会导致bundle加载失败。
• 容器核心框架：容器的基础服务（如组件注册器、配置客户端）必须先启动，才能加载线程池这类扩展组件。

2. 是否存在路径问题？若存在，该bundle的位置在哪里？ #

路径问题是可能的诱因之一，该bundle的默认位置：

• 在官方Vespa镜像中，bundle文件位于/opt/vespa/lib/jars/container-*.jar（具体文件名包含container-threadpool相关标识）。
• 自定义镜像中如果未修改Vespa的默认安装路径，位置与官方一致；若修改了VESPA_HOME环境变量，则路径会对应变更为$VESPA_HOME/lib/jars/下的对应jar包。

排查时可在容器内执行find /opt/vespa -name "*threadpool*.jar"确认文件是否存在、权限是否正确（需保证Vespa进程有读取权限）。

3. 是否因内存问题导致（当前配置2G，推荐配置为4G）？ #

大概率是内存不足导致的：

• Vespa官方推荐每个节点至少4G内存，2G内存会导致JVM堆内存紧张，在加载大量bundle时容易出现OOM（内存溢出）或GC停顿过长，进而引发socket写入错误、bundle加载超时失败。
• 手动重启后暂时缓解是因为重启时JVM内存被清空，短时间内内存占用较低，但随着集群运行，内存压力回升后可能再次出现问题。

建议将内存配置调整为官方推荐的4G及以上，同时可通过jstat、vespa-logfmt -l warning监控JVM内存使用情况。

4. Vespa加载此类bundle的机制是怎样的？ #

Vespa的bundle加载流程如下：

1. 配置获取：容器启动时，通过配置客户端从配置服务器拉取当前应用的所有组件配置，包括需要加载的bundle列表、依赖关系。
2. 类路径构建：根据配置中的bundle路径，将对应jar包加入JVM类路径。
3. 组件初始化：容器框架通过反射实例化bundle中的组件，优先初始化依赖的基础组件（如配置客户端、日志服务），再加载线程池这类业务相关组件。
4. 状态注册：组件初始化完成后，向容器注册自身状态，若初始化失败则标记为加载失败，触发集群状态异常。

整个过程依赖配置服务器的配置同步、JVM内存资源充足，任何环节出现阻塞或资源不足都会导致bundle加载失败。

内容的提问来源于stack exchange，提问作者Nitin G