Kubernetes® is a software tool that helps you better orchestrate and manage your cloud, as well as significantly simplifies cloud operations and lowers the cost of cloud computing expenses. While running a simple Kubernetes cluster for testing purposes is a relatively easy task, configuring a fully operational production Kubernetes cluster is challenging and requires specific expertise in container management, networking, storage, security, and other aspects of a production cloud. Many organizations decide to outsource this work to cloud providers who specifically focus on complex cloud systems.

The Rackspace KaaS solution enables you to run Kubernetes workloads on top of Rackspace Private Cloud powered by OpenStack (RPCO). You can request that Rackspace Kubernetes-as-a-Service is installed on an existing or new RPCO environment starting with RPCO v14.

Managed services#

In addition to the basic Kubernetes functionality, your Kubernetes cluster comes with managed services that provide extra features.


The rackspace-system and kube-system namespaces in Kubernetes are used for managed services. Do not modify any resources in these namespaces.

Rackspace KaaS provides the following managed services:

Any production cloud requires performance and uptime monitoring to enable cloud administrators to execute steps to address issues. The Managed Kubernetes solution leverages such tools as Prometheus and Grafana® integrated with the internal Monitoring as a Service (MaaS) system to enable Rackspace operators to track the health of your cloud. Rackspace KaaS deploys two instances of Prometheus. One is for internal use and the other is for monitoring Kubernetes applications. For more information, see Logging and monitoring.
Implemented by using such tools as Elasticsearch™, Fluentd, and Kibana, the logging managed service provides real-time data analytics and system resource utilization statistics of your cloud.
Private Docker® image registry
In addition to public Docker image registry, you can store and manage your own Docker images in a private registry implemented with VMware Harbor.
Rackspace KaaS uses Flannel for communication between the Kubernetes Pods. Flannel enables advanced networking features, such as network policies and overlay networking. You can define network policies as required for your cloud or request Rackspace Fanatical Support® to define them for you.
Rackspace KaaS uses a highly-available Ceph storage cluster provisioned through the OpenStack Block Storage (cinder) driver for Kubernetes PersistentVolumes (PV). Ceph provides persistent block storage for Kubernetes users and managed services internal data.

Ingress controller#

Kubernetes supports the concept of virtual hosting by using Ingress resources. The Ingress controller provided with your cluster enables Ingress resources for your cluster. The Ingress controller is highly available (HA) with two replicas. You can read more about Ingress resources in the official Kubernetes documentation.

Sites available through the Ingress controller are prefixed with the https://ingress.${RS_K8S_CLUSTER_NAME}.${RS_K8S_DOMAIN} URL.

Authentication and authorization#

Rackspace manages a Kubernetes Authentication service with which users do not interact directly, but which plays an integral role in granting access to a Kubernetes cluster. This service is responsible for managing users’ tokens and providing Kubernetes with identifying information about users, which the Kubernetes Authentication service derives from the OpenStack Identity service (keystone).

Users access Kubernetes clusters by providing a token that they generate in the Rackspace KaaS UI at https://<openstack-env-domain-name>:8891/login.

The Kubernetes Authentication service stores only hashes of tokens, so that the actual value of each token is visible only when it is created. If a token is misplaced or no longer used, it must be deleted. You can use the same token to authenticate with any Kubernetes cluster in the environment. Although each token is valid for one year from the time of creation, you can delete a token any time before it expires. Each user can create an unlimited number of tokens.

Users can access Kubernetes clusters by providing a token either by invoking kubectl --token or by adding a token to the kubeconfig file. Upon receiving a request with a token, the Kubernetes API passes the token to the Kubernetes Authentication service. If the Kubernetes Authentication service determines that the token is valid, it queries keystone to find information about the corresponding user and returns that information to the Kubernetes API. The Authentication service provides the following information to Kubernetes:

  • The user’s OpenStack username
  • The user’s OpenStack ID
  • The IDs of any OpenStack roles to which the user is assigned

Cluster roles#

The Kubernetes Authentication service enables access to Kubernetes clusters to users who provide valid tokens. However, to authorize a user to perform a specific set of operations, you must create a Kubernetes ClusterRoleBindings. The subject of the role bindings must reference such information as user and role IDs collected from the OpenStack Identity service.

Your Kubernetes cluster is pre-configured with a ClusterRoleBinding that grants cluster-wide administrative access to all users with a specific Keystone role. For example, if you created the kubernetes-admins role with the ID f6120fe6406a473682c3b25cdea4510a, your Kubernetes cluster has the following ClusterRoleBinding:

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
  name: "rackspace:default-cluster-admin"
- kind: Group
  apiGroup: rbac.authorization.k8s.io
  name: f6120fe6406a473682c3b25cdea4510a
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io


Note the difference in the Kubernetes and keystone terminology. A Kubernetes group is referred to as role in Keystone terminology. Do not confuse Keystone’s concept of groups with the Kubernetes concept of groups.

You might want to create additional Keystone roles and role bindings to provision and control Kubernetes access for users without administrative privileges.

High availability#

Your Kubernetes cluster is configured to be highly available. The Kubernetes components are replicated behind a load balancer and distributed on multiple compute resources.

Resource limits#

By default, your Kubernetes cluster has three worker nodes. The default configuration of your cluster node includes:

Kubernetes worker nodes:
  • vCPU: 4
  • RAM: 8 GB
  • Local storage: 40 GB of local storage
Private Docker registry:
  • Database: 10 GB


The private Docker registry database stores Docker images metadata. The actual Docker images are stored in the object storage system, such as Ceph RGW, OpenStack Swift, or other compatible object store deployed as part of your cloud.

If you need to resize your cluster, contact your Rackspace representative and request additional resources.