►
From YouTube: YAML Your Cloud! Managing Your Hosted Resources With Kubernetes - Megan O'Keefe & Abdul Samadh
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
YAML Your Cloud! Managing Your Hosted Resources With Kubernetes - Megan O'Keefe & Shabir Mohamed Abdul Samadh, Google
One of Kubernetes’ most powerful features is its declarative API, where the cluster is defined by its intended state. This transfers the responsibility to reconcile the intended and actual state from the user to the cluster. But it’s likely that users are also running workloads outside of Kubernetes, from databases to virtual machines— and they might be using multiple cloud providers at once. How to manage it all? In this talk, the speakers explore how Kubernetes’ declarative model can be used to manage cloud-hosted resources alongside their Kubernetes workloads. They will demonstrate this, first using Crossplane, a Kubernetes add-on with native multi-cloud support, and second, using custom controllers built by different cloud providers. Finally, they will show how to integrate OpenPolicyAgent with cloud-hosted resource definitions, to enforce custom policies across environments. Attendees will leave this talk ready to simplify their cloud configuration with Kubernetes.
A
A
A
A
So
all
of
kubernetes
component
centers
around
the
api
server,
it's
what
the
control
plane
uses
as
the
source
of
truth
for
external
tools,
clients
and
other
internal
components.
So
it's
how
the
nodes
know
what
containers
they
need
to
run.
It's
how
any
outside
actor
like
a
ci
cd
system
interacts
with
the
cluster
and
the
api
server
exposes
an
http
api
that
the
user
external
clients
and
also
the
internal
components
in
the
control
plane
can
connect
to
so
through
this.
A
So,
instead
of
telling
how
to
achieve
what
you
want,
what
the
declarative
model
says
is
what
you
want
and
how
kubernetes
knows
how
to
get
to
that
part
is
using
the
concept
of
controllers,
so
every
resource
or
an
object
in
kubernetes
has
a
controller
attached
to
it,
and
controllers
are
trying
to
continuously
drive
from
the
observed
state
to
the
desired
state
like
how
you
see
in
this
example
in
the
diagram
here
so
now.
The
next
question
is:
how
do
we
tell
the
api
server
what
you
want?
What
is
your
desired
state?
A
How
do
you
tell
it
for
this?
We
follow
the
kubernetes
resource
model
or
krm
to
define
the
resource
or
the
object
we
want.
So
the
krm
is
a
data
model
or
the
schema
following
which
the
intended
state
of
kubernetes
resources
are
expressed,
and
it
has
three
main
parts.
The
first
part
is
the
metadata
part,
which
explains
the
object
itself.
It
could
have
things
like
the
name,
namespaces
labels
or
even
annotations,
and
then
we
have
the
desired
state
spec
explaining.
What
is
the
state
you
want.
A
The
object
to
be
this
has
all
the
information
about
the
resource
itself.
If
it's
a
container
the
things
about,
what's
the
image
to
use,
what
ports
to
be
exposed
and
so
on,
and
finally,
you
have
the
status
field,
which
is
maintained,
which
maintains
the
current
state
of
the
object,
as
is
which
is
used
by
the
controllers
in
the
reconciliation
process.
A
A
You
have
an
additional
api
to
take
care
of,
and
this
also
comes
with
a
cli
and
tools
and
its
own
client
libraries.
So
usually
an
organization
running
kubernetes
would
not
only
use
kubernetes,
but
also
would
need
to
provision
cloud
resources
like
databases,
serverless
functionalities,
dns
networks
and
so
on.
So
this
results
in
having
to
deal
with
different
ways
of
interacting
with
your
resources
so,
and-
and
this
has
downsides
to
this
structure
setup
so
different
apis
with
different
formats-
require
the
expertise
to
manage
it.
A
You
also
need
to
deal
with
the
difference
in
paradigm
which,
between,
inter
imperative
and
declarative,
that
means
the
process
pipeline
would
change
and
also
crowdfunders
access
management,
which
is
commonly
known
as
identity
and
access
management
is
different
from
kubernetes
from
how
kubernetes
manages
access
to
its
resources,
which
uses
its
role-based
access
control
system,
and
on
top
of
all
of
this,
you
run
on
multiple
clouds.
If
you
run
on
multiple
crowds.
The
variation
amongst
these
increases
further.
A
A
A
So
what
would
it
look?
Like
is
what
you
see
here
in
the
diagram
diagram
that's
been
presented
like
we
see
on
the
right
side
here.
The
data
model
is
decoupled
and
defined
as
krm
with
the
tools
having
to
only
operate
and
worry
about.
You
know
dealing
with
krm,
rather
than
keeping
up
with
how
the
api
is
changing.
A
So,
in
an
ideal
scenario,
how
would
it
look
like
you
can
treat
your
cloud
resources
as
a
cloud?
You
know
as
krm
based
yaml
stored
inside
the
git
repositories,
and
you
can
integrate
your
cloud
resources
into
a
change,
approval
and
validation
process.
This
is,
of
course,
a
very
simplified
group
that
we
are
showing
here
you
can.
You
can
have
multiple
repositories
and
clusters.
B
Second,
you
actually
have
to
write
your
krm
or
yaml
resources
representing
those
hosted
cloud
infrastructure,
and
then
you
have
to
figure
out
where
to
put
the
yaml
files,
so
in
git,
or
figure
out
the
workflow
of
actually
getting
those
files
onto
one
or
more
clusters
and
then
finally,
we're
going
to
cover
how
to
set
up
guardrails
and
some
authentication
items
to
make
it
more
secure
to
be
managing
your
cloud
resources
inside
of
kubernetes.
There's
a
few
considerations
to
worry
about
there.
B
B
B
B
So
the
way
that
the
aws
controller
for
kubernetes
s3
edition
works
is
that
you
install
it
onto
the
cluster
we're
going
to
use
helm,
which
is
what
the
documentation
recommends
us
to
do.
You
have
to
give
ack
permission
to
create
aws
resources
from
inside
the
cluster,
so
that
includes
connecting
the
aws.
I
am
set
up
to
a
kubernetes
deployment
and
then
we
have
to
create
the
s3
yaml
and
then
finally,
we
are
going
to
show
an
app
that's
actually
using
the
s3
bucket.
B
B
B
Okay,
let's
run
through
another
cloud
provider.
So
now
we're
going
to
switch
over
to
google
cloud.
Google
cloud
offers
a
similar
service
to
ack.
It's
called
config
connector
there's
a
few
differences,
unlike
ack
config
connector
is
a
product.
It's
not
the
code,
for
it
is
not
open
source
in
the
way
ack
is,
and
it
also
operates
as
one
controller
that
can
manage
lots
of
google
cloud
resources
all
at
once,
rather
than
separate
controllers
for
each
resource
type
other
than
that.
B
These
are
very,
very
similar
tools
that
both
operate
inside
of
your
cluster
as
a
controller
right.
So
the
the
general
workflow
is
pretty
similar,
I'm
going
to
show
a
similar
setup,
a
hosted
kubernetes
cluster
in
google
cloud
that
has
permissions
to
create
resources
and
I'm
going
to
show
creating
a
cloud-hosted
resource
and
then
deploying
an
app
alongside
so
this
cluster.
Again,
it's
running
in
google
cloud.
We
can
see
it
here.
It's
called
symbol
shops.
This
is
a
google
cloud
project.
B
B
You
can
see
the
controller's
running
right
here,
so
that
should
be
all
ready
to
be
able
to
deploy.
Resources
on
our
behalf
should
be
noted
that,
like
aws,
you
do
have
to
set
up
im,
and
so
in
this
case
we
configure
config
connector
with
a
service
account
that
has
the
necessary
roles.
It
needs
to
create
resources
in
our
project
and
then
similar
to
the
s3
example.
We
can,
we
can
define
a
hosted
google
cloud
resource
as
krm,
so
in
this
case
we
have
a
instance
of
memory
store
called
redis
cart.
B
It
has
specific
spec
fields
to
memory
store
which
you
can
find
in
the
config
connector
documentation,
and
you
can
see
once
we've
applied
it,
which
I've
done
right
before
this
the
instance
is
created,
and
we
can
actually
see
in
the
google
cloud
console
over
here
on
the
right
managed
by
cnrm.
True.
What
that
basically
says
is
this
resource
was
created
from
inside
of
the
gke
cluster
using
config
connector.
B
B
Basically,
it's
a
project
owner.
It
can
delete
resources,
it
can
update
resources
and,
if
you
imagine,
a
large
production
system
that
could
be
risky
once
a
krm
resource
lands
in
the
cluster
it
gets
created,
config
connector
will
will
create
it.
So
you
want
basically
to
set
up
some
guard
rails
and
some
policies
that
happen
before
that
point.
So
what
I
mean
by
that
is,
how
is
that
km
getting
into
a
production
system?
Are
there
change
approvals
in
git?
Are
there
validations
there,
then,
once
a
resource
is
on
its
way
into
the
cluster?
B
How
do
you
make
sure
that
the
the
person
or
actor
deploying
it
is
valid
and
allowed,
and
how
do
you
make
sure
that
the
resource
is
set
up
in
a
secure
way
and
kubernetes
can
actually
handle
both
of
these
things,
which
is
cool?
The
question
of
who
can
create
what
kind
of
resource
is
actually
something
that's
pretty
much
already
covered
by
kubernetes
role-based
access
control
are
backed
for
short
and
you
may
have
used
this
for
things
like
you
know.
B
This
application
team
only
has
admin
permissions
in
like
this
specific
name
space,
and
it
helps
you
manage
multi-tenant
environments,
so
that's
already
covered,
but
then
there's
a
question
of
okay.
What
about
this
resource
right
here?
What
if
we
want
to
actually
look
inside
of
the
spec
for
a
specific
resource
type
and
set
guardrails
on
what
is
allowed
for
that
resource,
and
this
is
really
powerful,
because
with
regular
imperative
formats,
this
can
be
really
difficult.
You
know
there's
I
am
for
like
you
know
this.
B
This
user
can
create
a
redis
instance,
but
within
that
reticence,
instance
what
is
allowed
and
I'm
going
to
cover
a
project
in
cloud
native
computing
foundation
that
is
going
to
help
us
with
this
and
that's
called
open
policy
agent.
Open
policy
agent
is
a
open
source
project
with
different
parts
to
it.
One
of
them
is
called
gatekeeper
and
gatekeeper
is
a
kubernetes
admission
controller
that
runs
at
the
base
or
at
the
gate
of
the
kubernetes
api
server.
B
B
Right,
so
gatekeeper
has
a
little
bit
of
a
learning
curve,
but
once
you
get
started
with
it,
it
looks
really
similar
for
different
resource
types.
So
the
way
it
works
is
you
define
a
sort
of
an
abstract
policy.
This
is
called
a
constraint,
template
that
it's
a
it's
some
programming
code,
specifically
the
rigo
language,
which
I'll
show
in
a
moment
that
basically,
is
the
logic
of
the
policy,
but
the
actual
parameters
of
that
policy.
The
concrete
stuff
happens
in
a
separate
resource.
B
B
B
Imagine
that
our
organization
has
a
policy
that
says
you
have
to
be
on
that
version
of
redis,
for
whatever
reason
we
can
use
the
rigo
language,
which
is
a
policy
language.
It's
a
bit
different
than
a
general
purpose.
Language
you
can
see.
The
syntax
is
a
little
different,
but
basically
we're
looking
inside
of
the
resource
and
saying
is
the
redis
version.
What
it
needs
to
be
and
you
you
can
see.
This
is
not
a
hard-coded
version.
B
B
B
That
says,
as
we
defined
in
our
policy,
where
this
version
parameter
is
not
allowed,
must
use
version
parameter
and
yeah
this
this
resource
was
not
allowed
into
the
cluster,
then
again,
if
we
were
to
apply
another
reddit
v5
instance,
this
would
be
allowed
in
just
a
very
simple
example
of
how
gatekeeper
an
open
policy
agent
can
be
used
not
only
for
regular
kubernetes
resources,
but
also
for
cloud
hosted
resources
as
defined
as
krm.
So
really
powerful
and
again,
like
the
possibilities,
are
pretty
much
endless
here.
B
So
with
that,
I'm
gonna
quickly
pass
it
off
back
to
shabir.
The
one
thing
I
do
want
to
mention
you'll
see
you
may
have
noticed.
I
just
covered
two
cloud
providers,
kind
of
quick
in
succession
and
sure
you
might
just
be
operating
in
one
cloud
provider
at
a
time
and
using
one
of
the
these
tools
separately.
Could
work
really
well
for
your
organization,
but
imagine
that
you
actually
are
working
with
multiple
cloud
providers
at
once,
and
this
could
be
the
case
for
many
different
reasons.
A
So
crossplane
is
an
open
source,
kubernetes
add-on
that
can
be
simply
installed
into
any
of
your
kubernetes
clusters.
And
then
you
have
to
activate
controllers
the
various
different
cloud
providers
that
they
support
and
you
want
to
work
with.
So
they
have
wide
variety
of
supports,
so
many
of
the
public
clouds
out
there
and
with
that
crossplane
installed
inside
inside
your
cluster,
this
cluster
becomes
the
only
control
plane
for
everything
that
you
that
you're
managing
in
your
infrastructure.
A
It
could
be
your
kubernetes
resources.
It
could
be
the
cloud
resources
running
in
your
primary
primary
cloud
provider.
If
you're
running
on
another
cloud
provider,
then
you
know
you
can
use
the
same
control
plane
to
manage
resources
in
that
cloud
provider
and
also
it
can
extend
to
resources
in
your
on-prem
environments.
A
But
for
the
purpose
of
this
talk
we
will
stick
to
just
the
basic
deployment
example
using
cross
plane
and
in
terms
of
composition.
We
will,
you
know,
provide
you
useful
links
at
the
end
of
the
talk
and
also,
finally,
cross
pain,
provides
you
to
provide
the
support
for
you
to
set
policies
just
like
open
policy
agent
on
your
resources,
and
you
can
do
gatekeeping
work
on
top
of
it.
A
A
A
So,
let's
look
at
a
demo
for
the
purpose
of
demo.
We
will
not
go
through
setting
up
the
entire
setup.
We
have
already
set
it
up
in
a
kubernetes
cluster.
As
you
see
in
the
diagram
here,
we
have
a
gke
cluster
running
in
google
cloud
and
we
have
an
eks
cluster
running
in
aws,
just
without
megan
showed
and
we
have
cross
plane
installed
in
our
gke
cluster
and
this
cross
plate
installation
is
being
given.
A
A
So
what
you're
seeing
on
screen
is
the
kubernetes
cluster
that
I
have
created.
It's
called
cross
plane
cluster,
and
this
is
the
object
browser
for
the
cluster.
If
you
see
here,
you
can
see
that
it
has.
We
have.
It
has
a
bunch
of
new
object
types
which
are
which
are
then
spaced
under
crossplane
dot
io.
So
these
are
all
done
by
the
install
by
installing
cosplain
into
your
into
your
cluster
and
I'm
going
to
show
you
what
what
I
have
installed
by
look
by
going
through
some
of
the
items
in
the
cli.
A
Let's
see
what
it
shows,
as
you
can
see
here,
there
are
four
deployments
and
you
know
two
of
them
are
specific
to
two
providers.
One
is
for
aws,
one
is
for
gcp
crossplane,
also
installs
an
outback
manager
to
manage
access
control,
and
you
have
the
main
deployment
that
manages
all
of
crossplanes
activity.
A
A
So
if
you
see
here,
this
configuration
is
of
kind
provider,
config
that
says
it's
a
cosplay
provider
config
and
at
the
bottom,
you
can
see
that
it
has
associated
to
it
secret
reference
to
a
secret
inside
our
cluster,
so
this
secret
is
mainly
the
aws
seeker
that
we
would
usually
use
with
the
aws
cli.
Similarly,
the
gcp
config
has
the
gcloud.
A
A
A
A
So,
as
you
come
to
the
end,
you
know
let
us
wrap
up
today's
presentation.
What
we
saw
today
is
that
there
are
a
lot
of
ways
that
you
can
manage
your
cloud
infrastructure
in
alongside
your
kubernetes
deployment
as
well.
However,
kubernetes
resource
model
can
act
as
a
single
data
model
to
consolidate
all
of
them
and
all
your
infrastructure
in
a
single
place
using
the
declarative
model
at
the
kubernetes
page,
server
demands
and
different
cloud
providers
has
also
provided
their
own
solutions
to
be
able
to
do
cloud
resource
management
using
a
krm
based
model.
A
So
with
that,
we
come
to
the
conclusion
of
our
demo
here,
a
list
of
resources
that
we
used
in
the
slides
and
some
of
the
things
that
we
could
not
go
into
detail
because
of
the
time
constraints
please
go
through
them.
In
addition
to
that,
everything
that
we
showed
in
the
demo
has
been
has
been
put
up
in
a
git
repository
that
is
publicly
available
for
anyone
to
try
it
out.