Private, instructor-led training for platform engineers who already operate an Istio mesh and need to explain traffic and security behavior across cluster boundaries.
Applying mesh configuration does not prove that every proxy uses the intended behavior. Discovery, routing, identity, trust, and authorization can fail at different points in the same request.
LearnKube connects Kubernetes networking to the mesh's control and data planes. Engineers inspect a representative service path and verify the effect of a bounded traffic or policy change.
Hands-on learning and the skills engineers take back to work.
Preview: course-wide figures are not yet available.
The team already configures Istio, but a request depends on the routing and security state available to its proxies. Traffic rules select destinations, while authentication and authorization govern identity and access. Cross-cluster operation adds discovery and trust dependencies. Engineers must inspect the effective path and configuration before concluding that an accepted policy is active everywhere.
I separate a routing decision from an authorization decision before changing either policy. A request sent to the wrong destination can look like a security failure, and loosening access does not repair the intended service path.
— Daniele Polencic, LearnKube founder and Kubernetes instructor
| Production question | Mechanism to understand | Practice |
|---|---|---|
| Which destination is selected? | Routing rules and discovery | Inspect effective proxy configuration |
| Which identity is presented? | Certificates and workload identity | Trace a mutual-TLS request |
| Why is access denied? | Authentication and authorization policy | Compare allowed and denied calls |
| Did every path change? | Configuration distribution and boundaries | Verify both cluster directions |
Bitpanda's platform work includes ownership of cross-cluster Istio, traffic management, network security, and guidance for other engineers. The operating question includes both service behavior and the ability to explain it.
For that responsibility, we recommend a four-day workshop focused on a bounded mesh path, its control mechanisms, and evidence for proposed changes.
Participants need Kubernetes networking foundations. We adapt the existing networking and service-mesh material to the deployment mode and APIs your team actually uses.
Day 1
Connect probes and release behavior to the endpoints available to the mesh. Distinguish application health from proxy readiness and request success.
Hands-on exercises
Day 2
Explain how rendered configuration reaches controllers and proxies. Inspect effective configuration rather than assume that applying a resource completes its propagation.
Hands-on exercises
Day 3
Examine gateways, discovery, identities, trust, and authorization across the chosen cluster boundary. Verify intended and rejected traffic separately.
Hands-on exercises
Day 4
Connect credential lifecycle, connection state, placement, and scaling to mesh behavior. Define stop conditions and the evidence needed to recover from a traffic change.
Hands-on exercises
Your mesh deployment, traffic questions, and platform responsibilities can shape the agenda. Get in touch to tailor the workshop to your team's work.
When an engineer interprets every rejected request as an authorization problem, the instructor can compare its destination and identity first. Feedback from a separate Bloomberg course highlights reusable practical work:
Interactive labs prepared in a way that you can scrap and restart whenever you like, easy to follow instructions.
— Mike, Software Engineer at Bloomberg.
Tell us which Istio deployment and cluster paths you operate, which changes are difficult to validate, and which controls your team owns. We will recommend focused mechanisms and exercises.