After you complete the prerequisite steps described in Prerequisites,
proceed with bootstrapping your OpenStack-based Mirantis Container Cloud
management cluster.
To bootstrap an OpenStack-based management cluster:
Log in to the bootstrap node running Ubuntu 20.04 that is configured
as described in Prerequisites.
Prepare the bootstrap script:
Download and run the Container Cloud bootstrap script:
If you deploy Container Cloud on top of MOSK Victoria with Tungsten Fabric
and use the default security group for newly created load balancers, add the
following rules for the Kubernetes API server endpoint, Container Cloud
application endpoint, and for the MKE web UI and API using the OpenStack CLI:
direction='ingress'
ethertype='IPv4'
protocol='tcp'
remote_ip_prefix='0.0.0.0/0'
port_range_max and port_range_min:
'443' for Kubernetes API and Container Cloud application endpoints
'6443' for MKE web UI and API
Verify access to the target cloud endpoint from Docker. For example:
In case of issues, follow the steps provided in Troubleshooting.
Configure the cluster and machines metadata:
Adjust the templates/cluster.yaml.template parameters to suit your
deployment:
In the spec::providerSpec::value section, add the mandatory
ExternalNetworkID parameter that is the ID of an external
OpenStack network. It is required to have public Internet access
to virtual machines.
In the spec::clusterNetwork::services section, add the
corresponding values for cidrBlocks.
Configure other parameters as required.
In templates/machines.yaml.template,
modify the spec:providerSpec:value section for 3 control plane nodes
marked with the cluster.sigs.k8s.io/control-plane label
by substituting the flavor and image parameters
with the corresponding values of the control plane nodes in the related
OpenStack cluster. For example:
The flavor parameter value provided in the example above
is cloud-specific and must meet the Container Cloud
requirements.
Also, modify other parameters as required.
Available since Container Cloud 2.24.0. Optional.
Technology Preview. Enable custom host names for cluster machines.
When enabled, any machine host name in a particular region matches the related
Machine object name. For example, instead of the default
kaas-node-<UID>, a machine host name will be master-0. The custom
naming format is more convenient and easier to operate with.
To enable the feature on the management and its future managed clusters:
Since 2.25.0
In templates/cluster.yaml.template, find the
spec.providerSpec.value.kaas.regional section of the required
region.
In this section, find the required provider name under
helmReleases.
Under values.config, add customHostnamesEnabled:true.
For example, for the bare metal provider in region-one:
Optional. Available as TechPreview. To boot cluster machines from a block
storage volume, define the following parameter in the spec:providerSpec
section of templates/machines.yaml.template:
To boot the Bastion node from a volume, add the same parameter to
templates/cluster.yaml.template in the spec:providerSpec section
for Bastion. The default amount of storage 80 is enough.
Optional. Available since Container Cloud 2.24.0 as Technology Preview.
Create all load balancers of the cluster with a specific Octavia flavor by
defining the following parameter in the spec:providerSpec section of
templates/cluster.yaml.template:
Before Container Cloud 2.23.0, optional if servers from the Ubuntu NTP pool
(*.ubuntu.pool.ntp.org) are accessible from the node where
the management cluster is being provisioned. Otherwise, configure the
regional NTP server parameters as described below.
Since Container Cloud 2.23.0, optionally disable NTP that is enabled by default. This option disables the
management of chrony configuration by Container Cloud to use your own
system for chrony management. Otherwise, configure the regional NTP server
parameters as described below.
NTP configuration
Configure the regional NTP server parameters to be applied to all machines
of regional and managed clusters in the specified region.
In templates/cluster.yaml.template, add the ntp:servers section
with the list of required server names:
Optional. If you require all Internet access to go through a proxy server,
in bootstrap.env, add the following environment variables
to bootstrap the management and regional cluster using proxy:
Available since Container Cloud 2.24.0 and 2.24.2 for MOSK 23.2. Optional.
Technology Preview. Enable the Linux Audit daemon auditd
to monitor activity of cluster processes and prevent potential malicious
activity.
Configuration for auditd
In templates/cluster.yaml.template, add the auditd parameters:
Boolean, default - false. Enables the auditd role to install the
auditd packages and configure rules. CIS rules: 4.1.1.1, 4.1.1.2.
enabledAtBoot
Boolean, default - false. Configures grub to audit processes that can
be audited even if they start up prior to auditd startup. CIS rule:
4.1.1.3.
backlogLimit
Integer, default - none. Configures the backlog to hold records. If during
boot audit=1 is configured, the backlog holds 64 records. If more than
64 records are created during boot, auditd records will be lost with a
potential malicious activity being undetected. CIS rule: 4.1.1.4.
maxLogFile
Integer, default - none. Configures the maximum size of the audit log file.
Once the log reaches the maximum size, it is rotated and a new log file is
created. CIS rule: 4.1.2.1.
maxLogFileAction
String, default - none. Defines handling of the audit log file reaching the
maximum file size. Allowed values:
keep_logs - rotate logs but never delete them
rotate - add a cron job to compress rotated log files and keep
maximum 5 compressed files.
compress - compress log files and keep them under the
/var/log/auditd/ directory. Requires
auditd_max_log_file_keep to be enabled.
CIS rule: 4.1.2.2.
maxLogFileKeep
Integer, default - 5. Defines the number of compressed log files to keep
under the /var/log/auditd/ directory. Requires
auditd_max_log_file_action=compress. CIS rules - none.
mayHaltSystem
Boolean, default - false. Halts the system when the audit logs are
full. Applies the following configuration:
space_left_action=email
action_mail_acct=root
admin_space_left_action=halt
CIS rule: 4.1.2.3.
customRules
String, default - none. Base64-encoded content of the 60-custom.rules
file for any architecture. CIS rules - none.
customRulesX32
String, default - none. Base64-encoded content of the 60-custom.rules
file for the i386 architecture. CIS rules - none.
customRulesX64
String, default - none. Base64-encoded content of the 60-custom.rules
file for the x86_64 architecture. CIS rules - none.
presetRules
String, default - none. Comma-separated list of the following built-in
preset rules:
access
actions
delete
docker
identity
immutable
logins
mac-policy
modules
mounts
perm-mod
privileged
scope
session
system-locale
time-change
You can use two keywords for these rules:
none - disables all built-in rules.
all - enables all built-in rules. With this key, you can add the
! prefix to a rule name to exclude some rules. You can use the
! prefix for rules only if you add the all keyword as the
first rule. Place a rule with the ! prefix only after
the all keyword.
Example configurations:
presetRules:none - disable all preset rules
presetRules:docker - enable only the docker rules
presetRules:access,actions,logins - enable only the
access, actions, and logins rules
presetRules:all - enable all preset rules
presetRules:all,!immutable,!sessions - enable all preset
rules except immutable and sessions
Optional. Enable infinite timeout for all bootstrap stages by exporting the
following environment variable or adding it to bootstrap.env:
exportKAAS_BOOTSTRAP_INFINITE_TIMEOUT=true
Infinite timeout prevents the bootstrap failure due to timeout. This option
is useful in the following cases:
The network speed is slow for artifacts downloading
An infrastructure configuration does not allow booting fast
A bare-metal node inspecting presupposes more than two HDDSATA disks
to attach to a machine
Optional. Available since Container Cloud 2.23.0. Customize the cluster and
region name by exporting the following environment variables or adding them
to bootstrap.env:
The Keycloak URL that the system outputs when the bootstrap completes.
The admin password for Keycloak is located in
kaas-bootstrap/passwords.yml along with other IAM passwords.
Note
The Container Cloud web UI and StackLight endpoints are available
through Transport Layer Security (TLS) and communicate with Keycloak
to authenticate users. Keycloak is exposed using HTTPS and
self-signed TLS certificates that are not trusted by web browsers.
Not all of Swarm and MCR addresses are usually in use. One Swarm Ingress
network is created by default and occupies the 10.0.0.0/24 address
block. Also, three MCR networks are created by default and occupy
three address blocks: 10.99.0.0/20, 10.99.16.0/20,
10.99.32.0/20.
To verify the actual networks state and addresses in use, run: