Answers: <p>Restarting Istio controlplane should fix the issue on hand (pods in <code>istio-system</code>, most likely pilot).</p>
  <p>More importantly do not run Istio 1.2 its very outdated version with many bugs and security issues.</p>
  
Answers: CC BY-SA 4.0
Answers: 2021-05-12T17:58:08.140Z
Answers: Yes, we are abolishing the old version. This was just a plan to mitigate some connection issues while we setup our new clusters with latest istio.
Answers: bakadevops
Answers: CC BY-SA 4.0
Answers: 2021-05-12T15:20:26.640Z
Answers: 2021-05-12T15:20:26.640Z
Answers: Kyslik
Body: <p>I initially created an EnvoyFilter to apply <code>idle_timeout</code> of <code>5s</code> to outbound requests originating from workloads with label <code>app: mecha-dev</code>.</p>
  <pre><code>apiVersion: networking.istio.io/v1alpha3
  kind: EnvoyFilter
  metadata:
    name: tcp-idle-timeout
  spec:
    workloadSelector:
      labels:
        app: mecha-dev
    filters:
      - listenerMatch:
          listenerType: SIDECAR_OUTBOUND
          listenerProtocol: TCP
        filterName: envoy.tcp_proxy
        filterType: NETWORK
        filterConfig:
          idle_timeout: 5s
  </code></pre>
  <p>However, the filter did not work for me and I found out it was because my cluster is using <code>istio v1.2.5</code> which is a very old version and does not support <code>EnvoyFilters</code> properly and the envoy API for the same have been deprecated.</p>
  <p>Therefore, I deleted the <code>EnvoyFilter</code> using <code>kubectl</code>.</p>
  <p>But, even after deletion of the filter the <code>istio-proxy</code> sidecar containers keep on showing me the following error again and again:</p>
  <pre><code>[2021-05-11 11:59:14.109][22][warning][config] [external/envoy/source/common/config/grpc_mux_subscription_impl.cc:73] gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected: Error adding/updating listener(s) 10.155.0.113_443: Proto constraint validation failed (TcpProxyValidationError.StatPrefix: [&quot;value length must be at least &quot; '\x01' &quot; bytes&quot;]): idle_timeout {
    seconds: 5
  }
  </code></pre>
  <p>I deleted the pods and re-created new ones but this error keeps on showing up. Is there anything else I need to clean up or delete to get rid of this error?</p>
  
Comments: CC BY-SA 4.0
Comments: 2021-05-12T10:42:00.440Z
Comments: Have you deleted workloads only? Have you restarted controlplane as well (pods in `istio-system` namespace)?
Comments: Kyslik
Comments: CC BY-SA 4.0
Comments: 2021-05-12T11:44:48.690Z
Comments: @Kyslik there are a bunch of pods in ```istio-system``` namespace, do I gotta restart all?
Comments: bakadevops
Comments: CC BY-SA 4.0
Comments: 2021-05-12T11:48:58.640Z
Comments: Unless you run your production workloads on that cluster, yes. You gotta test things like this one way or another... I don't remember what components Istio 1.2 have, but I'd start with pilot or mixer.
Comments: Kyslik
Comments: CC BY-SA 4.0
Comments: 2021-05-12T11:49:45.983Z
Comments: It is not a prod workload so I can test these out.
Comments: bakadevops
Comments: CC BY-SA 4.0
Comments: 2021-05-12T13:19:58.363Z
Comments: @Kyslik after restarting pilot and mixer the errors were gone. Thanks for the suggestion.
Comments: bakadevops
Tags: <kubernetes><istio>
Title: Istio Keeps On Showing TcpProxyValidationError Errors
UserDisplayName: bakadevops
ThreadText: # Istio Keeps On Showing TcpProxyValidationError Errors
  
  (Asked by: username_0 on 2021-05-11)
  
  I initially created an EnvoyFilter to apply `idle_timeout` of `5s` to outbound requests originating from workloads with label `app: mecha-dev`.
  
  ```
  apiVersion: networking.istio.io/v1alpha3
  kind: EnvoyFilter
  metadata:
    name: tcp-idle-timeout
  spec:
    workloadSelector:
      labels:
        app: mecha-dev
    filters:
      - listenerMatch:
          listenerType: SIDECAR_OUTBOUND
          listenerProtocol: TCP
        filterName: envoy.tcp_proxy
        filterType: NETWORK
        filterConfig:
          idle_timeout: 5s
  
  ```
  
  However, the filter did not work for me and I found out it was because my cluster is using `istio v1.2.5` which is a very old version and does not support `EnvoyFilters` properly and the envoy API for the same have been deprecated.
  
  Therefore, I deleted the `EnvoyFilter` using `kubectl`.
  
  But, even after deletion of the filter the `istio-proxy` sidecar containers keep on showing me the following error again and again:
  
  ```
  [2021-05-11 11:59:14.109][22][warning][config] [external/envoy/source/common/config/grpc_mux_subscription_impl.cc:73] gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected: Error adding/updating listener(s) 10.155.0.113_443: Proto constraint validation failed (TcpProxyValidationError.StatPrefix: ["value length must be at least " '\x01' " bytes"]): idle_timeout {
    seconds: 5
  }
  
  ```
  
  I deleted the pods and re-created new ones but this error keeps on showing up. Is there anything else I need to clean up or delete to get rid of this error?
  
  **Tags:** kubernetes, istio
  
  > **Comments:**
  > **username_1**: Have you deleted workloads only? Have you restarted controlplane as well (pods in `istio-system` namespace)?  
  > **username_0**: @username_1 there are a bunch of pods in ```istio-system``` namespace, do I gotta restart all?  
  > **username_1**: Unless you run your production workloads on that cluster, yes. You gotta test things like this one way or another... I don't remember what components Istio 1.2 have, but I'd start with pilot or mixer.  
  > **username_0**: It is not a prod workload so I can test these out.  
  > **username_0**: @username_1 after restarting pilot and mixer the errors were gone. Thanks for the suggestion.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2021-05-12. Score: 1 | Accepted answer
  
  Restarting Istio controlplane should fix the issue on hand (pods in `istio-system`, most likely pilot).
  
  More importantly do not run Istio 1.2 its very outdated version with many bugs and security issues.
  
  > **Comments:**
  > **username_0**: Yes, we are abolishing the old version. This was just a plan to mitigate some connection issues while we setup our new clusters with latest istio.  
  
  ---
  
  