Spring Boot on GCP
  • Introduction
  • Getting Started
    • Google Cloud Platform
    • Cloud Shell
    • gcloud CLI
    • Hello World!
      • Cloud Shell
      • App Engine
      • Cloud Run
      • Kubernetes Engine
      • Compute Engine
      • Cloud Functions
  • Application Development
    • Development Tools
    • Spring Cloud GCP
    • Cloud Services
      • Databases
        • Cloud SQL
        • Cloud Spanner
        • Cloud Firestore
          • Datastore Mode
          • Native Mode
      • Messaging
        • Cloud Pub/Sub
        • Kafka
      • Secret Management
      • Storage
      • Cache
        • Memorystore Redis
        • Memorystore Memcached (beta)
      • Other Services
    • Observability
      • Trace
      • Logging
      • Metrics
      • Profiling
      • Debugging
    • DevOps
      • Artifact Repository
  • Deployment
    • Runtime Environments
    • Container
      • Container Image
      • Secure Container Image
      • Container Awareness
      • Vulnerability Scanning
      • Attestation
    • Kubernetes
      • Kubernetes Cluster
      • Deployment
      • Resources
      • Service
      • Health Checks
      • Load Balancing
        • External Load Balancing
        • Internal Load Balancing
      • Scheduling
      • Workload Identity
      • Binary Authorization
    • Istio
      • Getting Started
      • Sidecar Proxy
  • Additional Resources
    • Code Labs
    • Presentations / Videos
    • Cheat Sheets
Powered by GitBook
On this page
  • Automatic Sidecar Injection
  • Manual Sidecar Injection

Was this helpful?

  1. Deployment
  2. Istio

Sidecar Proxy

PreviousGetting StartedNextCode Labs

Last updated 4 years ago

Was this helpful?

Istio requires to run a sidecar proxy next to every instance of your containers that needs to participate in the service mesh. There are 2 ways of adding the sidecar proxy:

  1. Automatic sidecar injection

  2. Manual sidecar injection

Automatic Sidecar Injection

You can inject the Istio sidecar automatically for every pod that's deployed into a specific namespace. You can enable automatic injection by annotating the namespace you want to use the service mesh.

kubectl label namespace default istio-injection=enabled

Deploy a workload, such as the Helloworld application from the section.

kubectl apply -f k8s/deployment.yaml

Verify that the Helloworld pod has 2 containers rather than only 1:

kubectl get pods

Each container within a pod is named. Now that the pod has multiple containers, you can specify a container within the pod using -c containername parameter:

POD_NAME=$(kubectl get pods -lapp=helloworld -o jsonpath='{.items[0].metadata.name}')

kubectl logs ${POD_NAME} -c helloworld
kubectl logs ${POD_NAME} -c istio-proxy

If, for some reason, a workload do not want to participate in the mesh, then you can explicitly turn off automatic sidecar injection using annotation:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloworld
  ...
spec:
  template:
    metadata:
      labels:
        ...
      annotations:
        # Explicitly turn off automatic sidecar injection
        sidecar.istio.io/inject: "false"
    spec:
      ...

Manual Sidecar Injection

You can use istioctl to filter your existing Kubernetes deployment file and it'll produce the enhanced deployment manifest.

istioctl kube-inject -f k8s/deployment.yaml

In addition to your original manifest, the enhanced manifest now has an additional istio-proxycontainer.

You can save the enhanced manifest into a file for future deployments. Or, you can filter and apply in one command:

istioctl kube-inject -f k8s/deployment.yaml| kubectl apply -f

In most cases, Automatic Sidecar Injection is what you need.

Kubernetes Deployment