Architect leverages Kubernetes as the deployment target for your components. With Architect, it's not necessary to understand how Kubernetes works internally, as we handle all of the complexity for you. This includes networking, security, scaling, and more.
In order for Architect to interact with your cluster, while maintaining a high level of security, when you register you cluster we install an agent that interacts with your cluster on Architect's behalf. This application creates a secure connection using SSL over HTTP2 with the Architect servers that allows us to send commands to the cluster remotely. This means at no time do we ever store the credentials for your cluster anywhere in our infrastructure.
Cluster applications are required for your applications to be run properly by Architect. When a cluster is created, you'll be prompted to allow Architect to install them on your behalf. These applications include a load balancer, certificate management, and more. No configuration of these applications is required.
A cluster environment is similar to a namespace, and enables logical separation of deployed components. One cluster can have many environments, and all applications deployed to a cluster's related environments will be deployed to the same Kubernetes cluster. A common use of environments is to share resources of one cluster between many different preview environments which can be created and destroyed by a CI system at will. Creating a cluster with a single environment to host a production application is another common use case.
When an Architect account is created, it will automatically have the Architect public cluster added to it. This cluster will appear as "architect" on the clusters page of the Architect Cloud or when the command
architect clusters is run from the Architect CLI. This cluster is shared between all Architect Cloud users and is only intended for testing. As such, applications deployed to environments on the public cluster will be torn down 24 hours after the last pipeline was run. In order to allow a good experience for all users on this shared cluster, some features are not enabled, such as component scaling and resource (CPU and memory) configuration.
When an application is ready for a production deployment, Architect recommends that a private cluster be created and used on your cloud provider of choice. It can be added to the Architect Cloud as a cluster with the command
architect cluster:create <cluster-name> --kubeconfig <kubeconfig-file-path>
Once the cluster applications have been installed, create an environment on the new cluster with the command
architect environment:create <environment-name> --cluster <cluster-name>
That's it! You now have a production-grade cluster ready to host your components.