✅Prerequisites

Hardware requirements

Minimum requirements for Toucan are:

• An x86 Linux-based server. No requirements on the distribution or Kernel version.

• 2 Cores CPU

• 8 GB of RAM

• 20 GB of storage for the node, to host Kubernetes and the container images.

• +Additional block storage for your data (at least 50 GB).

Recommended requirements for Toucan are:

• An x86 Linux-based server. No requirements on the distribution or Kernel version.

• 4 Cores CPU

• 16 GB of RAM

• >50 GB of storage for the node.

• +Additional block storage for your data (at least 50 GB).

Software requirements

• Kubernetes 1.22+

  If you plan to host Kubernetes yourself, the following page will help you configure k3s for production.

  If you plan to test Toucan on Kubernetes, the next page will also present examples with minikube.

• Kubectl with an access to the Kubernetes cluster.

• Helm 3+.

• An access to Toucan's Quay registry. If you don't have access, contact us using our mail address: [email protected].

  • Test the access by running the following command:

    helm pull oci://quay.io/toucantoco/charts/toucan-stack

• A configurable DNS to forward traffic to the Toucan services.

• An Ingress controller like the Nginx Ingress controller to expose the Toucan services.

• Have a Curity Community Edition license. You can sign up for one here.

• (optional) cert-manager to handle certificates.

Prerequisite knowledge

Even if the deployment is abstracted, basic understanding of components is recommended:

• Kubernetes critical concepts: Ingress and Persistent Volumes.

• NGINX Ingress controller and reverse proxies

  • Required to expose traffic to the Toucan services.

• DNS records configuration (feel free to check the documentation of your DNS cloud provider, here's the one provided by Cloudflare).

  • Required to forward traffic to the Toucan services based on domain names.

• TLS configuration

  • Required to secure traffic to the Toucan services.

  • (optional) cert-manager to automatically manage certificates.

Are you self-hosting Kubernetes? Please read this.

If this is your first time configuring Kubernetes, exposing traffic through the Ingress Controller may not be immediate. We recommend using one of the following methods in order of preference:

• Cloud Controller Manager (if possible): This is the optimal choice for multi-node deployments, as it automatically handles network configuration without the hassle of manual setup.

• MetalLB: A solution for exposing traffic by announcing IP addresses of the Ingress Controller using L2 or BGP advertisements. MetalLB is ideal for multi-node setups where you need to manage load balancing and expose services over external IPs.

• ServiceLB: Included and exclusive to k3s, ServiceLB is the simplest solution to expose traffic on a single-node Kubernetes deployment. It automatically opens ports on the host without the need for advertisements and is perfect for small or local deployments.

• NodePorts: This method opens ports between 30000 and 32767 on each node, but you’ll need to manually forward ports using your router. This is a simple solution but may not scale well in larger environments.

Storage may also require additional configuration, and we recommend the following methods:

• Cloud Provider Storage Provisioner: Using your cloud provider’s storage solution (e.g., AWS EBS, Google Persistent Disk, or Azure Disk) provides the benefits of an optimized storage plane, including replication, availability, and compliance. This is the most robust option for production-grade storage.

• Local-Path Provisioner: Included with k3s, this provisioner mounts storage directly on the host. It's highly recommended for single-node setups but has the limitation of binding the Pod to a specific node. To optimize this setup, we suggest mounting an additional block storage at /opt/local-path-provisioner/ to separate application data from infrastructure data on the same disk.

• Other CSI Drivers (e.g., iSCSI): If you prefer, you can use other Container Storage Interface (CSI) drivers, such as iSCSI, for more custom storage configurations.

We do not recommend using self-hosted solutions like Ceph/Rook, NFS, Longhorn, or any other parallel/network storage unless you have dedicated storage nodes and a deep understanding of inter-node communication and performance tuning. These solutions typically require significant network bandwidth and can complicate setup and maintenance.

If you ever have storage nodes, for a multi node setup, we recommend splitting the storage between the compute nodes. You can then apply taints to designate certain nodes as "storage nodes" (e.g., storage=true), optimizing your storage layout:

If this is your first time self-hosting Kubernetes, we strongly recommend using k3s as your Kubernetes distribution. It simplifies network and storage configuration, making it the easiest way to get your cluster running with minimal effort.

Recommended tools

We recommend using the following tools:

• VSCode or any IDE with YAML support.

• Headlamp, a GUI for Kubernetes.

While kubectl should be enough to interact with the cluster, these additional tools will help you quickly navigate through the cluster.

Recommended documentation

• Helm documentation - Customizing the chart before installing

• Kubernetes Documentation

Warning

Before deploying Toucan Stack, it is strongly advised to have a comprehensive understanding on how Kubernetes operates, specifically with regard to storage and network management using features such as PersistentVolume, and Ingress.

What's next

Did you get everything ready?

Now it's time to deploy the stack! We'll also help you configure Kubernetes with the k3s distribution, if you haven't already deployed it.

⛴️Deploy Toucan using Helm Charts