Advanced
Service Mesh
#istioctl#debugging#mesh-ops
Mesh Operations and Troubleshooting Language
5 exercises — 5 exercises practising istioctl commands, sidecar injection debugging, mTLS handshake failures, and mesh upgrade vocabulary.
0 / 24 completed
1 / 24
A developer reports: "My pod is not getting the sidecar injected, even though I enabled injection on the namespace." What is the most likely cause and how do you diagnose it?
The annotation sidecar.istio.io/inject: 'false' on a pod overrides the namespace-level injection setting — always check pod-level annotations when injection is unexpectedly absent.
Injection is controlled at two levels: namespace (label istio-injection: enabled enables injection for all new pods) and pod (annotation sidecar.istio.io/inject: 'false' explicitly disables for that pod). Common scenarios where this annotation is set: the pod is a one-off Job or CronJob, the pod is a daemonset that shouldn't have a sidecar (e.g., Prometheus node-exporter), or a developer accidentally added it. Additionally, pods in kube-system and istio-system namespaces are typically excluded from injection. istioctl analyze surfaces these configuration issues with clear diagnostics.
Key vocabulary:
• sidecar.istio.io/inject: 'false' — pod annotation overriding namespace-level injection; disables sidecar for that pod
• istioctl analyze — validates mesh config; surfaces injection and resource configuration issues
• injection webhook — the mutating admission webhook that injects the sidecar; only runs for new pod creation
Injection is controlled at two levels: namespace (label istio-injection: enabled enables injection for all new pods) and pod (annotation sidecar.istio.io/inject: 'false' explicitly disables for that pod). Common scenarios where this annotation is set: the pod is a one-off Job or CronJob, the pod is a daemonset that shouldn't have a sidecar (e.g., Prometheus node-exporter), or a developer accidentally added it. Additionally, pods in kube-system and istio-system namespaces are typically excluded from injection. istioctl analyze surfaces these configuration issues with clear diagnostics.
Key vocabulary:
• sidecar.istio.io/inject: 'false' — pod annotation overriding namespace-level injection; disables sidecar for that pod
• istioctl analyze — validates mesh config; surfaces injection and resource configuration issues
• injection webhook — the mutating admission webhook that injects the sidecar; only runs for new pod creation
2 / 24
You run istioctl proxy-status and see that several pods show SYNCED while one shows STALE. What does this mean and what should you investigate?
STALE in proxy-status means the Envoy sidecar's configuration is out of sync with what istiod has sent — the xDS push has not been acknowledged by that sidecar.
istioctl proxy-status shows the sync state for each component of the xDS configuration: CDS (Cluster Discovery Service), LDS (Listener), EDS (Endpoint), RDS (Route). A STALE status means istiod sent a new config version but the sidecar hasn't acknowledged it yet. This can be transient (high load) or persistent (network issue, sidecar crash). To investigate: istioctl proxy-config clusters <pod> (see what config the sidecar actually has), kubectl logs -l app=istiod -n istio-system (look for push errors), kubectl describe pod <pod> (check sidecar container restarts).
Key vocabulary:
• istioctl proxy-status — shows xDS config sync state for all Envoy sidecars (SYNCED / STALE / NOT SENT)
• xDS — Envoy's configuration discovery API (CDS/LDS/RDS/EDS); istiod pushes config via xDS
• STALE — sidecar has not yet acknowledged the latest config version from istiod
istioctl proxy-status shows the sync state for each component of the xDS configuration: CDS (Cluster Discovery Service), LDS (Listener), EDS (Endpoint), RDS (Route). A STALE status means istiod sent a new config version but the sidecar hasn't acknowledged it yet. This can be transient (high load) or persistent (network issue, sidecar crash). To investigate: istioctl proxy-config clusters <pod> (see what config the sidecar actually has), kubectl logs -l app=istiod -n istio-system (look for push errors), kubectl describe pod <pod> (check sidecar container restarts).
Key vocabulary:
• istioctl proxy-status — shows xDS config sync state for all Envoy sidecars (SYNCED / STALE / NOT SENT)
• xDS — Envoy's configuration discovery API (CDS/LDS/RDS/EDS); istiod pushes config via xDS
• STALE — sidecar has not yet acknowledged the latest config version from istiod
3 / 24
An engineer reports: "Service A is getting connection reset errors when calling service B. Both have sidecars. The error says upstream connect error or disconnect/reset before headers. reset reason: connection failure." What is the most likely cause in a mesh context?
The 'connection failure' reset reason in Istio commonly signals an mTLS handshake failure — a TLS configuration mismatch between the two sidecars.
The most common cause: a DestinationRule with TLS mode DISABLE (or ISTIO_MUTUAL disabled) on the destination, while the destination's PeerAuthentication is STRICT (requires mTLS). The source sidecar sends plain text; the destination sidecar's PeerAuthentication rejects it — connection reset. The fix: ensure DestinationRule TLS mode is ISTIO_MUTUAL for all services where mTLS PeerAuthentication is STRICT. Diagnose with: istioctl authn tls-check <pod> <service>, which shows the effective TLS configuration for a service-to-service connection and highlights conflicts.
Key vocabulary:
• connection failure (reset reason) — Envoy's description of a TLS or connection-level error before HTTP headers were received
• TLS mode conflict — DestinationRule says DISABLE while PeerAuthentication requires STRICT; causes connection reset
• istioctl authn tls-check — diagnoses the effective mTLS configuration between two services
The most common cause: a DestinationRule with TLS mode DISABLE (or ISTIO_MUTUAL disabled) on the destination, while the destination's PeerAuthentication is STRICT (requires mTLS). The source sidecar sends plain text; the destination sidecar's PeerAuthentication rejects it — connection reset. The fix: ensure DestinationRule TLS mode is ISTIO_MUTUAL for all services where mTLS PeerAuthentication is STRICT. Diagnose with: istioctl authn tls-check <pod> <service>, which shows the effective TLS configuration for a service-to-service connection and highlights conflicts.
Key vocabulary:
• connection failure (reset reason) — Envoy's description of a TLS or connection-level error before HTTP headers were received
• TLS mode conflict — DestinationRule says DISABLE while PeerAuthentication requires STRICT; causes connection reset
• istioctl authn tls-check — diagnoses the effective mTLS configuration between two services
4 / 24
A team is performing an Istio control plane upgrade. They describe their approach as "canary upgrade." What does this mean in the context of Istio upgrades?
Istio canary upgrades use the revision feature — run two control planes simultaneously and migrate namespaces gradually, avoiding the risk of a big-bang upgrade.
The process: (1) install new Istio control plane with a revision label (e.g., istio.io/rev=1-21); (2) tag a test namespace with istio.io/rev=1-21 (instead of istio-injection=enabled); pods in this namespace get sidecars from the new control plane; (3) validate the new version with real traffic; (4) gradually update more namespaces to the new revision; (5) once all namespaces are on the new revision, uninstall the old control plane. If issues are found at any step, simply revert the namespace label — the old control plane is still running.
Key vocabulary:
• revision (Istio) — a named instance of the Istio control plane; enables running multiple versions simultaneously
• istio.io/rev label — pod/namespace label specifying which control plane revision provides sidecar injection
• canary control plane upgrade — migrating namespaces incrementally between old and new control plane revisions
The process: (1) install new Istio control plane with a revision label (e.g., istio.io/rev=1-21); (2) tag a test namespace with istio.io/rev=1-21 (instead of istio-injection=enabled); pods in this namespace get sidecars from the new control plane; (3) validate the new version with real traffic; (4) gradually update more namespaces to the new revision; (5) once all namespaces are on the new revision, uninstall the old control plane. If issues are found at any step, simply revert the namespace label — the old control plane is still running.
Key vocabulary:
• revision (Istio) — a named instance of the Istio control plane; enables running multiple versions simultaneously
• istio.io/rev label — pod/namespace label specifying which control plane revision provides sidecar injection
• canary control plane upgrade — migrating namespaces incrementally between old and new control plane revisions
5 / 24
You need to debug why service A's requests to service B are being routed to the wrong backend. You want to inspect the actual Envoy routing configuration on service A's sidecar. Which command provides this?
istioctl proxy-config route is the definitive tool for seeing what routing rules are actually active in an Envoy sidecar — as opposed to what Istio resources say should be active.
The difference between "what Istio says" and "what Envoy has" is crucial for debugging. An Istio VirtualService may be valid YAML but produce unexpected Envoy config due to subtle ordering or precedence issues. The proxy-config subcommands (listeners, clusters, routes, endpoints) dump the raw xDS state in the sidecar. For routing problems: istioctl proxy-config route <pod> lists virtual hosts and route tables; --name <hostname> filters to a specific service. Compare the actual route weights/subsets to your VirtualService spec to find discrepancies.
Key vocabulary:
• istioctl proxy-config route — dumps Envoy's Route Discovery Service (RDS) config for a specific pod's sidecar
• proxy-config subcommands — listeners / clusters / routes / endpoints; each dumps a different xDS config layer
• RDS (Route Discovery Service) — xDS component delivering HTTP route tables to Envoy
The difference between "what Istio says" and "what Envoy has" is crucial for debugging. An Istio VirtualService may be valid YAML but produce unexpected Envoy config due to subtle ordering or precedence issues. The proxy-config subcommands (listeners, clusters, routes, endpoints) dump the raw xDS state in the sidecar. For routing problems: istioctl proxy-config route <pod> lists virtual hosts and route tables; --name <hostname> filters to a specific service. Compare the actual route weights/subsets to your VirtualService spec to find discrepancies.
Key vocabulary:
• istioctl proxy-config route — dumps Envoy's Route Discovery Service (RDS) config for a specific pod's sidecar
• proxy-config subcommands — listeners / clusters / routes / endpoints; each dumps a different xDS config layer
• RDS (Route Discovery Service) — xDS component delivering HTTP route tables to Envoy
6 / 24
You're troubleshooting a service mesh where requests to Service X are intermittently failing with a `503 Service Unavailable` error. You've checked the service itself and confirmed it's healthy. Using Istioctl, you observe that traffic to Service X is being dropped by the Envoy proxy in the sidecar. What is the *most* likely reason for this behavior?
Envoy proxies in service meshes can implement circuit breaking to prevent cascading failures. Incorrectly configured limits on concurrent connections will cause Envoy to aggressively drop traffic when it perceives overload, leading to 503 errors for Service X. A network issue would likely manifest as timeouts or other connectivity problems, not just dropped requests. Configuring a faulty circuit breaker setting would similarly lead to premature traffic drops.
7 / 24
During an Istio upgrade, you notice that some pods are still running the old version of the control plane. The logs show a message: 'Control Plane Version Mismatch Detected'. What is the *primary* reason for this issue and what action should you take?
Istio deployments often utilize rolling updates for the control plane. If a significant delay occurs between deployment and pod update, or if network issues prevent synchronization, old versions can remain running until Kubernetes automatically restarts them. A corrupted etcd would cause more widespread issues than just control plane version mismatch. Misconfiguration is possible but less likely than delays during rollout.
8 / 24
A team is implementing an Istio canary upgrade for Service C. They are using a 10% traffic split between the new version and the existing version. After monitoring, they observe increased latency in the canary deployment. What should be the *first* step to diagnose this issue?
Canary deployments are designed to detect issues early. Increasing the split too quickly can mask problems and make diagnosis difficult. Examining Envoy logs provides detailed insights into how the new version is behaving under load – latency spikes, errors, or resource contention are key indicators. Rolling back immediately without investigation would be premature.
9 / 24
You need to troubleshoot why requests from your application to Service D are being routed through a different backend than intended. You want to examine the Envoy sidecar proxy configuration for Service D to understand how traffic is being directed. Which Istio command would be most helpful in achieving this?
The
istioctl proxy-config route -o json command specifically extracts the Envoy routing configuration from a pod's sidecar. This provides a detailed JSON representation of the rules that are determining traffic flow. While other commands can provide information about Istio, this is the most direct way to inspect the core routing logic within the Envoy proxy.10 / 24
You're debugging an issue where requests to Service Z are intermittently failing with a '502 Bad Gateway' error. The service itself appears healthy and there aren't any obvious application-level errors. After examining the Istio sidecar logs, you find repeated messages indicating that the upstream service is unavailable. What is the most likely cause of this behavior?
Transient network issues are common causes of '502 Bad Gateway' errors. The fact that the service itself appears healthy suggests a temporary connectivity problem on the backend. Options B, C and D represent other potential problems but not the most likely scenario given the initial symptom.
11 / 24
A developer reports that they're unable to deploy a new version of Service A using GitOps. The deployment fails with an error related to 'resource conflict'. After investigating, you discover that Istio is automatically scaling the number of replicas for Service A based on observed traffic patterns. What does this behavior illustrate about Istio's operational characteristics?
Istio's auto-scaling functionality, while beneficial for performance, can inadvertently create resource conflicts when deployed alongside GitOps. This highlights the need for careful coordination between these two systems to avoid unexpected behavior – especially in environments where scaling is dynamic.
12 / 24
You're troubleshooting a service mesh where requests to Service X are experiencing high latency. You've verified that the service itself isn't overloaded and there aren't any network issues between the client and Service X. After using Istioctl proxy-status, you notice that several proxies associated with Service X have a 'busy' status. What is the most probable reason for this observed behavior?
'Busy' proxies in Istio indicate that the control plane is actively managing traffic for those instances. This increased load can lead to latency as the proxies spend more time processing requests and making routing decisions – this is a common symptom of an overloaded control plane.
13 / 24
You need to diagnose intermittent connection errors between Service A and Service B within your service mesh. The error messages consistently point to 'upstream connect error' during the initial handshake. You examine the Envoy sidecars for both services and find that they are successfully establishing TCP connections with each other, but the application layer communication is failing intermittently. What should you investigate *first*?
Intermittent connection errors at the application layer often stem from issues with health checks. If the Envoy sidecars aren't correctly detecting that Service B is healthy, they won't forward traffic, leading to a 'connect error' – this is the most direct cause given the symptoms.
14 / 24
Alex: "I'm seeing a lot of `503 Service Unavailable` errors coming from my application to Service E. I've checked the service itself and it appears healthy. The mesh seems stable overall, but these intermittent failures are really impacting our users. What is the most likely reason for this, considering we're using Istio?", Insufficient: The Envoy proxy manages traffic routing; resource exhaustion within the proxy is a frequent cause of
503 errors. Istio configuration issues are less likely if the mesh appears stable overall. Transient network problems can certainly happen but aren't the primary focus when Istio is involved, and rate limiting by the service itself wouldn't typically manifest as intermittent 503s.15 / 24
You're reviewing a PR that introduces a new feature for
Service F. The PR description includes the following comment: "Implemented canary deployment using Istio traffic splitting to minimize risk during rollout." What does 'canary deployment' mean in this context, specifically related to Istio? Insufficient: A canary deployment involves deploying a controlled subset of traffic (typically a percentage) to the new version of the service. This allows you to monitor its performance and identify issues before exposing it to all users – minimizing risk. The other options represent different deployment strategies that don't align with Istio's capabilities or the core concept of canary testing.
16 / 24
Ben (a SRE) reports: "I'm seeing intermittent `502 Bad Gateway` errors when clients call Service G. The service itself seems healthy, and there are no obvious application-level issues." You use Istioctl to examine the traffic flow and observe that some requests are being routed through a different backend than expected. What's the *most* likely reason for this misrouting? Insufficient: While corrupted proxies or network issues can cause problems, misconfigured traffic management policies (virtual services) within Istio are the most common reason for unexpected routing behavior. The cluster stability issue would manifest in broader Kubernetes problems, not just Istio-specific routing.
17 / 24
Sarah, a developer, reports: "Service H is intermittently returning 503 errors. The service itself seems healthy, and the mesh appears stable according to Istioctl metrics. We've increased its CPU limits, but the issue persists." Considering this scenario, what is the *most likely* reason for these intermittent 503 errors in a service mesh environment?
Transient network connectivity issues are a common cause of 503 errors in service meshes, particularly when Envoy proxies handle high volumes of requests. While CPU limits can contribute, the description explicitly states the service is healthy and has been optimized for resources. Incorrect circuit breaker rules are less likely without specific configuration changes reported. Finally, scheduler issues are rare and wouldn't consistently impact a single service's availability.
18 / 24
During a team meeting discussing troubleshooting an Istio deployment, Mark says: "We need to examine the Envoy configuration on Service I to see which backend it's routing traffic to. We don't want to manually modify the config if possible." Which command would be the *most appropriate* for Mark to use?
The
istioctl proxy-config route -o YAML service_name=ServiceI command allows you to inspect the Envoy routing configuration directly without needing to modify it. This is ideal for understanding the current routing rules. Options B and C provide information about the deployment or pod but don't expose the specific routing details. Option D provides logs, which are useful for debugging application issues, not network routing.19 / 24
You're reviewing a PR that updates an Istio virtual service for Service J. The PR includes the following comment: "This update introduces a new header injection rule to enforce rate limiting based on client IP addresses." What is the *primary* benefit of using a virtual service with header injection in this scenario?
Header injection is a core Istio feature that provides granular control over traffic flow. By modifying HTTP headers (like adding rate limiting rules), you can influence how requests are routed and processed within the service mesh. While virtual services manage routing, header injection goes beyond simple routing to allow for policy enforcement.
20 / 24
Maria is investigating a persistent issue where requests to Service K are consistently timing out. She's using Istioctl to examine the Envoy configurations across multiple instances of Service K and notices that one instance has a misconfigured timeout value set to 5 seconds, while others have a default of 30 seconds. What is the most likely cause of this problem?
Option A: An issue with the underlying network infrastructure between the client and Service K.
Option B: The Envoy configuration mismatch causing premature timeouts on one instance of Service K.
Option C: A bug in the application code that's generating excessively long requests.
Option D: High CPU utilization on the nodes hosting Service K.
Option A: An issue with the underlying network infrastructure between the client and Service K.
Option B: The Envoy configuration mismatch causing premature timeouts on one instance of Service K.
Option C: A bug in the application code that's generating excessively long requests.
Option D: High CPU utilization on the nodes hosting Service K.
The core issue here is misconfiguration within the service mesh. Envoy's timeout settings are critical for handling request failures and preventing indefinite timeouts. A mismatch in these values, as observed by Maria, directly leads to premature timeouts on one instance of Service K, causing the client to time out. Options A, C, and D represent other potential issues but aren't the immediate cause linked to Envoy's configuration.
21 / 24
During a Slack conversation about troubleshooting intermittent errors with Service L, David says: "I'm seeing `503` errors when users try to access the dashboard. The service itself seems responsive, and I've checked for resource exhaustion. Could it be related to Istio's traffic shaping rules?" What action should he *immediately* take to investigate this further?
Option A: Immediately scale up the resources allocated to Service L.
Option B: Examine the Istio virtual service configuration for Service L, specifically focusing on any traffic shaping or rate limiting policies.
Option C: Run a full diagnostic test of the application code running within Service L.
Option D: Contact the network team to investigate potential network latency issues.
Option A: Immediately scale up the resources allocated to Service L.
Option B: Examine the Istio virtual service configuration for Service L, specifically focusing on any traffic shaping or rate limiting policies.
Option C: Run a full diagnostic test of the application code running within Service L.
Option D: Contact the network team to investigate potential network latency issues.
David's observation about traffic shaping rules is highly relevant. Istio's virtual services can enforce rate limiting or other traffic shaping policies that, if misconfigured, could lead to `503` errors when Service L receives requests exceeding those limits. Examining the virtual service configuration is the most direct way to determine if this is the root cause. Scaling resources (A) and running diagnostic tests (C) are less targeted initial steps.
22 / 24
You're reviewing a pull request that updates the Istio gateway configuration for Service M. The PR description states: 'This change implements a new policy to enforce TLS mutual authentication on all connections to Service M.' After applying the changes, you receive an error message in your logs stating: 'Control Plane Version Mismatch Detected'. What is the *most* likely reason for this?
Option A: The Istio operator failed to deploy the updated gateway configuration correctly.
Option B: The service mesh control plane hasn't fully synchronized with the new gateway configuration, leading to a version mismatch.
Option C: A bug in the application code is causing it to reject TLS mutual authentication requests.
Option D: The network infrastructure between Service M and the Istio gateway has experienced significant latency.
Option A: The Istio operator failed to deploy the updated gateway configuration correctly.
Option B: The service mesh control plane hasn't fully synchronized with the new gateway configuration, leading to a version mismatch.
Option C: A bug in the application code is causing it to reject TLS mutual authentication requests.
Option D: The network infrastructure between Service M and the Istio gateway has experienced significant latency.
Version mismatches in service meshes often occur due to synchronization delays. The control plane needs time to propagate changes made to the gateway configuration. While other options could cause errors, a version mismatch is the most common and direct consequence of applying new configurations without proper synchronization. The network latency (D) might *exacerbate* the problem but isn't the primary root cause.
23 / 24
During a standup meeting, John reports: "We're seeing intermittent `502 Bad Gateway` errors when clients access Service N. The service itself seems healthy, and there are no obvious application-level issues. We've increased the backend timeout to 60 seconds, but it hasn't resolved the problem." What immediate next step should the team take to investigate further?
Option A: Conduct a thorough code review of Service N's application logic.
Option B: Examine the Istio Envoy configuration for Service N, specifically focusing on upstream timeouts and health check settings.
Option C: Monitor the network latency between the client and Service N using tools like `ping` or `traceroute`.
Option D: Increase the overall resource limits (CPU/Memory) of the nodes hosting Service N.
Option A: Conduct a thorough code review of Service N's application logic.
Option B: Examine the Istio Envoy configuration for Service N, specifically focusing on upstream timeouts and health check settings.
Option C: Monitor the network latency between the client and Service N using tools like `ping` or `traceroute`.
Option D: Increase the overall resource limits (CPU/Memory) of the nodes hosting Service N.
The team's response to a `502` error often starts with examining Envoy configurations. Envoy is responsible for handling upstream connectivity and timeouts. Increasing the backend timeout (John's action) only addresses the symptom; the *real* cause might be an incorrect or overly aggressive timeout setting within Envoy itself, or a misconfigured health check that's prematurely marking the upstream service as unhealthy. Code review (A), network monitoring (C), and resource scaling (D) are all secondary investigations.
24 / 24
You're reviewing a pull request to update the Istio virtual service for Service O. The PR includes the following comment: 'This update enables HTTP/3 support and TLS session resumption to improve performance.' After deploying this change, you observe increased latency in requests to Service O. What is the *most* likely explanation?
Option A: The new TLS session resumption mechanism introduced a bug that's causing excessive overhead.
Option B: The network infrastructure between the client and Service O has become congested due to the increased traffic volume.
Option C: Istio's automatic circuit breaking rules are incorrectly identifying healthy requests as failures, leading to unnecessary retries.
Option D: The introduction of HTTP/3 is inherently more complex than HTTP/1.1 and causing performance degradation.
Option A: The new TLS session resumption mechanism introduced a bug that's causing excessive overhead.
Option B: The network infrastructure between the client and Service O has become congested due to the increased traffic volume.
Option C: Istio's automatic circuit breaking rules are incorrectly identifying healthy requests as failures, leading to unnecessary retries.
Option D: The introduction of HTTP/3 is inherently more complex than HTTP/1.1 and causing performance degradation.
While all options could *potentially* contribute to increased latency, the introduction of a new feature like HTTP/3 or TLS session resumption is often the most direct cause. These features are complex and can introduce subtle bugs or overhead that aren't immediately obvious. Congestion (B), circuit breaking (C) and inherent complexity (D) represent possible contributing factors but aren't as directly linked to the immediate performance impact of deploying the new feature.
Frequently Asked Questions
What will I learn from the "Mesh Operations and Troubleshooting Language — Service Mesh Operations | CoderLingo" exercise?
5 exercises practising istioctl commands, sidecar injection debugging, mTLS handshake failures, and mesh upgrade vocabulary.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall required.
How many questions are in this exercise?
This set contains 24 multiple-choice questions, each with a detailed explanation shown after you answer.
Do I need to create an account to track my progress?
No account is required. Your progress bar and score reset each time you reload the page, but you can retry the exercise as many times as you like.
Who is this Service Mesh Operations Language exercise for?
This exercise is built for IT professionals and non-native English speakers who need to read, write, and discuss service mesh operations language topics confidently at work.
What happens if I answer a question incorrectly?
You will see the correct answer highlighted along with a detailed explanation of why it is correct -- so every wrong answer becomes a learning moment, not just a lost point.
Can I retry this exercise?
Yes -- click "Try again" on the results screen at any time to reset your score and go through all the questions again.
How long does this exercise take to complete?
Most learners finish all 24 questions in under 10 minutes, since each question is answered by clicking a single option.
Where can I find more Service Mesh Operations Language exercises?
See the full Service Mesh Operations Language exercises hub for more vocabulary drills on this topic.
Is this exercise mobile-friendly?
Yes -- the exercise works on any device with a modern browser, including phones and tablets, with no app download required.