►
Description
Crossplane: Build and Manage Infrastructure using Kubernetes. In this presentation, we will be exploring Crossplane and understand how we can make use of a Kubernetes cluster and the all too familiar Kubernetes YAML definition files to manage and compose resources on all major cloud providers. We will first go through the Crossplane concepts such as providers, managed resources, composite resources and understand how Crossplane extends the functionality of Kubernetes beyond objects such as pods and deployments to provision and manage external infrastructure using CRDs. Towards the end of the presentation, we will see a short demo where we will deploy resources on the AWS cloud with the standard Kubernetes Cluster API by making use of Crossplane.
A
A
This
will
be
followed
by
a
quick,
hands-on
demo,
where
we'll
make
use
of
crossplane
to
deploy
resources
on
the
aws
cloud
and
we'll
wrap
up
this
session
with
a
round
of
q
a
before
we
begin.
Let's
go
over
some
of
the
prerequisites
and
assumptions
now
since
crossplane
installs
on
top
of
kubernetes,
a
basic
understanding
of
kubernetes
is
expected
I'll,
be
using
some
examples
of
core
services
in
aws
cloud.
So
a
basic
understanding
of
aws
or
cloud
computing
in
general
would
be
helpful
in
some
of
the
examples.
A
A
Crossplane
is
an
open
source
tool
that
is
installed
directly
on
top
of
kubernetes
as
an
add-on,
and
we
can
quite
literally
make
use
of
any
kubernetes
distribution.
Even
the
minimal
distribution,
such
as
mini
cube,
micro,
k8s
or
clusters
that
are
created
using
the
kind
utility
or
the
cubadium
tool
once
installed.
Crossplane
enables
orchestrating
infrastructure
or
manage
services
on
multiple
platforms
such
as
gcp,
aws,
azure
alibaba
cloud
by
making
use
of
the
kubernetes
api,
and
this
is
done
by
the
means
of
providers.
I
will
discuss
what
providers
are
in
detail
in
the
upcoming
slides.
A
A
As
long
as
it
has
an
api
that
supports,
create,
read,
update
and
delete
operations,
once
crossplane
is
installed
and
the
provider
configured,
we
can
now
define
the
configuration
of
an
ec2
instance
in
aws,
using
a
yaml
file
like
this
and
more
significantly,
we
can
make
use
of
native
kubernetes
commands
such
as
cube,
ctl,
create
or
cube
ctl
apply
to
provision
the
instance
to
check
the
status
and
check
for
the
events
of
the
resource
that
was
created.
We
can
run
commands
such
as
cube,
ctl,
get
or
cube.
A
Ctl
described
like
this
that
we
would
normally
do
with
native
kubernetes
objects,
such
as
spots
deployments,
persistent
volumes,
etc,
and,
as
you
can
see
here,
from
the
output
of
the
cube
ctl
get
command.
We
can
now
see
the
status
of
the
aws
instance
and
similar
to
native
kubernetes
objects,
controllers,
constantly
check
to
see
the
status
of
these
external,
managed
resources
and
reconciles
them
in
case
of
a
drift.
A
A
We
can
also
optionally
install
the
crossplane
cli
tool
that
extends
the
native
cube
ctl
tool,
enabling
it
to
do
things
such
as
installing
building
and
pushing
crossplane
providers
and
packages
in
the
upcoming,
slides
and
demo.
Towards
the
end,
we
will
make
use
of
this
to
install
the
aws
provider
configuration
in
our
kubernetes
cluster.
A
Earlier
we
touched
upon
the
concept
of
providers
a
little
bit.
Providers
in
crossplane
are
similar
in
function
to
providers
in
terraform.
They
facilitate
crossplane
to
provision
the
respective
infrastructure
resource.
On
a
specific
platform,
however,
in
crossplane
provider
is
a
package
that
bundles
two
components
together,
a
controller
which
runs
as
a
part
in
the
cross,
plane
system,
name
space
and
a
set
of
managed
resources
that
are
installed
as
custom,
resource
definitions
or
crds.
A
Now,
depending
upon
the
platform,
the
corresponding
provider
must
be
first
installed
on
the
kubernetes
cluster
before
we
can
start
provisioning
and
managing
resources
on
that
platform.
Now
this
can
be
easily
done
by
running
a
one
line:
cube
ctl
command,
provided
that
the
crossplane
cli
plugin
is
already
installed
now.
In
this
case,
we
are
installing
the
aws
provider
with
the
version
of
0.27.0
in
our
kubernetes
cluster.
A
Now
that
the
provider
is
installed,
we
need
a
way
to
authenticate
to
the
platform,
so
in
this
example,
crossplane
should
be
able
to
authenticate
with
the
aws
account
where
we
want
to
deploy
the
resources
for
aws.
This
is
done
by
creating
an
account
key
file
that
contains
the
access
key
id
and
the
secret
access
key
and
then
creating
a
kubernetes
secret
in
the
cross
plane
system
name
space
using
the
key
file.
A
A
A
A
The
api
version
for
this
object
is
ec2.aws,
dot,
cross,
plane,
dot
io
with
the
version
of
v
one
alpha
one
and
the
kind
is
instance
now
under
the
metadata.
We
have
the
name
of
the
object,
which
is
called
web
server.
In
this
case,
and
just
like
any
other
kubernetes
object,
we
can
also
add
additional
fields
such
as
labels
and
annotations
under
the
metadata.
A
The
for
provider
field
is
a
mandatory
field
and
it
is
used
to
define
the
desired
state
of
the
external
resources
which,
in
this
case,
is
the
easy
to
instance,
the
only
required
instance
parameters
are
the
region
and
the
image
id
which
have
to
be
supplied
in
this
definition
file.
There
are
several
other
parameters
that
can
be
supplied,
such
as
the
instance
type,
security
group
and
subnet
information,
but
these
are
optional
and
if
it
is
not
supplied,
a
predefined
default
value
are
used
while
provisioning
the
resource.
A
Another
field
that
we
have
used
under
the
spec
section
is
the
provider
config
reference
field.
Now
this
is
used
to
reference.
The
provider
config
object
that
we
created
earlier
and
it
is
used
to
authenticate
cross
plane
to
the
aws
provider,
and
that's
it
once
this
configuration
is
applied.
We
can
now
successfully
create
ec2
instances
or
any
managed
resource
in
aws.
A
A
A
A
Now,
in
the
interest
of
time,
I
will
not
be
going
over
composite
resources
in
detail,
but
I
wanted
to
mention
it
all
the
same
as
it
is
a
concept
that
promotes
effective
collaboration
between
platform
or
the
sra
team
that
manages
the
crossplane
environment
and
the
application
team
that
requests
for
infrastructure
at
a
very
high
level.
This
is
how
it
would
work.
A
The
composite
resources
are
configured
by
the
platform
or
the
sri
team
that
manages
cross
plane
and,
while
designing
the
composite
resources,
they
define,
which
managed
resources
should
be
created
by
the
composite
resource,
and
this
is
done
by
using
another
cross
plane.
Specific
resource
called
composite
resource
definition,
which
is
xrd
for
short
and
compositions.
A
For
example,
it
can
be
enforced
that
the
instance
type
of
an
ec2
and
since
resource
be
always
be
set
to
t2
micro,
but
the
image
id
can
be
something
that
can
that
the
consumers
of
the
composite
resource
can
configure
themselves
to
any
ami
of
their
choice.
So
who
are
the
consumers
of
this
composite
resource?
A
Now?
These
can
be
an
application
that
typically
does
not
have
access
to
create
the
composite
resource
directly
and
instead
they
would
use
something
known
as
a
composite
resource
claim.
Now.
This
is
similar
to
the
native
kubernetes
object,
called
persistent
volume
claim
when
application
can
request
a
persistent
volume
of
specific
class
size
or
access
mode.
A
A
A
A
You
can
see
here
that
the
crossplane
provider
aws
is
installed
and
it
is
in
a
healthy
state.
Now
this
environment
is
integrated
with
an
aws
sandbox,
which
makes
use
of
a
limited
user
with
limited
permissions
so
that
we
can
deploy
certain
resources
for
this
particular
demo.
Now,
let's
open
up
this
console
and
see
what
is
currently
configured
for
this
particular
account.
A
So
we
have
opened
the
aws
console
now,
let's
go
back
to
the
terminal
and
let's
create
the
key
account
file
that
we
can
make
use
of
to
create
our
provider
config
reference
now.
This
has
already
been
created
within
the
system
and
we
can
make
use
of
this
to
create
our
kubernetes
secret
that
we
will
use
to
authenticate
from
the
cross
plane
to
our
aws
account.
A
A
A
And
here
you
can
see
that
we've
got
our
different
yaml
files
and
these
are
the
resources
that
we're
going
to
create
so
we're
going
to
create
a
vpc,
a
subnet,
a
security
group
or
route
table,
an
internet
gateway
and
a
route
table,
and
finally
the
ec2
instance.
So
let's
go
back
to
our
aws
console
and
first
take
a
look
at
the
vpcs
which
are
currently
available
in
the
no
to
virginia
region,
which
is
us
each
one.
And
here
you
can
see
that
there
is
one
single
vpc
right
now
in
this
particular
region.
A
Now
before
we
create,
let's
just
inspect
this
yaml
file,
so
the
api
version
for
this
is
ec2.aws.crossplay.io,
which
is
the
api
group,
and
the
version
is
v1
beta1
and
the
kind
is
vpc.
The
name
of
the
vpc
is
going
to
be
sample
vpc
and
under
the
specs
section
we
have
four
provider
field,
which
is
mandatory
and
within
that
we
have
parameters
which
we
have
defined.
The
region
is
going
to
be
us
east
one.
A
The
cider
block
is
a
custom,
one
that
we
have
selected,
which
is
10.0.0.0
16,
and
we
have
also
opted
for
some
additional
parameters,
such
as
enable
dns
support,
is
equal
to
true.
Insistency
is
default
now,
you'll
also
notice
that
we
have
supplied
the
provider
config
reference
here,
which
is
the
name
of
the
object
that
we
just
created,
which
is
called
default.
Now,
let's
go
ahead
and
create
this
vpc
using
cubectl
create
command.
A
A
So
let's
go
ahead
and
create
this
instance,
but
before
that,
let's
also
go
and
check
the
image
id
that
the
instance
type
that
is
going
to
be
created
for
this
instance.
So
here
we
have
not
supplied
a
instance
type
for
this
particular
managed
resource.
So
it
will
offer
a
default
instance
type
which
has
been
configured
for
this
managed
resource
nscrd.
A
A
And
if
you
click
on
that,
under
the
spec
section,
we
can
see
that
the
four
provider
field
is
required
and
it
only
has
two
required
parameters
which
is
image
id
and
the
region.
Now
the
instance
type
is
optional
and
if
we
do
not
supply
it,
it
will,
by
default,
create
an
instance
type
of
m1
small.
So
let's
go
ahead
and
create
this
instance.