Appendix¶

Cluster Labels¶

Kubernetes clusters can have one or more labels applied to them, to control how your cluster is configured, and what gets installed into it.

Labels can only be applied to a cluster when it is created.

Available cluster labels¶

Label	Type	Default Value	Accepted Values / Examples	Description
`master_lb_floating_ip_enabled`	Boolean	`false`	`true` or `false`	Assign a floating IP to the Kubernetes API load balancer, to allow access to the Kubernetes API via the public Internet.
`api_master_lb_allowed_cidrs`	IPv4/IPv6 CIDR	`0.0.0.0/0`	`192.0.2.1/32`	Specify a set of CIDR ranges that should be allowed to access the Kubernetes API. Multiple values can be defined (see Specifying multiple label values).
`extra_network_name`	String	`null`	Network Name	Optional additional network to attach to cluster worker nodes. Useful for allowing access to external networks from the workers.
`csi_cinder_reclaim_policy`	Enumeration	`Retain`	`Retain` or `Delete`	Policy for reclaiming dynamically created persistent volumes. For more information, see Persistent Volume Retention.
`csi_cinder_fstype`	Enumeration	`ext4`	`ext4`	Filesystem type for persistent volumes.
`csi_cinder_allow_volume_expansion`	Boolean	`true`	`true` or `false`	Allows for expansion of volumes by editing the corresponding `PersistentVolumeClaim` object.
`kube_dashboard_enabled`	Boolean	`true`	`true` or `false`	Install the Kubernetes Dashboard into the cluster.
`boot_volume_size`	Integer	`20`	Greater than 0	The size (in GiB) to create the boot volume for Control Plane and Worker nodes. Currently, this is the only disk attached to nodes.
`boot_volume_type`	Enumeration	`b1.sr-r3-nvme-1000`	See Volume Tiers for a list of volume type names	The Block Storage volume type name to use for the boot volume.
`auto_scaling_enabled`	Boolean	`false`	`true` or `false`	Enable Worker node auto scaling in the cluster. When set to `true`, `min_node_count` and `max_node_count` must also be set.
`min_node_count`	Integer	`null`	Greater than 0	Minimum number of Worker nodes for auto scaling. This value is required if `auto_scaling_enabled` is `true`.
`max_node_count`	Integer	`null`	Greater than `min_node_count`	Maximum number of Worker nodes to scale out to, if auto scaling is enabled. This value is required if `auto_scaling_enabled` is `true`.
`auto_healing_enabled`	Boolean	`true`	`true` or `false`	Enable auto-healing on control plane and worker nodes. With auto-healing enabled, if nodes become `NotReady` for an extended duration they will be replaced. Note: Control plane machines will only be remediated one at a time. Worker nodes will not be remediated if 40% are considered unhealthy, preventing some cascading failures.
`keystone_auth_enabled`	Boolean	`true`	`true` or `false`	With this option enabled, a deployment will be installed into your cluster allowing the use of Role-Based Access Control with Catalyst Cloud’s authentication system. For more information see Role-Based Access Control. With this option disabled, the admin kubeconfig is still available as well as Kubernetes API Access Control.

Applying labels when creating a cluster¶

Labels may be set on a cluster at creation time either via the API or in the dashboard.

When running openstack coe cluster create, set the --labels option to define custom labels.

Each label should be provided in a comma-separated list of key-value pairs.

Note

Make sure to also define the --merge-labels option when defining custom labels.

Here is an example of setting a few custom labels:

openstack coe cluster create my-cluster-name \
--cluster-template kubernetes-v1.28.9-20240416 \
...
--merge-labels \
--labels csi_cinder_reclaim_policy=Retain,kube_dashboard_enabled=true,master_lb_floating_ip_enabled=false

Note

It is not possible to modify labels on a cluster in-place after it has been created.

When defining the openstack_containerinfra_cluster_v1 resource, use the labels attribute to define a label key-value mapping.

Note

Make sure to also set the merge_labels attribute to true when defining custom labels.

Here is an example of setting a few custom labels:

resource "openstack_containerinfra_cluster_v1" "my-cluster-name" {
  name                = "my-cluster-name"
  cluster_template_id = "b9a45c5c-cd03-4958-82aa-b80bf93cb922"
  ...
  merge_labels        = true
  labels = {
    csi_cinder_reclaim_policy     = "Retain"
    kube_dashboard_enabled        = "true"
    master_lb_floating_ip_enabled = "false"
  }
}

Warning

It is not possible to modify labels on a cluster in-place after it has been created.

If the labels are modified in Terraform after a cluster has been created, the cluster will be re-created, so be careful not to modify them unintentionally.

Specifying multiple label values¶

Some labels can have multiple values set for them.

Using the CLI, you can specify multiple copies of the label key-value pair, each with their own unique value.

For example, to define multiple CIDRs for api_master_lb_allowed_cidrs:

openstack coe cluster create my-cluster-name \
--cluster-template kubernetes-v1.28.9-20240416 \
...
--merge-labels \
--labels master_lb_floating_ip_enabled=true,api_master_lb_allowed_cidrs=192.0.2.1/32,api_master_lb_allowed_cidrs=192.0.2.2/32

When defining the openstack_containerinfra_cluster_v1 resource, define the label value as a comma-separated string, with all values listed.

For example, to define multiple CIDRs for api_master_lb_allowed_cidrs:

resource "openstack_containerinfra_cluster_v1" "my-cluster-name" {
  name                = "my-cluster-name"
  cluster_template_id = "b9a45c5c-cd03-4958-82aa-b80bf93cb922"
  ...
  merge_labels        = true
  labels = {
    master_lb_floating_ip_enabled = "true"
    api_master_lb_allowed_cidrs   = "192.0.2.1/32,192.0.2.2/32"
  }
}