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

1 About SUSE Cloud Application Platform

1.1 New in Version 1.5.2

  • SUSE Cloud Foundry has been updated to version 2.20.3:

    • cf-deployment has been updated to 12.17

    • Optimized startup time for various roles

    • Added/fixed podAntiAffinity rules for various roles

  • Stratos Console has been updated to version 3.1.0:

    • Improvements to the Kubernetes Dashboard integration (improved configuration and reliability)

    • Improved support for synchronous creation of service instances

    • Branding updated to "SUSE Stratos Console"

    • For a full list of features and fixes see https://github.com/SUSE/stratos/blob/master/CHANGELOG.md#310

  • Stratos Metrics has been updated to version 1.1.2:

See all product manuals for SUSE Cloud Application Platform 1.x at SUSE Cloud Application Platform 1.

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/1/.

1.2 SUSE Cloud Application Platform Overview

SUSE Cloud Application Platform is a software platform for cloud-native application deployment based on SUSE Cloud Foundry and Kubernetes.

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

SUSE Cloud Application Platform is comprised of the SUSE Linux Enterprise builds of the User Account and Authentication (uaa) Server, SUSE Cloud Foundry (scf), the Stratos Web user interface, and Stratos Metrics.

The Cloud Foundry code base provides the basic functionality. SUSE Cloud Foundry 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 SUSE Doc: SUSE Cloud Application Platform 1 refer to the commercially-supported SUSE Linux Enterprise version.

Cloud Application Platform is designed to run on any Kubernetes cluster. 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 SUSE Cloud Foundry. Most Cloud Foundry distributions run on virtual machines managed by BOSH. SUSE Cloud Foundry 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. SUSE Cloud Foundry components deployed in containers consume substantially less memory, as host-level operations are shared between containers by Kubernetes.

SUSE Cloud Foundry packages upstream Cloud Foundry BOSH releases to produce containers and configurations which are deployed to Kubernetes clusters using Helm.

1.3 Minimum Requirements

This guide details the steps for deploying SUSE Cloud Foundry on supported Kubernetes environments, namely SUSE CaaS Platform, Microsoft Azure Kubernetes Service, Google Kubernetes Engine, and Amazon Elastic Kubernetes Service.

Important: Required Knowledge

Installing and administering SUSE Cloud Application Platform requires knowledge of Linux, Docker, Kubernetes, and your Kubernetes platform. You must plan resource allocation and network architecture by taking into account the requirements of your Kubernetes platform in addition to SUSE Cloud Foundry requirements. SUSE Cloud Foundry is a discrete component in your cloud stack, but it still requires knowledge of administering and troubleshooting the underlying stack.

You may create a minimal deployment on four Kubernetes nodes for testing. However, this is insufficient for a production deployment. A supported deployment includes SUSE Cloud Foundry installed on SUSE CaaS Platform, Amazon EKS, Google GKE, or Microsoft AKS. You also need a storage back-end such as SUSE Enterprise Storage or NFS, a DNS/DHCP server, and an Internet connection to download additional packages during installation and ~10 GB of Docker images. Figure 1.1, “Minimal Example Production Deployment” describes a minimal production deployment with SUSE Cloud Foundry deployed on a Kubernetes cluster containing three Kubernetes masters and three workers, plus an ingress controller, administration workstation, DNS/DHCP server, and a SUSE Enterprise Storage cluster.

network architecture of minimal production setup
Figure 1.1: Minimal Example Production Deployment

Note that after you have deployed your cluster and start building and running applications, your applications may depend on buildpacks that are not bundled in the container images that ship with SUSE Cloud Foundry. These will be downloaded at runtime, when you are pushing applications to the platform. Some of these buildpacks may include components with proprietary licenses. (See Customizing and Developing Buildpacks to learn more about buildpacks, and creating and managing your own.)

1.4 SUSE Cloud Application Platform Architecture

The following figures illustrate the main structural concepts of SUSE Cloud Application Platform. Figure 1.2, “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.2: Cloud Platform Comparisons

Figure 1.3, “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.3: Containerized Platforms

Figure 1.4, “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.4: SUSE Cloud Application Platform Stack

1.4.1 SUSE Cloud Foundry Components

SUSE Cloud Foundry 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 SUSE Cloud Foundry: 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, which includes Tiller, the Helm server, and the helm command line client.

  • kubectl, the command line client for Kubernetes.

  • Long-running SUSE Cloud Foundry components.

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

  • SUSE Cloud Foundry Linux cell, an elastic runtime component that runs Linux applications.

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

  • The Kubernetes API.

1.4.2 SUSE Cloud Foundry Containers

Figure 1.5, “SUSE Cloud Foundry Containers, Grouped by Function” provides a look at SUSE Cloud Foundry's containers.

Figure 1.5: SUSE Cloud Foundry Containers, Grouped by Function
List of SUSE Cloud Foundry Containers

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


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


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


Sidekick to the Cloud Controller, periodically performing maintenance tasks such as resource cleanup.


Assists droplet upload from Diego.


Sidekick to the Cloud Controller, processes background tasks.


Universal Service Broker; SUSE's own component for managing and publishing service brokers.


API for the Diego scheduler.


Contains the Diego auctioning system that schedules user applications across the elastic layer.

diego-cell (privileged)

The elastic layer of SUSE Cloud Foundry, where applications live.


Provides SSH access to user applications, exposed via a Kubernetes service.


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 MariaDB server and component to route requests to replicas. (A separate copy is deployed for uaa.)


A pub-sub messaging queue for the routing system.

nfs-broker (privileged)

A service broker for enabling NFS-based application persistent storage when using the Diego scheduler.


Used as a Kubernetes job, performs cluster setup after installation has completed.


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


API for the routing system.


Used as a Kubernetes job to create secrets (certificates) when the cluster is installed.


Part of the logging system that allows user applications to be bound to a syslog drain.


Routes TCP traffic for your applications.

1.4.3 SUSE Cloud Foundry Service Diagram

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

Figure 1.6: 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

SUSE Cloud Foundry components ask uaa for tokens so they can talk to each other


External (HTTPS)

Requestor: SUSE Cloud Foundry clients

Request: SUSE Cloud Foundry API Requests

Request Credentials: OAuth2 Bearer token

Request Authorization: SUSE Cloud Foundry 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 SUSE Cloud Foundry API (for example users deploying apps)


External (WSS)

Requestor: SUSE Cloud Foundry clients

Request: Log streaming

Request Credentials: OAuth2 Bearer token

Request Authorization: SUSE Cloud Foundry application management

Listener: Cloud Application Platform components

Response: A stream of SUSE Cloud Foundry logs

Response Credentials: TLS certificate on external endpoint

SUSE Cloud Foundry clients ask for logs (for example user looking at application logs or administrator viewing system logs)


External (SSH)

Requestor: SUSE Cloud Foundry clients, SSH clients

Request: SSH Access to Application

Request Credentials: OAuth2 bearer token

Request Authorization: SUSE Cloud Foundry 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

SUSE Cloud Foundry 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.4.4 Detailed Services Diagram

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

Figure 1.7: Detailed Services Diagram
Print this page