Cluster API Provider OpenStack (CAPO)

repository·main·Indexed 18 days ago

https://github.com/kubernetes-sigs/cluster-api-provider-openstack

A provider for Cluster API that enables the management of Kubernetes clusters on OpenStack infrastructure. It includes resources for managing OpenStack clusters, machines, and servers, as well as specialized components like OpenStackClusterIdentity for centralized credentials and OpenStackFloatingIPPool for floating IP management. The provider supports detailed configurations for compute flavors, networking patterns (managed subnets or existing networks), security groups, and control plane deployment constraints.

Tokens
73.2K
Snippets
152
Records
284
Agent score
60%

What's inside cluster-api-provider-openstack

  1. New features in CAPO v0.14.0

    main

    The v0.14.0 release introduces several significant features and experimental capabilities:

    1. OpenStackClusterIdentity: Enables centralized credential management for OpenStack clusters.
    2. PriorityQueue: Support for the controller-runtime PriorityQueue feature (Experimental, disabled by default).
    3. Autoscaling to/from zero: Support for scaling clusters to or from zero nodes (Experimental, disabled by default).
    4. CAPI v1beta2 Support: Implementation of CAPI v1beta2 conditions and deprecations for both OpenStackCluster (OSC) and OpenStackMachine (OSM), along with CRD migration support.
  2. New features in v0.14.0-rc.0

    main

    The v0.14.0-rc.0 release introduces several key features and architectural changes:

    • Centralized Credential Management: Added OpenStackClusterIdentity for managing credentials.
    • Autoscaling Improvements: Added support for autoscaling to and from 0.
    • CAPI v1beta2 Support: Migrated manifests to CAPI v1beta2 and implemented support for v1beta2 conditions and deprecations for both OpenStackCluster (OSC) and OpenStackMachine (OSM).
    • Feature Flags: Added a PriorityQueue feature flag.
    • CRD Migration: Implemented logic for CRD migration.
    • Cluster API Update: Updated the underlying Cluster API dependency to v1.12.0.
  3. New features in v0.14.0-beta.0

    main

    The v0.14.0-beta.0 release introduces several key features and architectural changes:

    • Centralized Credential Management: Added OpenStackClusterIdentity for managing credentials.
    • CAPI v1beta2 Support: The provider has switched to CAPI v1beta2 for manifests and implemented v1beta2 conditions and deprecations for both OpenStackCluster (OSC) and OpenStackMachine (OSM).
    • CRD Migration: Implemented logic for Custom Resource Definition (CRD) migration.
    • PriorityQueue: Added a new PriorityQueue feature flag.
    • Cluster API Update: Updated the supported Cluster API version to v1.12.0.
  4. New features in v0.14.0-alpha.1

    main

    The v0.14.0-alpha.1 release introduces several key features and architectural changes:

    • OpenStackClusterIdentity: Added for centralized credential management.
    • PriorityQueue: A new feature flag has been introduced.
    • CAPI v1beta2 Support: The provider now supports CAPI v1beta2 conditions and deprecations for both OpenStackCluster (OSC) and OpenStackMachine (OSM). Manifests have also switched to CAPI v1beta2.
    • CRD Migration: Implementation of CRD migration logic.
    • Cluster API Update: Updated to support Cluster API v1.12.0.
  5. Bug fixes in v0.14.0-rc.0

    main

    Key bug fixes included in this release:

    • Networking: Allowed setting disablePortSecurity on OSM ports; fixed issues where selected fixed subnets were not applied; defined subnetID on LB members when networks differ.
    • Load Balancing: Ensured pool members reach the active state.
    • Server Management: Fixed OpenStackServer reconciliation issues when clusters are unpaused; handled SOFT_DELETED and DELETED states during server deletion.
    • Security: Uplifted Go to 1.24.8 to address security vulnerabilities.
  6. New features in v0.14.0-alpha.0

    main

    The v0.14.0-alpha.0 release introduces several significant changes to the provider, including:

    • Centralized Credential Management: Added OpenStackClusterIdentity.
    • Feature Flags: Added a PriorityQueue feature flag.
    • CAPI v1beta2 Support: Implementation of CAPI v1beta2 conditions and deprecations for both OpenStackCluster (OSC) and OpenStackMachine (OSM).
    • Manifest Updates: Switched to CAPI v1beta2 for manifests.
    • CRD Migration: Implemented CRD migration logic.
    • Cluster API Update: Updated the underlying Cluster API dependency to v1.12.0.
  7. What is OpenStackClusterIdentity and when to use it

    main

    The OpenStackClusterIdentity is a cluster-scoped resource designed for centralized OpenStack credential management.

    In multi-tenant environments, instead of storing OpenStack credentials (secrets) in every individual tenant namespace, you can store them once in a secure, central namespace (like capo-system) and create an OpenStackClusterIdentity resource. This resource acts as a bridge, allowing specific tenant namespaces to use those central credentials while maintaining strict access control via namespace selectors.

    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: OpenStackClusterIdentity
    metadata:
      name: production-openstack
    spec:
      secretRef:
        name: openstack-credentials
        namespace: capo-system
      namespaceSelector:
        matchExpressions:
        - key: kubernetes.io/metadata.name
          operator: In
          values: [team-a, team-b]
  8. What is the Priority Queue feature?

    main
    The PriorityQueue feature enables the use of the controller-runtime PriorityQueue within the provider. This feature improves controller responsiveness during full resyncs and controller startups by deprioritizing the reconciliation of objects that were not edge-triggered (i.e., objects that did not change due to a specific create or update event).
  9. Centralize OpenStack credentials with OpenStackClusterIdentity

    main

    You can centralize OpenStack credentials across multiple namespaces by using a cluster-scoped OpenStackClusterIdentity object. This object points to a single Secret containing a clouds.yaml file and can optionally restrict which namespaces are allowed to use these credentials via a namespaceSelector.

    Core Concepts

    • OpenStackClusterIdentity: A cluster-scoped resource that stores a reference to a Secret (containing clouds.yaml and an optional cacert).
    • OpenStackIdentityReference: A field used on OpenStackCluster, OpenStackMachine, or OpenStackServer to point to credentials. It supports two types:
      • type: Secret (default): The name refers to a Secret in the same namespace as the resource.
      • type: ClusterIdentity: The name refers to an OpenStackClusterIdentity resource. The Secret location is managed by the identity.
    • cloudName: Required for both types. It specifies which entry within the clouds.yaml file should be used.

    Access Control

    • If namespaceSelector is omitted, all namespaces can use the identity.
    • If namespaceSelector is provided, only namespaces matching the selector can use it. If access is denied, reconciliation fails and the controller may emit a IdentityAccessDenied Warning event.
    apiVersion: infrastructure.cluster.x-k8s.io/v1alpha1
    kind: OpenStackClusterIdentity
    metadata:
      name: production-openstack
    spec:
      secretRef:
        name: openstack-credentials
        namespace: capo-system
      namespaceSelector:
        matchExpressions:
        - key: kubernetes.io/metadata.name
          operator: In
          values: [team-a, team-b]
  10. Handle Conditions format change in v1beta2

    main

    In v1beta2, CAPO conditions have migrated from the CAPI v1beta1 type to the standard Kubernetes []metav1.Condition type. This affects OpenStackCluster, OpenStackMachine, OpenStackServer, and OpenStackFloatingIPPool.

    Key differences:

    • The severity field is removed.
    • The observedGeneration field is added.
    • The status field uses metav1.ConditionStatus ("True", "False", "Unknown") instead of corev1.ConditionStatus (though string values are identical, the Go types differ).
  11. Configure OpenStackCluster networking

    main

    The OpenStackClusterSpec allows you to define how the cluster connects to OpenStack networks. You can choose between having the provider manage the network or using existing OpenStack resources.

    Managed Networking

    If you provide managedSubnets ([]SubnetSpec), the cluster actuator will automatically create a network, subnets with the defined CIDR, and a router.

    • Note: Currently, only one IPv4 subnet is supported via this method.
    • MTU: You can set networkMTU (int) to address fragmentation. This requires the net-mtu neutron API extension. If left empty, the default OpenStack network service MTU is used.

    Existing Networking

    If you do not use managedSubnets, you can point to existing resources:

    • network: Specify an existing NetworkParam to use.
    • subnets: Specify existing []SubnetParam. All subnets must reside in the specified network. If no subnets are specified, all subnets in the network will be used.
    • primarySubnet: If multiple subnets are provided, use this to identify the primary subnet for load balancer VIP allocation and node member registration. If not specified, the first subnet in the resolved list is used.
    • router: Specify an existing RouterParam to avoid creating a new router.

    External Connectivity

    • externalNetwork: The OpenStack Network used for public internet access. If not defined, the controller attempts to use a single existing external network. If multiple exist and none are specified, it results in an error unless disableExternalNetwork is true.
    • disableExternalNetwork: Set to true to prevent the cluster from attempting to connect to an external network (useful for provider networks).
    • externalRouterIPs: An array of []ExternalRouterIPParam used if the router requires a fixed IP in a specific subnet.
    # Example conceptual configuration for existing networking
    spec:
      network:
        name: existing-network-name
      subnets:
        - id: "subnet-uuid-1"
        - id: "subnet-uuid-2"
      primarySubnet: "subnet-uuid-1"
      router:
        id: "router-uuid"
  12. Configure Control Plane Availability Zones

    main

    You can control where control plane nodes are deployed using the following fields in OpenStackClusterSpec:

    • controlPlaneAvailabilityZones: A list of []string specifying the allowed availability zones for control plane machines.
    • controlPlaneOmitAvailabilityZone: If set to true, the availability zone is omitted during node creation. This allows the OpenStack Nova scheduler to decide the availability zone based on other scheduling constraints.