Kubernetes Cluster Requirements
This document describes the requirements yaook/operator imposes on a Kubernetes Cluster. In contrast to Kubernetes API Requirements, this document is focused on the services and resources which need to be defined inside a cluster. For requirements on the Kubernetes deployment itself, such as feature flags or Kubernetes versions, please see Kubernetes API Requirements instead.
- If your underlying kubernetes cluster will be deployed with yaook/k8s, we recommend configuring yaook/k8s to include all of the desired features of your cluster. This includes the following features, which are required by yaook/operator:
- and the following features, which are optional to yaook/operator:
The hostname (including the domain part) of each node (as reported by
hostname -f) MUST be the same
as the name of the node object in kubernetes for the respective node.
When deploying all yaook operators on a kubernetes cluster, it is recommended to have at least 4 worker nodes with 4 (v)cores and 16384 MiB RAM each and 3 master nodes with 2 (v)cores and 2048 MiB RAM each. Dependent on your specific needs and kind of virtual machines you want to run, additional compute nodes or so called worker nodes are needed.
Node Software Requirements for Ceph
If ceph OSDs should be deployed on a kubernetes node,
lvm2 needs to be installed on it.
The Kubernetes cluster MUST have a default storage class set. This storage class MUST allow moving volumes between nodes.
In an upcoming release, the requirements will change to:
There MUST be a storage class which is host local (e.g. provided by the local-storage controller).
There MUST be a storage class which is not host local and can be moved between different nodes.
The networking SHOULD be provided by Calico. Other network layers may work, but are not officially supported and you are on your own.
networking.k8s.io/v1 API MUST be implemented by a proper ingress
Yaook itself does not require an external load balancer, but it is likely that your ingress controller (see above) will.
cert-manager.io/v1 API MUST be implemented.
monitoring.coreos.com/v1 Custom Resources MUST exist.
The usage of these resources (e.g. by the Prometheus Operator) is optional.
The following details additional storage requirements for individual services.
Cinder supports Ceph and/or Netapp as a block storage backend.
Glance supports Ceph or PVCs (via the file backend) as a storage backend.
PVCs need to support
ReadWriteMany as access method.
Gnocchi supports Ceph or S3 as a storage backend.
If Ceph should be used with Yaook it is RECOMMENDED to deploy the ceph cluster using Rook.io. It is OPTIONAL to run it in the same Kubernetes cluster as Yaook itself. Furthermore, these are the requirements that Ceph is posing on the kubernetes nodes.
If your underlying cluster is created by yaook/k8s, we recommend to use yaook/k8s to install rook, since it automatically configures rook to create and attach volumes for rook to use as storage devices.