Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE Cloud Application Platform 2.0.1

1 About SUSE Cloud Application Platform

1.1 New in Version 2.0.1

See all product manuals for SUSE Cloud Application Platform 2.x at https://documentation.suse.com/suse-cap/2/.

Tip: Read the Release Notes

Make sure to review the release notes for SUSE Cloud Application Platform published at https://www.suse.com/releasenotes/x86_64/SUSE-CAP/2.0/.

1.2 SUSE Cloud Application Platform Overview

SUSE Cloud Application Platform is a software platform for cloud-native applications based on Cloud Foundry Application Runtime (cf-operator, KubeCF, and Stratos) with additional supporting components.

SUSE Cloud Application Platform describes the complete software stack, including the operating system, Kubernetes, and KubeCF.

SUSE Cloud Application Platform is comprised of cf-operator (cf-operator), KubeCF (kubecf), the Stratos Web user interface, and Stratos Metrics.

The Cloud Foundry code base provides the basic functionality. KubeCF differentiates itself from other Cloud Foundry distributions by running in Linux containers managed by Kubernetes, rather than virtual machines managed with BOSH, for greater fault tolerance and lower memory use.

All Docker images for the SUSE Linux Enterprise builds are hosted on registry.suse.com. These are the commercially-supported images. (Community-supported images for openSUSE are hosted on Docker Hub.) Product manuals on https://documentation.suse.com/suse-cap/2/ refer to the commercially-supported SUSE Linux Enterprise version.

Cloud Application Platform is designed to run on any Kubernetes cluster as described in Section 5.2, “Platform Support”. This guide describes how to deploy it:

SUSE Cloud Application Platform serves different but complementary purposes for operators and application developers.

For operators, the platform is:

  • Easy to install, manage, and maintain

  • Secure by design

  • Fault tolerant and self-healing

  • Offers high availability for critical components

  • Uses industry-standard components

  • Avoids single vendor lock-in

For developers, the platform:

  • Allocates computing resources on demand via API or Web interface

  • Offers users a choice of language and Web framework

  • Gives access to databases and other data services

  • Emits and aggregates application log streams

  • Tracks resource usage for users and groups

  • Makes the software development workflow more efficient

The principle interface and API for deploying applications to SUSE Cloud Application Platform is KubeCF. Most Cloud Foundry distributions run on virtual machines managed by BOSH. KubeCF runs in SUSE Linux Enterprise containers managed by Kubernetes. Containerizing the components of the platform itself has these advantages:

  • Improves fault tolerance. Kubernetes monitors the health of all containers, and automatically restarts faulty containers faster than virtual machines can be restarted or replaced.

  • Reduces physical memory overhead. KubeCF components deployed in containers consume substantially less memory, as host-level operations are shared between containers by Kubernetes.

SUSE Cloud Application Platform uses cf-operator, a Kubernetes Operator deployed via a Helm chart, to install custom resource definitions that convert BOSH releases into Kubernetes resources, such as Pod, Deployment, and StatefulSet. This is made possible by leveraging KubeCF, a version of Cloud Foundry deployed as Helm chart.

1.3 SUSE Cloud Application Platform Architecture

The following figures illustrate the main structural concepts of SUSE Cloud Application Platform. Figure 1.1, “Cloud Platform Comparisons” shows a comparison of the basic cloud platforms:

  • Infrastructure as a Service (IaaS)

  • Container as a Service (CaaS)

  • Platform as a Service (PaaS)

  • Software as a Service (SaaS)

SUSE CaaS Platform is a Container as a Service platform, and SUSE Cloud Application Platform is a PaaS.

Comparison of cloud platforms.
Figure 1.1: Cloud Platform Comparisons

Figure 1.2, “Containerized Platforms” illustrates how SUSE Cloud Application Platform containerize the platform itself on top of a cloud provider.

SUSE SUSE CaaS Platform and SUSE Cloud Application Platform containerize the platform itself.
Figure 1.2: Containerized Platforms

Figure 1.3, “SUSE Cloud Application Platform Stack” shows the relationships of the major components of the software stack. SUSE Cloud Application Platform runs on Kubernetes, which in turn runs on multiple platforms, from bare metal to various cloud stacks. Your applications run on SUSE Cloud Application Platform and provide services.

Relationships of the main Cloud Application Platform components.
Figure 1.3: SUSE Cloud Application Platform Stack

1.3.1 KubeCF Components

KubeCF is comprised of developer and administrator clients, trusted download sites, transient and long-running components, APIs, and authentication:

  • Clients for developers and admins to interact with KubeCF: the cf CLI, which provides the cf command, Stratos Web interface, IDE plugins.

  • Docker Trusted Registry owned by SUSE.

  • SUSE Helm chart repository.

  • Helm, the Kubernetes package manager, and the helm command line client.

  • kubectl, the command line client for Kubernetes.

  • cf-operator, a Kubernetes Operator that converts BOSH releases to Kubernetes resources.

  • KubeCF, a version of Cloud Foundry deployed via cf-operator.

  • Long-running KubeCF components.

  • KubeCF post-deployment components: Transient KubeCF components that start after all KubeCF components are started, perform their tasks, and then exit.

  • KubeCF Linux cell, an elastic runtime component that runs Linux applications.

  • uaa, a Cloud Application Platform service for authentication and authorization.

  • The Kubernetes API.

1.3.2 KubeCF Containers

Figure 1.4, “KubeCF Containers, Grouped by Function” provides a look at KubeCF's containers.

Figure 1.4: KubeCF Containers, Grouped by Function
List of KubeCF Containers

Part of the logging system, manages connections to user application syslog drains.


Contains the KubeCF Cloud Controller, which implements the CF API. It is exposed via the router.


Sidekick to the Cloud Controller, processes background tasks.


A PXC database to store persistent data for various CAP components such as the cloud controller, UAA, etc.


API for the Diego scheduler.

diego-cell (privileged)

The elastic layer of KubeCF, where applications live.


An alternative to the Diego scheduler.


Enables persistent storage for applications when using the Eirini scheduler.


Provides SSH access to user applications when using the Eirini scheduler.


Routes log messages from applications and components.


Part of the logging system; exposes log streams to users using web sockets and proxies user application log messages to syslog drains. Exposed using the router.


A pub-sub messaging queue for the routing system.


Routes application and API traffic. Exposed using a Kubernetes service.


API for the routing system.


Service used to create, schedule and interact with jobs that execute on Cloud Foundry


A WebDAV blobstore for storing application bits, buildpacks, and stacks.


Routes TCP traffic for your applications.


User account and authentication.

1.3.3 KubeCF Service Diagram

This simple service diagram illustrates how KubeCF components communicate with each other (Figure 1.5, “Simple Services Diagram”). See Figure 1.6, “Detailed Services Diagram” for a more detailed view.

Figure 1.5: Simple Services Diagram

This table describes how these services operate.

Interface, Network Name, Network ProtocolRequestor & RequestRequest Credentials & Request AuthorizationListener, Response & Response CredentialsDescription of Operation


External (HTTPS)

Requestor: Helm Client

Request: Deploy Cloud Application Platform

Request Credentials: OAuth2 Bearer token

Request Authorization: Deployment of Cloud Application Platform Services on Kubernetes

Listener: Helm/Kubernetes API

Response: Operation ack and handle

Response Credentials: TLS certificate on external endpoint

Operator deploys Cloud Application Platform on Kubernetes


External (HTTPS)

Requestor: Internal Kubernetes components

Request: Download Docker Images

Request Credentials: Refer to registry.suse.com

Request Authorization: Refer to registry.suse.com

Listener: registry.suse.com

Response: Docker images

Response Credentials: None

Docker images that make up Cloud Application Platform are downloaded


Tenant (HTTPS)

Requestor: Cloud Application Platform components

Request: Get tokens

Request Credentials: OAuth2 client secret

Request Authorization: Varies, based on configured OAuth2 client scopes

Listener: uaa

Response: An OAuth2 refresh token used to interact with other service

Response Credentials: TLS certificate

KubeCF components ask uaa for tokens so they can talk to each other


External (HTTPS)

Requestor: KubeCF clients

Request: KubeCF API Requests

Request Credentials: OAuth2 Bearer token

Request Authorization: KubeCF application management

Listener: Cloud Application Platform components

Response: JSON object and HTTP Status code

Response Credentials: TLS certificate on external endpoint

Cloud Application Platform Clients interact with the KubeCF API (for example users deploying apps)


External (WSS)

Requestor: KubeCF clients

Request: Log streaming

Request Credentials: OAuth2 Bearer token

Request Authorization: KubeCF application management

Listener: Cloud Application Platform components

Response: A stream of KubeCF logs

Response Credentials: TLS certificate on external endpoint

KubeCF clients ask for logs (for example user looking at application logs or administrator viewing system logs)


External (SSH)

Requestor: KubeCF clients, SSH clients

Request: SSH Access to Application

Request Credentials: OAuth2 bearer token

Request Authorization: KubeCF application management

Listener: Cloud Application Platform components

Response: A duplex connection is created allowing the user to interact with a shell

Response Credentials: RSA SSH Key on external endpoint

KubeCF Clients open an SSH connection to an application's container (for example users debugging their applications)


External (HTTPS)

Requestor: Helm

Request: Download charts

Request Credentials: Refer to kubernetes-charts.suse.com

Request Authorization: Refer to kubernetes-charts.suse.com

Listener: kubernetes-charts.suse.com

Response: Helm charts

Response Credentials: Helm charts for Cloud Application Platform are downloaded

Helm charts for Cloud Application Platform are downloaded

1.3.4 Detailed Services Diagram

Figure 1.6, “Detailed Services Diagram” presents a more detailed view of KubeCF services and how they interact with each other. Services labeled in red are unencrypted, while services labeled in green run over HTTPS.

Figure 1.6: Detailed Services Diagram
Print this page