►
From YouTube: OpenShift Commons Gathering Santa Clara 2019 State of Kubernetes Operators talk Rob Szumski Red Hat
Description
OpenShift Commons Gathering
Santa Clara 2019
Kubernetes Operators
State of Operators: Frameworks, SDK and Beyond
Rob Szumski Red Hat
A
A
So
when
you
look
at
applications
running
on
kubernetes,
it
is
really
interesting
to
kind
of
dissect
the
history
there
and
if
you
look
at
it
at
first,
this
really
maps
to
win
certain
kubb
feature
sets
were
added,
and
this
kind
of
give
you
new
capabilities
for
running
certain
types
of
applications.
In
the
beginning
we
just
had
these
stateless
apps
we've
got
replica,
sets
and
deployments.
You
could
scale
these
things
out
horizontally.
That's
great
I'm!
You
know
everybody's
running,
very
simple
things,
but
what
you
really
want
to
get
to
is
stateful
applications.
A
You
want,
you
know,
having
staples
storage,
you
want
that
storage
to
follow
you
around
the
cluster
we
started.
Adding
things
like
staple
sets,
the
container
storage
interface,
all
these
new
parts
of
Kubb,
and
now
you
could
actually
be
pretty
productive
on
coop
you're,
starting
to
run
stateful
databases.
A
You
know
this
meets
a
lot
of
enterprise
needs,
but
what
you
don't
get
is
full
distributed
systems.
You
know
you
have
these
properties
inside
of
your
applications
that
aren't
modeled
in
just
kubernetes
objects
like
a
staple
set.
You
want
to
do
data
rebalancing
you
want
to
do
auto
scaling,
you
wanna,
do
seamless
upgrades
you
want
to
get
to
the
vision
that
Reza
just
laid
out
and
you
can't
get
there
with
just
Cube
alone.
You've
got
this
like
all
these
things
that
need
to
happen
inside
of
your
application.
A
There's
this
unique
knowledge
there
and
that's
got
to
be
captured
somewhere
to
be
able
to
run
that
on
kubernetes.
So
what
does
that?
It's
an
operator?
So
an
operator
is
taking
that
unique
knowledge
that
it
takes
to
run
your
application
from.
You
know
everything
that
would
be
in
like
a
run
book
or
that
you
would
keep
on
like
a
wiki
or
something
you
might
just
have
in
your
head
for
open.
That
thing
happens.
A
I
know
you
got
to
go
poke
this
bit
over
here
to
make
it
work
again
all
that
stuff,
you
can
actually
automate,
and
you
can
express
that
in
code
so
that
you
don't
have
a
human
having
to
be
there,
and
so
embedding
that
up
opps
knowledge
into
an
application
is
an
operator.
So
you've
got,
you
know,
version
1.1.2
of
your
operator.
You
add
some
new
functionality
put
a
new
version
out.
It
knows
how
to
upgrade
from
version
to
version.
A
You
need
to
go
start
this
tier
first
and
then
warm
up
this
cache
or
upgrade
the
database
schema
before
we
upgrade
the
front-end.
Whatever
types
of
things
that
you
need
to
do
every
day
to
get
your
job
done,
you
can
express
that
in
an
operator
and
what's
really
exciting
about
this
is
because
it's
a
nice
self-contained
unit
is
if
you're
distributing
software
which
either
that
means
to
another
group
inside
of
your
company.
You're
gonna
distribute
software
to
a
CI
system,
or
you
actually
publish
and
sell
software.
A
You
need
to
give
this
to
somebody
to
run
and,
as
you
have
these
multiple
tiers,
getting
a
customer
up
and
running
with
your
software
is
actually
pretty
hard.
I
mean,
even
if
they
have
coop
Kubb
is
already
world's
better
than
you
know,
trying
to
orchestrate
Ravi
m's.
But
you
need
to
be
able
to
do
all
this
stuff
correctly
and
that's
what
an
operator
lets
you
do
so,
what's
really
exciting
about
an
operator.
Is
that
you're
just
using
these
coop
primitives?
So
you
have
these
really
flexible,
app
architectures
that
are
possible.
A
A
Whatever
you
need
to
do,
and
then
you
know
build
on
all
those
cube,
primitives
for
doing
scheduling
across
availability
zones
and
the
failover
moving
storage
around
like
I
talked
about
so
you're,
not
reinventing
those
core
concepts.
You
know,
there's
a
group
of
thousands
and
thousands
of
contributors
to
cube
that
are
doing
a
really
great
job
at
those
low-level
bits.
What
you
need
to
bring
to
the
table
is
your
applications.
Knowledge
what
actually
needs
to
happen
when
this
needs
to
run,
and
then
you
know
you're,
not
just
gonna,
run
it
once,
but
you're
gonna.
A
This
thing
has
a
life
of
its
own.
You
know
running
across
black
Fridays
and
all
the
holiday
rushes
and
whatever
the
event
is,
that
makes
your
business
run.
You
have
a
uniform
story
for
debugging
and
deploying
that
so
you've
got
different
teams
that
can
share
operational
expertise
with
each
other.
You
know,
you've
got
teams
that
are
shipping
software
at
different
rates,
and
they
all
know
how
to
debug
that
so
whoever's
on
call
is
not
going
to
be
stuck
kind
of
trying
to
figure
out.
A
What's
going
on
reading
these
wiki
pages,
you
know
when
it's
crunch
time
at
2:00
a.m.
when
something's
down
and
then
a
key
to
the
Residence
Hall
vision.
There
is
that
this
is
truly
hybrid
you're,
just
using
kubernetes
primitives
under
the
hood,
and
so
what
you
get
is
something
that
can
run
anywhere.
You
can
run
coop,
and
so,
if
you're
distributing
software,
do
you
want
the
largest
ecosystem
possible?
A
Yes,
of
course,
that
you
can
address
your
market,
and
so
this
keeps
you
truly
hybrid
and
you're,
not
locked
in
to
any
certain
technology
stack
or
a
cloud
provider
yeah.
Do
we
want
that?
Does
that
sound
good?
Now,
let's
talk
about
how
we
get
that
so
as
well
as
I
said,
the
operator
framework
was
birthed
out
of
our
experience
at
core
OS,
as
well
as
at
Red
Hat,
building
these
operators
and
interacting
with
the
community
and
their
needs,
and
so
this
held.
A
A
So
we
set
all
that
up
for
you,
it's
a
bunch
of
code
generation
to
use
this
format
to
build
a
set
of
coherent,
consistent
apps,
but
with
a
framework
that
you
are
familiar
with,
so
we've
got
a
few
different
flavors
we've
got
our
go:
SDK
our
ansible
SDK
and
our
helm,
SDK
and
I'm
gonna
dig
into
each
one
of
those
in
a
second
and
then,
if
you
are
just
consuming
applications
on
kubernetes,
you
want
to
keep
these
applications
up-to-date.
You
want
to
manage
them
in
a
sane
way.
A
Your
day
to
operations
are
very
important,
and
so
this
is
a
way,
a
conduit
for
the
application
developers
to
get
you
a
stream
of
updates
in
a
sane
way
to
manage
and
apply
those
that
is
really
really
nice
for
security.
There's.
This
philosophy
that
we
had
at
core
OS
was
just
you
know:
bugs
are
inevitable
the
next
heartbleed,
the
next
shellshock,
whatever
it
is,
is
out,
and
the
only
thing
that
you
gives
you
defense
against.
That
is
just
updating
very
quickly.
You
need
to
have
automated
systems
for
patching.
A
You
know
your
Linux
layer,
your
applications,
your
front-end.
You
just
need
to
be
able
to
do
this
and
we've.
You
know
the
web
has
become
dramatically
more
secure,
as
automated
upgrades
have
come
to
our
web
browsers,
and
so
we
want
to
bring
all
of
that
experience
from
from
the
web
into
back-end
infrastructure,
and
so
this
is
really
really
important
for
security,
and
you
know
nobody
wants
to
be
in
the
headlines
for
having
their
unsecured
MongoDB
cluster
that
leaks,
700
million
email
addresses
like
it
did
last
week.
A
You
need
to
have
those
best
practices
embedded
in
something
steps
that
you
can't
do
that
we
have
operator.
It
knows
how
to
do
this,
for
you
TLS,
full
security.
No,
no,
no
brainer!
You
know
you
don't
need
to
worry
about
this
stuff,
and
so
that's
what
the
operated
framework
gives
you,
as
I
mentioned,
there's
three
different
pillars
to
this:
there's
on
the
build
side.
You've
got
to
build
these
operators
and
we
have
our
SDKs.
You
want
to
then
start
running
them.
A
You
might
not
be
running
just
one
or
two
of
these
operators,
but
there
might
be
30
or
40
of
them
on
a
cluster,
and
so
you
want
to
have
a
lifecycle
manager
there
to
help
you,
you
know,
run
and
upgrade
those
and
make
sure
that
they're
staying
up
to
date
and
then
once
you're
operating
these
at
scale.
You
want
to
start
looking
at
some
metrics
and
start
correlating.
A
Trends
between
different
operators
make
sure
everything
is
running
smoothly,
and
then
you
know
this
is
the
backbone
for
metering
to
do
auto
scaling
of
your
tears
and
things
like
that.
So
all
this
is
open
source.
It's
on
github
we've
got
all
of
these
different
projects
as
well
as
many
more
so
I
encourage
you
to
take
a
look
at
the
code
if
you're
interested
in
how
some
of
this
works
contribute
to
it,
of
course,
as
well
and
I
want
to
dig
into
a
few
of
these
pillars,
really
important
for
understanding
operators.
Is
this
maturity
model?
A
The
idea
that
you
know
there's
an
installation
experience
which
can
be
really
great
and
automated,
but
that's
kind
of
not
where
you
want
to
be.
You
actually
want
to
get
into
seamless
upgrades,
doing
full
lifecycle
management
of
your
applications,
and
so,
as
you
get
towards
the
right
of
this
diagram,
that
is
where
we
think
we
want
these
operators
to
be
over
time.
This
full
autopilot
the
thing
that
you
would
get
from
an
Amazon
RDS
or
any
of
the
other
hosted
services
from
a
cloud
provider.
A
For
you
know,
horizontal
and
vertical,
auto
scaling
kind
of
this
application
just
works.
The
way
that
you
would
expect.
If
you
just
naively,
came
in
here
and
said,
hey
I
just
want
this
database
to
store
my
data.
It
doesn't
matter
if
it's
terabytes
of
data
or
a
megabyte
so
on
the
bottom.
You
see
the
three
ST
case
that
I
mentioned
earlier.
A
The
helm
SDK
is
really
great
for
getting
kind
of
phase
one
into
phase
two,
so
you're
doing
some
simple
upgrades,
but
you
know
helm
doesn't
have
a
lot
of
logic
there
for
doing
any
of
these
complex
operations
that
we
are
talking
about,
data
rebalancing
and
that
type
of
thing,
and
that's
where
you
get
into
our
ansible
and
go
SDKs.
Where
you
can,
you
know,
do
these
complex,
rich
operations,
we're
going
to
talk
more
about
that?
The
operator
SDK
is
kind
of
feeds
in
these
three
into
a
common
testing
framework
and
verification.
A
Your
commercial
piece
of
software,
just
a
little
hobbyist
app
that
you
wrote
kind
of
all
of
those
are
welcome
and
operator
help,
and
one
thing
I
wanted
to
call
out.
Very
specifically
is
this
testing
framework.
If
you
can
picture
you've
got
your
database
operator,
my
sequel,
Postgres
Redis,
whatever
you
don't
want
this
thing
running,
amuck
and
starts
to,
like
you
know,
kill
all
your
production
instances
of
your
database
and
there
goes
your
data
and
so
testing.
This
is
extremely
important.
A
So
if
you
picture
an
operator
works
just
like
a
lot
of
kubernetes
primitives
under
the
hood,
so
you've
got
a
deployment
and
there's
this
reconciliation
loop
constantly
running
that
says:
oh
the
desired
replicas
count
is
three,
but
it's
currently
two
in
the
cluster
I
know
what
I
need
to
do.
I
need
to
add
one
to
that
two
to
make
it
three,
and
you
know,
there's
a
piece
of
code.
That's
constantly
doing
this.
When
building
an
operator,
you
need
to
write
this
code
for
your
application
and
testing.
A
That
is
extremely
critical,
so
that
you
know
that
when
one
of
your
leaders
of
your
database
fails,
for
example,
that
it
fails
over
correctly
and
does
whatever
it
needs
to
do
under
the
hood
to
make
that
safe
operation,
you
really
want
to
have
that.
Bulletproof
really
really
don't
want
to
delete
data,
and
this
is
how
we
build
trust
with
the
community
is
building
in
some
of
these
tools
so
that
you
don't
have
to
figure
out
exactly
how
to
instrument
your
reconciliation
loop.
A
We
kind
of
get
all
this
for
you
for
free
with
our
operator
SDK,
starting
down
the
list
kind
of
from
easiest
to
hardest.
If
you
will
our
helm,
sdk
is
really
great.
You
can
get
started
with
kind
of
no
code,
quote/unquote
I
know
this
is
Kelsey
Hightower's
funny
joke,
but
you
really
don't
have
to
write
any
code
for
this.
You
just
can
take
in
an
existing
helm
chart.
A
So
if
you
have
an
investment
in
doing
this
internally,
this
is
a
really
great
way
to
build
an
operator
and
what
you're
doing
is
connecting
that
helm
chart
to
a
reconciliation,
loop
and
plugging
it
into
the
kubernetes
api,
so
that
you
can
have
this
self-service
invocation
of
that
chart
and
connecting
the
if
you're
feeling
with
helm,
there's
values
that
you
pass
in
for
different
little
config
and
it
gets
templated
out
into
all
of
your
manifests.
What
you
do
is
add
those
into
a
custom
resource
definition
in
kubernetes.
A
This
is
the
official
extension
mechanism
for
kubernetes,
and
then
that
is
your
tunable
x'
that
you
pass
in
and
then
outputs
this
helm
tart.
That
gets
run
every
time
that
changes,
and
so
this
is
really
great
for
stateless
applications
or
very
simple
upgrades
if
you've
got
like
a
web
front-end
that
needs
to
go
from,
like
version
one
to
version
two,
but
you
know
you
can
load
balance
between
those
and
kind
of
seamlessly,
replace
it
really
great
for
a
hell,
mapper
ater,
but
you
know
running
a
database.
A
This
way,
I
wouldn't
advise
it
because
you
know
you
don't
have
control
over
what
that
data
is
actually
doing
when
it's
getting
moved
and
upgraded.
There's
certain
use
cases
where
you
could
probably
make
that
work
with
some
of
the
storage,
abstractions
and
kubernetes.
So
looking
at
the
helm
SDK
under
the
hood,
this
is
what
you're
actually
building
here
is
we're
gonna.
A
I've
got
my
production
in
my
staging
there
on
different
versions,
they're
ready-
and
this
is
kind
of
that
experience-
that
your
engineers
get
when
they're,
either
debugging,
something
or
rolling
this
out
and
then
in
your
CI
system.
What
you're
doing
is
addressing
this
Tomcat
object.
It's
not!
You
know
this
whole
pile
of
kubernetes,
manifest
that
might
get
out
of
sync
people
when
they're
reviewing
PRS
to
that
they
don't
exactly
know
what
they're.
Looking
at
you.
Just
get
this
really
nice
high-level
config
for
this
application,
and
you
can
build
this
for
anything.
A
This
is
the
beauty
of
kubernetes
extension
mechanism.
You
can
register
you
know
your
own
internal
web
apps
and
everything
like
that.
So
getting
a
little
bit
further
down
the
spectrum
of
getting
you
know
towards
that
level.
Five
maturity
model
is
our
ansible
sdk.
The
ansible
sdk
works
the
exact
same
way
under
the
hood,
except
for
what
you're
passing
in
there
is
a
set
of
play
books
and
then
when
to
invoke
those
play
books.
A
So
this
is
really
great
for
infrastructure
teams
that
might
not
have
a
lot
of
like
kind
of
traditional
developer
experience
where
they're
you
know
they're,
not
software
engineers,
but
they
they
get
into
this
stuff,
and
they,
you
know.
Maybe
you
have
a
bunch
of
automation,
already
written,
to
update
DNS
records
and
drain
load
balancers,
and
you
know
any
of
that
type
of
stuff,
as
well
as
interacting
with
cube
directly
in
play
books.
A
You
can
actually
tie
those
into
the
kubernetes
event
model
so
when
this
node
fails
start
running
this
playbook,
that
does
something
in
my
application
to
fail
it
over
doing
backups
kicking
off
any
of
that
type
of
automation.
Anything
you
can
do
with
ansible.
You
can
build
into
an
operator
and
then,
like
I,
said
earlier,
you
get
this
really
great
native
coop
experience.
We're
gonna
do
oh,
so
you
get
Tomcats
again.
It
looks
the
exact
same.
A
The
technology
used
to
build
that
operator
you
know
is,
is
different,
but
you're
getting
that
same
experience
and
then
all
the
way
on
kind
of
level.
Five,
the
the
thing
that
I
think
a
lot
of
our
like
database
vendors
are
going
to
use
to
build
operators
is
our
go
as
okay
and
the
really
exciting
thing
about
the
go
SDK.
Is
it
uses
the
same
tools
that
kubernetes
developers
upstream
use
to
build
kubernetes
everything
that
you
have
at
your
disposal
there?
A
You
want
to
warm
up
this
cache
you
want
to,
you
know,
generate
some
TLS
certificates
to
be
used
internally,
whatever
it
is.
That
needs
to
happen
on
startup
and
then
constantly
running.
This
checking
different
parameters
of
your
different
Tomcat
installations,
making
sure
that
they
haven't
drifted
from
the
desired
config
and
if
the
desired
config
has
been
updated,
go
through
and
do
whatever
steps
needed
to
make
that
happen,
and
this
can
be,
you
know
things
like
in
a
database.
A
You
might
flip
one
flag
from
you,
know
highly
available
from
false
to
true
and
that
actually
might
kick
off
a
whole
slew
of
different
operations.
We're
now,
oh
I
need
to
tweak
the
service
how
I
route
traffic
to
my
pods,
because
I
don't
have
one
now
I've
got
two
or
three
or
five.
Oh
now
we're
not
talking
over
like
localhost
and
so
I
need
to
generate
some
TLS
certs
I
need
to
set
up
an
auto
scaler
for
this
I
need
to
configure
backups
whatever
it
is
that
you
need
to
do.
A
Operators
at
some
of
these
large
financial
institutions,
for
example,
you
know-
have
a
lot
of
application
tiers
that
they
need
to
orchestrate
and
pretty
complex
ways,
and
so
hopefully,
we'll
see
some
of
those
folks
talking
about
that
stuff
over
time
as
the
community
grows
and
grows.
As
a
reminder,
you
know
using
something
like
the
SPARC
operator
means
that
you
don't
have
to
be
an
expert
in
spark
when
SPARC
components
get
deployed
and
need
to
discover
each
other.
You
don't
need
to
know
how
that
happens.
You
need
to
be.
A
You
know,
have
a
high-level
expertise
in
how
you
interface
with
SPARC
and
run
your
SPARC
jobs,
but
you
don't
really
need
to
care
exactly.
What's
going
on
under
the
hood
they're
the
experts
from
that
community
or
that
commercial
vendor
that
you're
getting
that
operator
from
have
baked
all
that
expertise
in
so
what
that's
doing
is
freeing
you
up
to
do
higher
level
tasks.
Getting
your
business
objectives
done
versus
having
to
go.
A
You
know,
read
a
bunch
of
wiki
pages
and
start
tweaking
all
your
gamal
files
for
three
hours
to
make
sure
you
get
something
that
actually
works.
They're
kind
of
taking
all
that
from
you.
Here's
a
view
of
what
one
of
the
operators
looks
like
on
operator
hub
and
I.
Think
it's
interesting
to
kind
of
break
down
what
the
lifecycle
management
tasks
that
you
need
are
if
you've
never
used
an
operator
before
or
you
have
a
little
bit
of
coop
experience,
but
not
a
ton.
A
It's
interesting
to
see
you
know,
we've
got
some
descriptions
of
this
and
you
know
this
has
a
capability
level
on
that
right-hand
side.
So
you
can
see
that
the
Amazon
service
operator
just
kind
of
handles
basic
install.
This
makes
sense
because
it's
mostly
orchestrating
some
Amazon
resources.
So
there's
not
a
lot
happening
on
the
cluster
itself
and
what
I
want
to
do
is
take
one
of
these
operators
and
really
look
at
what's
going
on
and
focus
on
these
the
two
right
hand:
circles
here
so
you've
got
this
operator
running
some
code.
A
That's
constantly
running
this
reconciliation
loop
and
then
it's
interfacing
with
kubernetes
and
a
bunch
of
objects
are
either
being
created
or
destroyed,
or
you
know
whatever
needs
to
happen
in
the
normal
lifespan
of
this.
But
let's
talk
about
how
that
actually
happens,
because
there's
a
lot
of
unique
and
important
security
touch
points
that
happen
in
the
communication
between
these
two
blocks.
So,
if
you
think
about
when
you
need
to
install
an
operator
what
needs
to
happen
here,
what
does
if
I'm,
using
this
lifecycle
manager?
A
What
is
it
doing
for
me
or
if
I'm
gonna
do
this
manually?
What
do
I
have
to
do
so?
First,
you've
got
to
install
these
CR
DS.
That's
the
custom
resource
definition,
that's
the
abstraction
of
your
application.
That
was
the
the
Tomcat
object
or
our
MongoDB
object,
for
example.
So
you
want
to
install
these
and
there
might
not
just
be
one
of
them,
but
there
might
be
like
five
of
them.
For
example,
the
MongoDB
operator
understands
how
to
install
three
different
versions
of
depending
on
what
you
want
to
do,
there's
the
standalone
version.
A
So
that's
really
great,
for
you
know,
ephemeral,
storage
on
a
single
instance,
just
kind
of
dev
mode.
Then
there
is
the
clustered
replica
set.
So
that's
you
know
replicate
this
between
a
few
different
nodes.
Then
there's
like
the
fully
started
cluster,
where
you're
kind
of
controlling
which
segments
of
data
get
instantiated
and
moved
around
the
cluster,
and
so
you
need
to
find
all
three
of
those.
A
If
you're
not
familiar
with
this
operator,
you
might
not
know
that
those
all
three
of
the
five
of
those
exist
and
so
and
then
also,
most
importantly,
does
anything
else
own.
These
CR
DS.
Does
anybody
else
managing
this
Postgres
object?
For
example,
you
don't
want
two
operators
trying
to
manage
one
cluster.
That
would
be
pretty
bad
and
then
the
lifecycle
manager
has
a
really
interesting
capability
which
is
doing
dependencies
between
operators.
A
So
you
can
imagine
that
you
know
you're
you're
gonna
have
your
spark
clusters
and
your
kafka
clusters
and
your
Redis
and
your,
but
an
application
is
probably
actually
going
to
consume
all
of
these
things
for
different
uses
inside
of
it,
and
so
your
operators
can
actually
start
to
work
together.
So
you've
got
an
application
that
has
a
front-end
that
needs
a
Postgres
database
and
it
says:
hey
I
need
a
Postgres
CRD
present
on
the
cluster,
but
I
don't
provide
that.
A
Go
go,
find
me
something
that
does
that
and
if
you
have
a
Postgres
operator
like
crunchy
on
the
operator
hub,
you
can
go
say
hey.
Let
me
go
plug
that
in
now
these
operators
are
working
together
and
they're
using
that
Kubb
api
to
do
it,
so
you
need
to
figure
all
that
stuff
out.
You
didn't
make
sure
you
have
all
the
things
present
to
run
your
application.
Then,
of
course
you
got
to
run
this
thing.
It's
a
container.
It's
nothing
special.
It
runs
on
the
host
in
kubernetes.
A
Just
like
anything
else,
so
you
got
to
start
a
deployment
for
that.
It's
a
deployment
cuz.
We
want
to
be
highly
available
and
you
know
give
it
replicas
equal
one,
and
then
this
operator
is
looking
for
these
other
CR
DS,
so
it
can
start
weaving
that
capability
together
now
you've
got
to
start
some
listening
on
some
namespaces.
A
So
if
you're
familiar
with
namespaces
in
coop,
this
is
how
you
segment
your
projects
from
each
other,
your
your
teams,
your
different
environments
from
each
other,
and
you
might
only
want
this
operator
running
across
five
namespaces
per
se,
or
only
in
this
one
namespace
I'm
just
testing
it
out.
So
you
got
to
hook
up
all
the
the
proper
role
based
authentication
for
that
give
it
a
service
account.
That
knows
how
to
watch
this
namespace
and
that
namespace
for
these
specific
primitives,
maybe
you're,
really
security.
A
Conscious
and
you
don't
want
this
operator
being
able
to
read
your
secrets.
You
can
do
that
via
the
permission
model
inside
of
kubernetes
and
the
lifecycle
manager
can
actually
help
you
orchestrate
all
of
this,
so
you're,
not
even
thinking
about
at
this
at
all,
and
then,
of
course,
you
know
you
want
to
give
an
operator,
it's
pretty
powerful
and
it
needs
to
be
able
to
read
some
of
your
cluster
to
do
its
job,
but
you
want
it
to
have
that
minimal
set
of
permissions
possible
just
to
keep
it.
A
You
know
the
blast
radius
down
as
small
as
possible
and
then
bind
those
to
the
service
account
that
your
operator
is
using.
So
all
of
that
happens
kind
of
auto
magically
for
you
inside
of
the
lifecycle
manager.
You
don't
need
to
be
an
expert
in
any
of
this,
and
the
authors
of
an
operator
are
expressing
all
of
these
inside
of
a
file
that
you
get
that
I
want
to
go
over
because
I
think
it's
really
interesting.
A
A
That's
running
on
your
cluster
1.1.2
of
the
operator,
for
example,
and
what
you
can
express
in
this
file
is
these:
are
the
the
C
RDS
that
you
I
own
or
I
require
so
either
I'm
gonna
manage
these
and
install
them,
and
here
they
are
or
I
depend
on
this
thing,
don't
install
me
until
I
have
one
of
those
present
on
the
cluster
and
then
you're
gonna
run
this
container.
That's
the
strategy
deployment
and
give
it
some
permissions.
A
You
can
have
both
permissions
inside
of
a
namespace
or
if
your
operator
is
doing
something
like
installing
storage
for
the
entire
cluster,
you
can
register
storage
classes
and
all
kinds
of
stuff
at
the
cluster
level
as
well,
and
then,
of
course,
running
that
deployment
inside
of
the
namespace
or
namespaces
that
it
needs
to
run.
So,
let's
jump
over
and
take
a
look
at
this
example
in
the
Amazon
service
operator.
A
Hopefully,
you
can
see
that
so
there's
some
interesting
stuff
in
here,
and
this
is
a
lot
of
metadata
about
you
know
the
version
of
the
operator
and
things
like
that
embedded
in
this
is
actually
an
example
of
in
this
case
running
in
ECR
repo.
If
you
were
going
to
instantiate.
This
here
is
an
actual
version
of
that
CRD
that
you
can
get
started
with
and
then
tweak
from
there.
So
these
are
kind
of
like
getting
started
templates
which
are
really
nice
to
have.
A
A
You
can
also
scope
them
down
a
little
bit
more
tightly
into
a
set
of
namespaces
or
just
a
single
namespace,
and
so
this
allows
your
operator
to
express
how
it
needs
to
be
installed
on
the
cluster,
so
that
you
don't
need
to
worry
about
this.
The
cluster
is
just
going
to
do
that
for
you,
via
the
lifecycle
manager.
A
Here's
that
deployment
that
I
looked
at
I
mostly
wanted
to
show
this
to
you,
so
you
can
get
an
idea
of
kind
of
how
your
how
granular
you're
getting
with
these
permissions.
This
is,
you
know,
looks
like
a
kubernetes
auerbach
object.
That's
because
that's
exactly
what
it
ends
up
being
on
the
backend
of
this,
but
it's
all
tied
together
to
the
version
of
the
Opera.
A
So
if,
for
example,
you
added
a
new
component
that
needed
to
use
a
config
map,
but
before
you
didn't
use
config
maps,
getting
a
new
version
of
that
operator
via
this
file
has
an
updated
permission.
The
lifecycle
manager
will
wire
that
new
permission
up
and
now
you
have
access
to
used
config
maps,
for
example.
So
your
application
just
got
smarter.
It
got
better,
it's
got
better
scalability
whatever,
then
the
feature
is
based
on
the
config
map
and
you
don't
have
to
worry
about
anything.
A
It
all
got
wired
up
for
you,
here's
the
actual
deployment
which
is
not
exciting.
It's
just
in
a
deployment
and
we're
passing
in
a
few
of
these
parameters,
and
then
the
last
thing
I
want
to
show
you
here
is
the
custom
resource
definitions.
This
is
the
Amazon
operator
expressing
the
objects
that
it
owns.
So
here
it
owns
a
kind
of
cloud
formation
template.
So
if
you
did,
coop
code
will
get
cloud
formation
of
templates
after
this
is
installed.
A
Some
of
the
the
awesome
capabilities
that
you
get
from
using
an
operator
with
the
lifecycle
manager,
is
you
get
this
self-service
experience
for
your
engineers,
so
they've
got
a
common
place
to
go
and
see
all
the
tools
available
to
them
at
their
disposal
that
you,
as
the
admin
of
their
cluster,
have
installed.
So
this
is
you
know
things
like.
A
Oh,
if
I
want
to
go,
get
a
stateful
database,
I've
got
and
I've
got
Redis
and
I've
got
Postgres
I've
got
whatever
it
is
installed,
and
these
engineers
can
go
to
you
know
your
cluster
catalog
to
go
see
what's
available
there
just
like
they
would
go
to
the
cloud
control
panel
of
one
of
their
favorite
cloud
providers
to
go,
get
these
types
of
services.
But
remember
you
want
to
be
truly
hybrid.
A
You
don't
want
to
be
tied
into
that
exact
implementation
of
Amazon
versus
goggle,
but
here
you're
providing
a
Trulli
hybrid
set
of
tools
for
your
users
to
use,
and
then,
at
the
end
of
the
day
they
have
self-service
they're,
just
expressing
these
very
simple
top
level
configs
for
a
database,
for
example,
and
getting
that
up
and
running
so
you
know
they're
prototyping,
really
quickly,
you're
going
to
production.
This
thing
can
scale
from
a
dev
use
case,
all
the
way
up
to
something
a
lot
bigger
and
if
you're
practicing
this
concept
of
get
ops.
A
This
makes
your
your
whole
pipeline
they're
very,
very
understandable
and
easy,
because
it's
really
high
level.
So,
instead
of
you
know
your
application
being
made
up
of
like
35
different
Kubb
objects
for
all
your
services
and
config
maps,
and
these
deployments
and
these
service
accounts
and
all
that
stuff
you're
expressing
these
high-level
config
so
I've
got.
You
know
two
tiers
of
my
my
database
or
my
database
in
my
front-end
and
that's
my
application.
You
just
have
these
two
objects
that
you're
managing
for
dev
and
production
and
behind
the
scenes
you've
got
this
operator.
A
That's
baked
in
that
actually
has
you
know
all
the
steps
that
would
have
been
done
in
like
the
run
book
or
whatever
to
make
that
happen
and
can
stamp
out
all
those
tube
resources.
So
that
stuff
is
there
and
you
still
get
all
the
power
of
that
inside
of
kubernetes
but
you're
not
managing
it
from
a
day-to-day
level.
So
if
you've
got
a
new
team
member,
for
example,
that
needs
to
get
like
a
dev
environment
set
up
here.
A
These
two
objects
go
talk
to
your
namespace
and
your
Koob
cluster
and
they're
good
to
go
couldn't
be
more
simple
than
that,
but
then
they
actually
get
the
complexity
there,
where
they
can
say.
Oh
yeah
run
this
in
actually
production
mode,
and
you
know
full
h.a
and
do
all
the
everything
that's
required,
but
then
you
get
that
inside
of
their
little
namespace
and
they
don't
need
to
be
an
expert
at
that
application,
which
is
really
really
exciting.
A
Then,
of
course,
if
you're
running
a
cluster
in
the
audience,
you
want
to
have
full
control
over
this
stuff
and
see.
What's
going
on
so
inside
of
openshift,
you've
got
access
to
all
the
operators
that
are
installed
on
the
cluster,
the
different
modes
that
they're
in
you
can
go
look
at
some
of
the
access
levels
that
they
have
and
then
see
what
their
update
status
is.
If
they've
got
security
updates
are
available
that
you
haven't
applied.
A
Lastly,
I
want
to
encourage
you
to
try
this
out.
We've
got
a
full
getting
started
guide
that
talks
through
building
your
first
operator
with
the
SDK
plugging
that
into
the
lifecycle
manager.
Getting
that
running
on
a
cluster
and
then
I
want
to
invite
you
to
come
to
continue
the
discussion
in
our
operator
sig
inside
of
OpenShift
Commons.
This
meets
the
third
Friday
of
every
month,
and
so
this
is
a
great
group
of
people
that
are
either
showing
off
operators
that
they
built
helping
each
other
solve
complex
problems.
Oh
hey!
We
had
an
issue
with
that.
A
How
did
you
solve
you
know
this
inside
of
your
application,
that
type
of
thing,
as
well
as
influencing
the
project
roadmap,
some
of
the
things
that
we're
working
on
next?
How
do
we
better
instrument
these
operators
make
them
easier
to
scale?
You
know
possibly
introduce
new
languages
for
the
SDK,
think
you
know
things
like
a
Java
operator.
Sdk
will
be
pretty
popular,
so
if
you're
interested
in
some
of
those
topics,
please
join
us
as
well.