Service mesh vs library-based approach in Kubernetes - CLI Comparison

Introduction

When microservices need to communicate securely and reliably, managing this communication can be tricky. Service mesh and library-based approaches solve this by handling service-to-service communication, but in different ways.

When you want to add features like load balancing, retries, and security between services without changing application code

When you want a centralized way to monitor and control traffic between microservices

When you prefer to keep your application code simple and separate from communication logic

When you want to embed communication logic directly inside your application for tighter control

When you want to avoid adding extra infrastructure components to your cluster

Commands

Check if the Istio service mesh components are running in the cluster namespace 'istio-system'.

Terminal

kubectl get pods -n istio-system

Expected Output

NAME                                    READY   STATUS    RESTARTS   AGE

istiod-5f7c9d7d7f-abcde                 1/1     Running   0          10m

istio-ingressgateway-7d9f8f9c9f-fghij   1/1     Running   0          10m

Verify that your application pods are running in your namespace before injecting the service mesh sidecar.

Terminal

kubectl get pods -n my-app-namespace

Expected Output

NAME                      READY   STATUS    RESTARTS   AGE

my-app-1234567890-abcde   1/1     Running   0          5m

Inject Istio sidecar proxies into your application deployment manifest and apply it to the cluster. This adds the service mesh features without changing your app code.

Terminal

istioctl kube-inject -f my-app-deployment.yaml | kubectl apply -f -

Expected Output

deployment.apps/my-app created

→

-f - Specifies the input deployment YAML file

Check application logs to confirm it is running without any library-based communication code.

Terminal

kubectl logs my-app-1234567890-abcde -c my-app-container

Expected Output

Starting application...

Listening on port 8080

Ready to serve requests

→

-c - Specifies the container name inside the pod

Check the Istio sidecar proxy logs to see the service mesh handling communication.

Terminal

kubectl logs my-app-1234567890-abcde -c istio-proxy

Expected Output

[Envoy] [2024-06-01T12:00:00.000Z] starting proxy

[Envoy] [2024-06-01T12:00:05.000Z] connection established to service-b

→

-c - Specifies the container name inside the pod

Key Concept

If you remember nothing else, remember: service mesh adds communication features outside your app code, while library-based approach embeds them inside your app.

Common Mistakes

Trying to use service mesh features without injecting sidecar proxies

The service mesh cannot manage traffic if the sidecar proxies are not present in the pods.

Always inject sidecar proxies using tools like istioctl kube-inject or automatic injection before deploying your app.

Adding service communication code in the app and also using a service mesh

This duplicates effort and can cause conflicts or unexpected behavior.

Choose either service mesh or library-based approach, not both, to handle service communication.

Not verifying that the service mesh components are running before deploying apps

Without the control plane running, the mesh features won't work and apps may fail to communicate properly.

Check service mesh pods in their namespace before deploying your applications.

Summary

Service mesh manages service communication by adding sidecar proxies to pods without changing app code.

Library-based approach requires adding communication code inside the application itself.

Use kubectl and istioctl commands to deploy and verify service mesh injection and operation.