10 Troubleshooting the data plane

 

This chapter covers

  • Troubleshooting a misconfigured workload
  • Detecting and preventing misconfigurations using istioctl and Kiali
  • Using istioctl to investigate the service proxy configuration
  • Making sense of Envoy logs
  • Using telemetry to gain insights into apps

When communicating over the network, many things can go wrong, as we’ve demonstrated throughout this book. A major reason why Istio exists is to help shine a light on network communication when things go wrong and put in place remediation capabilities like timeouts, retries, and circuit breaking so that applications can automatically respond to network issues. The service proxy gives us a very detailed view of what’s happening on the network, but what happens when the proxy itself behaves unexpectedly?

Figure 10.1 shows the components that participate in serving a request:

  • istiod, which ensures that the data plane is synchronized to the desired state
  • The ingress gateway that admits traffic into the cluster
  • The service proxy that provides access control and handles traffic from downstream to the local application
  • The application itself, which serves the request and may request another service that continues the chain to another upstream service, and so on
Figure 10.1 Components that participate in routing a request
CH10_F01_Posta2

10.1 The most common mistake: A misconfigured data plane

10.2 Identifying data-plane issues

10.2.1 How to verify that the data plane is up to date

10.2.2 Discovering misconfigurations with Kiali

10.2.3 Discovering misconfigurations with istioctl

10.3 Discovering misconfigurations manually from the Envoy config

10.3.1 Envoy administration interface

10.3.2 Querying proxy configurations using istioctl

10.3.3 Troubleshooting application issues