Istio sleep service pattern¶

The Istio sleep service pattern refers to a simple testing service deployed within a Service mesh (like Istio) that acts as a standalone source of requests.^[400-devops-07-monitoring-and-observability-k8s-istio-samples-sleep-readme.md]

Overview¶

The core of this pattern is a "sleep" service—a container, typically based on Ubuntu, that effectively does nothing but sleep.^[400-devops-07-monitoring-and-observability-k8s-istio-samples-sleep-readme.md] Despite its inactivity, it is equipped with utilities like curl, enabling it to execute network requests.^[400-devops-07-monitoring-and-observability-k8s-istio-samples-sleep-readme.md] This allows it to function as a stable entry point or "sandbox" Pod for invoking and experimenting with mesh networking features.^[400-devops-07-monitoring-and-observability-k8s-istio-samples-sleep-readme.md]

Usage¶

The primary use case for the sleep service is to interact with other services running inside the mesh, such as the [[Bookinfo]] sample application, to test Istio networking configurations.^[400-devops-07-monitoring-and-observability-k8s-istio-samples-sleep-readme.md] This involves executing commands inside the running sleep Pod.

For example, to send a request to a service named ratings, one would typically identify the sleep Pod and then execute a curl command:

export SLEEP_POD=$([kubectl](<./kubectl.md>) get [Pod](<./pod.md>) -l app=sleep -o jsonpath={.items..metadata.name})
[kubectl](<./kubectl.md>) exec -it $SLEEP_POD -c sleep -- curl http://ratings.default.svc.cluster.local:9080/ratings/1

Additionally, this pattern can be utilized to test and configure access to services located outside of the mesh, known as egress traffic.^[400-devops-07-monitoring-and-observability-k8s-istio-samples-sleep-readme.md]

Deployment¶

The sleep service is deployed via Kubernetes manifests, often named sleep.yaml.^[400-devops-07-monitoring-and-observability-k8s-istio-samples-sleep-readme.md] To function correctly within the Istio mesh, the service requires an Envoy sidecar proxy.

• Automatic Sidecar Injection: If the Kubernetes cluster has Automatic sidecar injection enabled, the manifest can be applied directly using kubectl apply -f sleep.yaml.^[400-devops-07-monitoring-and-observability-k8s-istio-samples-sleep-readme.md]

• Manual Injection: If automatic injection is not configured, istioctl must be used to manually inject the sidecar configuration before applying the manifest:^[400-devops-07-monitoring-and-observability-k8s-istio-samples-sleep-readme.md]

  [kubectl](<./kubectl.md>) apply -f <([istioctl](<./istioctl.md>) kube-inject -f sleep.yaml)
  

Sources¶

^[400-devops-07-monitoring-and-observability-k8s-istio-samples-sleep-readme.md]