Published on 00/00/0000
Last updated on 00/00/0000
Published on 00/00/0000
Last updated on 00/00/0000
Share
Share
8 min read
Share
If you're looking for a production ready Istio distribution based on the new Istio 1.7 release and with support for a safe and automated canary upgrade flow, check out the new Backyards 1.4 release.
In our open-source Banzai Cloud Istio operator we've been working on this feature as well. You can read more on Istio control plane canary upgrades in this blog post.
istiod
can be customized. In EnvoyFilters you can write Lua filters e.g. to manipulate request/response headers of the requests. The syntax of this Lua filter config was changed for Istio 1.7.
The old config looks like this:
If you run Istio 1.7 with an EnvoyFilter containing the old Lua filter config syntax which does not have a specific proxy version specified, your istio proxy containers won't start!
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: ef-1.6
namespace: istio-system
spec:
configPatches:
- applyTo: HTTP_FILTER
match:
context: ANY
listener:
filterChain:
filter:
name: envoy.http_connection_manager
proxy:
proxyVersion: ^1\.6.*
patch:
operation: INSERT_BEFORE
value:
name: envoy.lua
config:
inlineCode: |
function envoy_on_request(handle)
request_handle:headers():add("foo", "bar")
end
Whilst the new one should look like this (notice the changes from field config
to typed_config
):
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: ef-1.7
namespace: istio-system
spec:
configPatches:
- applyTo: HTTP_FILTER
match:
context: ANY
listener:
filterChain:
filter:
name: envoy.http_connection_manager
proxy:
proxyVersion: ^1\.7.*
patch:
operation: INSERT_BEFORE
value:
name: envoy.filters.http.lua
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua
inlineCode: |
function envoy_on_request(handle)
request_handle:headers():add("foo", "bar")
end
It is a good idea to fill the proxy.proxyVersion
field so that the EnvoyFilter is only applied to proxies with specific version and prevents these issues when incompatible changes happen in the syntax for newer Istio proxy versions.
It is important to know that you must use higher target port numbers for the gateway deployments (higher than 1024), otherwise they won't be able to start because the containers do not have root privileges.
proxy.holdApplicationUntilProxyStarts
flag comes into the picture, which was introduced in Istio 1.7 as an experimental feature and is turned off by default.
An even better solution for this problem will be when containers can be marked as sidecars and their lifecycle will be managed natively in Kubernetes. You can follow the GitHub issue on this feature here.
If proxy.holdApplicationUntilProxyStarts
is set to true, the sidecar injector injects the sidecar in front of all other containers and adds a post-start lifecycle hook to the sidecar container. The hook blocks the start of the other containers until the proxy is fully running.
Let's see how a pod starts when this feature is turned off:To learn more, you can read this blog post from the author of this feature.
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 26s default-scheduler Successfully assigned backyards-demo/analytics-v1-85454fbdd4-s2cm9 to ip-192-168-11-248.eu-north-1.compute.internal
Normal Pulling 25s kubelet, ip-192-168-11-248.eu-north-1.compute.internal Pulling image "docker.io/istio/proxyv2:1.7.0"
Normal Pulled 23s kubelet, ip-192-168-11-248.eu-north-1.compute.internal Successfully pulled image "docker.io/istio/proxyv2:1.7.0"
Normal Created 23s kubelet, ip-192-168-11-248.eu-north-1.compute.internal Created container istio-init
Normal Started 23s kubelet, ip-192-168-11-248.eu-north-1.compute.internal Started container istio-init
Normal Pulling 21s kubelet, ip-192-168-11-248.eu-north-1.compute.internal Pulling image "banzaicloud/allspark:0.1.2"
Normal Pulled 13s kubelet, ip-192-168-11-248.eu-north-1.compute.internal Successfully pulled image "banzaicloud/allspark:0.1.2"
Normal Created 13s kubelet, ip-192-168-11-248.eu-north-1.compute.internal Created container analytics
Normal Started 13s kubelet, ip-192-168-11-248.eu-north-1.compute.internal Started container analytics
Normal Pulling 13s kubelet, ip-192-168-11-248.eu-north-1.compute.internal Pulling image "istio/proxyv2:1.7.0"
Normal Pulled 5s kubelet, ip-192-168-11-248.eu-north-1.compute.internal Successfully pulled image "istio/proxyv2:1.7.0"
Normal Created 5s kubelet, ip-192-168-11-248.eu-north-1.compute.internal Created container istio-proxy
Normal Started 5s kubelet, ip-192-168-11-248.eu-north-1.compute.internal Started container istio-proxy
Notice, that the application container (banzaicloud/allspark:0.1.2
) was started before sidecar proxy container (istio/proxyv2:1.7.0
).
Now, let's set proxy.holdApplicationUntilProxyStarts
to true and restart the pod:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 48s default-scheduler Successfully assigned backyards-demo/analytics-v1-85454fbdd4-w9ptx to ip-192-168-11-248.eu-north-1.compute.internal
Normal Pulling 46s kubelet, ip-192-168-11-248.eu-north-1.compute.internal Pulling image "docker.io/istio/proxyv2:1.7.0"
Normal Pulled 36s kubelet, ip-192-168-11-248.eu-north-1.compute.internal Successfully pulled image "docker.io/istio/proxyv2:1.7.0"
Normal Created 36s kubelet, ip-192-168-11-248.eu-north-1.compute.internal Created container istio-init
Normal Started 36s kubelet, ip-192-168-11-248.eu-north-1.compute.internal Started container istio-init
Normal Pulling 34s kubelet, ip-192-168-11-248.eu-north-1.compute.internal Pulling image "istio/proxyv2:1.7.0"
Normal Pulled 26s kubelet, ip-192-168-11-248.eu-north-1.compute.internal Successfully pulled image "istio/proxyv2:1.7.0"
Normal Created 26s kubelet, ip-192-168-11-248.eu-north-1.compute.internal Created container istio-proxy
Normal Started 26s kubelet, ip-192-168-11-248.eu-north-1.compute.internal Started container istio-proxy
Normal Pulling 25s kubelet, ip-192-168-11-248.eu-north-1.compute.internal Pulling image "banzaicloud/allspark:0.1.2"
Normal Pulled 16s kubelet, ip-192-168-11-248.eu-north-1.compute.internal Successfully pulled image "banzaicloud/allspark:0.1.2"
Normal Created 16s kubelet, ip-192-168-11-248.eu-north-1.compute.internal Created container analytics
Normal Started 16s kubelet, ip-192-168-11-248.eu-north-1.compute.internal Started container analytics
As you can see, this time the sidecar container was started first as expected.
One thing to consider when using this feature is that commands which default to the first container will behave differently when an explicit container is not specified. The most prominent example is the kubectl exec
command which will default to the istio-proxy container by default. This should be kept in mind if you want to use this feature and have kubectl exec
in your scripts.
Even though this feature makes sure that the sidecar proxy container starts before the application container, it does not guarantee that the sidecar container is stopped after the app container. This is because the containers are started sequentially by the kubelet, but they are stopped in parallel.
principals
field in the Authorization Policy
resource. So far this field could only be used for sidecar proxies, but did not work for gateways.
For Istio 1.7, it was implemented so that principal based authorization now works for gateways as well.
This can be utilised e.g. when controlling which source workloads can access which external services from a cluster. We had a different recommended solution for this use case using the Sidecar resource, but with this change Authorization Policies
could be used for controlling egress traffic as well.
Want to know more? Get in touch with us, or delve into the details of the latest release.
Or just take a look at some of the Istio features that Backyards automates and simplifies for you, and which we've already blogged about.
Get emerging insights on emerging technology straight to your inbox.
Discover why security teams rely on Panoptica's graph-based technology to navigate and prioritize risks across multi-cloud landscapes, enhancing accuracy and resilience in safeguarding diverse ecosystems.
The Shift is Outshift’s exclusive newsletter.
Get the latest news and updates on cloud native modern applications, application security, generative AI, quantum computing, and other groundbreaking innovations shaping the future of technology.