PLEASE NOTE: This document applies to v0.4 version and not to the latest release v0.11Documentation for other releases can be found by using the version selector in the top right of any doc page.
This guide is an overview of enabling cloud service provisioning on an existing Kubernetes target cluster, including how to integrate Crossplane with existing cloud networking configurations to provide secure managed service connectivity. Step-by-step instructions are provided for GCP, AWS, and Azure.
Cloud service provisioning can be added to existing clusters by installing Crossplane directly onto the target cluster. Crossplane is designed to integrate with existing cloud networking and security resources, so managed services like RDS, CloudSQL, and Azure DB can be provisioned using Kubernetes objects and securely consumed by pods in a cluster.
Crossplane achieves this by:
Secretsthat pods in a
Deploymentcan use to securely access the managed service
Crossplane currently supports private IP secure connectivity for AWS, GCP, and Azure Stacks. Managed services instances are made available on the cluster’s prviate network(s) so pods can access them. Crossplane also supports configuring ingress/egress rules to further restrict allowed network traffic.
While each cloud provider uses different resources for establishing secure connectivity between a Kubernetes cluster (EKS, GKE, AKS) and managed services (RDS, CloudSQL, and Azure DB), the basic pattern is the same:
Crossplane provides Kubernetes resources for all of the above, so you can define a secure connectivity model for the managed services you want to make available for self-service provisioning in the cluster using claims and classes.
Crossplane employs a layered architecture consisting of managed resources that represent a cloud service, and resource claims and classes that enable dynamic provisioning of those services.
Managed resources are high fidelity representations of the API resources that
make up a cloud service. They’re not portable across clouds. A
CloudSQLInstance is an example of a managed resource - it’s relevant only to
the Google Cloud Platform (GCP) and exposes all of the nitty gritty
configuration details of a CloudSQL instance. The networking and security
Kubernetes resources mentioned above fall into this category.
Resource claims and classes are the next layer up. Resource claims like
MySQLInstance enable dynamic provisioning of managed resources by matching a
claim to a class like a
CloudSQLInstanceClass that provides the detailed
configuration template to provision a new cloud service instance. Resource
classes can reference secure connectivity resources (networks), such that new
instances of that class can be made available on the cluster’s private network.
Resource classes, cluster networking, and secure connectivity resources are
designed to work together to enable self-service provisioning of securely
connected cloud services in a Kubernetes cluster.
Resource claims can be matched to a class in several ways:
claim.spec.classRefto a specific class
The first two methods rely on a default class of service or use a
classSelector that matches any suitable resource class available in the
target cluster. As such, the first two methods are considered portable
resource claims that can be used in any cluster that provides the desired class
of service. You may have one cluster using GCP and another cluster using AWS,
and the same claim can be used in either cluster so long as the claim can be
matched to a suitable class of cloud service.
The third method uses an explicit
classRef to a specific resource class like
CloudSQLInstanceClass which means the claim may only be used with that
class. Since resource classes are specific to a single cloud, claims that use
classRef are not portable across different cloud providers.
Resource claims automatically write a connection secret that pods in a
deployment can use to securely access the underlying cloud service. The claim’s
writeConnectionSecretToRef field is used to specify the name of the secret
that should be created, which can then be used in the deployment’s
configuration. Since the claim is created in Kubernetes, and the secret is
automatically populated by Crossplane, all cloud service secrets are managed
automatically without leaving Kubernetes.
Step-by-step instructions for enabling cloud service provisioning on an existing cluster are provided in the service guides for: