kspacr is particularly useful for companies that want to leverage Kubernetes for their applications but don't have the expertise or resources to manage the infrastructure or Kubernetes clusters.
Our platform empowers developers to deploy their applications on Kubernetes with minimal effort, significantly reducing the time and costs associated with infrastructure and cluster management.
Kubernetes forms the foundation of kspacr. We offer flexibility in terms of Kubernetes cluster management - clusters can either be created and managed by us (kspacr-managed clusters) or you can connect your own customer-managed clusters to kspacr.
When it comes to kspacr-managed clusters, they are running on our infrastructure and cloud accounts. Customers are then billed based on the CPU and Memory usage of their deployments.
On the other hand, customer-managed Kubernetes clusters run in their own cloud accounts or on-premise in their own data centers. These clusters simply need to be connected to kspacr's system.
Clusters are independent
One of the key principles of our system is the independence of Kubernetes clusters. They do not rely on the availability of kspacr systems. This means that even if the kspacr systems experience downtime, all Kubernetes clusters and cluster components will continue to function as normal. This independence ensures that your applications remain uninterrupted, regardless of the status of kspacr systems.
Moreover, the kspacr control plane does not maintain connections to Kubernetes clusters that could potentially be used to access cluster resources. This design choice further enhances the security and independence of your Kubernetes clusters, ensuring that your operations remain secure and self-sufficient.
At kspacr, we go beyond just providing managed Kubernetes resources. kspacr also provides a Managed Kubernetes Platform, which includes the setup and maintenance of Kubernetes cluster components for enhanced observability & security, and a superior developer experience.
These platform components are managed by kspacr from within the cluster itself. Flux, a GitOps tool, continuously pulls manifests and changes from Git and applies them to the cluster. This means that your platform components are always up-to-date with the latest changes and configurations, reducing the need for manual updates and ensuring your namespaces & virtual clusters are always running optimally.
Deploying an application with
kspacr is a straightforward process. You can use the same methods and procedures that you would typically use with any Kubernetes cluster.
Dockerfile-Based Builds: If your application has a Dockerfile,
kspacr will use it to build your application container. This allows you to leverage the power and flexibility of Dockerfiles to define exactly how your application container should be built.
Cloud Native Buildpacks (CNB): In case your application doesn't have a Dockerfile, don't worry. kspacr will use
Cloud Native Buildpacks (CNB) to build your application container. CNBs provide a high-level abstraction for building containers in a way that's independent of the underlying codebase. This means you can build containers without needing to write a Dockerfile.
External Container Registries: kspacr connects to external container registries to push and fetch containers. This means you can use your preferred container registry with kspacr, providing you with the flexibility you need.
For manual deployment, you can use the
kspacr CLI to fetch the
kubecontext for the namespace where the application should be deployed. Once you have fetched the
kubecontext, you can use your local
helm to deploy the application manually or as part of your CI/CD process.
If you prefer to use GitOps for deployment,
kspacr has you covered. You can use the kspacr UI and CLI to create a Helm-based deployment for your application. This deployment is based on our
Golden Path Helm chart and is pushed to Git.
Once the deployment is pushed to Git,
Flux, the GitOps component in the Kubernetes cluster, will deploy your application to the cluster namespace. You can use a GitHub action, the UI, or CLI to update the deployment, for example, with a new container version. Any changes you make will be picked up by Flux and deployed to the namespace.