At the moment, the fake platform server runs natively on the host (where gingko runs), and ktunnel is used to make it accessible from within the K8s cluster. However, the tunnel connection is flaky (on macOS even more so than on native Linux, on macOS there are "connection refused" problems on almost every 2nd suite execution).
While we could solve this by replacing ktunnel with a different solution (e.g. telepresence), an even better solution would be to package the fake platform server as Docker container, deploy it to the cluster, and then expose it to the host (either via NodePort service or via kubectl port-forward). This would require adding more REST routes to the fake platform server, to control it , and implement a thin client layer that calls that REST interface.
At the moment, the fake platform server runs natively on the host (where gingko runs), and ktunnel is used to make it accessible from within the K8s cluster. However, the tunnel connection is flaky (on macOS even more so than on native Linux, on macOS there are "connection refused" problems on almost every 2nd suite execution).
While we could solve this by replacing ktunnel with a different solution (e.g. telepresence), an even better solution would be to package the fake platform server as Docker container, deploy it to the cluster, and then expose it to the host (either via
NodePortservice or viakubectl port-forward). This would require adding more REST routes to the fake platform server, to control it , and implement a thin client layer that calls that REST interface.