Cloud-native applications can now provision Yugabyte and Cockroach DB instances with the new Rook Stack using portable PostgreSQL claims via kubectl -- offering an in-cluster alternative to RDS, CloudSQL, and Azure DB. Streamlined documentation and UX improvements round out this important release.
It’s only been 6 weeks since the v0.3 release but we have a lot of ground to cover with a new Rook Stack for provisioning in-cluster stateful services, release automation for faster release cycles, GitOps support for complete environments, and streamlined documentation and UX improvements that make it easier to get started with Crossplane in dev and test environments today!
Rook-managed databases with claim-based provisioning
Previously when running Kubernetes apps in GKE, EKS, or AKS when you needed a managed database the only feasible option was to use the managed services (CloudSQL, RDS, Azure DB) offered by the same cloud provider as your managed Kubernetes cluster.
With Crossplane v0.4 and the new Rook Stack you can now provision Kubernetes clusters with Rook operators installed, so Kubernetes applications can consume Yugabyte and Cockroach DB instances provisioned with PostgreSQL claims via
kubectl as alternatives to CloudSQL, RDS, and Azure DB.
Checkout the new Rook Stack Guide for more info!
GitOps support for complete dev/test environments
In v0.3 we added support for secure connectivity for cloud services with many new Kubernetes resources including Networks, Subnets, Service Endpoints, Security Groups and more. However many of these resources, especially those for the AWS Stack, generated non-deterministic IDs that required waiting for one resource (VPC) to be created before creating the next resource (subnet) using the generated ID from the first resource. This required the use of scripts to sequence the creation of complete environments: Kubernetes cluster(s), networking, security, and classes of managed service.
The v0.4 release now supports cross-resource references, such that entire environments can now be declared in a single yaml file, version controlled in a Git repo, and applied with a single
kubectl command. We think that this is an amazing improvement in the usability of Crossplane and we are thrilled to have more people try it out since it's now easier than ever to use!
kubectl apply -f aws-dev-env.yaml
For example, an AWS
Subnet resource has a
spec.vpcIdRef field used by Crossplane to wait for the
VPC to be provisioned, so its ID can be used when provisioning the
Subnet. This all happens within Crossplane so you can just declare the complete desired-state of a dev or test environment and Crossplane will make it so.
apiVersion: network.aws.crossplane.io/v1alpha3 kind: Subnet metadata: name: sample-subnet1 spec: cidrBlock: 192.168.64.0/18 vpcIdRef: name: sample-vpc availabilityZone: us-west-2a reclaimPolicy: Delete providerRef: name: aws-provider
v1beta1 API types for databases/caches in GCP and AWS
Stacks for GCP and AWS now have v1beta1 API types for databases and caches, with expanded support for almost every parameter available in the underlying cloud provider APIs. Declarative yaml configuration can be committed to a Git repo, applied using
kubectl and Crossplane will create, update, or delete the underlying managed resources as needed.
Crossplane observes the Kubernetes API versioning guidelines:
Beta: Support for the overall features will not be dropped, though details may change. Support for upgrading or migrating between versions will be provided, either through automation or manual steps.
Checkout the updated API Reference for these new v1beta1 API types that are ready for use in dev and test environments today:
Simpler claim-binding model with label selectors
In Crossplane v0.3 we introduced support for provider-specific resource classes, where they were previously generic. However with resource classes becoming specific to a single cloud provider, the claims that referenced them lost their portability. To address this issue in v0.3, portable resource classes were added to map a portable claim kind to a portable resource class like
PostgreSQLInstanceClass that in turn could be mapped to a provider-specific class like
Crossplane v0.4 incorporates community feedback and replaces portable resource classes with a simpler claim-binding model that uses the label selector pattern used throughout Kubernetes today. Resource classes are now cluster-scoped and resource claims can now be matched to a resource class in several ways:
- class label selectors defined in the
- default resource classes marked
claim.spec.classRefthat is not portable across clouds
Checkout the Services Guide and the design doc for more info on this exciting new feature and how to use claims and classes to enable dynamic provisioning of managed services with RDS, CloudSQL, and Azure DB!
Faster monthly release cadence going forward
To keep the momentum rolling and shorten our feedback loops we wanted to release more often and v0.4 includes new release automation to make that happen. We’ll be releasing on a monthly cadence going forward so stay tuned for great new content!
And there’s more!
There are a number of features we’ll mention just briefly here:
- Crossplane supporting work for GitLab 12.5 Auto DevOps
- New Packet Stack to provision Packet bare-metal
- New Trace utility for enhanced debugging support
- New simple provisioning examples in Getting Started!
We have many things on tap including:
- GitLab 12.5 Auto DevOps integration
- CD integration examples for GitLab, Jenkins, and ArgoCD
- Stable v1beta1 API types for all GCP, AWS and Azure resources
- Resource packs for default classes and configurations
- Improved error messages surfaced in claims and/or eventing
- Stack Manager
- Enhanced security model
- Robot account support
- Annotation support: parent/child, UI, CRD
- Versioning and upgrade support
- Template Stacks with lifecyle hooks
- Additional real-world App Stacks
- Expanded Rook support for additional storage types
- Policy-based secure connectivity strategies
There are many different ways to get involved in the Crossplane project, both from the user side and the developer side. Please join us in helping the project continue to grow on its way beyond the v0.4 milestone as we move from alpha to beta over the coming months!
Join the open cloud movement to help level the playing field for everyone!