**NOTE:** K8s deployment has a dependency on the node’s IP address.
From our experience, it is strongly recommended to ensure that your platform always gets the same IP address for the main interface when it reboots. It also makes usage of the platform easier since it will reside at a well-known IP on your network.
Depending on your network setup, this can be achieved either by setting a static IP address on the host or configuring the DHCP server to always give the same IP address to your platform.
### STEP 1 - Verify pre-requisites
```bash
# Disable swap
sudo swapoff -a
sudo sed-i'/ swap / s/^/#/' /etc/fstab
```
### STEP 2 - Setup container runtime
Containerd is used as the k8s container runtime.
**NOTE:** Containerd was installed during Docker installation.
To install the container runtime prerequisites:
```bash
cat<<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF
sudo modprobe overlay
sudo modprobe br_netfilter
# sysctl params required by setup, params persist across reboots
cat<<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward = 1
EOF
# Apply sysctl params without reboot
sudo sysctl --system
```
To configure containerd:
```bash
# configure containerd
sudo mkdir-p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml
Each node (master & worker) must be able to access the docker registry where container images are stored. By default, we install and use a private cluster registry. To enable access to the registry, run the following commands on each node:
```bash
# Add the internal docker registry to the host file
# Note: Please check that all Helm v2 plugins that you have installed previously, work fine with the Helm v3, and remove the plugins that do not work with v3.
```
**STEP 5 - Migrate Helm v2 configurations**
```bash
helm 2to3 move config
helm repo list
# This will show all the repositories you had added for Helm v2
```
**Optional Step - Clean up of Helm v2 data and releases**
```bash
helm 2to3 cleanup
# It will clean configurations (helm v2 home directory), remove tiller and delete v2 release data. It will not be possible to restore them if you haven't made a backup of the releases. Helm v2 will not be usable afterwards.
```
## GPU Support
### NVIDIA
In order for Kubernetes to be aware of available GPU resources on its nodes, each host with a GPU must install the necessary drivers. The NVIDIA GPU Operator must also be installed in order to configure, install & validate all other components required to enable GPUs on k8s, such as the NVIDIA container runtime, device plugin & CUDA toolkit. More information can be found in this blog post.
How we do it:
#### STEP 1 - Install NVIDIA drivers
Determine which NVIDIA GPU hardware is installed on your setup using the command `lspci | grep NVIDIA` and find the recommended driver version for your GPU by searching the NVIDIA driver download page.
The NVIDIA GPU Operator configures, installs and validates the NVIDIA container runtime, device plugin & CUDA toolkit required to support GPUs within k8s containers. We use the NVIDIA method documented here.
**NOTE:** This procedure will take some time during first installation.
#### STEP 3 - Deploy a scenario requiring GPU resources
This can be done via MEC Sandbox frontend scenario configuration by selecting the number of requested GPUs for a specific application (GPU type must be set to NVIDIA). The application image must include or be based on an official NVIDIA image containing the matching NVIDIA drivers. DockerHub images can be found here.
GPU resources may also be requested via user charts in the configured MEC Sandbox scenario by adding the following lines to the container specification: