github.com/smartcontractkit/chainlink-testing-framework/libs@v0.0.0-20240227141906-ec710b4eb1a3/docs/setup/kubernetes.md (about)

     1  ---
     2  layout: default
     3  title: Kubernetes
     4  nav_order: 1
     5  parent: Setup
     6  ---
     7  
     8  # Kubernetes Setup
     9  
    10  In order to use this framework, you must have a connection to an actively running [Kubernetes cluster](https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster/) and an install of [kubectl](https://kubernetes.io/releases/download/). If you don't have a Kubernetes cluster handy, check out our quickstart guide on setting up a [local cluster](https://smartcontractkit.github.io/integrations-framework/quickstart/local-k8s-setup.html#local-kubernetes-cluster) which should work fine for smaller tests. Larger tests, or many tests run in parallel will likely render these local solutions inadequate. A Kubernetes cluster with 4 vCPU and 10 GB RAM is a good starting point.
    11  
    12  **The framework will use whatever your current KUBECONFIG context is**, see how to set a context [here](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/). Learn more about setting up a Kubernetes cluster [here](https://kubernetes.io/docs/setup/). Once you have the cluster setup and are running tests, you can monitor the test architecture with the [kubectl](https://kubernetes.io/docs/reference/kubectl/kubectl/) CLI, or check out [Lens](https://k8slens.dev/) for a handy GUI.
    13  
    14  ## Why?
    15  
    16  There's a lot of different components to bring up for each test, most of which involve:
    17  
    18  * A simulated blockchain
    19  * Some number of Chainlink nodes
    20  * An equal number of postgres DBs to support the Chainlink nodes
    21  * At least one external adapter
    22  
    23  Following the good testing practice of having clean, non-dependent test environments means we're creating a lot of these components for each test, and tearing them down soon after. In order to organize these test environments, and after finding `docker compose` to be woefully inadequate after a certain point, Kubernetes was the obvious choice.
    24  
    25  <div class="note note-purple">
    26  The Kubernetes setup process, and the resources needed to run a K8s cluster for these tests is a common pain point. We're exploring ways to lessen the resources needed, and possibly expand to other systems as well as Kubernetes.
    27  </div>