Cluster Object Store

The Cluster Object Store is an optional setting in the LinodeCluster resource definition that references an object storage bucket used for internal cluster operations. Currently, the Cluster Object Store feature enables the following capabilities:

• Bypassing bootstrap data limits during Linode provisioning

A Linode Object Storage bucket and access key are provisioned as the Cluster Object Store for each LinodeCluster resource with any of the *-full flavors. BYOB (Bring Your Own Bucket) may be used instead, by modifying a LinodeCluster definition:

apiVersion: infrastructure.cluster.x-k8s.io/v1alpha2
kind: LinodeCluster
metadata:
name: ${CLUSTER_NAME}
spec:
  objectStore:
    credentialsRef:
      name: ${CLUSTER_NAME}-object-store-credentials

to reference any Secret containing a object storage bucket's credentials in the following format:

apiVersion: v1
kind: Secret
metadata:
  name: ${CLUSTER_NAME}-object-store-credentials
data:
  bucket: ${BUCKET_NAME}
  # Service endpoint
  # See: https://docs.aws.amazon.com/general/latest/gr/s3.html
  endpoint: ${S3_ENDPOINT}
  access: ${ACCESS_KEY}
  secret: ${SECRET_KEY}

Alternatively, the LinodeObjectStorageBucket and LinodeObjectStorageKey resources can be used:

apiVersion: infrastructure.cluster.x-k8s.io/v1alpha2
kind: LinodeCluster
metadata:
name: ${CLUSTER_NAME}
spec:
  objectStore:
    credentialsRef:
      name: ${CLUSTER_NAME}-object-store-obj-key
---
apiVersion: infrastructure.cluster.x-k8s.io/v1alpha2
kind: LinodeObjectStorageBucket
metadata:
    labels:
        app.kubernetes.io/name: linodeobjectstoragebucket
        app.kubernetes.io/instance: ${CLUSTER_NAME}-object-store
        app.kubernetes.io/part-of: cluster-api-provider-linode
        app.kubernetes.io/managed-by: kustomize
        app.kubernetes.io/created-by: cluster-api-provider-linode
        cluster.x-k8s.io/cluster-name: ${CLUSTER_NAME}
    name: ${CLUSTER_NAME}-object-store
spec:
    credentialsRef:
        name: ${CLUSTER_NAME}-credentials
    region: ${OBJ_BUCKET_REGION:=${LINODE_REGION}}
---
apiVersion: infrastructure.cluster.x-k8s.io/v1alpha2
kind: LinodeObjectStorageKey
metadata:
    labels:
        app.kubernetes.io/name: linodeobjectstoragekey
        app.kubernetes.io/instance: ${CLUSTER_NAME}-object-store
        app.kubernetes.io/part-of: cluster-api-provider-linode
        app.kubernetes.io/managed-by: kustomize
        app.kubernetes.io/created-by: cluster-api-provider-linode
        cluster.x-k8s.io/cluster-name: ${CLUSTER_NAME}
    name: ${CLUSTER_NAME}-object-store
spec:
    credentialsRef:
        name: ${CLUSTER_NAME}-credentials
    bucketAccess:
        - bucketName: ${CLUSTER_NAME}-object-store
          permissions: read_write
          region: ${OBJ_BUCKET_REGION:=${LINODE_REGION}}
    generatedSecret:
        type: Opaque
        format:
            bucket: '{{ .BucketName }}'
            endpoint: '{{ .S3Endpoint }}'
            access: '{{ .AccessKey }}'
            secret: '{{ .SecretKey }}'

Capabilities

Bootstrap Data Limits During Linode Provisioning

Currently, during LinodeMachine bootstrapping, CAPL delivers the bootstrap data generated by a bootstrap provider to it's infrastructure Linode via one of the following services:

These data limits are bypassed when the Cluster Object Store feature is enabled.

An optional secondaryCredentialsRef can reference credentials for one secondary Object Store. CAPL tries the primary credentialsRef first and uses the secondary only when it cannot upload the bootstrap payload and generate a non-empty presigned URL with the primary. The instance Metadata still contains exactly one native cloud-init #include URL. This fallback only covers failures CAPL observes while preparing the bootstrap data; it does not provide failover after the selected URL has been handed to the instance.

spec:
  objectStore:
    presignedURLDuration: 24h
    credentialsRef:
      name: cluster-object-store-primary
    secondaryCredentialsRef:
      name: cluster-object-store-secondary