Bareos Ubuntu Prerequisites

This document describes creation of a single master, multiple node BareOS cluster using PMK. We recommend reading what is BareOSarrow-up-right for an understanding of BareOS and BareOS Cluster Architecturearrow-up-right before proceeding with this document.

A single master, multi-node Kubernetes cluster consists of one dedicated master node that is not used to run any workloads, and one or more worker nodes. The master node runs the Kubernetes control plane and the etcdarrow-up-right distributed database.

This type of cluster configuration should only be used to run workloads that can tolerate cluster downtime due to the single master node going down. For business critical production workloads that cannot tolerate any downtime, we recommend running them on a multi-master cluster.

triangle-exclamation

Create BareOS Cluster Using UI

Follow the steps given below to create a BareOS Kubernetes cluster using the PMK UI.

Step 1 – Login to the UI with either your Local Credentials or Single Sign On (Enterprise).

Step 2 – Navigate to the Infrastructure > Clusters tab and click on + Add Cluster.

Step 3 – In the cluster creation wizard, choose the "Signle-Master Cluster" option

Platform9 UI – Infrastructure - Clusters - Deploy
Platform9 UI – Infrastructure - Clusters - Deploy

Step 4 - On the Initial Setup page of the wizard, give your cluster a name. Select the Kubernetes version you'd like to deploy the cluster with. (If unsure, select the highest listed numeric version). The remaining properties can be left to their default values.

Step 5 – Follow the instructions to download and configure the PMK CLIarrow-up-right for each of the nodes to be onboarded and incorporated as part of the cluster.

Platform9 UI – Infrastructure - Clusters - Deploy - Multi-Master – Insufficient Nodes
Platform9 UI – Infrastructure - Clusters - Deploy - Multi-Master – Insufficient Nodes
circle-info

Info

The prep-nodearrow-up-right command will perform prerequisitesarrow-up-right checks on your node. If any checks fail, you will receive an output similar to the following.

circle-exclamation
triangle-exclamation
circle-info

Info

Step 5 - Once you have prepared all the nodes that will become part of your cluster, return to the PMK UI cluster creation wizard, and Next to proceed to the Master Node page of the wizard.

Step 6 – On the Master Node page of the wizard, you should now see all the nodes that you prepared in the previous step listed in the table. Select one of the nodes to be the master for your cluster. This node will run the Kubernetes control plane along with the etcd database.

Proceed to Next step.

Step 7 - In the Worker Node selection page of the wizard, select one or more nodes as worker nodes for your cluster.

Step 8 - At this point, you can choose to leave all the remaining properties of the wizard to their default values and click Finish and Review to review your cluster creation request before submitting it for creation.

At this point, your cluster is created and ready for use!

Step 9 - Following table describes all the options provided to you in the cluster creation wizard. Use this information to understand the various options provided to you, and to make meaningful changes to them when required.

Option
Description

Cluster Settings

Kubernetes Version

Select the Kubernetes Version from the list of supported Kubernetes versionsarrow-up-right.

Application & Container Settings

Privileged Containers

Select the check box to enable the cluster to run privileged containers. Note that being able to run privileged containers within the cluster is a prerequisite if you wish to enable service type load balancer using MetalLB. By default a container is not allowed to access any devices on the host, but a “privileged” container is given access to all devices on the host. For more information, see Privileged Policy Referencearrow-up-right

Make Master nodes Master + Worker

Opt to schedule workloads onto the master nodes, or, deploy only the necessary control plane services and cordon the masters otherwise.

Cluster Add-Ons

Enable ETCD Backup

Configures automated etcd backups

Deploy MetalLB + Layer2 Mode

MetalLB is a software load balancer that is deployed and managed by Platform9. MetalLB will be automatically attached to the cluster and allow services to be deployed using the LoadBalancer service type. Simplifying the steps required to make applications accessible outside of the cluster. Requirements: MetalLB requires a reserved network address range. MetalLB will manage the IP range to expose Kubernetes services Example: Starting IP 10.128.159.250 – Ending IP 10.128.159.253

Monitoring

KubeVirt

Network Plugin Operator

ETCD Backup Configuration

Storage Path

Storage path on the master node where etcd backups will be stored Requirement: The storage path specified here must be created and available on all Master Nodes

Backup Interval (Minutes)

Controls how often the backups will be performed (in minutes).

MetalLB Configuration

Address Range

Address range to be used by MetalLB when allocating to service load balancer instances. Example: Starting IP 10.128.159.250 – Ending IP 10.128.159.253

Field

Value

Cluster API FQDN

API FQDN

The FQDN (DNS Name) that is to be used to access the Kubernetes cluster API server from outside of the cluster.

Cluster Virtual IP Configuration

Virtual IP Address for Cluster

Required only when creating a multi-master cluster. The reserved IP address or the highly availability floating IP address with which the user accesses the cluster.

Physical Interface for Virtual IP Association

Required only when creating a multi-master cluster The network interface to which the virtual IP gets associated. Ensure that the virtual IP specified above is accessible on this network interface, and that all master nodes use the same interface name for the interface to be associated with the virtual IP.

Cluster Networking Range & HTTP Proxy

Containers CIDR

Required The IP range that Kubernetes uses to configure the Pods (Docker containers) deployed by Kubernetes.

Services CIDR

Required The IP range that Kubernetes uses to configure services deployed by Kubernetes

HTTP Proxy

Field
Option

Advanced API Configuration

Default API groups and versions

Select the Default API groups and versions option to enable on the cluster, the default APIs based on the Kubernetes installation in your environment

All API groups and versions

Select All API groups and versions option to enable on the cluster, all alpha, beta, and GA versions of Kubernetes APIs that have been published till date.

Custom API groups and versions

Select Custom API groups and versions option to specify one or more API versions that you wish to enable and/or disable. Enter the API versions in the text area following the Custom API groups and versions option. For example, to enable Kubernetes v1 APIs, enter the expression,api/v1=true. Similarly, to disable Kubernetes v2 APIs, enter the expression, api/v2=false. If you want to enable and/or disable multiple versions, you could enter comma-separated expressions, such as, api/v2=false,api/v1=true.

At this point, your cluster is deployed, and you are ready to start creating your workloads on it.

Create BareOS Cluster Using REST API

For advanced users, you can automate the process of creating a multi-master BareOS Kubernetes cluster by integrating with our PMK (Qbert) REST APIarrow-up-right.

Last updated

Was this helpful?