Complexity of Kubernetes Networking for Debugging

“Show HN: Mock Service Dependencies in K8s Clusters, No K8s Experience Required Hi HN! I’m Mia, a product manager&#x2F;engineer at Skyramp (<a href="http:&#x2F;&#x2F;www.skyramp.dev" rel="nofollow">http:&#x2F;&#x2F;www.skyramp.dev</a>) building tools that make it easy to test microservices in-cluster.<p>As a team of engineers with experience building cloud-native solutions at both startups and big co’s like VMWare, we are deeply aware of how frustrating it can be for devs to test their microservices in-cluster. One of the problems that has come up consistently as we have talked to developers is that of mocking service dependencies in a cluster. We narrowed down the problem to two use cases:<p>Case 1: A company partners with third party service providers to get data (for example, market data for a fintech company) and has to deal with test versions of those third-party services in their pipelines. The SLAs for these “Test Nets” are non-existent and result in flaky tests. In addition to the flakiness, devs cannot rely on these test networks when they have to run load tests. In each case, there is some amount of work involved in mocking out the dependency so the work never gets done.<p>Case 2: If a developer (particularly someone working with gRPC) wants to isolate their microservice for debugging an issue in-cluster, they will need to work with Kubernetes networking (fun for some of us, not for others :) ) and then deal with tons of boilerplate code to get it working.<p>We figured that we would start small and reduce the toil in getting in-cluster mocks going, so we created Mocker - an in-cluster mock server for gRPC and REST.<p>You can use Mocker either via the CLI or as a VSCode extension (<a href="https:&#x2F;&#x2F;marketplace.visualstudio.com&#x2F;items?itemName=skyramp.mocker-vscode" rel="nofollow">https:&#x2F;&#x2F;marketplace.visualstudio.com&#x2F;items?itemName=skyramp....</a>). These clients rely on our Worker that is deployed in your cluster via Helm. You can create mock configurations by simply pointing Mocker to your OpenAPI spec or your .proto files. These configurations are pushed to Worker which takes care of the networking inside the cluster to seamlessly help you switch between the mock and live versions of your dependency.<p>We’ve also built an OpenAI integration which can help you generate realistic mock data so you’ve got one less thing to worry about.<p>To sum it up, here is what you can do with Mocker:<p>1. Automatically create mock configurations: Simply point Mocker to the API file and get going!<p>2. Turnkey Mock Values: Mocker auto generates mock values that you can edit as needed. The CLI version has support for OpenAI generated mock values.<p>3. Complex mocks via Javascript support: Simulate dynamic mock responses for complex test cases by pointing to a Javascript file with the behavior.<p>4. gRPC Proxy: For gRPC services, Mocker acts as a proxy that allows you to selectively mock a subset of the methods in an endpoint, while directing others to the live service in your cluster.<p>5. VSCode Extension for a streamlined UI based experience designed to keep you in your workflow.<p>6. Coming soon: Out of the box support for generating latencies and error codes for testing failure cases.<p>We still have a lot of work ahead of us but would be grateful for any feedback or suggestions.<p>If you want to follow our journey and see what else we are up to, sign up here: <a href="https:&#x2F;&#x2F;www.skyramp.dev" rel="nofollow">https:&#x2F;&#x2F;www.skyramp.dev</a>.<p>Thanks, Mia”