OpenStack-Helm

The MariaDB chart deploys a 3-member Galera cluster using Kubernetes StatefulSets with persistent storage.

Deployment Lifecycle:

1. Seed Job: A temporary standalone Galera cluster is created via a Kubernetes Job. This job bootstraps authentication and exposes WSREP bindings.
2. StatefulSet Provisioning: Cluster members are provisioned one at a time. A member must pass its readinessProbes (validating MySQL is up and responsive) before the next member is provisioned.
3. Synchronization: The cluster uses xtrabackup-v2 for synchronization.
4. Cluster Completion: The seed job completes only when Galera reports as Synced and the number of reporting cluster members matches the replica count defined in your Helm values.
5. Steady State: Once the seed job terminates, new StatefulSet members will use the existing cluster members as gcomm endpoints instead of the seed job. This mechanism allows for scaling and restarting members.

Storage: StatefulSets use Persistent Volume Claims (PVCs) to provide stateful storage for /var/lib/mysql.

The deploy-env role relies entirely on specific Ansible inventory groups to determine where components are installed. You must define the following groups:

• primary: The deployer's machine. This is where kubectl and helm CLI tools are installed. This group must contain exactly one node.
• k8s_control_plane: The node(s) where the Kubernetes control plane is deployed. This group must contain exactly one node.
• k8s_cluster: All nodes belonging to the Kubernetes cluster, including both control plane and worker nodes.
• k8s_nodes: The worker nodes in the cluster.

Special Configurations:

• Single-node setup: If you want the control plane node to also run all workloads (single-node cluster), the k8s_nodes group must be empty. In this case, the primary node and the k8s_control_plane node can be the same physical machine.
• Multi-node setup: Include your worker nodes in the k8s_nodes group.

all:
  vars:
    ansible_port: 22
    ansible_user: ubuntu
    ansible_ssh_private_key_file: /home/ubuntu/.ssh/id_rsa
    ansible_ssh_extra_args: -o StrictHostKeyChecking=no
  hosts:
    primary:
      ansible_host: 10.10.10.10
    node-1:
      ansible_host: 10.10.10.11
    node-2:
      ansible_host: 10.10.10.12
    node-3:
      ansible_host: 10.10.10.13
  children:
    primary:
      hosts:
        primary:
    k8s_cluster:
      hosts:
        node-1:
        node-2:
        node-3:
    k8s_control_plane:
      hosts:
        node-1:
    k8s_nodes:
      hosts:
        node-2:
        node-3:

The Elasticsearch chart includes a CronJob for Elastic Curator to automate index management tasks such as taking snapshots, deleting old indices, restoring indices, or reindexing.

Important Configuration Rules:

• Configuration is handled via the conf.curator section in values.yaml.
• Do not use "None" for unused fields. If a field is not needed, leave it blank. Entering the string "None" will cause Curator to interpret it as a Python NoneType, resulting in an exception.

Curator configuration is split into two main parts: client (connection settings) and action_file (the actual lifecycle tasks).

conf:
  curator:
    client:
      hosts: ["elasticsearch-logging"]
      port: 9200
      use_ssl: False
      # Leave unused fields blank, not "None"
      certificate: 
    logging:
      loglevel: INFO
    action_file:
      actions:
        1:
          action: delete_indices
          description: "Clean up ES by deleting old indices"
          options:
            disable_action: True # Actions are disabled by default
          filters:
            - filtertype: age
              source: name
              direction: older
              timestring: '%Y.%m.%d'
              unit: days
              unit_count: 30

OpenStack-Helm utilizes a Prometheus and Grafana-based stack for metrics collection, alerting, and visualization.

Core Components:

• Prometheus: Scrapes metrics from targets via HTTP and stores them in a time-series database. It uses a specific querying language and supports service discovery or static configuration. It is used to evaluate alerting rules.
• Alertmanager: Interfaces with Prometheus to handle and send alerts based on rule evaluations.
• Grafana: Connects to Prometheus as a data source to provide single-pane dashboards. Dashboards can be bootstrapped via ConfigMaps or added via the web interface.
• Exporters: Specialized components (e.g., kube-state-metrics, ceph-exporter, openstack-exporter) that translate service-specific metrics into a format Prometheus can scrape.

Monitored Metrics Categories:

• Host Utilization: CPU, memory, disk I/O, and network I/O.
• Kubernetes: Pod status, replica availability, and job status.
• Ceph: Pool usage, latency, and health.
• OpenStack: Tenants, networks, flavors, floating IPs, and quotas.