Breaking changes in 4.0.1

Dropped support for deprecated API `aerospike.com/v1beta1` for AerospikeClusters

AKO no longer supports the deprecated API aerospike.com/v1beta1 for AerospikeClusters. Use the aerospike.com/v1 API for AerospikeClusters.

Dropped support for Kubernetes 1.22 and earlier versions

AKO no longer officially supports Kubernetes 1.22 and earlier versions. Upgrade your Kubernetes cluster to version 1.23 or later.

Dropped support for Aerospike Database versions older than 6.0.0

AKO no longer supports Aerospike Database versions older than 6.0.0.

Upgrade your Aerospike Database to version 6.0.0 or later before upgrading to AKO 4.0.1. Upgrading AKO without upgrading the Aerospike Database will result in irrecoverable Aerospike cluster.

Dropped support for AerospikeBackupService version v2.x

AKO no longer supports AerospikeBackupService version v2.x. Upgrade to the latest version (v3.0.0) of AerospikeBackupService. See Upgrade ABS for more information.

Replaced `kube-rbac-proxy` functionality with controller-runtime authz/authn feature

gcr.io/kubebuilder/kube-rbac-proxy image will no longer be available on gcr starting March 2025. There is no guaranteed timeline. See this discussion for more information.

We recommend upgrading to AKO 4.0.1 to avoid any failures due to the unavailability of the kube-rbac-proxy image. If you want to continue using kube-rbac-proxy, source the image from an alternative location, at your own risk.

Examples include:

quay.io/brancz/kube-rbac-proxy
Red Hat Registry (⚠️ If you are allowed to use it.)

AKO has replaced the kube-rbac-proxy functionality with controller-runtime authz/authn feature. This feature provides integrated support for securing AKO metrics endpoints by embedding authentication (authn) and authorization (authz) mechanisms directly into the AKO’s metrics server, replacing the need for kube-rbac-proxy to secure metrics endpoints.

It generates self-signed TLS certificate for the metric server if not provided and also, provides the option to give custom TLS certificates for secure communication.

For users running kube-rbac-proxy with custom configurations like user-provided TLS certs, you need to update the AKO configuration to provide the custom TLS certs for the metric server.

OLM Users

Add the following configuration to the AKO deployment resource:

# Add the volumeMount for the metrics-server certs
volumeMounts:
  - mountPath: /tmp/k8s-metrics-server/metrics-certs
    name: metrics-certs
    readOnly: true

# Add the --metrics-cert-path argument for the metrics server
containers:
  - name: manager
    args:
      - --metrics-cert-path=/tmp/k8s-metrics-server/metrics-certs

# Add the metrics-server certs volume configuration
volumes:
  - name: metrics-certs
    secret:
      secretName: metrics-server-cert   # The secret name containing the metrics-server certs
      optional: false
      items:
        - key: ca.crt
          path: ca.crt
        - key: tls.crt
          path: tls.crt
        - key: tls.key
          path: tls.key

Helm Users

Enable the metrics-server-cert generation via cert-manager and configuration in AKO deployment by setting certs.metrics.create to true in the values.yaml file.

certs:
  metrics:
    create: true
    metricsServerCertSecretName: "metrics-server-cert"

Dropped support for deprecated `ControllerManagerConfiguration` in controller-runtime and moved to flag-based configuration

AKO stopped using the deprecated ControllerManagerConfiguration configuration configMap provided in version 3.4.x and earlier as shown.

apiVersion: v1
kind: ConfigMap
metadata:
    name: aerospike-operator-manager-config
data:
  controller_manager_config.yaml: |
    apiVersion: controller-runtime.sigs.k8s.io/v1alpha1
    kind: ControllerManagerConfiguration
    health:
      healthProbeBindAddress: :8081
    metrics:
      bindAddress: 127.0.0.1:8080
    webhook:
      port: 9443
    leaderElection:
      leaderElect: true
      resourceName: 96242fdf.aerospike.com

Instead, most of the configurations have been moved to flag-based approach. The following flags are available for AKO configuration:

  -enable-http2
        If set, HTTP/2 will be enabled for the metrics and webhook servers
  -health-probe-bind-address string
        The address the probe endpoint binds to. (default ":8081")
  -kubeconfig string
        Paths to a kubeconfig. Only required if out-of-cluster.
  -leader-elect
        Enable leader election for controller manager. Enabling this will ensure there is only one active controller manager.
  -metrics-bind-address string
        The address the metrics endpoint binds to. Use :8443 for HTTPS or :8080 for HTTP, or leave as 0 to disable the metrics service. (default "0")
  -metrics-cert-key string
        The name of the metrics server key file. (default "tls.key")
  -metrics-cert-name string
        The name of the metrics server certificate file. (default "tls.crt")
  -metrics-cert-path string
        The directory that contains the metrics server certificate.
  -metrics-secure
        If set, the metrics endpoint is served securely via HTTPS. Use --metrics-secure=false to use HTTP instead. (default true)
  -webhook-cert-key string
        The name of the webhook key file. (default "tls.key")
  -webhook-cert-name string
        The name of the webhook certificate file. (default "tls.crt")
  -webhook-cert-path string
        The directory that contains the webhook certificate.

Adjust the AKO deployment parameters to use the new flag-based configuration. For example, to change the healthProbeBindAddress and metricBindAddress, set the corresponding flags in the AKO deployment.

containers:
  - name: manager
    args:
      - --health-probe-bind-address=:8081
      - --metrics-bind-address=:8443