Introduction to Crossplane at VSHN

VSHN – The DevOps Company
Tobias Brunner
Introduction to
Crossplane
Hi, I’m Tobias.
In the next minutes I’ll introduce Crossplane to you and
will show you around. At the end of this talk you will
know what it’s all about and how Crossplane could help
you.
Speaker notes
1

View Slide

• Kubernetes Operator
• Declarative Infrastructure Management
• Abstraction for Self-Service APIs
• Packaging and distribution of custom
infrastructure
• Started in 2018, CNCF Sandbox project
since 2020, move to Incubation requested
What?
⏭ Crossplane is an open source Kubernetes Operator
which enables to assemble infrastructure from multiple
vendors in a
⏭ declarative way.
⏭ It exposes higher level self-service APIs for users of
the platform to consume in an abstracted way, without
having to write any code besides YAML.
⏭ All these customized infrastructure description can
be packaged, easily distributed and shared.
⏭ Crossplane has been invented by the maintainers of
the well known storage operator Rook in 2018. It has
been donated to the Cloud Native Computing
Foundation in mid 2020 and recently applied to be
promoted to become an incubation level project.
There are a few key features, from which I will introduce
the three most important ones to you in the next slides.
Speaker notes
2

View Slide

• Building block for upstream API
• Managed Resource: Provider speci c
& opinionated CRDs
• XRM - Crossplane Resource Model: E.g.
spec.forProvider
• Of cial provider: AWS, GCP, Azure,
Rook, Alibaba
• More under the
GitHub org
Crossplane Providers ✨
crossplane-contrib
Let’s start with the Crossplane providers.
⏭ They are the building blocks for talking to upstream
APIs, like AWS, Azure, Google Cloud or even Helm.
⏭ And they provide an abstraction layer by bringing
provider specific custom resources with an opinionated
structure. Such provider specific resources are called
managed resources. From a users perspective they are
just standard Kubernetes custom resources.
⏭ But with the opinionated Crossplane resource
model, each of these custom resources look similar.
For example, each custom resource has a field called
"spec dot forProvider" which contains the detailed
configuration of the upstream resource. Most of the
time it reflects all possible options which are available
in the third-party API. This allows full flexibility per
supported API.
⏭ Besides the official Crossplane providers, a lot more
⏭ can be found under the crossplane-contrib GitHub
organization. This is also the place where new providers
are born and already contains a lot of very good
providers.
Speaker notes
3

View Slide

Composite Resource De nition (XRD)
API de nition, opinionated CRD - XRM
Composition
Collection of resources
Composite Resource (XR)
Cluster-scope instance of XRD,
selected Composition
Composite Resource Claim (XRC)
Namespace-scoped instance, maps to
XR
Crossplane Compositions
🥏 The next key feature are the Crossplane compositions.
This feature allows for custom and opinionated
infrastructure definitions which can be easily composed
and provided to the user of the platform in a self-
service way.
This feature consists of four object types which we will
now getting to know.
• The first one are Composite resource definitions -
called XRD - which define the custom API definitions.
With them the operator of the platform describes the
opinionated services which are then made available
to the user. XRDs in the background generate
Crossplane-flavored Kubernetes custom resource
definitions which adhere to the Crossplane Resource
Model.
• The Compositions actually implement the custom
infrastructure which is defined in XRDs. There can be
multiple implementations per XRD, which the user
then can choose from. One could for example be a
service which is tuned for production, the other one
might have options enabled which are great for the
development environment. The user then choses
which Composition should be selected when creating
the service instance.
• A composite resource is the cluster-scope object to
instantiate a custom service, implemented by the
selected composition.
• And with composite resource claims the user of the
platform specifies the infrastructure needs on a
namespace scope. This can be done for example
together with the application deployment.
By splitting cluster-scope and namespace-scope
objects, security constraints can be easily implemented
Speaker notes
4

View Slide

• Distribute Providers and con gurations
• Packaged as opinionated OCI image
• Con guration versioning
• RBAC handling
• Dependency management
• Packaging with Crossplane CLI
Crossplane Packaging 📦
And the last important feature are the Crossplane
packages.
⏭ With them, provider installation and configuration as
well as custom infrastructures can be easily distributed
and shared.
⏭ These packages are OCI compliant images which
contain just a bunch of Crossplane YAML and can
therefore be hosted on any OCI compliant registry.
⏭ Crossplane packages allow for configuration
versioning,
⏭ RBAC handling and
⏭ dependency
management.
⏭ Packaging can be done manually, but much better
via the Crossplane CLI.
Speaker notes
5

View Slide

• CLI Tool vs. Control-Plane
• State le handling vs. Reconciliation
• Full infra vs. pieces of it
• Crossplane can use Terraform providers (alpha) 💪
Comparison to Terraform ⇄
Some of you might wonder what the differences are
between Crossplane and Terraform as it looks like they
are mostly doing the same at first sight.
⏭ The main difference is that Terraform is designed to
be a CLI tool which acts only on invocation. Crossplane
on the other hand is an always running controller which
acts on change.
⏭ To know what’s the current state is, Terraform
tracks it in a state file. This complicates collaboration
on infrastructure and full automation a lot, mainly
because of state file locking mechanisms needed. If
the actual state differs to the one in the state file, bad
things may happen. Manual changes to the
infrastructure are only detected on the next CLI
invocation while Crossplane actively reconciles the
infrastructure all the time and makes manual changes
impossible to stay undetected.
⏭ Terraform always acts on the full infrastructure it
takes care of, where Crossplane is able to only
configure pieces of it, making it much less invasive for
small changes.
⏭ Lately Crossplane started an initiative to be able to
re-use Terraform providers as Crossplane providers
which could be a huge boost of available providers. The
VMware provider which was released just lately is
actually based on the Terraform provider.
This doesn’t mean that Terraform is bad, it just behaves
very differently to do a similar job. As Crossplane is a
control-plane and Terraform is designed to work with
control-planes, Crossplane could even be managed with
Terraform.
Speaker notes
6

View Slide

• Well-Known API
• Same language as app
deployment
• Tooling re-use (GitOps,
Project Syn)
• One place to de ne
everything
• Reconciliation loop, prevent
con g drift
• RBAC to protect
infrastructure management,
still allowing self-service
Why do we care? ♥
The previously introduced concepts and features are
the reasons why we at VSHN and I personally care a lot
about Crossplane.
But there are more reasons:
⏭ We can leverage the well-known Kubernetes API.
⏭
It’s the same language we also use to deploy
applications.
⏭ This allows to reuse already existing
tooling like GitOps or CI/CD Pipelines.
⏭ And the
infrastructure and deployment needs of an application
is defined on the same places.
⏭ As Crossplane runs a reconciliation loop all the
time, configuration drift isn’t possible anymore. The
control-plane is always active, looking for changes on
the upstream configuration. If it doesn’t match the
declared configuration, it simply makes sure to adhere
to it.
⏭ And last but not least, RBAC allows to protect the
infrastructure provisioning and configuration but
allowing self-service in an easy way.
Speaker notes
7

View Slide

Kubernetes Clusters
Helm
"App Cluster" / appc-app
Crossplane
"Service Cluster" / appc-service1
Service deployments (via Helm)
Composite
Resource
Developer
Crossplane Con guration
CompositeResourceDefinition
redisinstances.syn.tools
Composition
redis-small
API Definition
Creates
RedisInstance
redis1
Helm Release
redis1
Kubernetes
API
Service
Consumer
Live Demo 1 🐚
Let’s see how Crossplane looks like in real-life.
In this first live-demo we will have a look at various
Crossplane specific Kubernetes objects and provision a
Redis service.
The left diagram shows the demo Kubernetes clusters
in use. The top one is the one we’ll be looking at in the
demo. It runs Crossplane and it is the cluster in which
we’ll be deploying Redis. The actual service then runs
on the bottom cluster, the service cluster. Provisioning
happens via Helm.
The right diagram shows the Crosplane objects involved
in this demo. There is a Redis instance XRD, a
Composition which implements this XRD and we’ll be
creating a RedisInstance object to actually deploy the
instance.
Let’s dive in…
Speaker notes
8

View Slide

• Internal marketplace on Cloudfoundry
• Integration with Open Service Broker API
• Open Source Crossplane Service Broker
• Crossplane Helm Provider
• Huge environment
Crossplane Service Broker
🧩
github.com/vshn/crossplane-service-broker
After this first live-demo, I want to tell you more about
our first use case we’ve implemented with Crossplane.
⏭ It is an internal marketplace on Cloudfoundry to
enable self-service service provisioning for development
and service teams.
⏭ The integration to this marketplace had to be done
with the Open Service Broker API as this is the API
which is tightly integrated in the Cloudfoundry world.
⏭ To achieve this integration we developed a bridge
between Crossplane and the Open Service Broker API.
The two concepts match very well. Our Crossplane
Service Broker is available as an Open Source tool on
GitHub.
⏭ As the infrastructure of the customer doesn’t
provide any cloud services, we are provisioning the
actual services using the Crossplane Helm Provider on
service clusters.
⏭ This project already pushed the boundaries of
Crossplane a lot, we’re talking about more than 1000
managed services.
Speaker notes
9

View Slide

Kubernetes Clusters
Open Service Broker API
"Service Consumer" / appc-consumer1
Kubernetes Service Catalog (SVCAT)
Helm
"Control Plane" / appc-control
Crossplane & Crossplane Service Broker
"Service Cluster" / appc-service1
Service deployments (via Helm)
Service
Provisioning
and
Binding
Developer
Crossplane Con guration
Crossplane Service Broker
CompositeResourceDefinition
redisinstances.syn.tools
Composition
redis-small
API Definition
Creates
RedisInstance
redis1
Service Plan Service Instance
Helm Release
redis1
Open
Service
Broker
API
Service
Consumer
Provision
Deprovision
Service Offering
Live Demo 2 🐚
In this second demo we will see the service provisioning
of the same Redis service as we’ve seen in the first
demo, this time using the Open Service Broker API with
the Kubernetes Service Catalog.
This time we have three Kubernetes clusters for the
demo. The top one represents the end-user which has
the Kubernetes Service Catalog installed which
connects to the Crossplane Service Broker.
The control cluster in the middle runs Crossplane and
the Crossplane Service Broker and services are once
again deployed via Helm on the Service cluster.
The diagram on the right is nearly the same as in the
fist demo. This time it shows the mapping between
Crossplane objects and Open Service Broker API
constructs.
Let’s dive in…
That’s it for the demo part.
Speaker notes
10

View Slide

• Crossplane is …
• … the only Control Plane …
• … you ever need again.
Conclusion
🥳 In the last few minutes I gave you an overview of
Crossplane. Of course there’s a lot more to it, the best
way to learn it is to try it yourself.
And all I can say is:
⏭ Crossplane is
⏭ the only
Control Plane
⏭ you ever need again.
→ at least until something better appears
Speaker notes
11

View Slide

vshn.timer
Shameless self-marketing
Tobias Brunner –
VSHN AG – Neugasse 10 – CH-8005 Zürich – +41 44 545 53 00 – –
Thanks!
www.vshn.ch/blog/vshn-timer
tobru.ch/about-newsletter/
[email protected]
vshn.ch [email protected]
Thanks a lot for listening and don’t hesitate to contact
me if you have any questions or want to know more.
And if you’re interested in Cloud Native news and tools,
you’re invited to follow the vshn.timer and subscribe to
my personal newsletter.
Speaker notes
12

View Slide

Introduction to Crossplane at VSHN

Introduction to Crossplane at VSHN

Tobias Brunner

More Decks by Tobias Brunner

Other Decks in Technology

Featured

Transcript