Cloud Manager: A New Multicloud PaaS Platform Built on Kubernetes
The quest to find the right kind of PaaS (Platform-as-a-Service) — has for long been the holy grail of cloud computing. We claim that achieving this goal is finally in reach, and now it’s not the time to let go.
Multiple generations of technology have passed by which, by half-ingenuity, half-trial and error, have increasingly simplified the process of deploying and managing applications and services running in compute clusters — be it in a remote cloud or on-premises.
Two of the most recent attempts to create a general-purpose PaaS software — Cloud Foundry and Kubernetes — have come very close to realize the ultimate dream. However, by choices made in design or focus, both have issues and limitations of their own and there is room for improvement. Lessons can be learned from the experiences gathered in building and using these platforms, and prospects for combining the best of the two are on the rise. In the following, after some motivation and background, I preview our approach in building on what we feel is a better PaaS — as embodied in Cloud Manager.
Cloud Manager is an abstraction layer on top of Kubernetes, but designed from the ground-up for multicluster/multicloud DevOps use, with both developers and operations in mind.
It takes bits of inspiration from Cloud Foundry, which aims for uncluttered workflows, while still retaining all the power and non-paternalist viewpoint of Kubernetes.
Multicluster/Multicloud from the Ground up
Cloud Manager is a new PaaS that leverages all the power of Kubernetes for managing individual clusters, but it is built from the ground-up to support multiple clusters possibly in multiple clouds. Cloud Manager uses its own database to keep high-level management information about the clusters (e.g. credentials) and other, which facilitate the implementation of many desired features in a multicluster PaaS.
Cluster access settings can be imported in a variety of ways: by uploading/providing a kubeconfig file, by importing directly from cloud providers (10+ are supported), or manually.
Cloud Manager provides a flat space listing across the different clusters, which define the namespaces where resources are created.
Each space is mapped directly to a Kubernetes namespace in some cluster, but developers and DevOps don’t need to keep specifying and switching between clusters. Some intercluster operations are also simplified due to this flat virtual space listing. Namespaces that pre-existed in Kubernetes clusters can be attached to make them a fully managed space.
No Vendor Lock-In
Cloud Manager is completely unobtrusive for Kubernetes’ underlying clusters. The clusters are completely unaware of Cloud Manager or its management database. Cloud Manager is also 100% agnostic about the Kubernetes distribution, and does not require the installation of any agent in the cluster.
Stopping the use of Cloud Manager has no affects on the clusters, and there is minimal vendor lock-in. Parts of Cloud Manager runtime, and support libraries, are available as open-source. Other parts are in consideration/planned to be open-source throughout 2021.
We anticipate the evolution to an approach similar to Cloud Foundry, where core components are open-sourced and open to community/partner contributions, while some other components are kept as vendor differentiation IP.
Currently, the complete system is available in “freemium” model. It is free to use, but limited in functionally above a certain resource threshold in the free community edition.
Simplified UX/UI
At the UX/UI level, Cloud Manager borrows some of the best ideas of Cloud Foundry while still giving full access to all Kubernetes resources. Deployments are treated in a more holistic than in plain Kubernetes, by considering several related resources as part of the same application. This includes auto-creation of a matching service and DNS ingresses for each deployment.
DNS routes are managed in a simple way and in the likes of Cloud Foundry: Users can define one or more Domains, that specify information such as DNS hostname suffix and wildcard certificate. One or more DNS routes can be added to an application, at startup/creation time or while running. An option specifies if a route should use its own Kubernetes ingress (default) or a shared ingress. Routes can also overwrite or replace Domain level certificates (e.g. if a wildcard certificate is not available). Unlike some high-level tools, Cloud Manager does not introduce a new abstraction for the application. Rather, it uses directly the Kubernetes abstractions be it a (stateless) Deployment or a Statefulset.
Minimal Configuration and Microservices Friendly
Deployment settings are also simplified in a variety of ways. Minimal configuration is required with no need for complex YAML manifest files, for most use cases. Deployment settings are also stored in Cloud Manager management database, which allows for incremental — interactive configuration.
Deployments can be configured before actually deployed in a cluster.
This includes adding persistent volume mounts, and environment settings.
A variety of utility operations are supported on deployments as well, such as: “copy&paste” of deployments within a space or between spaces (possibly in different clusters), and generation/export of manifest files and reusable packaging.
Unlike other tools for Kubernetes, the use of Kubernetes’ main command-line tool kubectl is dispensable for most use cases.
Like Cloud Foundry, the concept of service binding is also supported but in a more general way and in complement to Kubernetes native abstractions (e.g. configmaps and secrets). A binding is a group of environment variables that are automatically set from values that depend on the deployment details of other services (e.g. URL and access credentials).
Deployments can define connectors, which other deployments can use to resolve bindings. Because there is no different treatment of stateless and stateful deployments, the same mechanism is useful both to connect to backing services and to other microservices. Like Red Hat Openshift, Cloud Manager can be optionally aware of the stack of a deployment to automatically generate configuration and bindings.
But it allows for the definition of custom bindings as well.
The usefulness of this is that it makes it easier to configure and deploy non-cloud native apps, and removes the number of use-cases where an external naming/config service is needed for cloud native apps.
While plain Kubernetes has some features to simplify interservice discovery and connectivity (e.g. space and cluster level DNS names), these mechanisms ignore DNS ingresses and by design can not work across clusters.
CI/CD Support Built-in
Because in Kubernetes all apps need to be packaged as images (currently, the Docker, containerd, and CRI-O runtimes are supported), the creation and distribution of images should be as much at the core of operations. This implies that CI/CD (Continuous Integration/Delivery) should not be regarded as an afterthought in a PaaS.
Cloud Manager as integrated support for CI/CD, built on Tekton. One or more image registries (possibly private) can be defined to both pull images and push images. And one or more git VCS (Version Control) implementations should be defined to pull source code repositories.
CI/CD settings are defined close to the deployment information, which fosters a culture of quick push — build-deploy release cycles. Builds are run usually in the same space and cluster where the deployment is defined. For non-development deployment, the CI/CD settings are left unset.
Secure webhooks are also supported to enable automatic builds and (optionally) deployments at commit time (for all or tagged versions only). Cloud Manager also helps in setting up a cluster and space to support the CI/CD Tekton runtime. Including installation of the runtime, and selected Task and Pipeline definitions from catalogs. All the low-level details of defining Tekton resources to run builds are done automatically by Cloud Manager.
Solutions Marketplace
Cloud Manager also as built-in support for a solutions marketplace. Similar features exist in many other tools for Kubernetes, but like in Cloud Foundry, it is baked in the core architecture and feature-set.
Marketplace solutions can be defined via one or more catalogs, defined by an index file, one compatible with Helm catalogs. Solutions can also be defined standalone as a “deployment plus settings,” which is useful for developer teams to create short/mid-term reusable solutions without the trouble of creating a catalog or elaborated definitions like a Helm chart.
Team/Enterprise Extensions
Cloud Manager is designed to be as light-weighted as possible. It runs as a standalone app in single-user mode with a low resource-usage footprint (2Gb memory), or in multi-user/enterprise mode with a Single Sign-On (SSO) Gateway, acting as an authentication and identity provider.
The SSO Gateway enables a variety of features needed for team collaboration, including account and group management, and invitations. The SSO Gateway is provided as part of an integrated platform, based on a microservices architecture, with includes other optional support services, such as a user notifications service — to notify collaborating users of events triggered by other, an external file storage service. This can be good for data backup snapshots, and social chat/comments in space dedicated channels.
Cloud Manager also takes inspiration from Cloud Foundry in simplifying the Kubernetes security model. A small set of high-level roles (manager, developer, and auditor), that map to Kubernetes RBAC permissions, provides a more convenient approach to express most security policies. For advanced use-cases, it is always possible to fall back to direct RBAC permission settings.
Getting Started
There are a variety of quick ways to get started with Cloud Manager. It can be run with Docker, or installed in an existing cluster with Helm. Installing Cloud Manager in single-user mode as a complement to Docker Desktop is a popular approach.
Cloud Manager is also available ready-to-install in the Kubernetes marketplace of several cloud providers.
The resources listed below provide detailed “getting started” instructions.
Cloud Manager preferred way of interaction by most developers is via a web user interface. A command-line tools is also available to enable script-based automation of tasks.
Learning More
- Cloud Manager, Kubernetes Better Dashboard
- Deploying Cloud Manager On-Premises
- Cloud Manager Reference Manual