Istio Ambient Mesh is a fairly new area in the service mesh ecosystem this premiere with collaboration of Solo.io and Google and I wanted to cover that further in the purpose of service mesh along with the approach of losing the sidecar.
What is a sidecar container?
Sidecar containers were introduced as a approach initially in Istio as a way to inject a extra container into a pod that would act as the communication mechanism, this is a simple explanation we will break down the architecture to dive a little deeper with this in another blog. Simply put this introduced some resources into your cluster and the approach of Ambient Mesh is to use a ztunnel in lieu of a sidecar this opens up the resource intensive nature of sidecars.
How does Ambient Mesh Differ?
From what I can gather on this subject further is that the approach uses two distinct layers noted in the reference documentation below this allows you take advantage of Layer 7 Processing Layer features along with features in the Overlay layer.
Photo credit: https://istio.io/latest/blog/2022/introducing-ambient-mesh/
Starting the cluster up with 3 nodes in a local kind cluster after you provisioned this should look similar
kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml
kubectl apply -f https://raw.githubusercontent.com/linsum/sample-apps/main/sleep/sleep.yaml
kubectl apply -f https://raw.githubusercontent.com/linsum/sample-apps/main/sleep/notsleep.yaml
Photo credit: https://istio.io/latest/docs/examples/bookinfo/
This is the application we are deploying from an architectural view
For this demo I’m using kind on the local machine along with running the configuration documented at this link https://istio.io/latest/blog/2022/get-started-ambient/
After you run through the installation ensure you have the istioctl installed if you don’t it’s fairly straight forward you can use the following documentation to do this
After our services are deployed/running we can now get to using the Ambient Mesh
We’ll run the following command to expose the ProductPage to the Istio ingress gateway to access the book info outside of a cluster.
kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml
Now let’s see what services are running with the following command
kubectl get svc -A
kubectl exec deploy/sleep -- curl -s http://istio-ingressgateway.istio-system/productpage | head -n1
kubectl exec deploy/sleep -- curl -s http://productpage:9080/ | head -n1
kubectl exec deploy/notsleep -- curl -s http://productpage:9080/ | head -n1
We can see we have a response back with <!DOCTYPE html>
Adding applications to the Ambient Mesh
For enablement of ambient mesh we will run the following command which labels our namespace.
kubectl label namespace default istio.io/dataplane-mode=ambient
#Send some traffic
kubectl exec deploy/sleep -- curl -s http://istio-ingressgateway.istio-system/productpage | head -n1
kubectl exec deploy/sleep -- curl -s http://productpage:9080/ | head -n1
kubectl exec deploy/notsleep -- curl -s http://productpage:9080/ | head -n1
You’ll get the three responses shown in the image above after running the command so somewhat similar to what we’ve seen previously the main difference is this is now mTLS communications as the default namespace is now a part of the Ambient Mesh
Photo credit: https://istio.io/latest/blog/2022/get-started-ambient/
I ran into some issues in my local cluster on locating the ds on another node due to that we will use the Layer 4 Authorization policy by running the command below
kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: productpage-viewer
namespace: default
spec:
selector:
matchLabels:
app: productpage
action: ALLOW
rules:
- from:
- source:
principals: ["cluster.local/ns/default/sa/sleep", "cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"]
EOF
This allows the sleep service account and istio-ingressgateway service accounts to call the productpage service.
We can confirm the authorization policy is working by running the below commands
# this should succeed
kubectl exec deploy/sleep -- curl -s http://istio-ingressgateway.istio-system/productpage | head -n1
# this should succeed
kubectl exec deploy/sleep -- curl -s http://productpage:9080/ | head -n1
# this should fail with an empty reply
kubectl exec deploy/notsleep -- curl -s http://productpage:9080/ | head -n1
Conclusion
Istio Ambient Mesh is still in its early stages and I’m really excited to see the continued expansion from Solo.io and Google in this space I plan on making more details exploring some of the key benefits of a service mesh along with in-depth breakdown of the ambient data plane mode in the weeks to come.
A quick demo provided to get you up and running is linked below on this