►
From YouTube: State of Operators: Framework, SDKs, & beyond Sébastien Pahl RedHat OpenShift Commons Gathering 2018
Description
State of Operators: Framework, SDKs, & beyond Sébastien Pahl, RedHat at OpenShift Commons Gathering 2018
https://commons.openshift.org/gatherings/Seattle_2018.html
A
Hi
welcome.
Thank
you
very
much
for
coming
as
Diane
said,
I'm
Sebastian,
I
work
at
Red
Hat
on
operators
and
I
lead
the
teams
that
are
doing
all
of
that.
So
it's
not
just
me.
It's.
It's
mainly
a
lot
of
engineers
working
with
passion
on
this
project.
I'm
gonna
go
into
detail
today
about
operators
and
what
an
operator
is
before
and
what
kind
of
tools
we
built
at
Red
Hat's
to
try
to
help
the
community
and
help
IVs
to
build
these
operators
and
to
also
distribute
them
and
operate
them
in
production.
A
That
is
the
whole
goal
of
this
endeavor.
So
containers
brought
us
a
lot
of
simplicity,
complications
as
well,
of
course,
but
simplicity
before
as
a
developer.
What
I
had
to
do
when
I
wanted
to
start
developing
my
software
just
start
not
doing
anything
else.
I
would
have
to
know
how
to
configure.
Let's
say
if
it
was
a
web
app,
my
Postgres
database
or
my
my
sequel
database
locally.
A
What
containers
brought
us
is
the
ability,
at
least
for
developers,
to
do
something
very
simple,
dr.,
Poole,
Postgres
or
Redis
run
it
I
can
start
developing
I.
Don't
have
to
do
anything
else,
that's
pretty
tremendous
like
it
shaves
off
hours
of
time,
and
it
also
allows
a
whole
category
of
people
who
weren't
able
to
do
this
at
all,
who
couldn't
access
that
to
start
working
on
their
code
and
focusing
on
their
own
problems.
A
Now
the
problem
with
docker
containers
and
all
of
these
things
is,
it
doesn't
translate
completely
all
these
promises
don't
translate
completely
into
the
production
world.
That's
why
we
have
things
like
kubernetes
once
running
something
locally.
It
doesn't
mean
that
you
can
run
it
on
a
cluster
with
with
failover
tolerance
and
also
things
like
managing
upgrades
of
them
and
also
in
general.
Kubernetes
helps
for
these
things
as
well
like
it.
A
It
comes
with
tremendous
amount
of
generic
features
to
help
you,
for
it
sample,
build
an
application
and
put
storage
behind
it,
and
if
your
application
dies,
storage
will
follow.
It
gives
you
high
level
primitives,
like
secrets
and
all
kinds
of
other
api's
that
you
can
use
to
build
and
deploy
your
applications.
But
today,
when
you
use
kubernetes,
it's
still
a
lot
of
manual
steps.
An
application
is
not
just
a
single
package
in
a
container
that
you
run
somewhere,
it's
usually
a
lot
of
domain-specific
knowledge,
that
is
in
the
heads
of
domain
experts
of
operations,
people.
A
This
is
internal
to
companies
for
their
own
software,
but
also
for
big,
open
source
projects
and
big
commercial
projects.
All
of
these
projects
require
a
lot
of
knowledge
to
operate.
Just
handling
upgrades
like
from
one
version
to
another
or
handling
like
the
scaling
up
and
down
of
such
an
application
based
on
concrete
and
important
metrics.
All
of
that
what
operators
bring
is
a
pattern
in
2016
core
OS
came
out
with
that
pattern
that
we
could
build
on
top
of
kubernetes
leverage,
all
these
generic
KPIs
and
build
a
system
that
does
all
of
this
automatically.
A
You
transform
all
your
domain-specific
knowledge
into
code,
and
you
leverage
and
extend
the
kubernetes
api
is
to
run
that
code
to
deploy
that,
on
top
of
not
just
one
kubernetes,
not
just
one
kubernetes
cluster
but
multiple
clusters
across
multiple
cloud
providers
and
also
locally
what
that
gives.
You
is
something
that's
akin
to
a
cloud
service
today
you
can
go
to
Amazon
and
ask
for
RDS
for
a
Postgres
database,
and
you
won't
worry
about
a
lot
of
things,
you're
worried
about
others
and
the
same
thing.
We
want
to
bring
to
open
source
and
commercial
software.
A
We
want
people
to
be
able
to
provide
that
same
mechanism
and
feeling
of
being
able
to
deploy
instances
of
your
completely
production-ready
services,
one
by
one
one
after
the
others.
I'll
show
later
an
example
about
how
you
can
do
it
with
the
Prometheus
or
an
sed
operator.
This
pattern
lends
itself
very
well
to
conflicts
and
stateful
applications,
but
it's
not
only
for
that.
You
can
also
help
deploy
web
applications
and
other
stateless
apps
with
it
and
lends
itself
particularly
well
to
more
complex,
distributed.
A
Applications
like
Kafka
or
Cassandra,
but
also
we'll
see
Postgres,
for
example,
is
not
that
easy,
even
if
it's
not
distributed
per
se,
there's
a
lot
of
operators
that
are
being
built
across
the
industry.
We
have
a
link
that
currently
we
have
them
referenced
in
this
github
repository
called
awesome
operators,
I'm
gonna
talk
about
various
ways
how
we're
gonna
bring
them
more
forward
than
that,
but,
as
you
can
see,
this
is
a
variety
of
software.
A
Red
Hat
has
contributed
their
own
like
Etsy,
D
and
Prometheus
through
the
acquisition
of
core
OS,
but
also
things
like
Kafka,
and
then
we
also
have
external
ISVs
and
also
open
source
solutions
that
are
building
their
own
like
for
Redis
and
for
Postgres
or,
like
crunchy,
is
doing
for
Postgres.
This
allows
you
to
use
the
same
open
source
software
that
you
know
as
a
very
simple
way
without
having
to
know
the
complexities
of
operating
it.
A
What's
the
operator
framework.
Well,
despite
building
operators,
it's
all
sounds
nice
and
easy.
Here's
a
new
promiseland,
here's
something
new
for
you
to
like
put
all
your
codes
and
it'll
do
magically
what
few
wants.
Well,
that's
not
how
it
really
works
in
practice.
In
practice.
You
have
to
know
a
lot
about
kubernetes.
You
have
to
know
a
lot
of
details.
You
have
to
build
a
lot.
You
have
to
run
that
code.
You
have
to
deploy
that
code.
A
You
have
to
do
a
lot
of
things
that
can
be
done
in
a
generic
way
in
a
way
where
you
write
at
once,
and
it's
reused
by
multiple
people.
The
operators,
decay
is
one
of
those
projects
that
we've
done
the
operator.
Sdk
allows
you
to
create
new
scaffolding
for
your
code
to
generate
that
new
codes
update
that
code
and
also
make
sure
that
you
don't
have
to
know
all
the
intricacies
of
the
kubernetes
api
when
you're
starting
and
that
you
can
focus
on
your
domain-specific
knowledge.
A
These
are
all
things
that
come
together
and
the
operators
decay
provides
libraries
to
tests
to
do
things
like
metrics
to
expose
your
your
to
expose
your
internal
domain-specific
knowledge
in
terms
of
a
kubernetes
api.
That's
what
it
does
once
you
have
an
operator,
let's
say,
for
example,
a
memcache
operator
that
when
you
sends
it
a
new
question,
it
will
generate
a
new
memcache
service
for
you
once
you
have
that
you're
going
to
end
many
more
operators,
you're
going
to
want
to
distribute
them
and
manage
them
in
order
to
distribute
and
manage
them.
A
We
created
something
called
the
marketplace
and
operator
psyche,
lifecycle,
manager.
What
it
does
operate.
Lifecycle
manager
is
kind
of
an
operator
for
operators,
you're
able
to
take
operators,
deploy
them
update
them
automatically
subscribe
to
new
versions
of
them.
If
you
want
it
to
happen
automatically
and
always
be
assured
that
you
have
a
certain
amount
of
operators
that
you
decided
on
your
cluster,
the
other
thing
that
it
does
for
that
is,
it
creates
and
I'll
show
it
in
a
demo
shortly
a
nice
UI
to
manage
all
of
that,
then
we
also
have
metering.
A
A
They
are
cost
in
terms
of
AWS
costs,
all
of
this
things
that
can
be
extracted
and
then
reported
on
where
the
metering,
so
that
teams
can
do
things
like
show
back
and
charge
back
and
all
of
these
things
there
will
be
a
completely
in-depth
session
about
metering
later
in
the
conference,
so
without
further
ado,
I'm
gonna
demo
a
bit.
If
that's
these
things,
because
I
think
that
this
is
one
of
the
more
interesting
ways
of
understanding
how
this
all
works.
A
So
what
I
have
here
is
a
cluster
that
is
installed.
It's
open
shift,
it's
running
the
latest
version
and
on
there
I
have
the
operator,
lifecycle
manager
and
the
operator
Marketplace
installed
what
their
marketplace
does,
and
this
is
a
very
early
preview
of
it.
We're
gonna
release
a
version
very
soon.
What
their
marketplace
does
is
it
allows
anyone
to
push
operators
to
Quetta,
IO
and
eventually
other
registries
and
using
these
operators
pushed
equator
at
yo
and
make
them
appear
in
every
single
in
any
single
cluster
that
has
the
marketplace
installed.
A
So
this
allows
is
vs
to
have
one
commonplace
of
building
and
exposing
operators.
Red
Hat
will
be
helping
and
certifying
I
these
operators
and
making
sure
that
they
work
in
a
fully
automatic
way
and
according
to
a
certain
set
of
standards,
and
our
tools
will,
like
the
framework,
will
help
validate
those
operators
automatically
continuously
over
time.
So
that's
somebody
who
uses
something
that
is
in
this
marketplace
can
have
the
guarantee
that
it's
continuously
updated.
If
one
doesn't
want
it,
one
can
also
say
at
every
step.
A
Yes,
I
want
to
check
on
every
upgrade,
of
course,
but
by
default
you
can
have
it
automatic.
You
upgrade
it
just
like
your
phone.
Does
it
for
different
apps
and
you
can
trust
that
they're
going
to
automatically
handle
things
like
failures
and
other
things
like
this
once
you
have
it
something
in
the
marketplace,
the
operator
of
a
cluster
can
decide
who's
allowed
to
install
these
applications
and
ask
the
operator
to
deploy
new
instances
of
them.
A
This
is
all
done
later
by
through
the
what
we
call
the
operator
lifecycle
manager
once
I
have
the
operator
lifecycle
manager
installed.
I
can
subscribe
to
operators
in
this
case,
I've
already
subscribed
to,
for
example,
at
CD
and
I
can
see
that
my
operator
is
installed.
My
operator
provides
me
with
a
bunch
of
different
operations
that
I
can
do
like,
for
example,
creating
a
new
at
CD
cluster.
Before
we
do
that,
have
a
look.
Do
we
already
have
a
net
CD
cluster
running
I
can
see
here.
Yes,
I
have
one
it's
called
example.
A
It
has
three
pods,
that's
quite
nice,
let's
do
a
new
one
ourselves.
So
in
this
case,
you
can
see
that
I'm
going
to
so
this
is
kubernetes
api.
So
now
we're
going
to
a
bit
more
into
the
details,
but
basically
every
single
kubernetes
api
looks
like
this.
I
I'm
pretty
sure.
Most
of
you
know
this
is
an
extension
to
that
API,
specifically
to
spin
up
new
at
CD
clusters,
fully
managed
at
CD
clusters.
A
We're
going
to
call
this
one
example,
since
we
already
have
one
so
we're
going
to
call
it
coop
con
and
a
size
of
3
is
the
default
or
3
nodes,
so
I'm
going
to
create
it,
and
you
can
see
that
I'm
taken
to
this
new
instance
page
where
I
can
see
that
my
coop
click
on
cluster
is
being
created
and
then
I
can
go
to
the
instances
go
here.
I
can
see
that
right
now
there
is
only
one
member
yet,
but
three
pods
I
can
change
the
size.
We're
not
going
to
do
this
right
now.
A
Still
spinning
up,
we
can
see
that
it
now
has
three
pods
and
also
you
can
also
see
every
single
kubernetes
resource
that
has
been
created
by
this
by
the
operator.
For
this
specific
instance
like,
for
example,
these
kubernetes
services,
because
that's
also
the
goal.
If
you
want
to
be
able
to
install
a
resource
easily,
you
should
be
able
to
uninstall
an
resource
easy.
So
we
have
this
kubernetes
these
this
SED
cluster
running
on
kubernetes.
A
Now
we
can,
for
example,
increase
the
size
because
it's
time
to
scale
up,
we
update
it
in
this
case,
OLM
is
doing
the
work
for
us
since
size
is
a
very
generic
keywords.
We
abstract
that
keyword
and
creates
a
UI
on
top
of
it.
This
is
not
possible
for
every
single
operator
out
there.
That's
why
you
can
always
go
down
in
the
yamo
and
create
it,
but
with
time
we'll
have
more
and
more
of
these
generic
patterns
abstracted
and
will
help
do
things
in
a
very
easy
manner.
A
So
you
can
see
that
the
size
is
now
at
5
pods.
We
can
check
that's
that
the
operator
has
done
its
job.
So
what
happens
when
I
increase?
This
here
is
that
the
cluster
doesn't
do
anything.
What
happens
is
that
the
operator
sees
a
change.
It
sees
that
it
wants
that
the
cluster
was
supposed
to
be
five
and
it
is
currently
three
and
then
what
it
does.
Is
it
spins
up
new
instances
and
then,
if
I
scaled
back
down
to
three
it'll
scale
them
back
down.
A
So
that's
one
of
the
example
of
how
multiple
@cd
clusters
can
be
managed
inside
of
a
single
kubernetes
cluster
in
an
easy
manner.
Another
nice
example
is
prometheus.
Prometheus
is
the
same
as
sed:
I'm
not
going
to
run
through
the
same
through
all
of
it.
But
Prometheus
has
a
couple
of
interesting
things
and
the
reason
I'm
calling
it
out
is
to
just
touch
them
them
real
quickly.
So
Prometheus,
as
you
see,
has
a
lot
of
different
api's.
One
of
these
api
is
prometheus
itself
is
if
I
want
to
deploy
a
new
prometheus
instance.
A
I
can
do
it
here
and
configure
it,
but
if
a
couple
of
other
interesting
things
is
that
we've
taken
advantage
of
the
kubernetes
api
and
provided
a
couple
of
objects
that
one
can
deploy
with
a
cube,
control
or
OC
like,
for
example,
Prometheus
rules
or
service
monitors
service
monitors
are
particularly
interesting.
They
are
objects
that
allow
you
to
direct
the
Prometheus
operator
to
start
watching
other
services.
So,
for
example,
if
I
am
deploying
a
CD,
I
can
create
a
service
monitor
for
Prometheus
to
be
watching
and
CDs.
Metrics
I
can
also
do
go
much
further.
A
I
can
use
the
SDK
which
is
in
the
beginning,
and
this
is
something
we're
actually
doing.
There's
pull
requests
for
that
I
can
use
the
SDK
to
automatically
create
service
monitors
and
then
I
can
use
OLMS
dependency
system
to
say
this
new.
Let
CD
cluster
has
the
optional
dependency
on
Prometheus,
so
that
once
you
deploy
it,
everything
gets
deployed
automatically,
including
the
Prometheus.
A
That
is
what
we
want
to
be
able
to
do
here,
bring
not
only
individual
operators
but
bring
composability
between
all
these
operators
and
bring
one
single
API
the
kubernetes
api,
to
manage
all
these
instances
and
deploy
them.
So
that's
the
bulk
of
it.
That's
the
bulk
of
the
demo
I'm
going
to
have
other
sessions
where
I'm
going
to
be
going
which
way
more
into
details,
but
that
is
what
we're
trying
to
build
for
the
future
of
application
management
on
top
of
OpenShift.
One
thing
that
was
probably
mentioned
this
morning
also
that's
interesting.
A
All
of
OpenShift
itself
is
built
with
operators,
not
all
of
them
use
the
sdk.
Some
do
some,
don't
just
like
every
other
operator
out
there.
You
don't
have
to
use
the
SDK
to
use
OLM,
you
don't
have
to
everything,
is
composable
but
not
completely
tightly
coupled
and
that's
something
important
to
understand,
because
that
means
that
open
ship
from
the
ground
up
is
operators
the
lowest
base
all
the
way
to
the
applications
running
on
top,
which
is
quite
an
achievement
from
a
lot
of
people
working
very
hard
for
sure
all
right.
A
So,
where
do
we
get
started?
How
do
we
use
this?
How
do
we
get
with
the
community?
Well,
we're
pretty
open.
It's
quite
easy.
All
these
projects
are,
of
course,
open
source.
You
can
use
them
all.
There's
a
github,
a
github
organization
called
operator
framework.
The
slides
will
be
I,
will
put
the
slides
I
will
give
a
link
to
the
slides.
You
will
be
able
to
go
to.
You
can
go
to
the
operator
framework
organization.
You
can
see
all
the
projects
that
I
have
demoed
there's
a
getting
started
guide.
A
A
There's
an
open
shift
sig
when,
where
we
meet
every
month
and
people
come
and
then
were
there,
operators
talk
about
their
operators,
talk
about
the
challenges
they
have
with
these
operators.
It's
been
quite
fun
to
interact
with
everyone
on
that
monthly
call,
and
then
we
have
a
slack
channel,
that's
quite
active
on
kubernetes
operators.
This
is
for
everyone.
This
is
to
talk
about
operators
in
general,
not
just
the
sdk
by
all
means.
Please
drop
by
there's,
always
somebody
to
answer
questions
there
and
I
found
it
quite
fun
there
too,
and
then
our
mailing
list.
A
Lastly,
that's
the
operator
framework
mailing
list.
If
you
have
any
problems
that
are
outside
of
the
github
repositories,
we
can
talk
there.
That's
the
main
thing,
one
more
shout
outs:
there's
a
lot
of
sessions
about
operators
doing
this
coop
con,
there's
one
on
Tuesday
night
with
Diane
and
I,
which
is
very
similar
to
this
one.
But
you
should
still
come.
I'll
squeeze
out
a
few
new
things.
Then
there's
a
deep
dive
in
this
one,
I'm
actually
going
to
be
building
an
operator,
so
I'll
use
the
time
to
build
I.
A
Think
I'll
do
it'll,
be
a
memcache
operator,
maybe
something
else,
but
a
very
simple
operator
we'll
do
it
from
scratch.
It'll
be
a
more
technical
session
in
which
we'll
use
go
to
build
an
operator
and
if
I
have
time
also
show
off
how
how
I
you
can
do
an
operator
with
ansible,
then
on
Thursday
there's
a
talk
by
Rob
and
chance
about
know.
A
First,
there's
a
keynote
by
Rob
in
the
morning
about
operators,
so
that's
always
fun
as
well,
then
there's
a
talk
by
chance
and
Rob
about
the
metering
framework
and
I
encourage
you
to
go
there,
because
that
is
a
vast
subject
that
I
didn't
cover.
Besides
saying
a
few
words
about
it
and
it's
fascinating,
so
that's
it!
The
last
thing
is
a
workshop.
It's
sold
out,
unfortunately,
but
you
can
always
knock
at
the
door,
we'll
see.
That's
it.
Thank
you
very
much.
I
appreciate
being
here.