如何降低GKE+ASM环境下istio-proxy的磁盘资源请求？

云上老周

2026-7-31

问题描述

我运行着带有ASM功能的GKE Autopilot集群，该集群用于开发环境，希望尽可能降低运维成本。由于启用了istio-injection，集群中每个Pod都包含istio-proxy，但该代理显示需要近300GiB磁盘空间，而通过kubectl get pod <pod-name> -o yaml查看的Pod配置里，磁盘请求仅为1GiB左右。

执行命令：

kubectl get pod <pod-name> -o yaml

返回的Pod资源配置片段：

...
    resources:
      limits:
        cpu: 250m
        ephemeral-storage: 1324Mi
        memory: 256Mi
      requests:
        cpu: 250m
        ephemeral-storage: 1324Mi
        memory: 256Mi
...

磁盘使用情况截图

请问运行ASM是否需要近300GiB的磁盘请求？能否降低该资源请求？

[编辑于2023-03-01]

如需复现该问题，可将以下YAML部署到带有ASM的GKE集群中，此时需为default命名空间添加istio-injection标签：

apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx-test
    service: nginx-test
  name: nginx-test
spec:
  ports:
    - name: http
      port: 80
  selector:
    app: nginx-test
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-test
  name: nginx-test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-test
  template:
    metadata:
      labels:
        app: nginx-test
      annotations:
        sidecar.istio.io/proxyCPU: 250m
        sidecar.istio.io/proxyMemory: 256Mi
    spec:
      containers:
        - image: nginx
          imagePullPolicy: IfNotPresent
          name: nginx-test
          ports:
            - containerPort: 80

解答

1. ASM/istio-proxy不需要300GiB磁盘请求

300GiB的磁盘请求完全不符合ASM（Anthos Service Mesh）或istio-proxy的正常资源需求。从你提供的Pod YAML来看，sidecar的ephemeral-storage请求/限制仅为1324Mi（约1.3Gi），这才是实际生效的配置，300GiB的数值大概率是统计错误或误解：

可能是监控工具误将节点级别的总磁盘容量当成了单个Pod的磁盘请求；
也可能是统计时将多个Pod的磁盘占用总和计算到了单个istio-proxy上；
Autopilot集群的节点默认磁盘容量通常在100GiB左右，300GiB更可能是多个节点的磁盘总量。

2. 如何降低istio-proxy的磁盘资源请求

开发环境下，istio-proxy的磁盘需求极低，完全可以进一步下调资源配置，具体方法如下：

（1）通过Pod Annotation单独配置

在Deployment的Pod模板中添加磁盘相关的annotation，直接指定sidecar的磁盘请求和限制：

metadata:
  annotations:
    sidecar.istio.io/proxyCPU: 250m
    sidecar.istio.io/proxyMemory: 256Mi
    sidecar.istio.io/proxyEphemeralStorageRequest: "512Mi"
    sidecar.istio.io/proxyEphemeralStorageLimit: "1Gi"

开发环境下，设置512Mi的请求、1Gi的限制完全足够满足istio-proxy的运行需求。

（2）全局统一配置（适用于整个集群）

如果需要批量调整所有sidecar的资源配置，可以修改ASM的全局注入模板：

通过配置IstioOperator资源，统一指定ephemeral-storage的请求和限制：

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    proxyResources:
      requests:
        cpu: 100m
        memory: 128Mi
        ephemeral-storage: 256Mi
      limits:
        cpu: 500m
        memory: 512Mi
        ephemeral-storage: 512Mi

开发环境可以进一步下调，比如请求256Mi、限制512Mi。

（3）排查并修正统计错误

如果300GiB的数值来自监控工具，需要检查工具的统计逻辑：

确认是否混淆了磁盘请求（request）和实际磁盘占用（usage）；
确认是否将节点的总磁盘容量误统计为单个Pod的资源请求；
可以通过kubectl exec <pod-name> -c istio-proxy -- df -h直接查看istio-proxy容器内的磁盘使用情况，验证实际占用。

3. 额外优化建议

配置istio-proxy的日志轮转：避免长时间运行后日志占用过多磁盘空间，可以通过Sidecar的日志配置实现自动轮转；
清理不必要的Sidecar注入：仅在需要服务网格能力的命名空间启用istio-injection，减少不必要的sidecar资源消耗。

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