►
From YouTube: Kubernetes Operators: Managing Complex Software with Software [I] - Josh Wood & Jesus Carrillo
Description
Kubernetes Operators: Managing Complex Software with Software [I] - Josh Wood, CoreOS & Jesus Carrillo, Ticketmaster
The Kubernetes container orchestrator scales and connects stateless applications quite easily. Stateful applications can require more work. Databases, caching systems, and file stores are harder to dynamically manage with data intact, and sometimes come with their own notion of clustering. Operators automate these tasks. Operators are Kubernetes agents that know how to deploy, scale, manage, and even upgrade complex applications.
In this talk, we'll illustrate the Operator concept, showing how Operators are built atop the Kubernetes third-party resources mechanism, with a close examination of the open source etcd Operator. We'll demonstrate Operators in action, including the extension of the Operator concept to upgrading Kubernetes control plane components themselves. The audience will learn how to deploy Operators, and how to begin developing Operators to manage their own stateful applications.
About Jesus Carrillo
Jesus Carrillo is a Senior Systems Engineer at Ticketmaster. He previously worked at AWS and Oracle and is passionate about new technologies and the best way to adopt them. When Jesus is not working he likes to relax and enjoy life.
About Joshua Wood
Josh Wood’s early adoption of the rkt container runtime led him to CoreOS, where he is responsible for documentation. Josh has worked in a variety of roles in innovative startups throughout his career, holding diverse titles from systems admin to product director and CTO. He is passionate about constructing the future of utility computing with open source technologies like Kubernetes and rkt.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
All
right,
good
afternoon,
everybody
I'm
Josh
wood
from
core
OS
I'm
here
with
ACS
curio,
seniors
officer,
senior
systems,
engineer
at
Ticketmaster
we're
going
to
talk
a
little
bit
this
afternoon
about
a
concept
we've
developed
at
core
OS
or
a
pattern.
You
might
call
it
for
management
of
sophisticated
stateful,
complex
applications
on
kubernetes
and
in
terms
of
the
kubernetes
api.
A
Critical
software
in
their
overall
services
stack
so
welcome
cloud
native
con
coupe
con
17,
and
thanks
for
coming
on
how
many
folks
here
verdict
over
Nettie's
I
know,
you
know
the
thing
we
all
love
the
most
about.
Kubernetes
are
certainly
that
drew
my
interest
to
it,
and
I
think
is
drawn
corporate
interest,
open
source
developer
interests
and
certainly
industrial
interest
in
the
platform
over
the
last
year
a
year
and
a
half
since
open
sourcing
is
how
easy
it
makes
it
to
scale
stateless
applications.
A
If
we're
talking
about
something
like
a
web
front-end
or
any
simple
app
that
doesn't
have
connections
to
persistent
storage
that
doesn't
have
its
own
Nessun
notions
of
clustering
or
internode
communication
scaling.
Applications
on
kubernetes
is
as
simple
as
using
the
tube
puddle
scale
command
to
scale
a
running
application
say
from
one
to
three:
how
does
this
work?
Well,
we
refer
to
the
parts
of
kubernetes
that
provide
command
and
control
lifecycle
management
as
the
control
plane,
and
that
name
comes
from
the
primary
piece
of
software
that
runs
in
that
control,
plane,
which
we
call
a
controller.
A
The
basic
stock
kubernetes
controller
has
a
simple
job.
It
looks
at
the
desired
state
of
an
application
or
deployment
described
by
Emmel,
manifest
file
or
wise
coordinated
by
an
administrator,
compares
it
to
the
actual
state
of
that
deployment
or
application
running
a
cluster
and
takes
actions
or
steps
to
reconcile
those
two
states.
This,
in
essence,
is
the
controller
concept.
You
could
call
it
an
Oda
loop,
you
can
observe
act
and
make
decisions
to
correct
situations.
A
So,
let's
say:
I
have
two
pods
running
for
my
simple
web
server
application
I
just
issued
a
coup
puddle
scale
for
three
replicas.
Essentially,
the
controller
loop
looks
at
the
difference
between
my
desired
state
in
the
actual
condition
in
the
universe
and
adds
the
pod,
so
that
now
I
have
three.
We've
even
made
this
simple
enough
that
you
can
do
it
with
a
graphical
application
in
our
tectonic
console
and
take
a
look
at
the
number
of
pods
running.
Ask
for
one
more
and
you
can
watch
it.
A
A
Some
of
my
applications
tend
to
read
and
write
files
or
report
things
in
a
database
or
have
other
notions
of
connection
that
expand
beyond
what
these
kinds
of
stateless
apps
expect
in
the
world
and
are
less
easy
to
migrate
between
cluster
node
members
in
the
event
of
application,
failure
or
scaling
requests
like
the
one
we
just
looked
at
we'd,
really
like
it.
If
managing
complex
apps,
like
databases
and
file
systems,
were
as
easy
on
kubernetes
as
creating
them
is
and
is
easy
to
manage
and
scale
those
apps.
A
As
the
simple
stateless
app
that
we
took
a
short
example,
look
at
it's
not
too
hard
to
say
who
cut
will
run
some
database.
You
got
an
image
and
you
bring
it
up
and
it's
running.
However,
what
if
that
database
has
its
own
notions
of
clustering
in
terms
of
masters
and
slaves,
or
leaders
and
followers?
Where
are
the
files
that
record
the
persistent
data
for
that
database
located
in
terms
of
+
or
resources?
How
do
the
pods
that
implement
the
database
application
find
connect
to
main
authentication
or
otherwise
access
those
staple
resources?
A
Secondly,
how
do
we
reconfigure
these
kinds
of
applications
when
it's
not
enough
to
tell
them
make
one
more
copy
of
this?
How
do
we
issue
commands
for
locating
persistent
data
stores,
persistent
special
network
connections,
perhaps
even
access
to
particular
computer
resources?
Last
but
not
least,
any
of
these
complex
apps
with
complex
data
that
persists
somewhere
in
the
world,
either
an
object,
storage
disk,
some
kind
of
a
volume
claim
in
the
end
that
data
needs
to
be
backed
up
and
managed
with
its
own
notion
of
what
a
life
cycle
of
data
preservation
looks
like.
A
A
If
only
kubernetes
knew
about
complex
applications,
so
the
answer
to
make
that
happen
is
to
take
advantage
of
the
extensibility
designed
into
the
API
and
the
kubernetes
architecture,
to
extend
kubernetes
to
work
with
particular
applications.
The
goal
is
to
come
up
with
something
simple
that
extends
the
kubernetes
api
to.
Let
us
talk
about
things
we
can't
currently
describe
in
API
terms
today.
What's
the
size
of
a
cluster
of
databases
or
file,
servers
that
I
want
to
have
running
on
my
kubernetes
cluster,
how
many
of
those
members
are
read?
A
I
think
the
easiest
way,
possibly
to
bring
this
into
some
kind
of
real
picture
that
you
can
reason
about
is
to
take
a
look
at
one
of
the
original
operators
we
initiated
at
core
or
less,
as
we
begin
to
define
and
explore
this
operators
pattern.
How
many
of
you
have
heard
of
SED
so
really
like
it
so
hard
conference.
Ask
questions
to
write
like
like
how
many
of
you
are
familiar
with
the
diet
of
worms
in
1331,
and
you.
B
A
Like
you
have
to
change
subject
matter
or
everybody
raises
their
hands,
sed
is
a
very
popular
distributed.
Key-Value
store,
it
solves
a
hard
problem
in
distributed
computing,
and
does
it
in
a
simple
lightweight
way
that
human
beings
are
at
least
somewhat
able
to
reason
about
by
implementing
the
wrapped
protocol,
rather
than
talk
size
for
consensus
in
distributed
databases.
In
short,
what
sed
does
is
store
little
bitty
pieces
of
information
that
need
to
be
coordinated
and
kept
consistent
among
multiple
members.
A
Storing
that
data
around
a
cluster
you
find
that
CD
at
the
heart
of
kubernetes,
storing
cluster
application
deployment
services
metadata
for
the
stock
kubernetes
control
plane.
Std
is
also
an
important
member
of
many
other
popular
distributed
applications
from
our
friends
in
the
open
source
and
industrial
communities.
That's
why
this
will
sort
of
all
on
that
slide.
A
So,
with
the
SED
operator,
we
built
an
operator
that
knows
how
to
manage
SED
clusters
and
keep
them
running
reliably
over
their
lifecycle
at
scale.
Deploying
this
operator
looks
really
really
simple.
On
the
surface,
you
pointed
at
a
yamo
file
and
at
the
end
of
the
talk,
I'll
give
you
the
URLs,
where
you
need
to
find
this.
All
of
the
work
I'm
speaking
about
today
is
open
source.
So
you
can
try
this
out
on
any
kubernetes
cluster,
pretty
much
immediately.
This
actually
deploys
the
operator
itself
rather
than
an
sed
cluster.
A
What
happens
after
this
step
is?
We
have
now
added
the
third-party
resources
and
the
custom
controller
binary
in
the
cluster
that
are
then
able
to
deploy,
create
and
manage
sed
clusters
for
us
again,
looking
at
sort
of
a
idealized
deployment
for
a
net
CD
cluster.
These
extensions
may
not
be
numerous
or
even
in
a
great
amount
of
depth.
They
just
provide
us
the
keys.
We
need
to
make
API
manipulations
of
an
application
around
which
the
API
was
not
originally
designed.
So
we're
looking
at
how
big
is
our
cluster?
A
So
to
take
a
look
on
the
screen
here,
if
you
look
at
sort
of
Group
one
we
have,
we
have
what
the
controller
maybe
would
consider
the
picture
of
reality.
The
thing
we
are
going
to
compare
to
our
desired
state.
Well,
if
you've
looked
back
at
the
Yambol,
we
were
showing
our
desired
state
is
considerably
different
from
the
state
represented
in
block
a
here.
We
want
three
pods.
We
only
have
two
running.
We
want
them
all
to
be
running.
A
Sed
version
3.1
point
zero,
but
we
actually
can
see
that
of
the
two
that
are
running
only
one
of
them's
running
the
version
we
requested
so
just
as
na
standards
kübra
a
standard
kubernetes
controller,
but
with
additional
specific
application
knowledge,
the
sed
custom
controller
that
comprises
with
the
third-party
resources.
The
sed
operator
can
examine
the
difference
between
reality,
desired
state
and
knows
how
to
actually
take
steps
in
sed
specific
terms
to
bring
the
condition
of
the
sed
cluster
to
that
described
in
the
desired
state
that
we
showed
in
the
manifest
file.
A
What's
that
really
going
to
mean,
in
this
particular
highly
simplified,
idealized
illustration,
it's
going
to
mean
that
we're
going
to
first
of
all
recover
at
least
one
member,
because
we're
short
of
one
member
of
the
three
we've
actually
requested
that
run
in
our
cluster.
We
are
going
then
to
actually
back
up
the
data
store
shared
by
that
entire
sed
cluster,
because
the
next
and
perhaps
most
important
step,
we're
going
to
take
in
our
reconciliation,
is
upgrading
that
recalcitrant
3.09
member
to
3.10.
A
In
short,
that's
what
the
SED
operator
does.
Those
are
the
basic
kubernetes
primitives.
It
extends
to
accomplish
that
work
and
it
is
open
source
code
which
you
can
examine,
use
to
run
your
own
sed
clusters
at
scale
on
kubernetes
manage
them
in
terms
of
coop
peddle
commands
in
the
kubernetes
api
and
additionally,
the
sed
operator
is
currently
one
of
the
best
and
cleanest
based
examples
of
where
you
might
start
writing
your
own
operators.
In
addition
to
SED,
like
we've
seen,
several
operators
arise
both
inside
pour
OS
and
in
the
field.
A
A
We
can
deliver
these
upgrades
because
the
container
gives
us
isolation
between
OS
and
application
layer,
so
the
same
I.
To
the
same
end,
we
are
trying
to
drive
this
idea
of
self
updating,
auto
updating
self
driving
infrastructure
up
through
the
stack
from
the
operating
system
to
things
like
at
CD
and
to
kubernetes
itself.
The
operator
work
is
a
key
underpinning
of
how
we're
delivering
self
driving
infrastructure
and
delivering
kubernetes
clusters
that
can
upgrade
and
manage
their
own
life
cycles
over
time
rather
than
requiring
manual
or
administrator
a
activity
at
grade
points.
A
The
sed
operator
lies
very
near
the
heart
of
how
that
work
is
being
delivered.
If
you
look
at
the
latest
release
last
week
of
tectonic
150
5.2
shortly
before
the
kubernetes
one
six
release
and
in
our
blog
post
making
the
release
announcement
for
this,
we
talk
in
some
detail
about
the
more
high
availability
at
CD
version
that
was
delivered
in
this
last
release.
A
A
lot
of
that
is
built
around
the
the
concepts
of
operators
and
how
they
manage
and
automate
the
management
of
SED
and
now
I
am
going
to
talk
about
one
of
the
other
operators
that
we
built
in
the
team
and
another
open
source
operator
for
managing
the
Prometheus
monitoring
and
alerting
system.
How
many
folks
here
used
Prometheus
to
monitor
their
systems
supposed
to
raise
your
hand,
hisses
I.
A
So
Prometheus
is
a
really
neat
monitoring
system.
Do
a
lot
of
charts
and
graphs.
We
can
take
many
many
detailed
measurements
and
much
of
the
kubernetes
api
and
the
sort
of
pod
interface
and
applications
that
you
run
on.
Kubernetes
are
instrumented
in
ways
that
Prometheus
can
gain
insight
to
and
report
statistics
and
measurements
from
out
of
those
statistics
and
measurement.
You
can
construct
reliable,
meaningful,
alerting
systems
for
when
things
do
go
wrong
and
people
have
to
take
action
or
perhaps
alerts
the
fire
operator
actions
in
an
idealized
automated
world
before
I.
Take
too
much
time.
A
I
am
going
to
point
out
that
our
Prometheus
operator
is
like
the
SCD
operator,
open
source
work
that
anyone
can
use
and
roll
out.
One
of
the
folks
that
has
taken
a
lot
of
initiative
in
rolling
this
operator
out
learning
it
in
deep
detail
and
building
production
systems
with
it
at
scale
at
his
place
of
employment.
I
happen
to
have
standing
on
stage
with
me
today.
A
So
I
would
actually
like
to
turn
this
over
to
KC's
carrillo
from
Ticketmaster
who's
going
to
take
the
general
outline
of
what
operators
might
be,
what
they
can
accomplish
and
drive
them
down
to
the
practical
level
of
what
Ticketmaster
and
hey
sis's
teams
are
doing
with
the
Prometheus
operator
at
Tech.
For
today
it
is
okay.
B
Good
evening
everybody
emphasis
Korea
I
work
at
the
kid
master
and
today
I'm
going
to
talk
about
our
journey
on
deploying
and
using
Prometheus
ticket
matter.
So,
first
of
all,
I
want
to
set
the
context
here
and
I
want
to
tell
you
how
to
get
master
is
going
to
use
or
is
using
Prometheus.
So
as
we
transition
to
a
DevOps
model,
we
are
getting
rid
of
on
open,
th
TV,
because
it's
a
gigantic
burden
in
our
operations
teams
to
keep
huge,
open,
th
EB
cluster
alive.
B
We
are
replacing
legacy
on
alerting
systems,
and
now
each
team
is
going
to
own
its
own
monitoring
and
alerting,
which
is
better
that
way.
So
we
we
started
evaluating
our
primitives
and
we
did
up
remove
concept.
It's
super
basic
and
it
was
closed.
Two
teams
that
arm
they
had
already
instrumental
applications
and
making
them
our
Prometheus
compatible
was
uneasy
step
and
teams
that
were
in
the
process
of
migrating.
Their
applications
to
AWS
and
I
wanted
to
take
the
extra
step
to
make
it
on
prometheus.
Enabled
the
architecture
of
this
pfg
was
super
simple.
B
It
was
Prometheus
and
Allard
manager
running
on
very
few
instances
and
it
was
sharing
which
it
was
shared
between
teams.
So
the
PLC
architecture
looks
something
like
that.
We
had
a
federation,
and
the
federation
is
just
another
set
of
promises
on
scraping
the
arm,
lower
layer,
promises
and
aggregating
all
the
metrics
into
a
single
point.
So
we
can
hook
up
Ravana
and
do
pretty
drafts
at
a
single
point.
B
B
B
So
then
we
say:
ok,
let's
roll
out
Prometheus
as
a
service,
so
the
teams
can
just
quickly
deploy
their
primitive
stack
and
get
a
lot
of
things
out
of
the
box
with
it.
So
the
Prometheus
as
a
service
must
allow
the
teams
to
quickly
deploy.
Ax
are
dedicated,
stack
and
I.
Have
the
goal
of
making
it
2
minutes
per
meter
stack.
B
It
should
not
represent
any
additional
burden
to
the
team,
so
they
just
permit
it'll
just
work
for
them
and
we
always
up
to
date
and
also
provide
pre-configured,
et2
and
keyboard
native
service
discovery
based
for
ec2,
based
on
tags
and
Kira.
Nerys
service
discovery
based
on
annotations
and
also
it
should
be
based
on
helm,
because
we
could
roll
out
our
newer
versions
of
the.
B
Service
discovery
templates
pretty
quickly
and
easy,
and
then
we
came
up
with
a
exporter
a
ticket
master
exported
database.
So
to
solve
the
network
shield
problems,
we
provided
a
well
known
port
of
of
a
well
known
port
range
for
the
exporters
we
open
the
akio
and
also
all
this
great
jobs
and
easy
to
service
discovery.
It's
based
on
this
database
exporter
database,
then
up
so
how
we
can
achieve
this.
Well
with
the
Prometheus
operator.
B
It
knows
it
allows
us
to
model
our
complex
primitives
stack
in
a
few
lines
of
code
of
configuration
also
for
the
Federation.
The
storage
is
outta
tune.
So
if
I
increase
the
memory
limit
for
the
pond,
that
is
running
our
Federation
workload,
the
primitives
operator
does
the
math
and
configures
it,
and
an
important
thing
is
that
our
manager
is
highly
available
by
default
with
the
primitives
operator.
I
just
need
to
say,
give
me
three
replicas
of
our
manager
and
it
will
configure
the
clustering
for
it.
B
So
what
we're
looking
forward
with
on
this
primitive
operator
arm?
We
we
are
really
interested
in
the
Federation
EPR,
because
right
now,
it's
manually
and
also
Federation
charting,
because-
and
this
is
really
important
for
us-
in
a
non
sale-
I-
don't
want
to
be
2
a.m.
in
the
morning
preparing
for
an
on
sale
and
have
to
scale
everything
and
charge
it
manually
right
and
also
graph
on
integration.
So
if
new
primitives
stack
is
deployed
to
the
kinetics
cluster,
I
can
have
the
arm
data
source
added
for
it.
B
And
one
interesting
thing
is
the
company
adoption
rate.
Everyone
loves
it.
We
have
two
weeks
of
production
already
clusters
and
the
adoption
rate
is
huge
right
now
we
have
like
four
teams
that
are
running
their
production,
grade,
monitoring
and
alerting
on
chromakey,
our
primitives
and
the
parameters
operator,
and
we
have
like
40
teams
that
are
evaluating
it
in
our
development
clusters,
and
this
is
a
quick
chart
of
of
hell
or
architecture
looks.
B
We
are
using
tectonic
clusters
and
we
have
deployed
a
set
of
easy
to
instances
that
are
running
there
are,
then,
has
a
specific
Negra
cells
to
be
able
to
reach
the
ec2
instances
on
the
port
range
that
we
carved.
For
this,
and
then
we
are
using
node
selectors
to
schedule
the
parameters,
workload
to
go
to
specific
nodes,
and
we
also
have
calcium
channel
or
network
policy,
and
then
the
federation
stores
the
data
into
any
beers
volume
EBS
is
eating.
The
EBS
are
provisioning
is
also
managed
by
the
operator.
B
A
So
the
question
since
I
don't
know
if
we
have
the
question
mic
room
in
the
audience
that
seems
to
be
sitting
up
here
on
the
podium,
but
the
question
was
not
specific
to
the
Prometheus
operator,
but
in
general,
how
do
operators
as
a
concept
or
a
pattern
compared
to
things
like
Helms
and
the
other
deployment
distribution
techniques?
We've
seen
a
rise
around
the
kubernetes
ecosystem
and,
secondly,
like
you
made
a
suggestion
that
operators
maybe
seem
to
you
more
like
a
concept
or
a
way
of
doing
things.
A
So
I'll
start
at
the
end,
I
think
you're
right.
In
that
sense,
the
way
what
I
think
I
like
to
think
of
operators
is
the
capital
o
as
a
pattern
or
a
concept.
The
way
that
complex
applications
can
be
managed
on
kubernetes.
We
have
not
boiled
operators
down
to
an
API
that
you
can
use
to
easily
construct
your
own
I
would
imagine
the
future
of
that
and
the
work
that
I
know
about
I'm.
Trying
to
generalize
that
stuff
is.
A
Their
very
nature
and
purpose
is
the
long
term
management
of
the
lifecycle
of
specific
applications.
They
do
encode
a
lot
of
application,
specific
knowledge
that
we
don't
necessarily
think
belongs
architectural
e
in
the
main
kubernetes
api,
which
is
why
we
chose
to
go
sort
of
this
route
of
extending
the
api
so
that
the
long
term,
how
do
I
build
my
own
operator
question
that
this
sort
of
train
of
thought
leads
us
to
is
today,
unfortunately
or
fortunately,
early
days.
All
this
is
pretty
new
stuff.
A
You
can
take
a
look
at
the
existing
actual
operator
code,
at
least
in
the
HCDA
operator.
There
has
been
some
work
to
abstract
the
general
operator
functions
somewhat
from
the
sed
functions,
but
they
still
live
in
a
single
codebase
right
now
in
the
future.
I
would
expect
there
to
be
something
like
an
SDK,
a
basic
software
development
kit.
That
is
like
the
bottom
of
an
operator
the
place
where
you
might
start
writing
your
own.
How
do
operators
compare
to
helm?
I?
A
Am
here's
a
I'm
going
to
answer
this
somewhat
glibly
and
not
even
make
any
attempt
to
hide
my
ignorance
of
one
side
of
the
question.
I
know
a
little
bit
about
helm.
I,
certainly
like
all
the
folks
at
Deus
and
I.
Think
I've
even
been
out
there
to
Boulder
to
speak,
and
so
like
I,
don't
I
just
don't
happen
to
know
a
lot
about
home
and
use
it
on
a
day
in
day.
Out
from
my
knowledge,
which
is
limited,
the
Asus
might
have
a
comment
after
I
wrap
up
here.
A
Helm
is
very,
very
deploy
and
replicate,
or
in
it
it
feels
more
like
configuration
management,
if
you
map
it
to
an
older
kind
of
concept
or
something
we
maybe
all
have
shared
knowledge
about.
An
idea
of
what
we
think
like
config
management
is
operators
are
a
long-running
application
that
stays
with
these
special
applications
as
they
run
on
kubernetes
clusters
and
not
only
deploy
them
in
easy
single
command-line
ways,
but
manage
their
overall
life
cycle
can
actually
upgrade
them
when
an
upgrade
is
available.
A
Not
when
you
run
a
set
at
home
commands
to
deploy
a
new
version
in
your
chart
and
I
think
that's
pretty
much.
How
I
see
the
difference
between
between
like
then
but
like
what
I
know
that
folks
do
with
helm
versus
what
I
do
know
about
operators
and
what
I
do
myself
with
operators?
I
could
even
and
here
will
be
where
I
go
too
far
and
really
reveal
my
ignorance.
I
could
even
imagine
a
helmet
that
deployed
some
kind
of
custom
operator.
B
Yep
so,
for
example,
we're
using
home
to
tilt
the
operator
that
we
need
our
Prometheus
instance
right.
So
we
we
use
it
to
generate
like
the
in
the
examples
that
George
did
on
the
the
Gamo
file
that
gets
pushed
to
the
API
and
and
we
would
help
with
hem.
We
construct
the
the
GPR
configurations
and
then
say
to
given
anything,
deploy
this
and
then
the
operator
takes
it
and
it
knows
how
to,
for
example,
create
another
manager
and
create
a
cluster
of
other
managers
that
that's
the
difference.
Right.
B
D
A
Okay,
so
the
roadmap
means
actually
did
not
know
about
all
such
an
extra
that
their
question
on
the
Q&A
they
had,
but
I
waited
to
inform
my
answer,
because
I
was
trying
to
do
a
little
bit.
Lauren
conveyed
with
us.
Refusing
I
mean
I
item
I.
Don't
personally
have
it
must
be
so
knowledge
about
that
plan
to
bring
home
into
the
problem
very
interesting
idea.
A
A
So
the
question
is:
are
there
plans
for
operators
for
complex
database
applications
like
my
sequel
or
Postgres
sequel?
We
have
done
experimental
work
on
them.
Definitely
for
Postgres
sequel.
That
is
a
piece
of
our
overall
infrastructure
out
at
some
edges
and
would
be
important
to
us,
and
they
are
also
those
are
exactly
the
kind
of
apps
that
we
would
expect
to
see.
A
So
there
is
a
work
operator
and
it
is
a
usable
in
live
running
operator
for
running
largest
urban
file
systems.
A
lot
of
problems
are
very
similar
in
solving
need
the
large
database
systems
issue.
So
yes,
is
a
very
long.
Yes,
one
of
the
things
we
love
to
manage
with
operators
of
our
databases.
Databases
are
tough
to
managing
distributed
clusters
right
now.
We
don't
have
good
ways
to
manage
a
Postgres
sequel
database
in
kubernetes
terms.
A
I
think
you
know.
Actually,
in
software
engineering,
you
try
very
hard
to
generalize
everything
you
can
and
reserve
the
specifics
to
the
places
where
they
must
live
part
of
the
idea
of
operators.
Is
they
are
that
place
where,
since
there
have
to
be
some
specifics,
this
is
where
they
should
live.
These
custom
controllers,
these
third-party
resources.
A
My
suspicion
is
that
the
API
from
the
previous
talk
is
much
more
general
and
would
be
a
general
kubernetes
feature,
whereas
you
would
build
an
operator
for
your
application
that
you
run
your
work
and
that
I
may
not
know
anything
about
I
think
that's
how
they
would
differ
again.
I
know
this
much
about
an
idea
for
for
a
services
API
and
an
endpoint
control
API,
so
I
have
an
idea.
What's
talking
about,
but
I
didn't
see
the
previous
talk,
so
it
a
little
hard
to
do
a
direct
comparison.
A
Certainly,
what
distinguishes
operators
is
their
specificity
to
particular
applications.
That's
so
what's
what's
different
about
them
than
the
work
we
do
every
day
upstream,
on
stock
open
source
kubernetes
is
we're
trying
all
the
ways
to
generalize
and
abstract
stuff
we're
putting
in
the
main
code
base
and
reserve
the
specifics
and
the
intricacies
of
individual
application
design
to
these
operators.