►
From YouTube: OpenShift Commons Briefing: Getting Started With Operators with Sebastien Pahl (Red Hat)
Description
Sebastien Pahl - How to Get Started with Operators, Update on Operator Framework and discussion of resources
OpenShift Commons Briefing
July 2018 Operator Framework SIG
A
B
Perfect,
thank
you
very
much,
Diane
all
right.
So,
let's
get
started.
I'll
keep
this
not
in
presentation
mode,
because
I
want
to
jump
to
websites
real
quickly.
So
quick
introduction
like
what
is
an
operator
and
what,
where
are
we
doing
here?
Rob
touched
a
bit
on
this
point.
Our
goal
here
is
to
build
applications
that
have
Grenadian
a
native
API.
B
What
that
means
is
we
want
to
take
complex
applications
like,
for
example,
Postgres
or
Kafka,
which
there's
going
to
be
a
good
talk
about
right
after
me,
and
we
want
to
take
all
their
logic
and
all
their
the
complex
knowledge
that
is
in
each
application,
and
it
put
it
into
a
program.
We
want
to
be
able
to
operate
it
automatically.
B
We
want
to
be
able
to
leverage
all
the
features
of
these
applications
that
have
to
do
with
upgrades
and
other
pieces,
and
we
want
to
do
it
behind
kubernetes
AP
is
why
behind
kubernetes
api
is
because
that
way,
you
have
one
way
of
managing
all
your
applications.
It's
nice
to
build
a
single
docker
container.
Where
are
you
gonna?
Have
your
application
package
and
a
way
to
run
it
anywhere,
but
we
all
know
that
application
get
much
more
complex
than
that
and
they
require
multiple
containers
and
then
they
require
operational
knowledge.
B
What
do
I
do
with
these
containers?
How
do
I
deploy
them,
and
that
is
specific
to
each
and
every
single
application?
There's
not
one
application
out
there,
or
at
least
there's
a
lot
there's
a
lot
of
different
applications
out
there
and
they're
all
have
their
own
quirks.
Their
old
operational
knowledge
there
and
it's.
It's
really
only
the
experts
of
these
applications
that
know
how
to
install
them
and
operate
them,
and
that's
not
even
talking
about
when
we
get
into
the
kubernetes
world.
B
B
All
the
applications
domain-specific
knowledge
into
that
operator,
so
upgrades,
for
example,
when
you're
gonna
kick
off
upgrades
of
an
application.
You
want
everything
to
be
in
there
to
be
able
to
do
that
smoothly
same
thing.
To
fail,
your
recovery
scaling
up
scaling
down,
and
that's
I'm,
just
scratching
the
surface
here,
because
we
all
know
how
complex
applications
and
get
so
the
idea
is,
if
you
build
an
operator,
you
can
then
do
that
in
one
single
place,
and
then
people
can
reuse.
B
That
operator,
just
like
they've,
been
able
to
reuse,
docker
containers
and
that's
quite
powerful,
like
getting
it
from
getting
it
from
having
to
learn
everything
about
that
application
to
being
able
to
start
them
in
a
second
and
Oriya
worry
about
it.
Anymore
and
Rob
mentions
a
good
point,
which
is
that
it's
the
same
feeling
that
you
have
when
you're
in
the
cloud
when
you're
in
the
cloud
and,
for
example,
use
AWS,
you
go
to
our
you,
want
a
database
you're
provision
and
RDS.
B
What
is
the
operator
framework?
The
operator
framework
is
for
now
it's
three
projects
that
kind
of
work
hand-in-hand
together.
The
first
one
would
be
the
SDK.
The
SDK
is:
how
do
you
build
that?
What
how
can
we
abstract
as
much
common
code
as
possible
between
all
these
operators,
because,
if
everybody's
going
to
write
an
operator
for
their
application
as
much
as
there's
domain-specific
knowledge
on
these
applications,
there's
also
very
a
lot
of
similar
things.
B
I
like
to
use
the
example
of
TLS
right,
everybody
needs
to
deploy
TLS
certificates
manager
to
TLS
certificates
and
also
be
able
to
rotate
TLS
certificates.
That
is
something
where,
as
like,
while
the
rotation
and
deployment
that
these
TLS
certificates
is
specific
to
every
single
app
the
common
codes
to
be
able
to
generate
those
certs,
you
basically
use
a
single
one-liner
to
tell
it,
for
example,
on
the
kubernetes
deployments.
B
I
want
this
to
now
have
a
TLS,
sir,
in
front
of
it
that
can
be
abstracted
away
and
used
in
a
common
manner
across
multiple
applications,
and
so
it's
things
like
this
and
also
tools
for
upgrades
for
metrics
and
others
that
we
want
to
encode
into
the
operators
DK,
so
that
people
have
a
very
easy
time
to
build
operators.
I
hope
everybody
is
following
me
until
now.
The
next
step,
once
you
have
an
operator,
is
well
an
operator
is
good,
but
that's
just
one
application
you
run
once
and
then
what?
B
If
you
have
multiple
versions
of
these
application
in
your
cluster?
What
if
you
want
to
upgrade
them?
But
if
you
want
to
upgrade
multiple
at
a
time,
that's
where
the
lifecycle
management
sure
comes
in
and
I'll
talk
about
it
a
bit
more
later,
but
Rob
mentioned
it.
It's
about
it's
a
problem
that
people
don't
know
they
already
have
it's
it's
basically
the
next
step
and
then
metering.
Another
thing
that
building
things
with
an
operator
will
can
help.
B
Is
you
can
actually
then
take
all
the
interesting
metric
that
and
that's
specifically
interesting
for
people
like
ISVs
or
or
which
is
you
can
encode
in
your
operator?
All
the
logic
that
you
need
to
bring
back
the
interesting
metrics
that
you
need
to
know
is
my
is
my:
is
my
application
doing
well
and
also
how
could
I,
for
example,
as
a
vendor
bill
against
my
application
and
how
do
I
know
if
I'm
in
signed
off,
let's
say
AWS
how
much?
How
do
I
know
how
much
this
single
database
table
or
even
row
costs
first?
B
That
requires
quite
a
bit
of
logic
to
write
into
the
SDK
into
the
operator,
but
that
logic
can
then
be
aggregated
through
the
operator
meeting
framework
and
a
metering
tool
toolkit,
so
I'm
gonna
rego
a
go
again
on
multiple
on
multiple
on
all
of
these
through
their
each
of
their
websites.
There's
a
question
I'm
just
going
to
check
if
it's
a
question
we'll
answer
that
later
all
right,
so
mainly
that's.
The
main
goal
of
this
presentation
is:
how
do
I
get
started?
Where
do
I
go
where?
B
Where
do
I
start
so
then
the
first
part
is
obviously
our
operator
framework
org
on
Vita
and
there
you
have
all
the
projects
that
are
related
to
these
things.
One
thing
you
have
list
of
operators
and
I
want
to
also
go
in
to
each
project
individually.
So
if
you
go,
for
example,
to
the
SDK,
you
can
see
that
this
is
that's
the
project.
B
That's
where
you
get
you
get
started,
and
it's
I
want
to
talk
a
bit
about
how
easy
it
is
to
basically
get
started
if
you've,
if
you're
familiar
with
something
like
and
not
everybody
likes
it,
but
it's
a
good
analogy.
Ruby
and
rails,
when
you
do
Ruby
and
you
don't
have
to
know
the
intricacies
of
HTTP,
you
don't
need.
You
know
the
intricacies
of
a
Postgres
at
first
and
you
can
get
started
by
basically
using
models.
B
You
built
you
put
in
Europe
your
your
domain,
specific
code,
which
was
happened
here,
which
is
a
much
longer
process
than
this
shows,
of
course,
and
then
once
you're
happy
you're
able
to
build
push
it
just
like
any
container
and
then
deploy
it,
and
here
it
shows
a
deployment
by
hands
because
we
don't
have
a
lifecycle
manager
yet,
but
at
the
that's
just
an
example,
so
I
encourage
you
to
come
here.
There's
there's
quite
a
bit
of
stuff
to
have
a
look
at
this
is
just
the
getting
started
guide.
B
You
also
have
that
we
have
quite
a
bit
of
documentation
to
user
guide
and
more
interesting
if
you're
interested
in
knowing
how
you
build
your
first
operator,
we've
put
in
an
example
to
show
how
you
can
build
a
vault
operator
with
this
SDK
and
to
go
a
bit
more
in
in
like
technical
terms,
because
I'd
like
to
do
to
explain
that
here.
This
is
the
basic
structure
of
a
an
operator.
B
It
has
multiple
multiple
like
it
has
all
the
go
dependencies
and
everything,
and
then
you
would
put
your
logic
into
one
place,
which
is,
for
example,
here
of,
and
your
basically
writes
a
handler.
This
one
is
a
very
simple
handler.
That's
now
calling
other
other
piece
of
the
code,
but
the
basics
of
an
operator
is
really
shown
well
here,
which
is
you
have
a
loop.
You
receive
events
from
the
kubernetes
api
and
then
you
basically
work
on
those
events
to
to
do
what
you
need
for
your
application.
A
B
B
Is
basically
the
operator
lifecycle
manager?
That's
the
next
place.
I
encourage
you
to
have
a
look
at
the
this
repository
is
quite
simple
to
use.
It
also
has
the
same
getting
started
guide
as
everything
you
don't
need
to
it
works
and
it
will
eventually
be
included
an
open
shift,
but
you
can
install
this
on
every
single
kubernetes
cluster,
and
that
is
an
important
distinction,
because
if
you
imagine,
you
have
to
use
different
variety
of
uber,
Navy
styles,
it
doesn't
matter
as
long
as
the
zipa
kubernetes
compatible
cluster.
B
You
can
install
that
lifecycle
manager
and
what
you
get
out
of
this
lifecycle
manager
is
basically
a
repository
of
applications
where
you
can
then
decide
I
deploy
these
applications
in
a
multi-tenant
fashion.
That's
the
that's
one
of
these
goals.
You,
the
lifecycle
manager,
is
aware
of
the
burn,
ADEs
namespaces.
It's
able
to
tell
do
it
and
it
also
does
one
other
important
thing.
It
manages
the
CR
DS,
so
that's
users
don't
have
to
install
them
themselves.
They
don't
have
the
permission
to
do
that.
B
B
The
last
part
I'd
like
to
highlight
is:
we've
made
a
list
of
operators.
Not
everything
here
uses
the
operators
decay,
but
if
you've
built
an
operator,
I
would
encourage
you
to
contribute
it
here
to
highlight
it,
and
basically
this
this
repository
is
probably
going
to
get
curated
more
and
more.
We're
gonna
show
show
off
what's
built
with
the
operators
DK.
B
What's
not
what
can
be
used,
but
right
now,
it's
basically
a
list
of
many
things,
but
you
can
see
that
already
a
lot
of
people
have
like
it's
the
operator
concept
and
started
building,
what's
called
an
operator
or
their
specific
platform.
I
don't
want
to
vouch
for
the
quality
of
each
of
these,
since
they
are
not
like
going
through
any
certification
process
whatsoever,
and
that's
where,
where
other
operator
framework
also
comes
in
our
goals
is
not
just
to
help.
You
build
these
operators,
but
eventually
our
goal
is
to
help
you
test.
B
These
operators
make
sure
that
they
work
that
it
behave
well
in
a
lot
of
environments,
so
we
want
to
build
B
through
the
sdk,
a
common
way
to
test
them
and
to
certify
them
on
the
platform
like
openshift,
that
is,
that
is,
what's
going
to
transform
a
list
like
this,
which
you've
all
seen
in
the
past
for
various
applications
containers
and
basically
no
yes,
this
that's
that's
a
list.
That's
I
still
have
to
do
my
own
research,
but
with
once
we're
a
bit
further
down
the
road
with
our
testing
kits
you'll
be
able
to
know.
B
So
that's
a
quick
intro
through
all
of
that
and
then
the
last
thing
I
would
say,
take
a
look
at
our
getting
started
guide
it's
much
more
in
death
than
the
just
one
on
the
operator
SDK
that
I
showed
off
here.
It
is
an
end-to-end
test
with
operator
SDK
and
the
lifecycle
manager
will
throw
in
the
metering
in
it
eventually,
but
this
will
a
label
to
to
do
everything
that
I
said
dry
out
everything
and
what
I
said
in
a
single
kubernetes
cluster
quite
easily
like
just
follow
this,
and
everything
will
become
much
clearer.
B
The
last
things
I
would
like
to
add.
Are
we
created
a
channel
to
talk
all
things
operator
on
the
kubernetes
lac
and
we
also
have
a
Google
Group.
These
links
will
be
shared
by
day
and
after
the
for
everybody
who
wants
to
join.
So
that's
it.
That
is
the
main
thing
that
I
wanted
to
do
and
what
I
wanted
to
highlight.
We
can
show
and
showing
you
what's,
each
and
every
one
of
these
components
are
all.
A
Right
well,
thanks:
Sebastian
I
think
that
helped
kick
it
off
and
set
the
groundwork
for,
and
especially
the
concepts
and
the
links
and
I
will
add
all
that
into
the
gist
and
into
the
mailing
list
as
well.
There
are
a
couple
of
questions
and
some
of
them
have
been
answered
in
the
QA
and
chat,
but
I
think
if
we
go
back
to
Alexander
Lazich
question
and
I
can
unmute
people
that's
two
as
well,
so
it
examine
their
wants
to
follow
up
on
that,
find
you
sure-
and
you
are
you
have
a
mutant
for
yourself,
Alexander.
D
A
D
B
So
I'll
I'll
take
that
when
the
our
the
goal
of
our
framework
is
to
go
through
CR
DS
like,
of
course,
you
can
right.
Cooper
neat
like
if
we
forget
about
the
framework
for
a
second,
you
can
write
a
kubernetes
controllers
that
does
all
this
right.
That
listens
just
to
specific
things,
and
also
the
operator
framework
itself
is
also
capable
with
the
SDK
of
listening
to
specific
objects.
B
But
what
we're
trying
to
do
here
is
kind
of
an
opinionated
pattern
where
we
drive
things
through
CR
DS,
because
it
allows
us
to
like
you
need
to
put
that
API
somewhere
and
if,
if
all,
if
all
your
controller
basically
is
doing,
is
like
doing
some
ingress
work
or
let's
say
watching
a
couple
of
stateful
sets
with
and
doesn't
need
to
be,
basically
influenced
through
a
CR
D.
Then
it's
not
necessarily
the
you.
Don't
necessarily
need
to
use
something
like
the
SDK
which
butter
you
can
still
call
it
kind
of
an
operator
something
Robin
yeah.
E
I
was
just
gonna
say
in
like
your
case.
If
you're
orchestrating,
like
an
external
DNS
provider,
the
CR,
do
you
still
might
have
a
place
for
you
to
hold
configuration
so
say
like
the
external
Amazon
zone,
that
you
want
to
write
these
DNS
records
to,
and
then
you
want
to
listen
on
the
routes
or
the
cert,
and
then
you
know
hook
up
the
services
or
whatever
so
I
think
there's
probably
still
a
place
for
a
CR
D
in
there,
because
you
need
that
configuration
for
what
this
thing
is
going
to
do.
B
E
E
You
know,
you've
you've
tested
out
this
Postgres
operator,
but
you're
running,
you
know,
say
30
copies
of
it
and
every
team
is
running
databases
operator
and
then
till
you
have
a
node
failure
or
you
have
a
networking
blip
or
one
of
your
AC's
goes
out.
If
that
Postgres
operator
is
instrumented
to
start
emitting
metrics
about
when
it's
doing
failover
or
when
it's
shards
or
whatever
kind
of
underlying
storage
is
not
available,
you
can
start
to
get
a
sense
of
like
how
these
things
impact
the
actual
applications.
E
It's
that
you're
getting
a
very
specific
thing.
So
another
example
say
you
were
running
like
a
very
large
cloth,
cluster
or
SEF
cluster
that
if
you
have
to
do
heels
on
some
of
that
underlying
stuff,
as
things
are
getting
replicated
round,
knowing
how
many
of
those
happen
per
hour
or
per
week
or
whatever,
and
correlating
that
to
cluster
events
can
be
really
really
useful
for
you
to
help
either
make
your
operator
more
efficient.
So
why
is
this
thing
healing
so
much?
E
C
Lunch
I,
like
it
and
I
want
I
wondered
if
I
would
have
I
would
I
would
be
able
to
make
this
metric
system
get
a
domain
knowledge
of
my
operators.
So
let's
say
I
have
a
program
and
there
I
want
to
charge
by
users
so
would
I
be
able
to
plug
easily
the
domain
knowledge
of
my
of
my
application
into
this
operator
matrix.
E
Yes,
100%
those
types
of
metered
billing
type
use
cases
are
perfect
for
this
framework
and
that's
one
of
the
exciting
things
that
you
know
there's
like
a
set
of
operational
things,
but
then
also
a
set
of
business
things
that
you
can
get
unlocked
by
using
this
and
so
yeah.
What
you
would
do
is
in
the
SDK
we're
gonna
build
some
functionality
where
you
can
say,
I
want
to
emit
this
metric,
but
I'm
already
tracking
and
then
it'll
get
scraped
by
the
metering
system
and
then
aggregated
and.
F
That
these
metering,
though
the
actual
getting
that
data
is
only
the
1/2
and
so
like
the
metering
component,
offers
api's
and
long-term
we're
going
to
probably
build
in
default
exporters
that
can
basically,
on
top
of
the
existing
reporting
functionality,
is
that
you
already
get
it.
You
can
query
the
the
results
out
of
the
api's,
and
so
then
the
the
next
piece
would
be
to
for
us
to
make
it
easy
for
you
to
get
that
kind
of
data
out.
B
What's
what
we
have
is
actually
a
helm
operator
that
is
there
and
you
can
use
kind
of
very
easily
once
you
have
the
lifecycle
manager
installed
and
that
kind
of
gives
you
it
gives
your
app
quite
a
bit
of
ways
of
using
helm,
charts
with
operators
and
you're
able
to
use
them
the
helm
without
tiller
you're
able
to
use
helm
without
having
too
many
privileges,
which
is
something
that
is
quite
useful.
It's
about
how
versus
operators
I'll
let
Rama
Ribbit's,
it's
like
they
complement
each
other
right
like
the
helm.
Ops
are
simpler.
E
Yeah
and
if
you
think
about
it
this
way,
helm
is
really
good
for
running
these
stateless
applications.
But
it's
kicked
off
with
like
the
helm,
CLI
or
you
know
it's
like
you
know,
a
human
is
in
the
loop
there,
and
so
one
of
the
exciting
things
about
the
operator
is
you're,
taking
that
human
out
of
the
loop
and
then
you're,
making
it
kubernetes
native
so
you're
not
having
to
write
against
a
helm,
API
you're,
just
using
a
CRD
and
the
way
our
helm
operator,
kit,
I
linked
it
in
the
chat
works.
E
You
model
you
want
to
model
C
or
D
or
C
or
D
is
modeled
for
you.
That
basically
has
your
values
that
you
would
pass
into
a
chart
as
the
configuration
in
the
CR
D
and
then,
when
you
instantiate
that
you
have
your
the
image
that
the
operator
runs
in
actually
has
your
chart
baked
into
it.
This
allows
you
to
version
it
with
container
tags,
which
is
really
nice
and
you've
got
this
immutable
artifact.
You
passing
the
values
and
then
I'll
pop.
E
If
you
want
to
add
more
stapl
kind
of
stuff
to
your
application,
then
what
you
can
do
is
move
it
over
to
I'll,
say
like
a
real
crew
operator,
a
go
code
operator
and
do
the
same
thing
model
those
things
and
start
building
in
your
staple
logic.
And
so
that's
where
we
think
the
helm
operator
kit
is
really
nice.
If
you
started
with
an
operator
and
then
you
can
kind
of
decide
how
much
further
you
need
to
take
it.
F
I
know
I
can
tell
you
confidently.
This
works
because
I
don't
use
that
actual
helm
operator
kid
we
developed
on
the
metering
project,
but
I
use
a
precursor
to
that.
That
is
a
home
operator
and
90%
of
the
components
in
metering
are
deployed
using
a
helm
operator
stack
and
only
include,
and
then
that
operator
is
actually
what
employs
the
bespoke
cooperator.
That
does
all
the
specific
metering
stuff
as
well.