1. Optional. If the Kubernetes cluster with the Codefresh Runner is behind a proxy,continue with [Complete Codefresh Runner installation](#complete-codefresh-runner-installation).

<!--- what is this -->

For reference, have a look at the repository with the chart: [https://github.com/codefresh-io/venona/tree/release-1.0/.deploy/cf-runtime](https://github.com/codefresh-io/venona/tree/release-1.0/.deploy/cf-runtime).

For reference, have a look at the repository with the chart: [https://github.com/codefresh-io/venona/tree/release-1.0/.deploy/cf-runtime](https://github.com/codefresh-io/venona/tree/release-1.0/.deploy/cf-runtime){:target="\_blank"}.

For Codefresh Runners on [EKS](https://aws.amazon.com/eks/){:target=\_blank"} or any other custom cluster in Amazon, such as kops for example, configure the Runner to work with EBS volumes to support [caching]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipeline-caching/) during pipeline execution.

For Codefresh Runners on [EKS](https://aws.amazon.com/eks/){:target="\_blank"} or any other custom clusterin Amazon, such as kopsfor example, configure the Runner to work with EBS volumes to support [caching]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipeline-caching/) during pipeline execution.

> The configuration assumes that you have installed the Runner with the default options:`codefresh runner init`

There are three optionsfor this:

1. Run`dind-volume-provisioner` pod on the node/node-group with IAM role

1. Mount K8s secretin [AWS credential format](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html){:target="\_blank"}:

To~/.aws/credentials

OR

By passing the`AWS_ACCESS_KEY_ID` and`AWS_SECRET_ACCESS_KEY` as environment variables to the`dind-volume-provisioner` pod

1. Use [AWS identityfor Service Account](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html){:target="\_blank"} IAM role assigned to`volume-provisioner-runner` service account

**Minimal policyfor`dind-volume-provisioner`**

* Select the runtime you just added, and get its YAML representation:

**Step 4:** Modify the YAML:

* In`dockerDaemonScheduler.cluster`, add`nodeSelector: topology.kubernetes.io/zone:<your_az_here>`.

> Make sure you define the same AZ you selectedfor Runtime Configuration.

* Modify`pvcs.dind` to use the Storage Class you created above (`dind-ebs`).

Here is an example of the`runtime.yaml` including the required updates:

Configure the Codefresh Runner to uselocal SSDsfor your pipeline volumes:

[How-to: Configuring an existing Runtime Environment with Local SSDs (GKE only)](https://support.codefresh.io/hc/en-us/articles/360016652920-How-to-Configuring-an-existing-Runtime-Environment-with-Local-SSDs-GKE-only-){:target="\_blank"}

<br />

1. Run`dind-volume-provisioner-runner` pod on a node with an IAM role which can create/delete/get GCE disks

1. Create Google Service Account with`ComputeEngine.StorageAdmin` role, download its keyin JSON format, and pass it to`codefresh runner init` with`--set-file=Storage.GooogleServiceAccount=/path/to/google-service-account.json`

1. Use [Google Workload Identity](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity){:target="\_blank"} to assign IAM role to`volume-provisioner-runner` service account

Notice that builds runin a single Availability Zone (AZ), so you must specify Availability Zone parameters.

**Configuration**

[How-to: Configuring an existing Runtime Environment with GCE disks](https://support.codefresh.io/hc/en-us/articles/360016652900-How-to-Configuring-an-existing-Runtime-Environment-with-GCE-disks){:target="\_blank"}

<br />

You can configure your Codefresh Runner to use an internal registry as a mirrorforany container images that are specifiedin your pipelines.

1. Set up an internal registry as describedin [https://docs.docker.com/registry/recipes/mirror/](https://docs.docker.com/registry/recipes/mirror/){:target="\_blank"}.

1. Locate the`codefresh-dind-config` config mapin the namespace that houses the Runner.

For the storage options needed by the`dind` pod, we suggest:

* [Local Volumes](https://kubernetes.io/docs/concepts/storage/volumes/#local){:target="\_blank"} `/var/lib/codefresh/dind-volumes` on the K8S nodes filesystem (**default**)

* [EBS](https://aws.amazon.com/ebs/){:target="\_blank"} in the case of AWS. See also the [notes](#installing-on-aws) about getting caching working.

* [Local SSD](https://cloud.google.com/kubernetes-engine/docs/how-to/persistent-volumes/local-ssd){:target="\_blank"} or [GCE Disks](https://cloud.google.com/compute/docs/disks#pdspecs){:target="\_blank"} in the case of GCP. See [notes](#installing-on-google-kubernetes-engine) about configuration.

* [EBS](https://aws.amazon.com/ebs/){:target="\_blank"}in thecase of AWS. See also the [notes](#aws-backend-volume-configuration) about getting caching working.

* [Local SSD](https://cloud.google.com/kubernetes-engine/docs/how-to/persistent-volumes/local-ssd){:target="\_blank"} or [GCE Disks](https://cloud.google.com/compute/docs/disks#pdspecs){:target="\_blank"}in thecase of GCP. See [notes](#gke-google-kubernetes-engine-backend-volume-configuration) about configuration.

**Networking Requirements**

*`dind`: Pod creates an internal networkin the cluster to run all the pipeline steps; needs outgoing/egress access to Docker Hub and`quay.io`.

*`runner`: Pod needs outgoing/egress access to`g.codefresh.io`; needs network access to [app-proxy](#app-proxy-installation) if installed.

*`engine`: Pod needs outgoing/egress access to`g.codefresh.io`,`*.firebaseio.com` and`quay.io`; needs network access to`dind` pod

All CNI providers/plugins are compatible with the runner components.

Codefresh pipelines require disk space for:

* [Pipeline Shared Volume]({{site.baseurl}}/docs/example-catalog/ci-examples/shared-volumes-between-builds/) (`/codefresh/volume`, implemented as [docker volume](https://docs.docker.com/storage/volumes/){:target="\_blank"})

* [Pipeline Shared Volume]({{site.baseurl}}/docs/yaml-examples/examples/shared-volumes-between-builds/) (`/codefresh/volume`, implemented as [docker volume](https://docs.docker.com/storage/volumes/){:target="\_blank"})

* Docker containers, both running and stopped

* Docker images and cached layers

**Where it runs:** On Runtime Cluster as CronJob

(`kubectl get cronjobs -n codefresh -l app=dind-volume-cleanup`). Installedincase the Runner uses non-local volumes (`Storage.Backend!= local`)

**Triggered by:** CronJob every 10min (configurable), part of [runtime-cluster-monitor](https://github.com/codefresh-io/runtime-cluster-monitor/blob/master/charts/cf-monitoring/templates/dind-volume-cleanup.yaml){:target="\_blank"} and runner deployment

**Configuration:**

4. Volume Provisioner listensfor PVC events (create) and based on StorageClass definition it creates PV object with the corresponding underlying volume backend (ebs/gcedisk/local).

5. During the build, each step (clone/build/push/freestyle/composition) is represented as docker container inside dind (docker-in-docker) pod. Shared Volume (`/codefresh/volume`) is represented as docker volume and mounted to every step (docker containers). PV mount point inside dind pod is`/var/lib/docker`.

6. Engine pod controls dind pod. It deserializes pipeline yaml to docker API calls, terminates dind after build has been finished or per user request (sigterm).

7.`dind-lv-monitor` DaemonSet OR`dind-volume-cleanup` CronJob are part of [runtime cleaners](#types-of-runtime-cleaners), `app-proxy` Deployment and Ingress are described in the [App-Proxy installation](#app-proxy-installation), `monitor` Deployment is for [Kubernetes Dashboard]({{site.baseurl}}/docs/deploy-to-kubernetes/manage-kubernetes/).

App-Proxy requires a Kubernetes cluster:

1. With the Codefresh Runner installed<!--- is this correct? -->

1. With an active [ingress controller](https://kubernetes.io/docs/concepts/services-networking/ingress/){:target="\_blank"}

1. With an active [ingress controller](https://kubernetes.io/docs/concepts/services-networking/ingress/){:target="\_blank"}.

The ingress controller must allow incoming connections from the VPC/VPN where users are browsing the Codefresh UI.

The ingress connection**must** have a hostname assignedfor this route, and**must** be configured to perform SSL termination.

Because we used IAM AddonPolicies`"autoScaler: true"`in the`cluster.yaml` file, everything isdone automatically, and there is no need to create a separate IAM policy or add Auto Scaling group tags.

* Deploy the cluster autoscaler:

{:start="2"}

* Add the`cluster-autoscaler.kubernetes.io/safe-to-evict` annotation:

* Edit the`cluster-autoscaler` container command:

* Do the following asin the example below:

* Replace`<YOUR CLUSTER NAME>` with the name of the cluster`cluster.yaml`

* Add the following options:

* Set the autoscaler version:

If the version of the EKS cluster 1.15, the corresponding autoscaler version according to [https://github.com/kubernetes/autoscaler/releases](https://github.com/kubernetes/autoscaler/releases){:target="\_blank"} is 1.15.6.

1. Install the Runner with additional options:

* Specify the zonein which to create your volumes,for example:`--set-value=Storage.AvailabilityZone=us-west-2a`.

* (Optional) To assign the volume-provisioner to a specific node,for example, a specific node group with an IAM role that can create EBS volumes,`--set-value Storage.VolumeProvisioner.NodeSelector=node-type=addons`.

{:start="3"}

1. When the Wizard completes the installation, modify the runtime environment of`my-aws-runner` to specify the necessary toleration, nodeSelector and disk size:

* Run:

* Modify the file`my-runtime.yml` as shown below:

codefresh runner init --set-value Storage.Backend=azuredisk --set Storage.VolumeProvisioner.MountAzureJson=true

Storage:

Backend: azuredisk

```shell

codefresh runner init --values values-example.yaml

storage: