Istio working without Envoy?

1

Hello, rookie question here about Envoy injection

I created a deployment, service, destination rule, virtual service, and gateway in GKE for testing. Everything is basically empty, just placeholders for future development. And it worked! Then I started reading about sidecar injection, and realized I was deploying in a namespace without istio-injection=enabled. I went and checked, and indeed Envoy wasn’t created as a sidecar.

My question is, why is the deployment working :slight_smile: can istio work without envoy?

2

Details: (I’m deploying in dev namespace)

$ kubectl get ns -L istio-injection
NAME           STATUS    AGE       ISTIO-INJECTION
default        Active    56d       enabled
dev            Active    14d       
istio-system   Active    35d       disabled
kube-public    Active    56d       
kube-system    Active    56d       

$ kubectl get deploy -n dev
NAME                         DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
playbook-service-prod        1         1         1            1           8d

$ kubectl get po -n dev
NAME                                          READY     STATUS    RESTARTS   AGE
playbook-service-prod-777c4f9868-7tt8c        1/1       Running   0          5d 

 $ kubectl get po playbook-service-prod-777c4f9868-7tt8c -n dev -o jsonpath='{.spec.containers[*].name}'
playbook-service

// only one container running, no Envoy
3

Hi Jason,

Without the sidecar installed, services will talk directly to each other without going through Istio. Any Istio configuration, will not take effect, but communication between pods should still work.

4

But I’m accessing my service through the istio ingressgateway, not just interservice communication. And its serving only on a specific hostname, which is a configuration I applied in the gateway. So it appears its taking configurations after all

5

The ingress gateway doesn’t use auto-injection, but instead is an instance of Envoy itself. It’s still able to communicate with Pilot.

What I think is happening here (need to test) is:

Ingress gateway is receiving a config from Pilot which it uses to communicate with the pods. The pods themselves don’t have a config, so if you had, say mTLS enabled, the ingress gateway would attempt to use it, but the pods would not since they are not receiving a configuration.

6

Just deployed bookinfo without sidecar injection and confirmed that this is correct. If you look at istioctl proxy-status, you can see something similar to:

./bin/istioctl proxy-status
NAME CDS LDS EDS RDS PILOT VERSION
istio-egressgateway-79fbcb8c94-lk75l.istio-system SYNCED SYNCED SYNCED (100%) NOT SENT istio-pilot-7fff84cb-jtxvb 1.1.3
istio-ingressgateway-75d44f97d7-qrrq2.istio-system SYNCED SYNCED SYNCED (100%) SYNCED istio-pilot-7fff84cb-jtxvb 1.1.3

This shows that only istio-ingressgateway and istio-egressgateway have configuration and both are fully synced.

Looking at proxy-config route, we can see:

istioctl proxy-config route istio-ingressgateway-75d44f97d7-qrrq2.istio-system
NOTE: This output only contains routes loaded via RDS.
NAME VIRTUAL HOSTS
http.80 1
1

This indicates that ingress gateway knows about the http.80 route, which if we examine:
./bin/istioctl proxy-config route istio-ingressgateway-75d44f97d7-qrrq2.istio-system --name http.80 -o json

includes configuration for the bookinfo routes (/productpage, /login, /logout, /api/v1/products). So the ingress gateway knows how to find the bookinfo productpage routes.

However, if you notice from the initial output, there is no configuration in the bookinfo pods. So Istio is “working” in the sense that the ingress gateway knows how to find it, but it’s not working in the sense that you can configure the bookinfo pods themselves.

7

!!! That makes more sense now. I havent gotten my hands into the istioctl tool yet. Thank you for taking the time to look into this.

So is it a typical practice to turn on injection by default, and only exclude namespaces that have the label istio-injection=false?

8

No problem.

Istio provides two options for injection.

Manual injection:

 kubectl apply -f <(istioctl kube-inject -f samples/httpbin/httpbin.yaml)

and automatic injection:

kubectl label namespace default istio-injection=enabled

Automatic injection takes place namespace wide if the label is istio-injection=enabled and happens behind the scenes. Manual injection takes place on each deployment. Either option works.