Deploy Compute Plane
Connect Kubernetes Cluster in your cloud account to TrueFoundry Control Plane
TrueFoundry provides an easy way to attach a new compute plane to the control plane. It provides the Terraform code using which you can bring up all the necessary components of the compute plane in your cloud account. The key components of the compute plane are:
- Kubernetes Cluster - This is the primary compute on which the applications deployed by the control plane run. This can be EKS, GKE, AKS, Openshift, Oracle Kubernetes engine orany other standard Kubernetes cluster. The control plane should have read access to the cluster configuration. The following addons need to be present on the compute-plane cluster depending on your usecase. You can bring your own addons and have full flexibility on the configuration of the addons.
ArgoCD (Essential)
ArgoCD (Essential)
TrueFoundry relies on ArgoCD to deploy applications to the compute-plane cluster. The infra applications are deployed in the default project in argocd while the user deployed applications are deployed in tfy-apps project. If you are using your own ArgoCD, please create a tfy-apps project with the following spec.
Istio (Essential)
Istio (Essential)
Istio is a really powerful service mesh and ingress controller. TrueFoundry uses Istio as the primary ingress controller in the compute-plane cluster. We don’t inject the sidecar by default - its only injected in cases where needed for the following usecases:
- Request Count Based autoscaling
- Oauth authentication for Jupyter Notebooks.
- Intercepts feature to redirect / mirror traffic to other applications.
- Authentication for services deployed on the cluster.
ArgoRollouts (Essential)
ArgoRollouts (Essential)
Argo Rollouts is used to power the canary and blue-green rollout strategies in TrueFoundry.
Prometheus (Essential)
Prometheus (Essential)
Prometheus is used to power the metrics feature on the platform. It also powers the autoscaling feature on the cluster.
ArgoWorkflows (Optional)
ArgoWorkflows (Optional)
TrueFoundry uses Argo Workflows to power the Jobs feature on the platform.
Keda (Optional)
Keda (Optional)
Keda is used to power the autoscaling feature on the platform.
Loki (Optional)
Loki (Optional)
GPU Operator (Optional)
GPU Operator (Optional)
GPU Operator is used to deploy workloads on the GPU nodes. It’s a TrueFoundry provided helm chart that’s based on Nvidia’s GPU operator.
Grafana (Optional)
Grafana (Optional)
Grafana is a monitoring tool that can be installed to view the metrics, logs and create dashboards on the cluster. You can install the TrueFoundry grafana helm chart that comes with a lot of inbuilt dashboards for cluster monitoring.
[AWS Only] Metrics-Server (Essential)
[AWS Only] Metrics-Server (Essential)
Metrics-Server is required on AWS EKS cluster for autoscaling.
[AWS Only] AWS EBS CSI Driver (Essential)
[AWS Only] AWS EBS CSI Driver (Essential)
AWS Ebs CSI Driver is required for supporting EBS volumes on EKS cluster.
[AWS Only] AWS EFS CSI Driver (Essential)
[AWS Only] AWS EFS CSI Driver (Essential)
AWS Efs CSI Driver is required for supporting EFS volumes for EKS cluster.
[AWS Only] AWS Load Balancer Controller Essential)
[AWS Only] AWS Load Balancer Controller Essential)
AWS Load Balancer Controller is required for supporting load balancer on EKS.
[AWS Only] TFY Inferentia Operator (Optional)
[AWS Only] TFY Inferentia Operator (Optional)
TFY Inferentia Operator is required for supporting Inferentia machines on EKS.
Cert-Manager (Optional)
Cert-Manager (Optional)
Cert-Manager is required for provisioning certificates for exposing services. In AWS you can use the AWS Certificate Manager to provision the certificates. For more details on how to setup the certificates, please refer to the TrueFoundry documentation.
- Docker Registry - This is the registry where the docker images built by the control plane are pushed. This can be ECR, GCR, ACR, Quay, Dockerhub, JFrog, Harbour, or your own docker registry.
Quay or any other standard docker registry. The control plane should have access to push to this registry. - Blob Storage (Optional) - This will be used to store the ML models and artifacts. This is optional and only needed if you intend to use the model registry feature. The control plane should have access to read and write to this blob storage. Possible integrations are AWS S3, Azure Blob Storage, GCP Storage, Minio or any other S3 compatible storage.
- Secret Store (Optional) - This will be used to store the secrets for the applications. This is optional and only needed if you intend to use the secret store feature. The control plane should have access to read and write to this secret store. Possible integrations are AWS ParameterStore, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager.
- DNS and Certificates - We need to setup a domain name and point it to the load balancer in the compute-plane cluster. This will allow us to provide domain names to the workloads deployed on the cluster. The domain name can be a single domain or a wild card domain. For e.g. if you point a domain like
*.example.com(wildcard domain) to the load balancer, the services will be exposed likeservice1.example.com,service2.example.cometc. However, if you point a domain liketfy.example.com(non-wildcard domain) to the load balancer, the services will be exposed liketfy.example.com/service1,tfy.example.com/service2etc. Many frontend applications do not work with path based routing (the latter case) and hence we recommend using wildcard domains. We also need to provision certificates to terminate the TLS traffic on the load balancer. For this we can use the AWS Certificate Manager or cert-manager with GCP Cloud DNS or Azure DNS. You can also bring your pre-created certificates.