Project: Fabric8 Kubernetes Client (App Definition and Development / Application Definition & Image Build)
File: kube-api-test.md

`kube-api-test` makes it easy to implement integration tests with Kubernetes API Server in Java. Inspired by in Kubebuilder (Golang). It runs the API Server binaries directly (without nodes and other components, but with etcd). Linux, Windows, Mac is supported. Include dependency: ```xml <dependency> <groupId>io.fabric8</groupId> <artifactId>kube-api-test</artifactId> <version>[version]</version> <scope>test</scope> </dependency> ``` See sample unit test ```java @EnableKubeAPIServer class JUnitExtensionSimpleCaseTest { // Use @KubeConfig annotation to inject kube config yaml to init any client @KubeConfig static String kubeConfigYaml; @Test void simpleTestWithTargetVersion() { var client = new KubernetesClientBuilder() .withConfig(Config.fromKubeconfig(kubeConfigYaml)) .build(); client.resource(TestUtils.testConfigMap()).create(); var cm = client.resource(TestUtils.testConfigMap()).get(); Assertions.assertThat(cm).isNotNull(); } } ``` The underlying API can be used directly. See See it's . ```java class KubeApiServerTest { @Test void apiServerTest() { var kubeApi = new KubeAPIServer(); kubeApi.start(); var client = new KubernetesClientBuilder() .withConfig(Config.fromKubeconfig(kubeApi.getKubeConfigYaml())) .build(); client.resource(TestUtils.testConfigMap()).create(); var cm = client.resource(TestUtils.testConfigMap()).get(); Assertions.assertThat(cm).isNotNull(); kubeApi.stop(); } } ``` Use dependency: ```xml <dependency> <groupId>io.fabric8</groupId> <artifactId>kube-api-test-client-inject</artifactId> <version>[version]</version> <scope>test</scope> </dependency> ``` The client can be directly injected to the test. See sample test . ```java @EnableKubeAPIServer class JUnitFabric8ClientInjectionTest { static KubernetesClient client; // emitted code } ``` See available configuration options documented in Not all those properties can be overridden using annotation, since might not make sense to do it for an individual test case. However, those can be passed to and also configured globally using environment variables, see In general, it is not advised but if instructed kube config file (~/kube/config) is updated by the framework. See related property in annotation. The config file is automatically cleaned up on stop. In the background Kubernetes and etcd (and kubectl) binaries are downloaded if not found locally. All the certificates for the Kube API Server and for the client is generated. The client certificates are generated with group `system:masters`; Binaries are downloaded automatically under ~/.kubeapitest/k8s/[target-platform-and-version] if no binary found locally. If there are multiple binaries found, the latest if selected (unless a target version is not specified). Also can be used to download binaries manually. By executing `setup-envtest use --bin-dir ~/.kubeapitest` will download the latest required binaries to the default directory. This is useful if always running the tests in offline mode. Parallel test execution is explicitly supported for JUnit5, in fact the project tests are running parallel. Running a new instance for each test case. This speeds up the tests (in our case >75%) in a way that test cases are also fully isolated from each other. Although we experienced stability issues on non-Linux platforms. An additional benefit of running K8S API Server this way, is that it makes easy to test and/or In general, it is a best practice to use additional standard frameworks to implement Kubernetes webhooks, like with Quarkus or Spring. However, we demonstrate how it works in