- Use filters with caution as they could destabilize the mesh!
- Filters are additive. There will be implicit dependencies and interactions among them.
- Rootnamespace filters are applied before workload namespace filters.
- Upgrades are non trivial, as the filter specifications may change.
Envoy filters are leveraged when the other Istio primitives are insufficient.
- Workload Selector
- If absent, then it will apply to all elements of the mesh.
- If present and deployed in the root namespace, then it will apply to all namespaces in mesh.
- If present and deployed in a non-root namespace, then it will apply to the non-root namespace.
- Leverages basic label syntax:
foo: bar
- ConfigPatches
- A list of patches to apply, that will be done sequentially.
- Should be restricted to a single function. (i.e. Create a filter for each "task")
Level Two: What type of envoy resource am I updating, which of those resources am I updating, and what am I applying?
- ApplyTo
- Match
- Allows you to select from gateway, sidecar_in, sidecar_out, and between proxy versions, listeners, filter chains, route configs, and clusters.
- Rule of Thumb:
- Proxy & Listener -> Mesh Configuration
- Clusters -> Kubernetes Services
- Route Configs -> Headers
- Network Filters -> Proxy Protocols
- HTTP Filters -> External Services
- HTTP Routes -> Headers, Redirects, Responses
- Patch
- No validation for patch!
-
Operation (Patch Logic)
- Add, Remove, Replace, Insert, Insert_Before, Insert_After
- Before or After should be used with caution, names are unstable
- You can only replace filters
- You cannot add or remove route-configs or http-routes.
-
Value
- Specific to resource being patched.
- Filters generally include:
name: "given name" typed_config: "@type": "type.googleapis.com/envoy.extensions.filters..."
-
FilterClass
- Authn -> after authentication
- Authz -> after authorization
- Stats -> before stats