Enrico Biella

Deploying OpenStack with Helm and FluxCD on Kubernetes

Mon, 20 Jul 2026 00:00:00 GMT

Following up on our previous post where we automated a production-ready Kubernetes cluster, this guide details how to deploy a complete OpenStack environment on top of it. We will use the OpenStack-Helm 2026.1.0 charts and manage the entire lifecycle through a GitOps workflow powered by FluxCD.

This approach treats your OpenStack deployment as code, ensuring reproducibility, auditability, and simplified management.

Architecture Overview

The deployment is managed from a central Git repository. FluxCD continuously reconciles the state of the Kubernetes cluster with the configuration defined in Git. The OpenStack-Helm charts themselves are treated as read-only upstream sources, with all customizations applied via Helm value overrides.

Here's a breakdown of the layers:

┌──────────────────────────────────────────────────────────────────┐
│  Git Repository (this repo)                                      │
│  FluxCD config + Helm value overrides only                       │
│  charts/ = READ-ONLY upstream 2026.1.0 (never modified)          │
└───────────────────────┬──────────────────────────────────────────┘
                        │ FluxCD reconciles
                        ▼
┌──────────────────────────────────────────────────────────────────┐
│  Kubernetes Cluster (prod / region1)                             │
│                                                                  │
│  Infrastructure layer (Ansible-managed, pre-deployed)            │
│  ├── MetalLB L2           gateway VIP: 172.24.61.20              │
│  ├── Envoy Gateway        gateway-default / envoy-gateway-system │
│  ├── cert-manager         TLS automation                         │
│  ├── Rook-Ceph            RBD block storage                      │
│  └── FluxCD               GitOps controllers                     │
│                                                                  │
│  openstack namespace (FluxCD-managed)                            │
│  ├── PKI: selfsigned-bootstrap → openstack-ca (internal TLS)    │
│  ├── Infrastructure: rabbitmq, mariadb, memcached, redis, etcd   │
│  ├── Storage: ceph-adapter-rook                                  │
│  ├── Networking: openvswitch, ovn, libvirt                       │
│  ├── Core: keystone, glance, cinder, placement, neutron, nova    │
│  ├── Extended: barbican, heat, magnum, octavia, designate        │
│  ├── Dashboard: skyline                                          │
│  └── Monitoring: prometheus, mysql-exporter, os-exporter         │
└──────────────────────────────────────────────────────────────────┘

All public-facing services are exposed via a single external IP (172.24.61.20) and are accessible via https://<service>.172.24.61.20.nip.io.

Key Design Decisions

This setup incorporates several important design choices to ensure a robust and maintainable production environment.

Helm Hook Removal in 2026.1.0

OpenStack-Helm 2026.1.0 has removed support for Helm 2, and with it, the helm3_hook value. All jobs (like database initialization, user creation, etc.) are now standard Kubernetes Job resources.

Job Ordering: Instead of Helm hooks, job execution order is managed by kubernetes-entrypoint init containers within each service pod. These containers check a list of static dependencies (dependencies.static.<component>.jobs) and wait for required jobs to reach the Completed state before allowing the main service container to start.
Job Protection: To prevent FluxCD or Helm from deleting completed jobs during reconciliation, we apply a global patch to all Job resources, setting helm.sh/resource-policy: keep. This is critical for stability. To re-run a job (e.g., after an upgrade), you must manually delete it first.

Cluster-Managed Gateway

The Gateway resource, which defines how traffic enters the cluster, is managed by our Ansible playbooks from the previous guide, not by FluxCD. This separates the core ingress infrastructure from the application layer.

Gateway Name: gateway-default
Gateway Namespace: envoy-gateway-system
TLS: A single wildcard certificate (gateway-wildcard-tls) covers all *.{ip}.nip.io subdomains.
Cross-Namespace Routing: The gateway is configured to allow HTTPRoute resources from any namespace to attach to it, which is how our openstack namespace exposes its services.

Only the HTTPRoute resources, which map paths to OpenStack services, are managed via GitOps.

HTTPS-Only Public Endpoints

Security is paramount. All public-facing OpenStack endpoints are configured for HTTPS only (scheme.public: https on port 443). A global HTTPRoute is set up to automatically redirect any incoming HTTP (port 80) traffic to its HTTPS equivalent. Internal cluster communication between OpenStack services remains plain HTTP for performance.

Internal Public Key Infrastructure (PKI)

The deployment establishes its own internal PKI using cert-manager, completely separate from the gateway's TLS certificate. This is used for securing internal components like MariaDB and RabbitMQ with mTLS.

The chain of trust is: selfsigned-bootstrap (ClusterIssuer) -> openstack-ca (Certificate) -> openstack-ca (ClusterIssuer) -> per-service certificates

Repository Structure

A well-organized GitOps repository is key. Here is the layout:

charts/                              # READ-ONLY upstream 2026.1.0 charts
clusters/
└── prod/
    ├── flux-system/                 # Flux GitSource + Kustomization entries
    └── region1/
        └── openstack/
            ├── kustomization.yaml
            ├── patch-helmrelease-openstack-gitops.yaml   # Global patch for Jobs
            ├── patch-helmrelease-timeouts.yaml
            ├── pki/                 # Internal PKI bootstrap manifests
            ├── releases/            # HelmRelease manifests (one per chart)
            ├── values/              # Helm value overrides as ConfigMaps
            │   ├── credentials.yaml (SOPS-encrypted)
            │   └── ...
            └── gateway/
                └── httproutes.yaml  # HTTPRoutes for OpenStack services
.sops.yaml                           # SOPS age key configuration

Prerequisites

Cluster Infrastructure

This guide assumes you have a running Kubernetes cluster with the following components, as configured in our previous article:

| Component | Purpose | | ------------- | -------------------------------------------------- | | MetalLB | Provides the VIP 172.24.61.20 for the gateway. | | Envoy Gateway | Manages ingress traffic via the gateway-default. | | cert-manager | Automates TLS certificate management. | | Rook-Ceph | Provides RBD block storage for Cinder and Glance. | | FluxCD | Powers the GitOps reconciliation loop. |

Admin Workstation Setup

You'll need the following tools on your local machine to manage the deployment:

# Install SOPS and age for credential encryption
sudo apt update && sudo apt install -y age
curl -LO curl -LO https://github.com/getsops/sops/releases/download/v3.13.2/sops-v3.13.2.linux.amd64
sudo install sops-v3.13.2.linux.amd64 /usr/local/bin/sops

Deployment Walkthrough

Step 1: Node Preparation

First, prepare your Kubernetes worker nodes. OpenStack components require higher inotify limits for monitoring file changes. We also need to label the nodes so that the OpenStack-Helm charts can correctly schedule pods.

# Increase inotify limits on all worker nodes
for NODE in k8s-worker1 k8s-worker2 k8s-worker3; do
  ssh $NODE "sudo sysctl -w fs.inotify.max_user_watches=524288 && \
             sudo sysctl -w fs.inotify.max_user_instances=1024"
done

# Label nodes for OpenStack roles
for NODE in k8s-worker1 k8s-worker2 k8s-worker3; do
  kubectl label --overwrite nodes $NODE \
    openstack-control-plane=enabled \
    openstack-compute-node=enabled \
    openvswitch=enabled \
    l3-agent=enabled \
    openstack-network-node=enabled
done

# Create the target namespace
kubectl create namespace openstack

Step 2: Credential Encryption with SOPS

Never commit plain-text secrets to Git. We use SOPS with age to encrypt our credentials.yaml file.

Generate an age keypair:

age-keygen -o age.agekey
# This will output a public key, e.g., age1ql3z...

Store the private key in the cluster: FluxCD needs the private key to decrypt the credentials.

kubectl create secret generic sops-age \
  --namespace=flux-system \
  --from-file=age.agekey=./age.agekey

Configure and encrypt: Add the public key to your .sops.yaml file. Then, populate clusters/prod/region1/openstack/values/credentials.yaml with your desired passwords and encrypt it.
```
sops --encrypt --in-place clusters/prod/region1/openstack/values/credentials.yaml
```
You can now safely commit the encrypted file. To edit it later, simply run sops clusters/prod/region1/openstack/values/credentials.yaml, which will open it in your default editor and re-encrypt on save.

Example credentials.yaml file Use this file as example for you repo

# ============================================================
# SOPS ENCRYPTION REQUIRED BEFORE COMMITTING TO GIT
#
# Steps:
#   1. Fill in all Password1
#   2. Run: sops --encrypt --in-place clusters/prod/openstack/values/credentials.yaml
#   3. Only then: git add clusters/prod/openstack/values/credentials.yaml && git commit
#
# To edit after encryption:
#   sops clusters/prod/openstack/values/credentials.yaml
# ============================================================
apiVersion: v1
kind: Secret
metadata:
  name: openstack-credentials
  namespace: openstack
stringData:
  values.yaml: |-
    endpoints:
      identity:
        auth:
          admin:
            password: Password1
          cinder:
            password: Password1
          glance:
            password: Password1
          nova:
            password: Password1
          swift:
            password: Password1
          service:
            password: Password1
          test:
            password: Password1
          keystone:
            password: Password1
          neutron:
            password: Password1
          barbican:
            password: Password1
          placement:
            password: Password1
          heat:
            password: Password1
          heat_trustee:
            password: Password1
          heat_stack_user:
            password: Password1
          magnum:
            password: Password1
          magnum_stack_user:
            password: Password1
          mariadb-server:
            password: Password1
          octavia:
            password: Password1
          designate:
            password: Password1
          ironic:
            password: Password1
          skyline:
            password: Password1
          user:
            password: Password1
      oslo_db:
        auth:
          admin:
            username: root
            password: Password1
          keystone:
            username: keystone
            password: Password1
          nova:
            username: nova
            password: Password1
          nova_api:
            username: nova_api
            password: Password1
          nova_cell0:
            username: nova_cell0
            password: Password1
          neutron:
            username: neutron
            password: Password1
          cinder:
            username: cinder
            password: Password1
          glance:
            username: glance
            password: Password1
          placement:
            username: placement
            password: Password1
          heat:
            username: heat
            password: Password1
          barbican:
            username: barbican
            password: Password1
          magnum:
            username: magnum
            password: Password1
          octavia:
            username: octavia
            password: Password1
          designate:
            username: designate
            password: Password1
          powerdns:
            username: powerdns
            password: Password1
          sst:
            username: sst
            password: Password1
          audit:
            username: audit
            password: Password1
          exporter:
            username: exporter
            password: Password1
          skyline:
            username: skyline
            password: Password1
      oslo_db_persistence:
        auth:
          admin:
            username: root
            password: Password1
          octavia:
            username: octavia
            password: Password1
      oslo_db_api:
        auth:
          admin:
            username: root
            password: Password1
          nova:
            username: nova
            password: Password1
      oslo_db_cell0:
        auth:
          admin:
            username: root
            password: Password1
          nova:
            username: nova
            password: Password1
      ceph_object_store:
        auth:
          glance:
            username: glance
            password: Password1
            tempurlkey: supersecret
      oslo_messaging:
        auth:
          admin:
            username: rabbitmq
            password: Password1
          user:
            username: rabbitmq
            password: Password1
          guest:
            password: Password1
          keystone:
            username: keystone
            password: Password1
          nova:
            username: nova
            password: Password1
          neutron:
            username: neutron
            password: Password1
          cinder:
            username: cinder
            password: Password1
          glance:
            username: glance
            password: Password1
          heat:
            username: heat
            password: Password1
          barbican:
            password: Password1
          magnum:
            username: magnum
            password: Password1
          octavia:
            username: octavia
            password: Password1
          designate:
            username: designate
            password: Password1
      powerdns:
        auth:
          admin:
            password: Password1
      oci_image_registry:
        auth:
          barbican:
            username: barbican
            password: Password1
          cinder:
            username: cinder
            password: Password1
          designate:
            username: designate
            password: Password1
          etcd:
            username: etcd
            password: Password1
          glance:
            username: glance
            password: Password1
          heat:
            username: heat
            password: Password1
          keystone:
            username: keystone
            password: Password1
          libvirt:
            username: libvirt
            password: Password1
          magnum:
            username: magnum
            password: Password1
          mariadb:
            username: mariadb
            password: Password1
          memcached:
            username: memcached
            password: Password1
          neutron:
            username: neutron
            password: Password1
          nova:
            username: nova
            password: Password1
          octavia:
            username: octavia
            password: Password1
          openvswitch:
            username: openvswitch
            password: Password1
          ovn:
            username: ovn
            password: Password1
          placement:
            username: placement
            password: Password1
          powerdns:
            username: powerdns
            password: Password1
          prometheus:
            username: prometheus
            password: Password1
          prometheus-mysql-exporter:
            username: prometheus-mysql-exporter
            password: Password1
          prometheus-openstack-exporter:
            username: prometheus-openstack-exporter
            password: Password1
          rabbitmq:
            username: rabbitmq
            password: Password1
          redis:
            username: redis
            password: Password1
          skyline:
            username: skyline
            password: Password1

Step 3: Bootstrap FluxCD

Point FluxCD at your Git repository to kick off the deployment.

# Run a pre-flight check
flux check --pre

# Bootstrap FluxCD against your GitLab repository
flux bootstrap gitlab \
  --owner=<your-gitlab-group> \
  --repository=openstack-helm \
  --branch=main \
  --path=clusters/prod/flux-system \
  --token-auth

Step 4: Monitor the Deployment

Once Flux is bootstrapped, it will begin deploying the HelmRelease resources. The kubernetes-entrypoint logic enforces a specific order.

You can watch the progress:

# Watch all HelmReleases in the openstack namespace
flux get helmreleases -n openstack --watch

# Stream logs from the helm-controller for detailed info
kubectl logs -n flux-system deploy/helm-controller -f

The deployment will proceed in stages, starting with infrastructure services like MariaDB and RabbitMQ, then core services like Keystone, and finally the extended services and dashboard.

Accessing Your OpenStack Cloud

Once the deployment is complete, all services will be available at their respective nip.io URLs.

Service Catalog

| Service | Public URL | Notes | | ------------- | ------------------------------------------ | -------------------------- | | Keystone | https://keystone.172.24.61.20.nip.io/v3 | Identity & Auth | | Skyline | https://skyline.172.24.61.20.nip.io | Web Dashboard | | Nova | https://nova.172.24.61.20.nip.io/v2.1 | Compute API | | NoVNC | https://novnc.172.24.61.20.nip.io | VM Console Access | | Cinder | https://cinder.172.24.61.20.nip.io/v3 | Block Storage (Ceph RBD) | | Glance | https://glance.172.24.61.20.nip.io | Image Service (Ceph RBD) | | Neutron | https://neutron.172.24.61.20.nip.io | Networking (OVN) | | Placement | https://placement.172.24.61.20.nip.io | Resource Inventory | | Heat | https://heat.172.24.61.20.nip.io/v1 | Orchestration | | Barbican | https://barbican.172.24.61.20.nip.io | Key/Secret Manager | | Magnum | https://magnum.172.24.61.20.nip.io/v1 | Kubernetes as a Service | | Octavia | https://octavia.172.24.61.20.nip.io | Load Balancer as a Service | | Designate | https://designate.172.24.61.20.nip.io/v2 | DNS as a Service |

Trusting the Gateway CA

Since the gateway uses a self-signed certificate, you must configure your local environment to trust it.

# Extract the CA certificate from the cluster
kubectl get secret gateway-wildcard-tls -n envoy-gateway-system \
  -o jsonpath='{.data.ca\.crt}' | base64 -d > gateway-ca.crt

# For the OpenStack CLI, set the OS_CACERT environment variable
export OS_CACERT=/path/to/your/gateway-ca.crt

Verifying the Deployment

With the CA configured, you can use the openstack CLI to interact with your new cloud.

Install the client libraries:

pip install python-openstackclient python-magnumclient \
            python-octaviaclient python-heatclient python-designateclient

Configure clouds.yaml:

clouds:
  openstack_helm:
    region_name: RegionOne
    identity_api_version: 3
    cacert: /path/to/your/gateway-ca.crt
    auth:
      username: admin
      password: <your-admin-password>
      project_name: admin
      project_domain_name: default
      user_domain_name: default
      auth_url: https://keystone.172.24.61.20.nip.io/v3
EOF

Set the active cloud and test:

export OS_CLOUD=openstack_helm

openstack endpoint list
openstack compute service list
openstack network agent list

Maintenance and Troubleshooting

The GitOps model simplifies maintenance. To upgrade OpenStack, you would update the image tags in your values ConfigMaps, commit, and push. FluxCD handles the rolling update.

If a HelmRelease gets stuck, use flux get helmreleases and kubectl describe helmrelease to diagnose the issue. If a pod is stuck in Init, check the status of its dependency jobs with kubectl get jobs -n openstack.

This setup provides a powerful, declarative, and version-controlled foundation for running a production OpenStack cloud on Kubernetes.

Networking Deep Dive: Neutron with OVN and Open vSwitch

Our OpenStack deployment leverages the power of Open Virtual Network (OVN) as the backend for Neutron, the OpenStack Networking service. This modern architecture uses OVN and Open vSwitch (OVS) to provide a scalable and efficient software-defined network (SDN).

What is Open vSwitch (OVS)?

Think of Open vSwitch as a smart, software-based network switch that runs on every compute node in our Kubernetes cluster. [1] It operates at the data link layer (Layer 2) and is responsible for the actual forwarding of network packets between virtual machines. [2] Just like a physical switch, it learns MAC addresses to direct traffic to the correct destination. [2]

What is OVN (Open Virtual Network)?

If OVS is the muscle, OVN is the brain. OVN is a control plane for OVS, providing a higher-level abstraction for virtual networking. [1] It takes the logical network concepts from Neutron—such as virtual networks, routers, subnets, and security groups—and translates them into rules that OVS can understand. [3]

How They Work Together

The synergy between OVN and OVS is what makes the networking stack so powerful:

When you make a request to the Neutron API (e.g., "create a new network"), Neutron communicates this to OVN's Northbound database.
A central OVN component, ovn-northd, translates this high-level request into logical flows in the OVN Southbound database. [3]
On each compute node, an agent called ovn-controller is constantly watching the Southbound database. It takes the logical flows and converts them into specific, physical OpenFlow rules for the local OVS instance. [3]
OVS then uses these rules to forward packets for the VMs running on that node.

This architecture replaces the legacy collection of Python-based Neutron agents (like neutron-l3-agent, neutron-dhcp-agent) with a more robust, centralized, and database-driven control plane. [3] This results in better performance, greater scalability, and a simplified overall network architecture. [5]

Traffic Patterns: East-West vs. North-South

OVN handles two primary traffic patterns very differently, which is key to its efficiency.

East-West Traffic (Internal)

East-West traffic refers to all communication between workloads inside the OpenStack cloud. This includes:

VM-to-VM communication within the same tenant network.
Traffic between VMs in different networks that is routed through a virtual router.

This traffic stays within the OVN overlay network, encapsulated in tunnels (like Geneve or VXLAN). It is highly efficient because it doesn't need to traverse the physical network gateway, making it ideal for backend services, database replication, and internal API calls.

North-South Traffic (External)

North-South traffic is any communication between an internal workload and the outside world. Examples include:

A user accessing a web server on a VM via a Floating IP.
A VM downloading software updates from the internet.

This traffic must leave the OVN overlay and travel through a gateway to the physical network. In our Neutron setup, this is handled by:

Virtual Routers: With gateway ports connected to a provider network (like the external-net we create later).
Floating IPs: Which use Network Address Translation (NAT) to map a public IP to a VM's private IP.

Post-Deployment: Creating a Magnum Kubernetes Cluster

Now that your OpenStack cloud is running, a common next step is to use Magnum (Container Orchestration Engine) to create Kubernetes clusters for your tenants. This section guides you through creating the necessary networking and templates.

Step 1: Create External Network and Subnet (via Skyline)

Before tenants can create clusters with public IPs, you need an external network in you Administrator tenant.

Log in to the Skyline dashboard (https://skyline.172.24.61.20.nip.io) as the admin user.
Navigate on Administrator
Navigate to Network > Networks.
Click Create Network.
Give it a name, for example, external-net.
Check the External Network box.
Proceed to create a subnet for this network. Define an IP range that is routable in your physical environment but does not overlap with other services (e.g., 172.24.61.100 - 172.24.61.150). Set the gateway IP for this subnet.
Click on Console to go back to the Skyline dashboard.

Step 2: Create a Router

To connect your private tenant networks to the new external network, you need a router.

In Skyline, go to Network > Routers.
Click Create Router.
Give it a name (e.g., provider-router).
After creation, click on the router and set its gateway to the external-net you created.
You can then add interfaces to connect this router to existing private tenant networks.

Step 3: Prepare Fedora CoreOS Image for Magnum

Magnum uses specific images to boot Kubernetes nodes. Fedora CoreOS is a common choice. The following commands should be run on a machine with the OpenStack CLI installed and configured.

# Set the desired Fedora CoreOS version
export FCOS_VERSION="35.20220116.3.0"

# Download the image
wget https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/${FCOS_VERSION}/x86_64/fedora-coreos-${FCOS_VERSION}-openstack.x86_64.qcow2.xz

# Decompress the image
unxz fedora-coreos-${FCOS_VERSION}-openstack.x86_64.qcow2.xz

# Upload the image to Glance
openstack image create \
  --public \
  --disk-format=qcow2 \
  --container-format=bare \
  --file=fedora-coreos-${FCOS_VERSION}-openstack.x86_64.qcow2 \
  --property os_distro='fedora-coreos' \
  fedora-coreos-latest

This makes a public image named fedora-coreos-latest available in Glance for Magnum to use.

Step 4: Create the Magnum Cluster Template

A cluster template defines the parameters for creating Kubernetes clusters. This command creates a template that uses the Fedora CoreOS image and Calico for networking.

openstack coe cluster template create k8s-cluster-template \
  --image fedora-coreos-latest \
  --keypair <your-keypair-name> \
  --external-network external-net \
  --dns-nameserver 8.8.8.8 \
  --master-flavor m2.small \
  --flavor m2.small \
  --docker-volume-size 15 \
  --network-driver calico \
  --volume-driver cinder \
  --coe kubernetes \
  --public \
  --labels kube_tag=v1.28.9-rancher1,container_runtime=containerd,containerd_version=1.6.31,containerd_tarball_sha256=75afb9b9674ff509ae670ef3ab944ffcdece8ea9f7d92c42307693efa7b6109d,cloud_provider_tag=v1.27.3,cinder_csi_plugin_tag=v1.27.3,k8s_keystone_auth_tag=v1.27.3,magnum_auto_healer_tag=v1.27.3,octavia_ingress_controller_tag=v1.27.3,calico_tag=v3.26.4

Note: Replace <your-keypair-name> with the name of an SSH keypair you have already uploaded to OpenStack.

With this template, users can now run openstack coe cluster create ... --cluster-template k8s-cluster-template to provision their own Kubernetes clusters.

Bonus: Uploading a General-Purpose Ubuntu Image

It's also useful to have standard cloud images for creating regular virtual machines. Here is how you can upload an Ubuntu 24.04 image.

# Download the Ubuntu cloud image
wget https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img -O ubuntu-24.04-server.img

# Upload the image to Glance
openstack image create \
  --disk-format qcow2 \
  --container-format bare \
  --public \
  --property os_type=linux \
  --file ubuntu-24.04-server.img \
  ubuntu-24.04-server

Deployment in Action

Here are some snapshots from the openstack-helm stack

Automating a Production-Ready K8s Cluster with Ansible

Mon, 13 Jul 2026 00:00:00 GMT

This post walks through a set of Ansible playbooks that fully automate a production-ready Kubernetes cluster on Debian or Ubuntu nodes. The setup goes from base OS configuration through Rook-Ceph for storage, Envoy Gateway for ingress, FluxCD for GitOps, and a complete observability stack with Prometheus and Grafana.

Component Versions

All component versions are pinned for reproducible deployments and can be customized in the Ansible inventory.

| Component | Version | | -------------------- | ------------------------------ | | Kubernetes | 1.34.9 | | Container runtime | containerd | | Pod networking | Calico 3.32.0 (eBPF dataplane) | | Load balancer | MetalLB 0.16.1 | | TLS management | cert-manager v1.13.0 | | Distributed storage | Rook-Ceph 1.19.7 | | GitOps | FluxCD 2.18.4 | | Ingress | Envoy Gateway 1.8.1 | | Monitoring | kube-prometheus-stack 87.2.1 | | Kubernetes Dashboard | 7.14.0 | | Helm CLI | 3.21.2 |

Architecture Overview

The cluster is designed for robustness and modern cloud-native practices.

External traffic     |
MetalLB (L2/BGP)  -->  Envoy Gateway  -->  HTTPRoutes
                     |              +---------------+---------------+
                     v              v               v
                 Grafana        k8s-dash        Ceph-dash
                     ^              |
                     |  cert-manager (self-signed wildcard)
                     |
  kube-prometheus-stack
    Prometheus --> scrapes via ServiceMonitor
    Grafana    --> sidecar watches ConfigMaps (dashboards)
                       ^
    Rook-Ceph ServiceMonitor (labeled release: kube-prometheus-stack)

  Rook-Ceph (operator + cluster + StorageClass: general)

  FluxCD (GitOps controller)

Network Configuration

The nodes in this setup utilize multiple network interfaces, a common pattern in virtualized environments like OpenStack. Here's a typical netplan configuration for the control plane:

network:
  version: 2
  ethernets:
    ens160:
      addresses:
        - '172.24.61.40/24'
      nameservers:
        addresses:
          - 8.8.8.8
      routes:
        - to: 'default'
          via: '172.24.61.254'
    ens192:
      addresses:
        - '10.0.0.4/24'
    ens224:
      dhcp4: false

ens160: The primary interface for external access and Ansible management (172.24.61.0/24).
ens192: An internal network for cluster communication (10.0.0.0/24).
ens224: An external flat network used by OpenStack.
ens256: An internal network used by Octavia LB communication.

The worker nodes follow a similar pattern, with an additional interface (ens256) often reserved for octavia lb communication traffic.

network:
  version: 2
  ethernets:
    ens160:
      addresses:
        - '172.24.61.41/24'
      nameservers:
        addresses:
          - 8.8.8.8
      routes:
        - to: 'default'
          via: '172.24.61.254'
    ens192:
      addresses:
        - '10.0.0.1/24'
    ens224:
      dhcp4: false
    ens256:
      dhcp4: false

Ansible Roles

The automation is broken down into logical Ansible roles:

common: Configures the base OS, disables swap, installs containerd, sets up required kernel modules, and installs kubelet, kubeadm, and kubectl.
control_planes: Initializes the Kubernetes control plane using kubeadm and installs the Calico CNI.
nodes: Joins the worker nodes to the cluster.
cluster_addons: Deploys the entire application stack, including MetalLB, cert-manager, Rook-Ceph, FluxCD, Envoy Gateway, and the monitoring components.
update-and-reboot: A maintenance playbook for system-wide updates and reboots.

Prerequisites

System Requirements

| | Control plane | Worker nodes | | ----------- | ---------------------------------- | ----------------------------- | | OS | Debian 11/12 or Ubuntu 22.04/24.04 | same | | CPU | 2+ cores | 2+ cores | | RAM | 4 GB+ | 2 GB+ | | Disk | 30 GB+ | 20 GB+ (+ raw disks for Ceph) | | Network | Static IP, internet access | same |

Note: Ceph requires at least one raw (unformatted) block device per worker node. The Calico eBPF dataplane requires a Linux kernel version of 5.3 or higher.

Control Machine Setup

# Install Ansible and the kubernetes.core collection
sudo apt update && sudo apt install -y ansible python3-pip
ansible-galaxy collection install kubernetes.core

# Install python3-kubernetes
sudo apt install -y python3-pip python3-kubernetes
pip3 install kubernetes --break-system-packages

# Verify
ansible --version

You will also need to configure passwordless SSH access from your control machine to all cluster nodes.

# Generate a key pair if needed
ssh-keygen -t ed25519 -C "ansible"

# Copy to every node (adjust IPs to match your inventory)
ssh-copy-id root@172.24.61.40   # control plane
ssh-copy-id root@172.24.61.41   # worker 1
ssh-copy-id root@172.24.61.42   # worker 2
ssh-copy-id root@172.24.61.43   # worker 3

Installation

Step 1: Configure Inventory

Clone the project repository and edit the inventory/dev file to match your node IPs.

[control_planes]
k8s-control-plane1 ansible_host=172.24.61.40

[nodes]
k8s-worker1 ansible_host=172.24.61.41
k8s-worker2 ansible_host=172.24.61.42
k8s-worker3 ansible_host=172.24.61.43

Step 2: Review Configuration

Key variables are located in inventory/group_vars/all.yaml. Pay special attention to the networking and monitoring sections.

# Networking
metallb_mode: 'l2'
metallb_ip_range: '172.24.61.20-172.24.61.30'
metallb_l2_interface: 'ens160'
gateway_ip: '172.24.61.20'

# Calico eBPF
calico_ebpf: true
calico_ebpf_dsr: true

# Monitoring
grafana_admin_password: 'ChangeMe123!'

Step 3: Deploy

You can deploy the entire cluster with a single command:

ansible-playbook -i inventory/dev playbooks/k8s_all.yaml

For the first run, it's recommended to execute the playbooks one by one:

# 1. Base OS configuration on all nodes
ansible-playbook -i inventory/dev playbooks/common.yaml

# 2. Initialise control plane and install Calico
ansible-playbook -i inventory/dev playbooks/control_planes.yaml

# 3. Join worker nodes
ansible-playbook -i inventory/dev playbooks/nodes.yaml

# 4. Install the full add-on stack
ansible-playbook -i inventory/dev playbooks/cluster_addons.yaml

Step 4: Access the Cluster

Copy the kubeconfig from the control plane to your local machine to manage the cluster with kubectl.

scp root@172.24.61.40:~/.kube/config ~/.kube/config
kubectl get nodes

Deep Dive: Calico eBPF Networking

This setup uses Calico's eBPF dataplane, which replaces kube-proxy entirely. This offers several advantages over the standard iptables-based mode, including lower latency, higher throughput, and better scalability.

| | Standard Calico (iptables) | Calico eBPF | | --------------------------- | --------------------------- | ----------------------------------- | | Service routing | kube-proxy iptables rules | eBPF programs in kernel | | kube-proxy dependency | Required | Eliminated | | External traffic path | SNAT on ingress node | Direct Server Return (no extra hop) | | Connection scaling | O(n) iptables rules | O(1) eBPF map lookups |

The control_planes role automates the configuration by patching the FelixConfiguration and disabling the kube-proxy DaemonSet.

Deep Dive: Monitoring Stack

The cluster_addons playbook deploys a kube-prometheus-stack and integrates it with Rook-Ceph for comprehensive monitoring.

Ceph Dashboard Integration

A key challenge is getting the Ceph dashboards into Grafana reliably. The solution used here is both robust and idempotent:

The Ansible playbook uses curl on the control plane to fetch the official dashboard JSON files directly from the Rook-Ceph GitHub repository, version-locked to the deployed Ceph version.
It then creates a ConfigMap in the monitoring namespace for each dashboard.
These ConfigMaps are labeled with grafana_dashboard: "1".
A Grafana sidecar container (k8s-sidecar) is configured to watch for ConfigMaps with this label across all namespaces and automatically hot-loads them into Grafana.

This approach ensures dashboards survive Grafana restarts and are automatically updated when the Ceph version is changed in the Ansible variables.

Here is the list of dashboards automatically loaded into Grafana:

And here is an example of the main cluster dashboard:

Accessing Dashboards

At the end of a successful deployment, the playbook prints an access summary. The services are exposed via MetalLB and Envoy Gateway using nip.io for DNS.

| Service | URL | Credentials | | -------------------- | ---------------------------------- | --------------------------------------------- | | Grafana | https://grafana.<gw-ip>.nip.io | admin / grafana_admin_password | | Kubernetes Dashboard | https://dashboard.<gw-ip>.nip.io | Bearer token (printed at run end) | | Rook-Ceph Dashboard | https://ceph.<gw-ip>.nip.io | admin / auto-generated (printed at run end) |

All services are secured with self-signed HTTPS certificates managed by cert-manager.

Maintenance and Troubleshooting

The playbooks are idempotent, so they can be re-run safely.

# Rolling OS update + reboot
ansible-playbook -i inventory/dev playbooks/update-and-reboot.yaml

# Re-run only the add-on stack
ansible-playbook -i inventory/dev playbooks/cluster_addons.yaml

# Check Ceph cluster health
kubectl exec -n rook-ceph deploy/rook-ceph-tools -- ceph status

This project provides a powerful and repeatable foundation for running Kubernetes in a production environment. The combination of Ansible's automation with best-in-class cloud-native tools creates a cluster that is both feature-rich and maintainable.

Tips to improve concentration

Sat, 10 May 2025 00:00:00 GMT

import { Aside } from 'astro-pure/user'

You're trying to concentrate, but your mind is wandering or you're easily distracted. What happened to the laser-sharp focus you once enjoyed? As we age, we tend to have more difficulty filtering out stimuli that are not relevant to the task at hand.

What's fogging up focus?

Like a computer that slows with use, the brain accumulates wear and tear that affects processing. This can be caused by a number of physiological stressors such as inflammation, injury to blood vessels (especially if you have high blood pressure), the buildup of abnormal proteins, and naturally occurring brain shrinkage.

The following factors can also affect your concentration.

Underlying conditions. Depression or sleep disorders (such as sleep apnea) can undermine your ability to concentrate. So can the effects of vision or hearing loss. You waste precious cognitive resources when you spend too much time trying to make out what's written on a page or just hear what someone is saying.

Medication side effects. Some drugs, especially anticholinergics (such as treatments for incontinence, depression, or allergies), can slow processing speed and your ability to think clearly.

Excessive drinking. Having too much alcohol impairs thinking and causes interrupted sleep, which affects concentration.

Information overload. We are bombarded with information from TVs, computers, and messages such as texts or emails. When there's too much material, it burdens our filtering system and it's easy to get distracted.

Strategies to stay focused

To improve attention, consider the following strategies.

Mindfulness. "Mindfulness is about focusing attention on the present moment, and practicing mindfulness has been shown to rewire the brain so that attention is stronger in everyday life," says Kim Willment, a neuropsychologist with Brigham and Women's Hospital. She recommends sitting still for a few minutes each day, closing your eyes, and focusing on your breathing as well as the sounds and sensations around you.

Cognitive training. Computerized cognitive training games aim to improve your response times and attention. Evidence that this works has been mixed. "The goal of playing these games is not to get better at them, but to get better in the cognitive activities of everyday life," Willment says. "But there is evidence that a person's ability to pay attention can be improved by progressively pushing the person to higher levels of performance. So if you reach a certain level of sustained attention, pushing it to the next level can help improve it, and this may translate to everyday life."

A healthier lifestyle. Many aspects of a healthy lifestyle can help attention, starting with sleep and exercise. There is a direct link between exercise and cognitive ability, especially attention. When you exercise, you increase the availability of brain chemicals that promote new brain connections, reduce stress, and improve sleep. And when we sleep, we reduce stress hormones that can be harmful to the brain, and we clear out proteins that injure it.

Aim for seven to eight hours of sleep each night, and 150 minutes per week of aerobic exercise, such as brisk walking.

Other healthy steps to improve focus: eat a Mediterranean-style diet, which has been shown to support brain health; treat underlying conditions; and change medications that may be affecting your ability to focus.

Getting older is out of your control, but healthier living is something you determine, and it may improve concentration.

Article from: Harvard Health Publishing

Using MDX

Sun, 01 Jun 2025 00:00:00 GMT

This theme comes with the @astrojs/mdx integration installed and configured in your astro.config.ts config file. If you prefer not to use MDX, you can disable support by removing the integration from your config file.

Why MDX?

MDX is a special flavor of Markdown that supports embedded JavaScript & JSX syntax. This unlocks the ability to mix JavaScript and UI Components into your Markdown content for things like interactive charts or alerts.

If you have existing content authored in MDX, this integration will hopefully make migrating to Astro a breeze.

Example

Here is how you import and use a UI component inside of MDX.
When you open this page in the browser, you should see the clickable button below.

import { Button } from 'astro-pure/user'

Click Me

Markdown Syntax Support

Wed, 26 Jul 2023 08:00:00 GMT

Basic Syntax

Markdown is a lightweight and easy-to-use syntax for styling your writing.

Headers

When the content of the article is extensive, you can use headers to segment:

# Header 1

## Header 2

## Large Header

### Small Header

Header previews would disrupt the structure of the article, so they are not displayed here.

Bold and Italics

_Italic text_ and **Bold text**, together will be **_Bold Italic text_**

Preview:

Italic text and Bold text, together will be Bold Italic text

Links

Text link [Link Name](http://link-url)

Preview:

Text link Link Name

Inline Code

This is an `inline code`

Preview:

This is an inline code

Code Blocks

```js
// calculate fibonacci
function fibonacci(n) {
  if (n <= 1) return 1
  const result = fibonacci(n - 1) + fibonacci(n - 2) // [\!code --]
  return fibonacci(n - 1) + fibonacci(n - 2) // [\!code ++]
}
```

Preview:

// calculate fibonacci
function fibonacci(n) {
  if (n <= 1) return 1
  const result = fibonacci(n - 1) + fibonacci(n - 2) // [!code --]
  return fibonacci(n - 1) + fibonacci(n - 2) // [!code ++]
}

Currently using shiki as the code highlighting plugin. For supported languages, refer to Shiki: Languages.

Inline Formula

This is an inline formula $e^{i\pi} + 1 = 0$

Preview:

This is an inline formula $e^{i\pi} + 1 = 0$

Formula Blocks

$$
\hat{f}(\xi) = \int_{-\infty}^{\infty} f(x) e^{-2\pi i x \xi} \, dx
$$

Preview:

$$ \hat{f}(\xi) = \int_{-\infty}^{\infty} f(x) e^{-2\pi i x \xi} , dx $$

Currently using KaTeX as the math formula plugin. For supported syntax, refer to KaTeX Supported Functions.

Images

![Alt text](https://placehold.co/200x200.png)

Preview:

Strikethrough

~~Strikethrough~~

Preview:

~~Strikethrough~~

Lists

Regular unordered list

- 1
- 2
- 3

Preview:

Regular ordered list

1. GPT-4
2. Claude Opus
3. LLaMa

Preview:

GPT-4
Claude Opus
LLaMa

You can continue to nest syntax within lists.

Blockquotes

> Gunshot, thunder, sword rise. A scene of flowers and blood.

Preview:

Gunshot, thunder, sword rise. A scene of flowers and blood.

You can continue to nest syntax within blockquotes.

Line Breaks

Markdown needs a blank line to separate paragraphs.

If you don't leave a blank line
it will be in one paragraph

First paragraph

Second paragraph

Preview:

If you don't leave a blank line it will be in one paragraph

First paragraph

Second paragraph

Separators

If you have the habit of writing separators, you can start a new line and enter three dashes --- or asterisks ***. Leave a blank line before and after when there are paragraphs:

---

Preview:

Advanced Techniques

Inline HTML Elements

Currently, only some inline HTML elements are supported, including <kdb> , such as

Key Display

Use <kbd>Ctrl</kbd> + <kbd>Alt</kbd> + <kbd>Del</kbd> to reboot the computer

Preview:

Use Ctrl + Alt + Del to reboot the computer

Bold Italics

<b> Markdown also applies here, such as _bold_ </b>

Preview:

Markdown also applies here, such as bold

Other HTML Writing

Foldable Blocks

<details><summary>Click to expand</summary>It is hidden</details>

Preview:

Tables

| Header1  | Header2  |
| -------- | -------- |
| Content1 | Content2 |

Preview:

| Header1 | Header2 | | -------- | -------- | | Content1 | Content2 |

Footnotes

Use [^footnote] to add a footnote at the point of reference.

Then, at the end of the document, add the content of the footnote (it will be rendered at the end of the article by default).

[^footnote]: Here is the content of the footnote

Preview:

Use [^footnote] to add a footnote at the point of reference.

Then, at the end of the document, add the content of the footnote (it will be rendered at the end of the article by default).

[^footnote]: Here is the content of the footnote

To-Do Lists

- [ ] Incomplete task
- [x] Completed task

Preview:

[ ] Incomplete task
[x] Completed task

Symbol Escaping

If you need to use markdown symbols like _ # * in your description but don't want them to be escaped, you can add a backslash before these symbols, such as \_ \# \* to avoid it.

\_Don't want the text here to be italic\_

\*\*Don't want the text here to be bold\*\*

Preview:

_Don't want the text here to be italic_

**Don't want the text here to be bold**

Enrico Biella

Deploying OpenStack with Helm and FluxCD on Kubernetes

Architecture Overview

Key Design Decisions

Helm Hook Removal in 2026.1.0

Cluster-Managed Gateway

HTTPS-Only Public Endpoints

Internal Public Key Infrastructure (PKI)

Repository Structure

Prerequisites

Cluster Infrastructure

Admin Workstation Setup

Deployment Walkthrough

Step 1: Node Preparation

Step 2: Credential Encryption with SOPS

Step 3: Bootstrap FluxCD

Step 4: Monitor the Deployment

Accessing Your OpenStack Cloud

Service Catalog

Trusting the Gateway CA

Verifying the Deployment

Maintenance and Troubleshooting

Networking Deep Dive: Neutron with OVN and Open vSwitch

What is Open vSwitch (OVS)?

What is OVN (Open Virtual Network)?

How They Work Together

Traffic Patterns: East-West vs. North-South

East-West Traffic (Internal)

North-South Traffic (External)

Post-Deployment: Creating a Magnum Kubernetes Cluster

Step 1: Create External Network and Subnet (via Skyline)

Step 2: Create a Router

Step 3: Prepare Fedora CoreOS Image for Magnum

Step 4: Create the Magnum Cluster Template

Bonus: Uploading a General-Purpose Ubuntu Image

Deployment in Action

Automating a Production-Ready K8s Cluster with Ansible

Component Versions

Architecture Overview

Network Configuration

Ansible Roles

Prerequisites

System Requirements

Control Machine Setup

Installation

Step 1: Configure Inventory

Step 2: Review Configuration

Step 3: Deploy

Step 4: Access the Cluster

Deep Dive: Calico eBPF Networking

Deep Dive: Monitoring Stack

Ceph Dashboard Integration

Accessing Dashboards

Maintenance and Troubleshooting

Tips to improve concentration

What's fogging up focus?

Strategies to stay focused

Using MDX

Why MDX?

Example

More Links

Markdown Syntax Support

Basic Syntax

Headers

Bold and Italics

Links

Inline Code

Code Blocks

Inline Formula

Formula Blocks

Images

Strikethrough

Lists

Blockquotes

Line Breaks

Separators

Advanced Techniques

Inline HTML Elements

Key Display

Bold Italics