Upbound Docs - Provider families

Provider families

Upbound packages each of the official providers for Amazon AWS, Google GCP and Microsoft Azure as a “family.”

A provider family organizes the provider’s resources into unique packages, organized by a common set of services.

Provider families reduce the resources required to install and run providers and improve performance over a single monolithic provider.

Provider family requirements

Provider families have the following requirements and restrictions:

Crossplane version 1.12.1 or UXP version 1.12.1-up.1 or later
Remove existing monolithic providers matching the new provider family.

Warning

If a provider family installs into a cluster with an existing monolithic provider, the family provider doesn’t take effect.

The monolithic provider continues to own all provider resource endpoints until it’s removed.

For information on migrating from monolithic providers to provider families read the family providers migration guide

Installing a provider family

Installing a provider family is identical to installing other Crossplane providers. Create a Provider object with the provider package to install.

For example, to install the provider family AWS S3 provider:

apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: upbound-provider-aws
spec:
  package: xpkg.upbound.io/upbound/provider-aws-s3:v0.37.0

Install multiple services with multiple Provider objects. For example to install both AWS S3 and EC2 providers:

apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: upbound-provider-aws-s3
spec:
  package: xpkg.upbound.io/upbound/provider-aws-s3:v0.37.0
---
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: upbound-provider-aws-ec2
spec:
  package: xpkg.upbound.io/upbound/provider-aws-ec2:v0.37.0

Tip

Browse the Upbound Marketplace to find the provider services to install.

To install Providers in an offline environment set skipDependencyResolution: true in the Provider.

apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: upbound-provider-aws-s3
spec:
  package: xpkg.upbound.io/upbound/provider-aws-s3:v0.37.0
  skipDependencyResolution: true

When installing multiple providers, apply skipDependencyResolution to every Provider.

apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: upbound-provider-aws-s3
spec:
  package: xpkg.upbound.io/upbound/provider-aws-s3:v0.37.0
  skipDependencyResolution: true
---
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: upbound-provider-aws-ec2
spec:
  package: xpkg.upbound.io/upbound/provider-aws-ec2:v0.37.0
  skipDependencyResolution: true

View the installed providers with kubectl get providers

kubectl get providers
NAME                          INSTALLED   HEALTHY   PACKAGE                                               AGE
upbound-provider-aws-ec2      True        True      xpkg.upbound.io/upbound/provider-aws-ec2:v0.37.0      25m
upbound-provider-aws-s3       True        True      xpkg.upbound.io/upbound/provider-aws-s3:v0.37.0       25m
upbound-provider-family-aws   True        True      xpkg.upbound.io/upbound/provider-family-aws:v0.37.0   24m

The first provider installed of a family also installs an extra provider-family Provider. The provider-family provider manages the ProviderConfig for all other providers in the same family.

Note

Each family provider defines a dependency on the latest available version of the corresponding provider-family, which is automatically resolved and installed by the Crossplane package manager.

Hence, when you install an older version of a family provider, you can expect to receive newer versions of the provider-family provider, and it is safe to ignore this version mismatch.

If you still want to control the version of the provider-family, consider using the skipDependencyResolution: true option as described in the Install Providers in an offline environment section above.

Using ControllerConfigs

The ControllerConfig applies settings to a Provider Pod. With family providers each provider is a unique Pod running in the cluster.

When using ControllerConfigs with family providers, each provider needs a ControllerConfig applied.

For example, both providers reference the same controllerConfigRef.name .

apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: upbound-provider-aws-s3
spec:
  package: xpkg.upbound.io/upbound/provider-aws-s3:v0.37.0
  controllerConfigRef:
    name: my-controllerconfig
---
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: upbound-provider-aws-ec2
spec:
  package: xpkg.upbound.io/upbound/provider-aws-ec2:v0.37.0
  controllerConfigRef:
    name: my-controllerconfig
---
apiVersion: pkg.crossplane.io/v1alpha1
kind: ControllerConfig
metadata:
  name: my-controllerconfig