►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Deep Dive: Operator Framework BoF - Diane Mueller & Sebastian Pahl, Red Hat
An Operator is a method of packaging, deploying and managing a Kubernetes application. A Kubernetes application is an application that is both deployed on Kubernetes and managed using the Kubernetes APIs and kubectl tooling. To be able to make the most of Kubernetes, you need a set of cohesive APIs to extend in order to service and manage your applications that run on Kubernetes. You can think of Operators as the runtime that manages this type of application on Kubernetes. http://coreos.com/operators The Deep Dive will cover the * The Operator Framework is an open source toolkit to manage Kubernetes native applications, called Operators, in an effective, automated, and scalable way. This session will discuss the Operator SDK, Operator Metering and Operator Lifecycle Manager.
To learn more: https://sched.co/Grdd
A
All
right
welcome
everyone.
Thank
you
for
coming
to
see
my
talk.
I'm
Sebastian
I'm,
a
director
of
engineering
at
OpenShift
and
I'm
here
to
talk
about
the
operators
and
the
operator
framework,
and
this
is
to
go
a
bit
deeper
into
the
material
than
yesterday.
So
first
of
all,
I
would
like
to
ask
who
here
has
been
to
the
talk
yesterday.
That
was
an
intro
to
the
operator,
all
right,
quite
a
few,
so
that
way,
I
know
how
to
modulate
what
I'm
gonna
say
and
what
I'm
gonna
present
great.
A
So
yesterday
we
talked
about
operators
what's
an
operator
what
the
operator
framework
is
and
what
different
components
they
are.
I'm
gonna
go
over
this
briefly
again
today
and
I'm.
Gonna
do
a
couple
of
the
demos
that
I
did
yesterday
again,
just
so
that
everybody
sees
the
same
things
and
but
the
thing
that
I'm
gonna
adds
that,
were
we
didn't
do
yesterday
and
to
go
a
bit
deeper,
I'm
going
to
be
building
an
operator,
a
very
simple
operator,
something
that
you'll
be
able
to
replicate
yourself
by
just
going
to
the
docks
and
try
yourself.
A
But
the
goal
here
is
to
show
you
what
it
takes.
What
pieces
an
operator
is
made
off
all
right,
let's
get
started
so,
what's
an
operator
a
few
less
slides
than
yesterday,
an
operator
is
a
way
of
building
an
application
and
driving
an
application
on
top
of
kubernetes
behind
kubernetes
api
s,
and
the
idea
is
that
when
you
have
an
application
like
say,
database
like
Postgres
or
Cassandra
or
or
something
like
Redis
doesn't
matter,
any
complex
application
will
need
a
lot
of
domain-specific
knowledge
that
domain-specific
knowledge
can
be.
A
You
can
use
kubernetes
and
help
yourself
to
those
generic
tools
that
exist
in
kubernetes,
like
stateful
sets
CSI
deployments
ingress
to
help
you
try
to
solve
some
of
those
domain-specific
problems,
but
in
the
end,
when
it
comes
to
really
fully
automating
an
application
and
by
fully
automating
I
mean
handling
updates
from
one
version
to
another.
Without
waking,
people
up
handling
failure
recovery
if
it's
needed
scale
the
application
up
and
down
depending
on
some
scenarios.
All
of
that
should
be
handled
automatically.
A
Humans
should
not
be
involved
in
this
kind
of
operation,
because
that
kind
of
breaks
the
promise
that
containers
gave
us
containers
promised
was
hey.
You
package,
it
once
and
runs
n
everywhere.
Well,
that's
true
for
developers,
but
in
production,
there's
so
much
more!
That
needs
to
be
done,
and
so
operators
is
a
pattern.
You
take
all
this
domain-specific
knowledge,
you
put
it
behind
kubernetes
api,
so
you
extend
the
kubernetes
api.
A
So
thanks
to
CR,
DS
and
you're,
able
to
then
have
once
build
it
once
and
then
be
used
by
users
again
and
again,
like
a
cloud
service.
Just
like
you
use
RDS
in
on
AWS,
you
go
and
you
ask
for
new
database.
You
need
another
one,
you
ask
for
another
one.
The
same
thing
should
be
true
for
any
kind
of
open
source
or
closed
source
software.
That's
running
on
top
of
kubernetes.
You
should
be
able
to
just
ask
for
an
instance
of
it
and
use
it.
A
You
should
not
have
to
understand
how
to
deploy
it
and
manage
it.
So
that's
the
promise
that
we're
trying
to
fulfill
that's
where
we're
trying
to
go
with
this.
This
is
very
early
stages
of
all
of
this,
but
there's
been
a
tremendous
amount
of
people
that
jumped
on
this
and
wanted
to
also
operate
automatically,
and
so
across
the
industry
we've
seen
more
and
more
things.
We've
come
out
with
our
own.
A
We
have
things
like
Etsy
and
Prometheus
that
allow
you
to
automate
at
CD
and
Prometheus
completely
automatically
on
top
of
a
Cabrini's
framework,
and
these
two
come
from
the
Kubik
communities.
Themself
the
sed
operator,
the
Prometheus
operators
maintained
by
the
Prometheus
community,
and
then
you
also
you
can
have
either
vendors
or
communities
or
authors
that
are
building
these
operators.
So
you
have
things
out
there
like
Postgres
or
a
couch
base
or
Redis,
and
we've
made
a
list
there's
this
URL.
A
If
you
have
an
operator-
and
you
want
to
contribute
to
it,
you
can
go
add
it
to
this
list.
This
is
very
open.
We
don't
require
you
to
use
any
special
technology.
Anybody
who
has
something
that
applies
to
this
logic
as
allowed
to
come,
contribute
it
there
eventually
we're
going
to
find
a
way
to
expose
those
operators
better
to
kubernetes
clusters.
I'm
going
to
show
a
few
of
these
during
my
demos,
but
that's
the
bulk
of
it.
That's
the
idea,
the
idea
being
not
to
have
to
do
things
over
and
over
again.
Alright.
A
So,
let's
start
with
the
operator
framework,
what's
the
operator
framework
well,
building
an
operator
is
not
easy
either.
You
need
to
know
a
lot
about.
Kubernetes
kubernetes
is
a
wonderful
API,
there's
a
lots
that
you
can
do
with
it,
but
you
need
there's
a
lot
of
details
that
you
need
to
know.
You
need
to
become
an
expert
building
automating.
Your
application
is
something
where
suddenly,
you
have
to
be
not
only
an
expert
in
terms
of
your
application,
but
also
in
terms
of
kubernetes.
That
is
quite
a
lot
at
once.
A
What
we're
trying
to
do
here
is
trying
to
give
a
set
of
tools,
a
set
of
projects
that
we
bundle
together,
but
are
all
usable
independently
for
nature
another
to
help
build
operators-
that's,
for
example,
the
operator
SDK.
So
how
do
you
build
an
operator?
How
do
you
package
it?
How
do
you
test
it
if
you're
going
to
ensure
that
this
is
a
repeatable
process?
If
you're
gonna
make
sure
that
this
is
going
to
be,
people
are
going
to
install
it
and
Trust
it
automatically.
A
A
Certs
upgrades
all
of
this
there's
a
lot
of
generic
code
that
can
be
done
and
help
there
and
also
an
abstraction
to
kubernetes
helping
people
to
not
have
to
deal
with
all
the
details,
but
only
the
higher-level
to
get
started
to
be
able
to
focus
on
their
own
domain
specific
codes
and
their
app
that
they
want
to
build.
Once
you
have
such
an
operator-
and
you
have
built
it,
you
need
a
way
to
run.
A
The
operators
operator
can
run
it's
just
another
kubernetes
applications
or
there's
nothing
special
about
it,
but
once
you
start
having
a
lot
of
operators,
they
have
versions,
they
have
their
own
life
and
we've
built
something
called
the
operator
lifecycle
manager,
an
operator
for
operators.
It
helps
you
subscribe
to
different
channels
of
operators,
know,
for
example,
that
that
operator
will
always
be
stable,
that
one
will
always
be
preview.
A
It
allows
you
to
decide
what
namespace
is
allowed
to
have
operators
and
what
not-
and
it
also
allows
you
to
make
sure
that
upgrades
are
either
handles
of
operators
are
handled
automatically
or
if
you
need
somebody
to
approve
an
upgrade.
All
of
these
things
are
done
by
the
lifecycle
manager,
and
then
another
component
of
the
framework
is
what
we
call
metering.
There's
a
whole
talk
about
this
on
Thursday
and
I,
encourage
you
to
go.
A
This
is
about
measuring,
what's
happening
in
your
communities,
cluster
collecting
it
through
Prometheus
and
then,
most
importantly,
being
able
to
create
reports
on
top
of
it
and
do
things
I
charge
back
or
show
back
knowing
thanks
to
logic
inside
of
an
operator,
for
example,
how
much
a
certain
table
costs
on
AWS
or
how
much
you're
spending
for
a
certain
amount
of
traffic
on
the
other
side.
That
is
what
metering
can
do.
It
can
aggregate
these
metrics
and
then
create
reports
all
right.
So
next
thing
is
demo.
A
That's
the
main
thing
that
I
wanted
to
show
here
and
we're
going
to
go
over
a
lot
of
the
concept
that
I've
talked
about
in
a
high-level
in
a
more
detailed
way
during
this
demo.
Alright,
so,
let's
start
with
an
open
shift
cluster,
which
is
a
normal
kubernetes
cluster.
Here,
I'm
not
going
to
be
showing
things
in
the
UI,
yet
we're
gonna
first
start
by
building
an
operator,
but
later
on
we're
gonna
come
back
and
have
a
few
looks
at
what
we
can
do
with
the
operator
lifecycle
manager.
A
A
The
idea
here
is
that
all
I
have
installed
as
a
command.
Is
the
operator
SDK?
That's
a
command
that
I'm
going
to
be
using.
Currently
I,
don't
have
a
project
yet
and
we're
going
to
be
building
a
memcache
operator.
A
memcache
operator
is
an
operator
that
you
can
run
and
then,
if
you
need
a
memcache
cluster,
you
can
just
ask
I,
need
a
memcache
cluster
and
give
it
the
size
of
the
memcache
cluster
that
you
need
if
one
of
the
memcache
instances
in
that
cluster
dies,
the
operator
spins
it
back
up.
A
So,
let's
start
by
first
creating
a
directory
which
you've
had
and
now
we're
gonna
do
something
which
is
called
it's
the
first
command
you
do
when
you
use
the
operator
SDK,
it's
called
operators
TK
new.
It's
is
when
you're
from
zero.
When
you
don't
it's
like
get
in
it,
and
this
is
going
to
bootstrap
the
operators,
decay
directory
and
the
boilerplate
code
that
you're
going
to
need
to
start
building
an
operator.
Currently,
it's
installing
all
the
dependencies,
the
dependency
that
you're
seeing
being
installed
on
it
here
is
quite
long.
A
These
are
all
the
dependencies
that
you
need
when
you
want
to
start
using
things
and
talking
to
the
kubernetes
api,
there's
a
bit
more
in
there,
of
course,
that
the
operators
DK
needs,
but
it's
still
quite
an
amount
of
things
most
of
it
gets
pulled
automatically
when
you
take
climb,
go
an
API
machinery,
but
still
it's
quite
a
lot
to
know
and
quite
a
lot
to
process.
This
is
going
to
be
done
in
just
a
bit
and
we're
gonna
be
able
to
go
from
there.
Alright.
A
So
now,
I
have
a
directory
with
a
memcache
operator.
This
is
doesn't
do
anything.
Obviously
this
is
an
empty
shell.
I
could
build
it.
If
I
were
to
deploy
and
build
this
now,
it
would
be
an
empty
API
that
does
nothing
so
we're
gonna
start
doing
things.
The
first
thing
that
you
want
to
do
is:
if
we're
going
to
build
a
memcache
operator,
we
need
an
API.
We
need
a
CR
D
and
we
need
to
be
able
to
tell
it
what's
fields
and
what
options
it
takes.
A
So
the
SDK
generates
all
that
boilerplate
code
and
scaffolds
the
rest
of
the
project.
So,
in
this
case,
I
just
ran
a
command
called,
add
API
I'm,
creating
API
that
has
the
version
cache
dot
example.
Comm
v1
alpha
and
the
kind
memcache
and
what's
interesting
for
us
here
is
to
look
at
what
it
looks
afterwards.
Let
me
just
copy
it
over
and
that's
the
one
here.
A
So
if
we
look
at
this,
this
is
going
to
be
our
API,
so
we're
in
go
code
here,
because
we
want
to
express
and
go
code
how
it's
going
to
look
to
the
operator.
Now.
Only
this
is
a
generated
file.
The
thing
I've
copied
it
in
because
I've
altered
one
thing,
which
is
this
file,
and
this
line
here
sighs
and
this
line
here.
Node
the
way
see
are
these
work.
Is
you
have
a
place
where
you
can
submit
fields,
and
then
you
have
a
status?
A
That's
get
written
that
gets
written
back
by
the
operator
and
we're
currently
building
an
operator
that
takes
a
size,
the
size
of
the
cluster.
How
many
memcache
instances
do
I
want
here
and
then
reports
back
how
many
nodes
are
actually
running
here
in
the
status?
These
are
the
two
fields
you
see
where
this
can
go
with
more
complicated
projects.
More
complicated
projects
will
have
more
inputs
and
more
outputs
and
we'll
be
able
to
show
that
the
rest
is
usually
generated,
but
it
can
be
edited
if
needed.
A
The
next
thing
that
we
need
to
do
is
well
now
that
we
have
an
API.
We
need
to
act
on
that
API,
so
we
need
a.
We
need
to
really
need
to
build
a
community
controller
again
we're
going
to
generate
most
of
that
code
by
calling
operator,
SDK,
add
controller
again,
an
API
it
kind
and
now
I'm
going
to
copy
over
the
code
off
the
controller.
This
is
you
can
find
all
of
this
on
the
website
itself
in
the
repository
and
there
we
have
our
controller.
So
this
is
the
code,
the
actual
user
wrote.
A
This
is
the
business
logic.
This
is
that
is
not
generated
like
this
whole
reconcile
function
is
the
heart
of
the
operator.
What
happens
in
the
reconcile
function
is
it
looks
at
the
state
it
gets
called
periodically
and
periodically.
It
then
looks
at
the
state
of
the
world:
do
I
have
memcache
running
well.
Do
we
know
all
right?
Let's
start
memcache
it
started
deployment.
A
B
A
Idea
here
is
that
we
constantly
get
in
this
loop,
and
this
is
how
an
operator
works.
Looking
at
the
state
of
the
world,
what
do
I
want,
fixing
that
state?
This
is
how
upgrades
would
be
handled.
This
example
doesn't
handle
an
upgrade
to
be
fair
and
memcache.
It
might
not
be
that
hard,
but
for
more
complex
application
you
would
be
looking
what
version
do
I
have
running?
Do
I
have
to
run
certain
migrations?
Do
what
do
I
do
to
go
from
point
A
to
point
B!
A
That's
what
you
care
about
in
that
function
and
that
function
is
your
human,
the
human,
that's
usually
behind
a
pager
and
wakes
up
and
brings
your
servers
back
up
and
fixes
it
and
does
all
that?
That's
what
that
loop
does?
We
can
go
way
further
than
that
and
we're
going
to
show
some
example
that
are
not
just
a
loop
to
keep
something
up,
but
also
something
to
IP
eyes
to
interact
with
an
operator,
but
that's
the
the
main
goal
here
all
right.
A
So
now
that
we've
created
this
we've
just
copied
code
and
right
we
just
code,
then
we
just
edited
the
file.
So
we're
going
to
generate,
we
need
to
call
the
operators
to
K
to
generate
the
actual
code
and
then
we're
done.
We
are
going
to
be
able
to
build
it.
So
the
first
thing
we're
gonna
do
is
build
a
docker
image
that
contains
all
of
this.
A
Then
I
do
have
files
here
that
are
generated
by
the
SDK
about
how
to
deploy
it,
though.
The
permissions
on
the
kubernetes
cluster,
the
service,
counts.
The
operator
yeah
Mel,
is
the
deployment
itself
of
the
operator.
So
now
I'm
going
to
just
quickly
swap
the
image
name
for
the
one
that
we
used.
You
can
see
quad
io
s,
Paul
memcache
D,
that's
the
one
that
we
used
when
we
built
so
now
our
operator
will
be
deployable
and
now
we're
going
to
quickly
push
this
operator
to
Quay.
A
Could
cheat
and
control
see
since
I've
already
updated
this
we're
done
all
right,
I'm
impatient?
Okay.
So
let's
now
see
what
we're
gonna
do.
First,
what's
do
you
need
to
run
an
operator?
First,
you
have
the
CR
D.
This
was
generated
by
the
customer,
a
cisgendered
F
initial
was
generated
by
the
operators,
decay
it
can
take.
It's
declares
what
kind
of
customer
resources
we
can
do
in
this
case.
We
want
to
start
putting
new
memcache
instances
with
certain
sizes,
so
this
is
to
declare
the
CR
D
then.
A
So,
let's
first
of
let's
create
that
one
first
done,
then
we
have
the
service
account,
so
the
service
account
also
a
file
generated
by
the
SDK.
That's
the
idea.
That's!
Obviously
the
operator
needs
to
run
as
some
user.
That's
that's
the
user.
They
op
it
runs
out
and
then
the
role
in
the
role
bindings
are
the
permissions
that
that
certain
user
has
and
now
we're
gonna
start
deploying
the
operator
know
that
we're
gonna
have
a
look
at
because
this
is
a
normal
kubernetes
app.
A
This
normal
kubernetes
app
here
is
deploys
the
memcache
operator.
So
it's
a
deployment
it
has.
It
uses
the
service
account
that
we
just
created
it
finds
in
a
certain
port.
It
uses
the
image
that
we
created
earlier
and
we
have
a
couple
of
radius
probes
and
then
some
environments,
but
that's
it
like
which
namespaces
we
want
to
be
watched,
the
operator
name,
but,
as
you
see
normal
kubernetes
application,
so
we're
going
to
deploy
that
one.
B
D
A
A
A
A
A
A
There
we
go
so
it's
terminating,
but
it's
already
back,
while
it's
terminating
so
there
we
go
so
we're
back.
So
I
killed
a
bunch
of
things
that
nothing
happens.
This
is
what
we
want
right,
like
that's
the
goal,
all
right.
Okay,
what
can
I
do
with
this?
Let's
see
I
have
a
new
API,
a
micro,
Bernays
cluster.
A
A
B
A
Alright,
so
in
this
example,
we
saw
a
memcache
d-theta
thing.
Oh
one,
last
thing
that
I
like
to
show
as
well
is
this.
Obviously
this
is
meant
to
do
multiple
of
these,
so
I
can
do
a
memcache
D
to
store
this
apply,
and
now,
if
I
get
the
pods
I
have
two
instances
running.
These
are
two
different
memcache
D
for
two
different
applications
and
they
have
two
different
names.
So
all
it
takes
is
this
instead
of
having
a
lot
of
yamo
to
deploy
memcache
D
all
the
time
and
also
knowing
how
to
maintain
it.
A
You
just
have
to
include
this
tiny
mo
here
with
the
rest
of
your
application.
Okay,
oh
it
loaded
beautiful,
okay!
So
in
here
we
can
see
that
we
have
memcache
D
memcache
D
here,
and
so
you
can
see
them
it's.
You
can
see
that
I
have
the
two
instances
running
there.
This
is
the
and
that's
that's
the
interesting
thing
you
can.
You
can
see
that
they
all
have
or
present
as
their
own
API
in
the
in
the
in
the
cluster
itself.
Alright,
let's
go
on
with
continuing
what
are
other
options
to
build
operators.
A
You
saw
a
lot
of
llamó
here,
a
lot
of
go
codes.
There
are
other
options.
The
operator
SDK
supports
what
we
call
ansible
operators.
So
if
you
have
already
a
lot
of
ansible
code
go
in
there
operator
frame
recovery,
then
again,
I'm
showing
you
things,
you
can
show
see
and
repositories
on
the
Internet.
But
here
you
can
see
that
you
have
things
like
the
memcache,
the
operator
and
the
memcache
the
operator
one
seconds.
This
is
not
the
right
thing.
A
So
that's
that
the
last
thing
that
I
wanted
to
show
here
is
inside
of
the
OLM.
The
operator
lifecycle
manager,
I
showed
a
few
of
these
demo.
A
few
pieces
of
these
demos
yesterday,
but
I
wanted
to
just
show
this
when
it's
when
everything
gets
put
together.
So
when
everything
comes
together,
the
operators
are
exposed
to
the
operators,
lifecycle
manager
with
files
that
we
call
cluster
service
versions.
A
It's
a
big
yeah
mole
that
describes
what
an
operator
depends
on
what
an
operator
requires,
and
you
can
start
building
the
Pennsy
grafts
between
operators
and
you
can
start
also
reporting
status
in
ways
that
this
operator
cycle
lifecycle
manager
understands.
So,
if
you
look
at
the
instances
currently,
we
don't
have
any
instance
running.
A
So,
let's
create
an
sed
cluster
same
thing,
same
way,
that
I
created
the
the
other
one,
we're
gonna
call
it
example
size
three
create,
and
then
we,
when
we
create
this
cluster,
we
can
see
that
it
starts
up
and
when
we
go
to
that
cluster,
we're
waiting
now.
So
what
we're
waiting
on
is
on
the
operator
to
return
status
and
to
tell
us
that
everything
went
okay
and
then
the
cluster
is
up.
A
So
you
can
go,
have
a
look
at
the
resources
to
see
if
they're
already
there
so
right
now
we
only
have
one
running
to
running
three
running
so
now
we
have
three
sed
instances
running
and
if
we
go
to
the
over,
you
can
see
that
the
sizes
of
three
pods,
but
there
are
only
two
members
that
are
active
yet
why?
Because
this
is
actual
status
reported
by
the
operator,
the
operator
has
custom
logic.
A
That
knows
what
an
sed
cluster
is
and
reports
it
back,
and
then
we
show
that
we
show
that,
and
now
you
see
three
members,
we
show
that
so
that
you
can
actually
know
and
depend
on
the
fact
that
the
STD
clusters
up
and
not
just
pause
running.
So
these
are
example
of
custom
logic
that
can
then
abstract
it
and
be
shown
in
one
way.
The
Etsy
operator
has
more
than
just
being
able
to
do
new
new
new
city
clusters.
It
can
also
create
a
CD
backup
and
restore
tasks.
A
And
so
once
you
start
playing
the
dependency
game,
you're
going
to
be
able
to,
through
all
them,
install
a
big
fleet
of
software
that
all
depend
on
each
other
and
start
watching
and
monitoring
each
other
just
like
intended.
So
that's
kind
of
the
Legos
that
we're
putting
together
to
try
to
make
all
of
this
work.
That's
what
I
wanted
to
show
today,
I,
that's
it
yeah.
The
next
things
that
I
wanted
to
say
is
that
there
are
how
to
get
started.
Please
go
to
the
website
the
operator
framework
website
and
go.
A
E
A
couple
questions
I
had
one
of
them
was
related
to
dependencies,
and
this
is
an
issue
I
have
with
with
helm
when
you're
installing
an
operator
you
have
to
install
it
separately.
You
can't
say:
oh
this
home
chart
depends
on
this
this
operator
right
so
and
from
what
you
were
describing
it.
Then
it
sounds
like
you
you're,
working
on
a
way
to
address
that.
E
A
Two
things
in
the
operated
lifecycle
manager,
where
you
can
require
other
operators,
depend
on
other
operators,
but
where
we're
really
going
is
to
for
operators
to
tell
you
what
API
is
they're
using
inside
of
a
kubernetes
cluster
if
they're,
depending
on
certain
amount
of
api's,
and
if
we're
declaring
the
api's
that
are
using,
we
can
easily
say
if
something
is
going
to
work
or
not.
In
addition
to
tests
versus
just
depending
on
versions
that
you
don't
know
if
it's
going
to
work.
A
The
way
it
works
is
you
have
the
operator
running
at
CD
operator
running
and
it's
deployed
new
versions
of
its
deployed
at
a
certain
version.
That's
called
at
version
a
of
s
CD,
and
then
you
update
the
operator
and
this
operator
is
capable
of
handling
version,
B
of
n
CD,
and
so
what
it
happens
is
that
operator.
C
C
A
H
Okay,
two
questions:
actually
the
first
one
talks
about
best
practices
around
create
an
operator
because
there
are
some
things
on
the
the
site:
the
github
page
that
talks
briefly
about
that
yeah,
but
I
wanted
to
see
if
there's
anything
coming
out
that
gives
people
you
know
best
practice
around
creating
that
the
other
question
I
have
also
is:
what
is
your
recommendation
about
running
the
operator
inside
or
outside
the
cluster,
because
I
know
in
that
documentation?
It
allows
you
to
do
both
yeah.
What
what
do
you
recommend
so.
A
Best
practices
we're
trying
to
encode
the
best
practices
in
side
of
the
operator
framework,
but
we're
also
trying
to
document
them.
So
that's
that's
our
goal
here
and
that's
an
ongoing
effort
and
then
running
inside
or
outside
the
cluster
outside
the
clusters
for
development.
If
you're
on
your
machine-
and
you
really
want
to
iterate
quickly-
that's
why
you
run
it
outside
of
the
cluster.
I
Thanks
ed,
the
question
I
have
is
about
managing
the
underlying
kubernetes.
Like
objects
like
pods
and
deployments.
Is
there
you
know
with
the
memcache
one
you
used
a
pod?
Is
there
a
reason
to
use,
you
know
manage
at
the
pod
level
or
the
replica
set
level
within
an
operator
or
is
it
depend
on
the
use
case?
It's.
D
A
A
A
K
A
That's
what
we're
hoping
for
building
making
sure
that
building
test
and
test
suite
are
a
part
of
building
an
operator
and
also
not
letting
things
run
if
everything
is
not
green
and
checked,
and
so
when
you're
gonna
get
an
operator,
the
test
will
be
embedded,
at
least
with
the
for
at
least
with
the
operator
for
a
framework
tests
are
embedded
within
the
operators.
So
when
you
get
in
on
the
cluster,
you
can
run
its
tests
yeah.
L
L
Can
expose
any
piece?
Okay,
that's
it,
and
the
second
thing
is
I
used
I
just
used
to
operate
SDK
like
a
couple
of
weeks
ago
to
create
a
custom
operator,
but
I
didn't
want
to
do
any
of
this
fancy
reconciling
stuff
I
just
wanted
it
more
as
a
watcher
to
just
get
the
get
information
from
the
CRT
and
just
send
an
API
call
out.
Is
there
some
sort
of
a
support
you're
going
to
have
just
for
like
a
custom
controller
like
a
handler
like
not
come
that
doesn't
come
with
this
whole
reconciler.
A
So
it's
not
the
there
there's
always
a
loop,
because
you're
watching
a
CR
and
you're
reconciling
something.
But
if
that's
your
use
case,
it's
doable
like
there
there's
people
who
are
building
operators
that
call
out
to
clout
api's
to
do
things
right
to
to
instantiate
AWS
instances
to
to
create
whatever
they
want
outside
of
their
kubernetes
cluster.
That's
also
one
of
the
big
pluses
of
the
ansible
you
can
like.
Despite
not
wanting
to
write
code,
you
can
also
just
write
a
lot
of
ansible.
That
goes
and
does
things
on
your
physical
network.
L
F
A
I
mean
the
operator
SDK
is
focused
on
really
making
it
easy
to
opportu
to
to
build
applications
right
like
there
there's
a
lot
of
lower-level
things
that
you
can
want
and
want
to
do
and
specialized
things
that
you
would
want
to
do
with
the
other.
Api
is
what
we
focus
on
is
for
people
who
are
building
applications
to
automate
them.
Like
that's
our
level.
That
doesn't
mean
that
it's
not
you
can't
use
the
lower-level
things
to
do
more
detailed
work,
or
sometimes
you
need.
A
B
M
So
my
question
is
more
from
a
design
of
a
operator,
basically
so
for
around
the
application
workflow
again.
So
if
the
application
has
multiple
executable
cuts
itself,
what's
the
best
practice
to
design
the
operator,
is
it
like
should?
Should
we
run
a
part
for
every
executable?
Should
there
be
one
container
for
each
executable,
just
it.