►
From YouTube: State of the Operators: Framework, SDKs and Beyond
Description
State of the Operators: Framework, SDKs and Beyond
A
A
A
Just
want
to
give
a
little
bit
of
background
on
operators
in
case
you're
kind
of
you
know,
you've
heard
the
term,
but
you
don't
know
where
it
came
from
it
basically
maps
to
the
adoption
phases
of
apps
and
kubernetes.
Much
like
we've
heard
from
all
the
folks
on
stage
today,
and
it
really,
you
know,
we
kind
of
went
from
stateless
applications
with
you
know
just
scale
out
like
engine
X,
pods
and
caching,
and
some
of
the
stuff
that
you
heard
about
earlier
very
easy
to
replicate,
but
then
really
quickly.
A
You
want
to
get
into
staple
workloads,
and
you
know:
we've
got
things
in
kubernetes
like
the
container
storage
interface
and
staple
sets
to
help
you
do
that,
and
you
can,
you
know,
get
a
very
simple
Postgres
deployment
going
where
you're
just
sharing
storage-
and
you
know
it's
following
the
pot
around
in
the
cluster
but
very
quickly-
we've
moved
on
to
complete
distributed
systems.
So
you
know
you,
don't
have
all
the
primitives
in
kubernetes
that
you
need
to
do
things
like
data
rebalancing.
A
Take
the
operational
expertise
and
bake
it
into
a
piece
of
software
such
that
you
can
combine
that
piece
of
software
with
some
desired
configuration
and
out
pops
a
bunch
of
kubernetes
objects.
So
you
know
we're
not
interacting
if
you've
ever
run
a
complex
distributed
system
on
cube
and
you've
got
like
35
different
yamo
objects
for
all
kinds
of
stuff.
You
know
it
gets
kind
of
crazy.
All
you
need
to
do
is
interact
with
one
kind
of
top-level
config
for
the
operator.
A
The
exciting
thing
about
this
is
that
you're
building
on
kubernetes
primitives.
So,
since
all
this
stuff
ends
up
as
deployments
and
staple
sets
and
config
maps
and
secrets,
you're
not
reinventing
how
any
of
that
works.
You
know
we've
got
thousands
of
engineers
at
work
upstream
on
kubernetes,
making
secret
handling
really
great
making
service
discovery.
Really
great.
You
don't
need
to
reinvent
that,
but
what
you
can
do
is
use
that,
if
you
think
of
that,
as
your
toolkit,
you
can
use
all
of
that
to
then
construct
your
application.
A
A
They
can
work
on
any
conformant
kubernetes
cluster,
and
then
you
have
uniform,
deploy
debug
experience
using
coop
cuddle
using
any
tooling
that
you've
already
built
around
the
kubernetes
api,
and
this
is
really
great
when
you
have
engineers
that
are
either
moving
between
teams
or,
as
we
heard
about
earlier
Oh,
everyone's
kind
of
doing
90%
of
the
same
thing
and
either
their
Jenkins
pipeline
or
whatever
the
tooling
that
they
built
to
deploy
applications.
So
you
can
share
a
bunch
of
that
knowledge
using
an
operator
as
well.
A
Do
we
want
that?
Does
that
sound
great?
Is
that
the
nirvana
that
we
want
to
be
here
all
right,
then
we're
gonna
talk
about
how
we
get
that
and
it
starts
out
with
the
operator
framework.
This
was
a
collection
of
open
source
tools
that
we
introduced
about
a
year
ago
now,
and
it
really
has
two
main
use
cases.
We've
got
folks
that
are
in
the
community
and
for
builders
that
are,
you
know,
distributing
software.
A
So
this
allows
you
to
very
easily
create
an
operator
around
your
application,
and
this
can
be
either
like
a
database
that
you
might
sell
as
a
commercial
vendor.
It
might
be
an
open
source
ecosystem
like
the
tensorflow
community,
or
it
might
be
an
internal
application
within
your
bank,
your
insurance
company,
your
ecommerce
shop,
whatever
you
do
and
then
at
some
point,
you
need
to
actually
deploy
that
out
in
a
cluster
and
that's
done
by
some
end
users,
whether
those
are
sres
within
your
organization.
A
There
might
be
customers
of
yours
and
they
want
to
keep
this
stuff
up
to
date.
You
know
in
the
days
of
all
these
security
vulnerabilities,
of
which
we
just
you
know,
had
a
new
one.
Last
week,
this
stuff
needs
to
be
up-to-date.
You
need
to
have
a
stream
of
updates
coming
down.
We
think
the
stream
of
updates
to
the
operator,
which
then
operates
the
software,
makes
a
ton
of
sense.
A
So
if
you
haven't
looked
at
the
SDK
and
the
lifecycle,
manager
and
operator
metering,
those
are
the
components
of
the
framework,
at
least
the
three
main
ones,
and
these
are
tools
that
roughly
map
to
building
new
operators
running
those
operators
on
a
set
of
clusters
and
then
collecting
metrics
and
other
things
at
scale.
Once
you
have,
you
know,
you're
running
a
thousand
databases
with
an
operator.
These
are
all
housed
in
a
vendor,
neutral,
github,
org
operator
framework
and
we've
got
a
collection
of
all
this
software,
as
well
as
a
few
other
projects
there
as
well.
A
One
thing
that's
really
important
to
understand
when
we're
talking
about
operators
is
we
have
this
maturity
model,
and
this
is
really
important,
because
these
things
can
be
really
complex
and
every
application
is
a
little
bit
different,
but
we
want
to
be
able
to
map
these,
so
we
can
talk
about
them
in
conjunction
with
each
other
and
at
the
bottom
here
you'll
see
some
of
the
flavors
of
the
SDK
which
we're
going
to
talk
about,
and
these
are
roughly
how
this
technology
maps
to
these
maturity
models.
This
isn't
like
a
perfect
diagram.
A
You
know
you
can
get
kind
of
between
a
bunch
of
these
phases
and
you
don't
have
to
use
any
of
our
SDKs
as
well,
but
this
roughly
gets
from
you
know,
table
stakes
is
install
and
upgrade,
and
everybody
here
is
doing
that
with
software
today.
So
you
know
you
just
have
to
have
that
in
this
modern
ecosystem.
But
all
the
way
to
the
right-hand
side
of
this
is,
if
you
picture
like
the
smartest
cloud
service
that
you've
ever
seen,
you
know
this
is
something
that
is
horizontally
and
vertically.
A
Auto
scaling
auto-tuning,
based
on
the
number
of
requests
or
the
type
of
workload
that
it's
processing.
You
know
it's
something:
that's
auto:
upgrading,
auto
backup,
whatever
it
is,
auto
failover.
This
picture
that
cloud
service.
This
is
what
that
category
is
all
about,
and
what
these
SDKs
and
all
the
community
that
we're
building
around
this
is
designed
to
do
is
to
get
everybody
to
this.
A
This
phase,
five
of
this
maturity
model,
and
we
think
that's
kind
of
the
key
for
having
this
truly
hybrid
cloud
and
the
experience
that
you
actually
want
that
cloud
like
experience,
but
on
Prem
on
any
hardware
you
want
and
your
private
data
centers
behind
you.
You
know
your
the
lockdown
environment
on
Amazon,
whatever
it
is.
This
truly
cloud
like
experience
powered
by
kubernetes.
A
So
how
do
we
get
there?
The
first
step
is
taking
either
one
of
our
SDKs
off
the
shelf,
or
you
can
just
you
know,
build
and
operator
yourself
and
what
this
feeds
into
is
these
three
flavors
share
some
things
in
common
and
the
testing
framework
is
the
first
and
this
is
really
really
important,
because
if
you
picture
like
a
database
operator,
it's
a
Postgres
operator,
let's
say
there's
going
to
be
this
desired
state
loop
in
there.
A
That's
comparing
all
the
post-crisis
that
you
have
out
there
if
they
need
to
do
leader
election
that
they
need,
if
you
failover,
if
they
need
to
be
backed
up
whatever
it
is,
and
you
want
that
to
work,
you
don't
want
it
and
you
know
you're
in
production
and
your
databases
are
getting
deleted
by
your
operator
and
you
don't
have
their
backups
or
your
backups
aren't
running.
You
know.
A
That's
really
really
critical,
that
this
is
well
tested,
and
so
our
SDKs
help
you
do
that,
no
matter
what
technology
that
you're
using
and
then
we
go
into
some
of
it.
We
have
called
a
scorecard-
and
this
is
just
something-
that's
like
a
kind
of
blackbox
testing
for
an
operator
to
make
sure
can
I
instantiate
this
on
the
cluster
when
I
give
it
a
custom
resource.
Does
it
actually
do
something?
A
All
of
this
so
I
want
to
talk
through
some
of
the
SDKs,
because
in
the
high
level
that
you
get
some
of
the
previous
presentations,
you
know
just
dig
a
little
bit
into
the
technical
details.
So
you
kind
of
know
what
you're
getting
into
if
you
want
to
go
home
and
build
one
of
these
and
the
first
and
easiest
way
to
get
started
is
with
our
Hjelm
SDK
I
call
this
like
the
quote:
unquote,
no
code!
A
This
is
different
than
Kelsi
Hightower's,
no
code
thing
if
you're
familiar
with
that
pretty
funny,
and
what
this
allows
you
to
do
is
we've
written
all
the
tooling
for
you
to
take
an
existing
helm,
chart,
build
it
into
an
operator
and
then
run
that
on
a
cluster.
So
it's
constantly
looking
for
changes
to
your
desired
configuration,
which
is
like
your
helm,
values,
yeah,
Mille
and
then
applying
those
out
kind
of
rerunning
that
templating-
and
this
is
what
it
all
takes
to
do.
A
It
is
you
can
just
go
say
this-
is
a
I
want
to
take
the
stable
tomcat
chart,
build
it
into
an
operator.
The
nice
thing
about
what
this
is
doing
under
the
hood
is
it
is
a
container
build.
So
you
know
we
like
containers,
because
there
are
mutable
artifacts,
we
conversion
them,
and
then
we
know
that
we're
going
to
get
the
same
deployment
outside
when
we
run
it
on
this
cluster
or
that
cluster.
You
get
the
same
thing
with
an
operator.
A
Here
you
see,
we've
got
two
of
them
running
totally
native
into
the
experience
that
you're
used
to
all
these
things
get
written
out
to
like
the
kubernetes
audit
log.
You
can
put
our
back
around
them
all,
just
a
really
great
experience,
all
cube
native
and
what
you're
operating
against
is
that
Tomcat
object
that
you
see,
which
is
a
custom
resource?
It's
an
instance
of
a
custom
resource
definition,
and
the
exciting
thing
is
that
is
your
API
surface.
A
Now
you
can
change
your
operator
as
much
as
you
want
implementing
new
features,
adding
new
things,
but
this
this
object
is
what
you
our
end.
Users
are
going
to
be
coding
against,
and
so
we
have
an
ansible
SDK.
That
gets
you
much.
The
exact
same
experience,
but
if
you
have
an
investment
in
ansible
playbooks
and
that
you're
kind
of
you
know,
maybe
you
have
a
more
op
c
background
than
like
a
traditional
software
development
background.
This
is
a
really
great
way
to
get
started
there.
A
A
So
you
same
object
schema
you
get
the
same
experience
on
hosi,
so
it
doesn't
matter
what
technology
that
you
use
to
build
these
and
last
the
last
flavor
of
our
SDK
is
our
go
SDK,
and
this
is
you
know,
kind
of
the
cream
of
the
crop,
the
most
powerful
SDK
that
we
have
and
under
the
hood.
This
is
using
all
the
same
tooling
as
kubernetes
developers
use
upstream.
A
So
you
can
write
extremely
powerful
operators,
and
this
is
what
a
lot
of
the
staple
workloads
like
the
mongos
and
the
Redis
and
Couchbase
and
crunchy
data
all
these
folks
use
because
they
just
need
a
lot
of
control
over
what's
happening
in
the
operator,
and
this
code
chunk
that
I
have
here
is
a
really
simple
stubbed
out
desired
state
loop.
This
is
what
your
operator
is
constantly
running,
and
so,
when
I
talk
about,
you
know
bringing
the
operational
expertise
to
that.
You
have
about
your
piece
of
software.
A
This
is
what
your
right,
so
here
we're
just
saying:
oh
you
know
we
don't
have
any
Tomcats.
This
is
an
initial
deployment,
so
here's
the
code
to
go
construct,
one
of
those
it's
these
staple
sets.
It's
create.
This
config
map
generate
this
TLS
certain
into
these
pods.
You
know,
etc,
etc.
You
would
stub
all
that
out
there
and
then
you've
just
got
this
constant
loop
running
about
checking.
A
You
know
all
the
parameters
of
your
Tomcats
and
you
know
if
you,
if
your
operator
knows
how
to
do
a
new
thing
in
the
future,
then
it
can
upgrade
those
into.
That
is
a
really
key
part
of
that,
and
so
that's
kind
of
you
know.
We
wrote
all
the
logic
to
talk
to
the
kubernetes
api
and
all
those
types
of
things
so
that
you
can
just
focus
on
writing
this
desired
state
loop.
A
A
Operators
that
have
listed
them
on
operator
hub,
and
the
idea
here
is
to
have
your
end-user
software
engineers,
the
folks
that
you
are
supporting
or,
if
you're,
on
one
of
these
teams
to
get
workloads
running
really
quickly
in
a
production
ready
environment
without
having
to
be
an
expert.
So
if
you
need
to
run
a
spark
cluster,
you
need
to
know
how
to
use
spark,
of
course,
but
you
don't
need
to
be
an
expert
in
oh
this
component.
A
When
it
comes
up,
it
does
service
discovery
and
talks
to
this
thing
and
the
load
balancing
works
like
this.
You
know
you
just
need
to
be
kind
of
at
a
very
high
level
times
every
workload
that
you
run
from.
You
know:
messaging
queues
to
staple
workloads,
to
machine
learning,
ai
workloads,
all
that
type
of
stuff.
I
wanted
to
call
out.
One
example,
which
is
kind
of
cool,
which
is
amazon,
has
a
service
operator.
This
is
listed
on
an
operator
hub
with
all
the
other
operators
that
we
have
and
what
this
does
is
translate.
A
Amazon
objects
like
an
s3
bucket
or
an
RDS
database,
or
whatever
into
kubernetes
CR
DS.
So
once
again,
you're
using
that
cube
native
tooling,
you
can
put
our
back
around.
Who
can
create
these,
who
can
modify
them,
but
behind
the
scenes
it's
actually
talking
to
Amazon
and
creating
you
know
all
those
objects
for
you
and
so
I
think.
That's
where
we're
going
to
see
the
operators
concept
going
is
starting
to
talk
to
other
remote
resources.
You
know
connecting
with
internal
workflows
that
your
organization
might
have
like
we
heard
from
six
earlier
about.
A
A
So
this
gets
you,
you
know
an
H,
a
production,
ready
form
of
MongoDB.
You
can
use
that
and
you
know,
keep
you
in
a
git
repo,
for
example,
and
do
git
ops,
but
it's
self-service.
So
you
can
tune
this.
If
you've
got
settings
you
want
to
move
from
staging
to
production.
You
don't
have
to
get
your
admins
involved.
You
don't
need
to.
You
know
deal
with
your
central
IT
team,
which
is
a
really
really
powerful
concept.
When
you
want
to
have
you
know,
40
teams
sharing
a
cluster.
A
This
is
the
only
way
that
you
can
kind
of
scale
to
that
and
I
mentioned
get
ops
and
you've
heard
it
today.
The
get-ups
power
is
is
really
really
cool
when
this
works.
So
you
can,
you
know,
think
about
like
a
pull
request,
maybe
that
you've
seen
recently
for
a
bunch
of
Kubb
objects.
I
mentioned.
Sometimes
you
have
this.
You
know
a
complex
app.
That's
made
up
of
35
kubernetes
objects,
you're
reviewing
someone
who
made
a
change
that
has
to
go
talk
to
maybe
20
of
those
things.
A
It's
a
new
secret
that
you
need
to
wire
through
everything
now
you're
reviewing
these
35
things,
you're,
not
maybe
a
spirt
in
all
of
them,
because
it's
the
front
end
and
a
back
end,
for
example,
and
so
you're
kind
of
like
yeah.
That
PR
seems
good,
but
I,
don't
really
know
how
this
actually
bubbles
through
everything.
But
wouldn't
you
rather
just
go.
A
If
you
want
to
introspect,
what's
going
on,
you
need
a
higher
level
view
versus
you
know
you
might
have
1500
pods,
as
we
saw
or
you
know,
we've
got
clusters
that
have
thousands
and
thousands
and
thousands
of
pods
on
them
very
hard
to
see.
What's
going
on
and
then
as
an
admin,
you
have
full
insight
into
the
operators
that
are
running,
and
you
know
we
were
talking
about
that
stream
of
updates.
A
You
need
to
know
exactly,
maybe
in
production
you
don't
subscribe
to
a
stream
of
updates
from
Couchbase,
for
example,
but
in
staging
more
dev
or
in
everyone's
individual
environment.
You
do,
and
this
is
really
powerful,
but
you
also
need
to
be
able
to
see
what
versions
is
everything
at
what
channels
am
I
on
and
different
namespaces?
So
you
can
see
that
inside
of
the
OpenShift
console,
you
can
also
interact
with
these
via
the
command
line.
A
So
I
want
to
encourage
you
to
try
this
out.
We've
got
a
getting
started
guide
that
ties
together
the
entire
operator
framework,
but
you
can
also
look
at
getting
started
guides
for
all
the
flavors
of
SDKs
that
we
saw
so
if
you've
got
helm
charts.
If
you
want
to
try
the
answerable
SDK
or
give
it
a
whirl
for
the
entire
go
SDK,
you
can
find
all
that
on
the
top
link.
A
We
also
have
an
operator
special
interest
group
that
meets
as
part
of
Oakland
chef
Commons,
and
this
is
a
group
of
folks
like
yourselves,
that
are
solving
problems
together,
showing
off
things
that
they've
made
trying
to
figure
out.
What's
the
best
practice
for
doing
X
or
Y,
and
some
things
that
we're
working
on
in
this
group
are
things
like
if
you're
familiar
with
the
open
service
broker
and
it's
binding
concept
bringing
that
into
the
operator
ecosystem?
A
What
does
that
look
like
how
do
operators
work
together
if
you've
got
a
cluster
monitoring
operator
in
a
database
operator?
Can
you
auto
orchestrate
monitoring
of
that
database?
Those
types
of
things
are
all
things
that
we're
talking
about
in
this
SIG,
so
we'd
love
to
have
you
and
bring
your
use
cases
to
that
as
well,
and
then,
lastly,
if
you're,
just
you
want
to
consume
some
operators
or
see
which
ones
are
out
there
operator
hub
do
is
constantly
updated.
I
think
you
know,
we've
got
30
or
40
operators
on
there
right
now.
A
You
can
also
find
these
inside
of
an
open
ship
for
cluster,
as
you
saw
this
morning,
so
really
exciting
community
that
we're
building
there,
and
if
you
have
an
operator
that
you
want
to
list,
please
let
us
know
it's
kind
of
a
pull
request
process
that
you
can
do
on
github
as
well.
So
with
that
we're
going
to
start
our
panel.
So
if
our
panelists
could
start
coming
up
here
and
I'll
be
around
afterwards
we'd
love
to
take
your
questions
about
building
operators
a
little
bit
later
on.