Kubernetes Architecture Explained

Kubernetes Architecture Explained

The Cloudify Kubernetes support consists of three main components:


Key features

Native Kubernetes Template support

Helm 3 Template Support

Helm 3 plugin allows you to create a Helm client for each deployment; add repositories, create releases, and easily deploy an application on any existing Kubernetes cluster.

Multi Kubernetes Cluster Support

The use cases for multi Kubernetes cluster can be driven by different needs

Cloudify was designed to manage highly distributed deployments and therefore fit well as the Multi-Cluster Kubernetes service broker.

The Cloudify blueprint allows users to define multiple services across different clusters as part of the same deployment template. Users can also use the Cloudify Service Component DSL to bind a particular service to a Kubernetes cluster dynamically at runtime.

Interoperability between Kubernetes providers and non-Kubernetes services.

Cloudify provides a rich set of out of the box plugins that support VM, Serverless, legacy apps, or any other REST service as part of the same deployment. This allows users to create an automation blueprint that includes Kubernetes and non-Kubernetes services and use the native dependency, relationship, workflow features as with any other node types. This opens up the options to enable interoperability between Kubernetes and non-Kubernetes services in the following way:

Managed as code with built-in integration with CI/CD

Cloudify provides built-in integration with a list of Ci/CD tools such as Jenkins, Git Actions, Circle CI, etc.

This integration includes a generic template that allows users to run any Kubernetes service without having to write a Cloudify blueprint as a wrapper. The Cloudify wrapper blueprint will be attached to the service behind the scene, and in this case, will simplify significantly the learning curve needed to run those services through Cloudify and the Ci/CD tool of choice.

Management UI

The Cloudify management UI is focused on service management and less on monitoring the Kubernetes infrastructure. As such it provides a catalog service that provides a simple interface to deploy Helm or native Kubernetes services. Topology view which tracks the service dependency and state of a deployment. Workflow which monitors the execution steps on a particular service.

UI Component




Getting Started with Cloudify Kubernetes

Hello world example

The first example is a very simple hello world application. The application consists of a Kubernetes Deployment type resource and a Kubernetes Service type resource. The resources are packaged in a single YAML file. This is a traditional Kubernetes resource template with one unique difference, which is that it has been parameterized using a Jinja template. This file is delivered to the Cloudify Manager with a blueprint. In the blueprint, a single node template refers to this file. The “container” and “container_port” parameters may be changed to replace the application and port parameters in the Kubernetes resources.

Multi-Cluster Example

In the following example, we used a combination of Jenkins and Cloudify Jenkins Plugin as a Multi Kubernetes Cluster broker between OpenShift and GKE. In this example, OpenShift act as our development environment and GKE as the production environment. The pipeline pushes the same application across the two clusters. Cloudify is used to abstract the authentication and different setup needed for each cluster environment. We refer to this pattern as EaaS (Environment as a Service).


Click to watch a demo

Continuous Deployment Example

Cloudify provides tight integration with popular CI/CD tools such as GitHub Actions, CircleCI, and Jenkins. This integration provides pipeline developers with the ability to involve Cloudify in their pipelines using facilities native to the CI/CD platform.

For GitHub, Cloudify provides a set of GitHub Actions, one of which is the “Create Kubernetes Environment” action.

An example of how Cloudify’s Kubernetes GitHub action is used can be found in our GitHub Actions example repository.