►
From YouTube: From Tweet to BadIdea: Creating an Embeddable Kubernetes Style API Server - Jason DeTiberus
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. 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.
From Tweet to BadIdea: Creating an Embeddable Kubernetes Style API Server - Jason DeTiberus, Equinix Metal
Kubernetes Custom Resource Definitions (CRDs) have made building Kubernetes-style declarative APIs easy. However they depend on an existing Kubernetes cluster, which can lead to difficult bootstrapping issues when building infrastructure management tooling. Would it be possible to remove the Kubernetes cluster dependency by piecing together the components that Kubernetes itself uses to implement the features needed to support CRDs? This talk explores the process of attempting to do just that through the process of building a minimal and embeddable Kubernetes style API Server with CRD support.
A
Hello,
thank
you
for
joining
me
for
from
tweet
to
bad
idea,
creating
an
embeddable,
kubernetes
style
api
server.
My
name
is
jason
detebros.
I
am
at
equinix
metal
and
I
am
working
to
bring
cloud
native
infrastructure
management
into
the
data
center.
I
am
also
one
of
the
co-maintainers
for
the
cluster
api
project,
and
you
can
generally
find
me
on
twitter
at
dtipper.
A
A
A
A
A
Well,
this
rabbit
hole
got
me
doing
a
lot
of
research.
You
know.
Has
somebody
already
done
this?
You
know
there's
been
kind
of
rumblings
back
forth
between
people
in
the
community
about
whether
or
not
this
is
something
that
could
be
possible.
You
know
people
talking
about
potentially
doing
it.
Tim
hawking
was
talking
about
this
back
in
2018,
about
trying
to
move
more
kubernetes
resources
themselves
towards
crds
versus
being
built
in
types
and
and
things
like
that.
A
A
A
I'd
also
like
to
avoid
exposing
unnecessary
ports.
You
know,
there's
there's
no
reason
why
an
application
would
need
to
expose
things
that
are
only
used
internally.
So
can
we
take
advantage
of
some
features
to
avoid
having
to
expose
many
different
ports
and
talking
back
to
each
other
on
open
public
ports?
A
So
if
you
look
at
some
of
the
existing
tooling
in
the
space,
it
generally
falls
into
several
different
categories.
The
first
one
is
api,
aggregation
and
generally
right
now,
the
most
mature
project,
for
that
is
the
simple
api
server
kind
of
like
api
server.
The
hard
way
you
basically
have
to
create
everything
from
scratch,
and
that
seems
very
painful
maintenance,
wise,
and
it
also
doesn't
actually
give
me
the
capability
of
being
able
to
run
crds
using
it.
A
There's
also
a
new
and
upcoming
project.
Api
server
builder
alpha,
which
is
trying
to
do
for
api
aggregation.
What
the
kubeler
project
has
done
for
building
crd
based
projects
that
also
brings
into
the
same
kind
of
deal
is
that
it's
meant
for
building
aggregated
api
servers,
and
I
really
want
to
be
able
to
leverage
the
functionality
of
cres
rather
than
api
aggregation.
A
Maybe
not
necessarily
for
trying
to
you
know,
do
the
embedded
xia
model
that
I
have.
Hopefully
my
thought
is.
Is
you
would
still
be
able
to
rely
on
these
tools
in
addition
to
a
new
project,
to
sit
there
and
provide
the
full
functionality
for
this?
So
we
don't
expect.
I
don't
expect
to
be
recreating
the
functionality
that
exists
with
the
crd-based
tool
and
then
why
not
just
use
the
underlying
libraries.
Like
I
said
I
don't
want
to
reinvent
unnecessary
wheels.
A
They're,
also
right
now
very
highly
tied
into
cobra,
and
if
you
use
the
commands
directly,
it
automatically
exposes
all
of
the
command
line.
Arguments
from
kubernetes
and
quite
a
bit
of
the
functionality
for
actually
tying
together
the
extensions
api
server
and
the
aggregation
server
right
now
actually
lives
in
kubernetes,
kubernetes
itself.
A
Like
I
said,
these
are
tied
into
command
line
arguments,
so
there's
a
layer
of
command
line
config
that
goes
into
options.
That
then
needs
to
be
chained
through
several
different
ways
and
and
the
components
are
kind
of
glued
together
at
various
different
points
of
that
configuration
chain
so
trying
to
correctly
wire
them
all
up
together
is
actually
quite
error
prone
today,
outside
of
the
main
repository.
A
So
what
exactly
would
the
standalone
use
case
look
like
well
in
this
in
this
simple
use
case,
my
thought
is:
is
you
would
have
your
own
application
providing
its
own?
You
know
services
for
whatever
you're
trying
to
do
you'd
be
able
to
embed
in
kind
of
what's
currently
this
bad
idea
project
and
you
can
leverage
the
existing
kubernetes
clients
and
tooling
to
interact
with
that
application.
A
For
the
purposes
of
this
demo,
I
am
going
to
take
advantage
of
two
different
repositories,
both
under
the
github
organization,
the
tire
fire.
I
created
this
github
organization,
basically
as
a
joke,
because
I
didn't
know
exactly
if
this
idea
was
going
to
have
legs
or
not,
and
the
core
library
that
I'm
going
to
be
using
today
is
under
the
bad
idea
repository
and
the
example
application
that
I've
started
to
create
that
actually
embeds
the
bad
id
api
server
is
just
example
right
now,
so
let's
go
ahead
and
take
a
look
at
that
code.
A
So
if
we
come
in
here,
just
look
at
the
dependencies
that
we're
bringing
in
right
now
we
can
see
that
I
am
importing
bad
idea
and
outside
of
that,
I'm
importing
very
little
from
the
other
kubernetes
repositories.
I
am
importing
controller
runtime
here
because
I
built
this
project
out
using
the
qbuilder
scaffolding
for
the
crd
resources
and
the
controllers,
and
I
did
have
to
pull
in
api
machinery
and
client
go
right
now.
I
did
have
to
make
sure
that
the
controller
runtime
version
is
synced
up
with
the
api
server
version
that
bad
idea
is
using.
A
A
Here
in
the
main
function,
it
looks
very
much
just
like
a
normal
q-builder
based
application,
I'm
creating
basically
the
signal
handler
to
be
able
to
handle
cleaning
up
of
the
resources,
I'm
spawning
off
the
bad
idea
server,
and
this
is
doing
a
lot
of
leg
work
behind
the
scenes.
For
me,
this
is
actually
going
to
spin
up
the
embedded
lcd
instance.
A
It'll
also
stand
up
the
necessary
components
to
be
able
to
handle
that
as
well,
and
then
at
that
point,
I'm
creating
a
client
configuration
into
that
bad
idea
server
and
if
I
go
up
there
to
that,
real
quick.
All
I'm
doing
here
is
basically
generating
kind
of
a
very
basic,
rudimentary
cube
config
the
server.
I
know
it's
going
to
be
coming
up
on
localhost
port
6443.
A
So
I
do
need
to
set
a
username
and
a
password
here
to
make
the
client
tooling
happy.
It's
actually
going
to
ignore
that
and
just
allow
it
anyway
as
an
unauthenticated
request,
and
then
I'm
going
to
put
that
together
in
the
cube
config
and
with
that
cube
config.
I'm
then
generating
a
rest
config
and
here's
where
things
get
a
little
hacky
right
now,
but
as
soon
as
what
I'm
doing
here
is
I'm
basically
waiting
for
that
bad
idea,
server
that
we
created
to
come
up.
A
So
I'm
creating
a
discovery,
client
here
and
making
sure
that
the
server
responds
before
continuing
and
again
a
little
bit.
Hacky
right
here
is
I'm
basically
just
shelling
out
to
customize
and
cube
cuddle
right
now
to
apply
the
crds
that
are
defined
through
the
q
builder
scaffolding
and
then
at
that
point.
A
After
those
resources
have
been
applied,
I'm
now
actually
starting
up
the
controller
manager
for
the
q
builder
based
controller
in
this
project.
Now
I
I
just
really
started
kicking
the
tires
on
this.
I
didn't
really
have
a
really
good
example
to
use.
So
basically,
I
just
created
a
very
simple
bar
type
within
the
within
a
food
group.
For
the
purposes
of
this
demo,
it's
just
a
very
simple
spec
definition.
A
If
I
actually
go
into
the
controller,
we
can
see
that
all
I'm
doing
in
the
reconcile
right
now
is
I'm
getting
the
request
requested
resource.
I
have
a
couple
of
to-do's
in
here
to
actually
do
something
with
them
and
then
I'm
simply
just
setting
the
status
just
to
show
that
the
resource
has
been
reconciled,
so
I
can
go
ahead
and
bring
that
up
right
now,.
A
And
this
is
going
to
actually
go
and
spawn
up
the
all
those
instances.
All
of
those
services
that
I
mentioned
and
we're
going
to
see
some
errors
in
here.
I'm
still
working
out
some
of
the
intricacies
around
how
to
wire
all
of
these
things
together,
especially
in
the
case
that
we
don't
have
things
like
services
and
endpoints.
A
A
A
A
A
A
So,
let's
see,
if
that
happens,
and
we
do
we
see
that
resource
is
actually
there.
So
we've
created
this
minimal
embedded
api
server,
we've
crea,
we've
wrapped
it
in
this
example-
application,
where
we've
also
defined
these
crds
and
with
one
binary
we're
able
to
bring
up
a
system
that
is
persisting,
data
with
ncd
and
can
interact
with
crd.
A
A
So
what
exactly
is
missing?
Well,
the
first
thing
is
configurability
of
pretty
much
everything
everything
from
what
tls
certificates
you
want
to
use
to
being
able
to
use
an
external
lcd
data
source,
or
even
some
of
the
different
configuration
around
what
ports
you
want
to.
Listen
to,
and
things
like
that.
A
A
So
we
need
to
try
to
figure
out
how
to
handle
that
type
of
situation
and
then,
finally,
the
ability
to
run
all
of
the
non-deployment-based
components
of
a
non-trivial,
crd-based
application-
and
I
figured
something
like
cert
manager-
would
be
a
good
kind
of
milestone.
Like
can
we
run
all
of
the
bits
assert
manager
outside
the
actual
deployments
as
part
of
this
project?