Tigera: The Ticket Says "Can't Reach the Database": Troubleshooting VM and Pod Traffic with Evidence
The app team says the payment service can’t reach the database. That’s the whole ticket.
What you have to work with is a flow record: a source address, a destination address, a port, and a verdict. What you’ve been asked about is workloads — which service, which VM, which policy allowed or denied it — and a pair of addresses doesn’t answer that. One of them belongs to a pod that has been rescheduled twice since the record was written.
Meanwhile the four things that could have caused it look identical from the application’s side. A routing failure, a name-resolution failure, a policy denial and an application error all arrive as the same timeout, and the difference between a ten-minute investigation and a lost afternoon is knowing which to rule out first.
This session works one connectivity failure backwards: from the service graph, into the flow record that names the policy that made the decision, through DNS and L7, and down to packet capture only when the bytes are genuinely the question. You leave with a sequence you can run under pressure, not a tour of a UI.
What you will learn: The Map and the Close-Up — Which question you’re actually asking: service graph and flow logs for what is talking to what, flow record and packet capture for why one connection failed. A Dependency Map Built From Traffic That Actually Happened — Not a diagram that was accurate in March, with VMs and pods in one view — including what turns up that nobody knew was talking. Reading a Denied Flow — The fields that turn “denied” into “denied by this rule”: which policy and tier decided, staged or enforced, and the selector that put the workload in scope. The DNS Failure That Looks Exactly Like a Network Failure — Resolution failures reach the application as connection timeouts, which is how they eat an afternoon. How DNS logs separate the two in seconds. When the Connection Succeeds and the Application Still Fails — Methods and status codes for when the network did its job and the transaction broke anyway, and the point where packet capture becomes the right tool. One Broken Transaction, Worked Backwards — Graph, flow record, DNS, L7, in order, and the decision at each step about where to look next, written down so anyone can run it. Who should attend:- Network and security engineers who run Flow Visibility and Traceflow daily and want to know precisely what replaces each, before they are on the hook for a cluster.
- Platform engineers on call for applications made of both VMs and pods, who need a repeatable way to separate a routing failure from a policy failure from a DNS failure.
- Security engineers who have to produce evidence that a policy is doing what it claims, that a flow was denied or that a dependency exists for an auditor who will not accept a screenshot of a dashboard.
Join us to work a failed VM-to-service transaction from symptom to cause, using flow, DNS and L7 evidence that carries workload identity rather than just addresses and to leave with the troubleshooting sequences you can use in your own cluster. An educational session on the mechanics, not a product pitch. Bring your questions!