►
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
Managing stateful services in Kubernetes is difficult. The Operator pattern has been created to deal with this, but existing frameworks require users to have intimate knowledge of Go and Kubernetes controller patterns. The Kubernetes Universal Declarative Framework (KUDO) is an operator development toolkit and runtime that makes writing operators productive and simple, enabling operator developers and end users to use tools they already know to manage the stateful services work with. This webinar will introduce KUDO, demonstrate the operator development toolkit, and show existing operators that have been written with KUDO.
A
Since
for
everyone
who
is
joining
us
today,
welcome
to
today's
CN
CF
webinar,
we
are
introducing
the
kubernetes
universal
declarative
operator.
My
name
is
you
heard
varetsky
I'm
a
developer
advocate
at
the
cloud
native
computing
foundation
and
I'll
be
moderating.
Today's
webinar
and
I
would
like
to
welcome
our
presenter
today.
It's
Jared
Dillon,
a
staff
engineer
at
D
to
Ike
here.
A
First
of
all,
I'd
like
to
mention
a
few
housekeeping
items.
So
during
the
webinar
you're
not
able
to
talk
as
an
attendee,
there
is
a
Q&A
box
at
the
bottom
in
August
of
the
screen
and
feel
free
to
drop.
Your
questions
there
we'll
get
to
get
some
to
the
questions
in
the
end
or
Jared
can
also
take
some
of
them
during
the
webinar.
A
This
is
an
official
webinar
of
the
cloud
native
computing
foundation
and
it's
an
subject
to
the
CN
CF
code
of
conduct.
So
please
do
not
add
anything
to
the
Charter
questions
that
would
be
a
violation
of
the
code
of
conduct
and
please
be
respectful
to
all
of
your
participants
and
presenters.
So
now,
I'd
like
to
hand
it
over
to
Jared
to
kick
off
their
presentation.
B
Thanks
Igor,
hello,
everyone,
my
name
is
Jared
Dillon
and
I.
As
a
said,
I'm,
a
staff
engineer
and
the
good
a
product
owner
over
at
t2,
our
day-to,
like
you,
and
these
links
will
be
up
again.
But
as
kudos
community
project
I
wanted
to
give
people,
the
resources
they
need
to
come
in
participate
get
some
more
information
on
their
own.
So
we
have
a
website.
It's
at
cooter
dev,
our
git
repo
to
org,
is
under
CUDA
builder,
slash
Kudo
and
we
have
a
select
channel
inside
of
the
kubernetes
slacks.
B
So
if
you're
interested
in
participating
in
our
community
and
you're,
not
already
in
the
kubernetes
slack
I'll
have
that
link
at
the
end
so
that
you
can
go,
join
the
kubernetes
slack
and
ask
questions
and
get
more
information
on
actually
using
Kudo.
So
I
want
to
start
out
and
talk
about
a
little
bit
about
operators
and
operator
development.
For
those
who
aren't
aware
of
operators
in
liquid
space
operators
are
a
concept
of
combining
kubernetes
customer
resource
definitions
and
a
custom
controller.
B
Yes,
there's
a
question
about
the
youtube
link
being
invalid.
I
will
update
that
in
and
put
it
as
a
comment
in
or
afford
that
to
Taylor
II
or
as
a
comment
to
maybe
add
to
the
youtube
description
or
will
post
in
the
Kudo
slack
so
going
back
to
operators
an
operator
is
a
combination
of
kubernetes
customer
resource
definition
and
a
controller
that
that
provides
functionality
on
top
of
that
controller.
B
So,
for
example,
you
may
want
to
stand
up
at
CD
clusters
inside
of
kubernetes,
and
so
so
you
want
to
represent
that
as
something
more
than
just
kubernetes
primitives,
as
also
be
concerned
about
the
day
to
life
cycles
of
these
more
complicated
pieces
of
software.
The
operators
were
envisioned
to
cover
so
over
time.
A
couple
of
different
frameworks
for
developing
operators
have
have
come
and
and
begun
to
develop
out
in
the
community
when,
as
people
start
to
ask
okay,
how
do
I
build
an
operator?
B
How
do
I
build
these
custom
controllers
and
it
turns
out
that's
pretty
hard
in
order
to
build
an
operator
right
now
in
kubernetes,
you
need
pretty
advanced
kubernetes
and
distributed
systems.
Knowledge
and
you
have
to
do
most,
listen.
Go
there.
There's
some
other
SDKs
out
there,
but
go
is
closest
to
the
kubernetes
source
code.
A
lot
of
it
is
generated
anyway,
and
and
is
often
the
more
most
mature
client
for
doing
that
and
if
you're
a
vendor
building
operators
in
the
space.
Your
your
building
operators
for
your
software
to
distribute
to
to
your
customers.
B
It
can
be
really
challenging
to
hire
for
these
skills.
If
that's
not
part
of
your
core
competency,
if
you're,
if
you're
stateful
services
are
written
in
Java,
but
now
you
have
to
do
software
development
and
go
it's
a
whole
separate
team,
separate
from
your
actual
operational
team
to
do
so
and
building
a
really
good
operator
takes
a
lot
of
code
and
a
lot
of
time
to
do
in
its
current
state.
B
It's
right
now,
fifty
three
thousand
lines
of
code,
a
lot
of
that
is
generated,
but
that's
just
benefit
of
the
go
code,
generation,
client
generation
tools
being
really
good
at
this
time.
Now,
if
you're,
actually
trying
to
use
these
operators
running,
these
taper
workloads
can
be
pretty
complicated
and
every
operator
has
its
own
workflow.
Its
own
API
is
its
own
debugging
tools
and
when
you
have
five
six
of
these
controllers
all
running
in
your
cluster,
they
can
get
pretty
tough
to
manage
and
right
now
running,
stateful
workloads
of
cuba's.
B
And
then
it
increases
it's
a
tool
to
increase
developer
productivity
when
actually
building
these
operators.
So
the
idea
behind
Coonan
we'll
talk
about
this
a
lot
today,
it's
about
being
able
to
ship
your
software
with
its
run
book.
If
you're
shipping
a
MySQL
operator-
and
you
want
to
be
opinionated
about
how
backups
and
restores
are
done,
kudos
a
tool
for
doing
that
at
a
very
high
level
in
a
very
productive
way
and
for
end
users
and
end
operators
of
these
of
the
these
operators
are
at
the
end.
App
developers
is
what
we
call
them.
B
There's
there's
an
intent
to
provide
increased
productivity
and
we'll
talk
about
that
some
as
well
when
operating
these
services
by
providing
a
common
control
plane
for
performing
a
lot
of
these
tasks
and
and
reducing
the
surface
that
people
need
to
know
about
when
actually
going
to
operate
these
services.
So.
B
B
B
You
a
lot
of
these
operator
frameworks
that
are
out
there
aren't
necessarily
as
concern
or
leave
it
to
you
as
the
developer,
to
really
make
it
application
aware
for
your
particular
operator,
and
so
there's
no
standards
yet
around
things
like
backups
and
restores
there's,
there's
Cooper
Nettie's
primitives
for
those,
but
the
leanest
gets
wide
open
on
what
you
should
do
as
a
best
practice
when,
when
going
to
put
in
these
day
2
operations-
and
so
we
believe,
there's
a
lot
of
value
in
making
this
particular
set
of
tasks.
A
lot
easier.
B
So
kudos
developers
in
a
couple
ways
we
provide
extractions
for
sequencing
lifecycle
operations
and
we'll
talk
about
this
using
a
series
of
KU
Bernays
objects
that
are
both
native
and
series
and
then
allowing
to
perform
sequencing
around
them
by
using
by
using
a
concept
called
plans,
and
you
can
think
of
these,
as
as
manual
run
books
that
you
might
keep
in
your
organization
or
in
your
tooling
of
how
to
actually
perform
some
sort
of
tasks.
Be
it
deployed,
be
an
upgrade,
be
a
tack
off
the
topic,
be
it
a
day
at
a
database
index.
B
Food
also
provides
an
extension
next
mechanism,
so
one
thing
we
wanted
to
solve
was
this
idea
that
you
would
have
to
actually
fork
the
entire
code
base
of
an
operator
or
of
a
chart
or
whatever,
in
order
to
add
in
your
your
specific
tooling
to
that,
and
so
we
have
an
extension
mechanism
based
on
customize
to
allow
for
you
to
to
tailor
that
to
your
environment.
Then
we
want
we,
then
the
intent.
There
is
four
organizations
that
have
their
special
method
of
backup
or
their
their
special
operational
needs.
B
They
can
tailor
existing
charts
without
having
to
go
off
on
their
own
and
have
to
merge
back
in
updates
down
the
road
and
they're
providing
IVs
with
a
tool
to
really
just
ship
those
best
practices
and
a
run
book
alongside
their
software.
We
also
ship
with
a
testing
tool
and
we're
probably
going
to
split
that
out
as
its
own
tool,
because
it's
a
really
nice
tool,
but
it's
enables
TDD
of
kubernetes
resources
on
their
own
and
to
be
able
to
make
assertions
when
you
create
conveyance
resources.
What
should
happen
in
your
cluster?
B
We
have
the
same
similar,
API
and
sealion
workflow
experience
for
all
of
these,
and
these
are
all
kubernetes
customer
resource
definitions
and
custom
resources
under
the
hood.
So
we
we,
while
we
have
a
plug
in
everything,
is
intended
to
work
just
straight
through
cube,
CTL
and
through
get-ups.
If
you
want
to
continue
using
your
existing
workflows
but
take
advantage,
they're
running
them
with
the
Kudo
controller
manager
and
we're
working
on
tooling
for
this
to
become
a
bit
better,
but
we're
also
working
on
existing
operators
to
be
managed
by
Kudo
and
really.
B
This
is
for
we'll
talk
a
little
bit
later
about
how
Kudo
one
of
the
upcoming
features
for
Kudo
is
dependencies,
and
so
we
want
to
also
fit
Kudo
into
the
larger
ecosystem
by
being
able
to
depend
on
other
great
operators
out
there
that
are
in
existence
and
just
to
repeat
what
Taylor
just
said
in
the
chat.
If
anyone
has
any
questions,
please
drop
them
into
the
Q&A
box
at
the
bottom
of
zum
and
at
various
points
I
am
I,
will
stop
and
answer.
Those
in
an
upcoming
is
features
around.
B
So
just
a
walkthrough
technically
a
little
bit
the
lifecycle
orchestration
with
Kudo
we
are.
We
are
settling
into
this.
This
yeah
mo
our
versioning,
this
yeah
Molly,
so
that
we
can
continue
to
experiment
with
it.
But
we
have
a
concept
of
plans.
Plans
are
your
top-level
lifecycle
operations,
you've
deployed
backup/restore
ad
topic,
various
other
things
and
phases,
there's
really
a
grouping
mechanism
for
tasks,
and
this
is
to
handle
complicated
use.
B
Cases
such
as
HDFS
or
or
other
software,
that
really
has
to
be
really
can't
be
deployed
by
just
throwing
all
the
manifests
at
it
at
once.
So
this
is
a
large,
very
coarse-grained
grouping
of
tasks.
It
says
strategy
serial
there,
but
phases
can
only
be
run
serially
as
of
zero.
Eight
zero.
So
that's
slightly
incorrect.
It's
at
the
step
level,
where
you
can
decide
between
parallel
and
serial
for
actually
running
these
steps.
B
So
within
phases
we
have
groups
of
steps
and
really
steps
are
our
groupings
of
kubernetes
resources
or
tasks
that
do
something
to
your
cluster
and
and
this-
and
this
is
where
we,
you
can
really
start
to
tweak.
So,
for
example,
you
may
be
able
you
may
be
able
to
deploy
something
zookeeper
in
parallel,
but
you
really
wanted
to
play
something
that
Kafka
serially,
and
so
this
allows
you
to
tweak
how
that
all
happens
and
how
you
actually
run
this
during
say
an
upgrade
cycle.
B
This
is
particularly
important
with
something
like
zookeeper
@cd,
where,
if
you're
going
to
scale
or
if
you
are
going
to
perform
an
upgrade,
you
really
want
to
do
that
in
a
rolling
way,
and
you
want
to
do
it
with
some
financial
API
awareness
and
I.
Had
a
great
question
come
in
and
I'll
address
that
after
the
next
slide,
that
is
correct
and
that's
on
our
roadmap,
but
I'll
address
it
earlier
than
that,
and
the
question
is
actually
not
all
address
it
now.
What
are
the
permissions?
B
B
One
we've
discussed
is
having
dynamic
our
back
control,
so
that
is
when
you
go
to
install
an
operator
with
Kudo
it
will
the
the
operator
or
the
cluster
user,
who
is
actually
doing
that
will
use
their
service
account
through
the
Kudo
CLI
tool
to
adjust
the
roll
bindings
for
Kudo
to
be
able
to
work
with
that
particular
operator
that
reduces
automate
automate
ability.
A
little
bit
because
it
does
require
the
user
who's
adjusting
those
permissions
to
be
able
to
do
that.
B
We
are
also
working
as
part
of
our
GA
process
to
shrink
the
surface
of
Kudo
so
that
you
can
apply
a
custom
service
account
to
it
so
that
it
can
operate
on
the
exact,
namespaces
and
resources.
You
want
one's
a
static
way
of
achieving
the
same
thing
as
the
dynamic,
but
we
want
to
push
some
of
that
back
into
the
hood
back
under
the
hood,
where
possible,
to
make
the
individual
operator
experience
a
little
bit
better
if
that,
hopefully,
that
gets
user
question.
B
All
right
so
getting
unto
lifecycle
orchestration
coming
with
Kuno.
One
thing:
we're
trying
to
do
is
push
a
lot
of
this
into
a
much
more
declarative
environment
and
do
a
lot
more
declaratively.
We
talked
about
get
up,
get
up,
sand
and
whatnot,
but
it
only
goes
a
certain
level
with
where
we're
at
and
so
for
Kudo.
Next,
what
we're
working
on
is
becoming
more
declarative
towards
components,
and
so
you
would
declare
a
set
of
components
say:
a
backup,
a
broker,
a
topic
and
CUDA
would
manage
these
as
CRTs
for
you
in
your
cluster.
B
So
you
would
write
a
create,
update,
upgrade
delete
and
in
various
custom
plans,
for
each
of
these
components
and
very
CLI
extensions
that
could
go
along
with
these
components
and
kudo
will
convert
this
into
a
set
of
series
that
you
don't
have
to
manage,
and
so
all
of
your
application
components
and
your
topology
now
become
CR
DS
and
and
they
can
be
treated
like
any
other
kubernetes
resource.
So
those
are
subject
to
Valero
backups,
whatever
get-ups
tools
that
you're
using
any
kubernetes
native
or
web-based
are
back
that
you're
using
etc
right.
B
So
you
may
want
to
represent
a
Kafka
topic
as
a
CR
D
set
the
number
of
partitions.
Now
you
post
your
cluster
components
and
topology
can
be
backed
up
and
dropped
onto
another
cluster,
and
it's
all
declarative,
though
we're
still
working
this
out
and
the
reason
this
hasn't
landed
or
really
we're
still
working
on.
B
So
here's
a
quick
breakdown
architecture.
We
actually
just
updated
this
today
because
there's
one
thing
out
of
date
on
here,
but
we
have
the
a
kudo
controller
manager,
that's
running
inside,
of
your
kubernetes
cluster,
working
on
a
set
of
CRTs
and
those
series
our
operator.
These
CRTs
today
are
operator
operator
version
and
instance,
so
we
store
everything
local
to
your
cluster.
There's
no
external
package
store
all
these
operator.
Definitions
exists
inside
of
your
cluster,
so
you
may
have
kafka
operator
with
multiple
versions,
and
then
you
would
have
an
instance
of
this.
B
That
then
runs
these
kafka
images
and
you're.
The
cube
CTL
kudo
plugin
is
the
opinionated
way
to
interact
with
all
that,
so
it's
going
to
fetch
from
the
file
system
or
from
a
Kuno
repository
with
an
index
Toyama.
These
various
operators
get
this
definition,
convert
it
into
the
right
set
of
CRTs
and
put
that
onto
the
cluster
and
the
reason
we
do
that
these
operator
and
operator
version
series
are
really
internal
definitions
for
us
and
not
meant
for
you,
even
though
you
can
back
them
up
restore
that.
B
So
this
format,
this
operator
format,
that's
in
the
repository,
is
stable,
whereas
this
is
that
these
are
not
yet
public
api's
and
so
that
that's
because
we're
continuing
to
iterate
on
operator
and
operator
versions
instance
will
stabilize
and
are
in
our
coming
version
and
then
operator
mo
and
grams
yeah
mo
inside
the
repo
will
stabilize
as
well
and
another
great
question:
how
are
tasks
defined
when
I
get
to
the
live
demo?
I
will
show
that
Kudo
zero.
B
Eight
zero
is
actually
changing
that
a
little
bit,
but
you
have
a
tasks
section
in
operator,
yeah
mo
that
lists
off
off
your
various
possible
tasks,
and
the
kubernetes
templates
are
resources
that
go
into
those.
So
in
Olo
we
will
have
an
applied
tasks,
a
delete
tasks,
a
helmet
art
tasks
and
a
pipe
task
for
piping
between
resources
and
all
those
takes
slightly
different
fields,
for
example,
apply
and
delete.
B
Take
a
list
of
resources,
whereas
pipe
takes
a
container
spec
and
an
ID
to
tag
that
with
to
use
in
future
templating
on
the
hell
chart
takes
the
helm
chart
inter
version
and
their
value
thought
yeah
mo
again.
If
that
that
doesn't
quite
answer,
your
question
I'll
show
it
a
bit
in
the
demo
and
then
you
can
also
ask
for
in
slack
thanks
for
the
question.
That's
a
great
one.
B
So
talk
a
little
bit
about
the
community,
we
are
very
CNC
appliance
in
the
beginning.
We
are,
we
are
we've
been
talking
about
Kudo
and
the
CNC
F
sandbox,
as
well
as
conveyance
SIG's.
So
we
have
an
open
and
open
governance
model.
Now
that's
based
around
kubernetes
and
Han
split
proposals.
Caps.
We
do
something
slightly
different
and
we've
tweaked
it
for
because
we
do
not
have
special
interest
groups,
we're
just
a
holistic
project.
B
B
Mysql
right
now
we're
at
zero
seven
five
and
we
do
minor
releases
every
two
to
four
weeks.
We've
bunch
of
github
stars
we're
pretty
happy
with
the
growth
there
for
the
age
of
the
project.
We've
been
talking
with
a
lot
of
people,
various
organizations
interested
in
building
operators,
even
purely
internal
ones,
using
kudos.
So
we're
not
just
thinking
about
database
companies,
we're
thinking
about
centralized
IT
teams
who
want
to
also
do
some
internal
management
of
cluster
level
services,
and
we
have
57
contributors
with
six
of
them
working
full
time
right
now.
Sudo
so
robust.
B
We're
growing
we'd
love
for
more
participation
in
this,
so
to
do
a
quick
comparison
of
kudos
to
some
other
tools
out
there
and
and
I
and
I
use
comparison
a
little
bit
unfairly,
because
we
believe
that
kudos
sits
into
an
ecosystem
and
there's
reasons
to
use
Kudo,
there's
reasons
to
not
use
Kudo
as
compared
to
these
other
tools.
So
really
think
of
this,
as
as
we
have
much
more
robust
comparisons
on
the
site,
but
this
is
just
a
quick
mental
model
that
you
can
take
as
kudos
as
compared
to
these
other
tools.
B
These
tools
are
all
great
which
just
fits
in
a
little
bit
differently,
so
the
very
first
operator,
SDK
and
queue
builder
Kudo,
is
a
polymorphic
controller
were
in
and
we're
looking
at
multiple
types
of
operators.
So,
whereas
with
queue
builder,
you
would
generate
out
your
one
holistic
operator
and
you're
working
in
that
codebase
be
a
hell,
1b,
ansible
or
be
built
and
go
Kuno
is
is
entirely
configured
via
CRTs.
B
We
are
supporting
some
whip
of
extensibility
with
that
tasks
system
we're
talking
about
coming
soon,
but
as
of
right
now,
this
you
don't
extend
kudo
itself
with
your
own
code.
The
other
operator
SDK
and
queue
builder
are
generative,
so
you
generate
out
your
operator
and
then
you're
working
from
that
project,
and
that
has
implications
around
how
you
go
an
upgrade
at
your
project
and
some
other
things
and
with
kudo
you
upgrade
the
controller
manager
and
we
may
have
a
deprecation
policy
around
our
CR
DS.
B
But
really,
if
you
have
something
like
your
MySQL
dump
tool,
we
want
you
to
use
that
because
it's
typically
going
to
be
application
aware,
and
that
is
to
say
a
lot
of
this
software.
You
can't
just
pick
up
and
take
this
the
snapshot
of
the
volume
and
dump
it
somewhere
else.
You
actually
have
to
do
this
in
the
way
that
the
software
prefers.
You
do
it,
and
that
may
be
the
case
with
Redis
and
grabbing
the
app
and
only
log
it
which
is
different
from
MySQL,
which
is
different
from
elastic
and
Kaufmann
anything
else.
B
B
B
So
there's
no
notion
of
an
ecosystem
of
operators
running
it
just
sits
individually,
meta
controller
is
does
not
does
not
have
much
there
for
you
for
sequencing
good
as
much
more
robust
sequencing,
and
if
you
need
that
Kudo
is
a
great
choice
for
it,
and
Kudo
also
thinks
about
okay,
I've
deployed
and
I
want
to
start
performing
operations.
Now,
what
do
I
do?
Meta
controller
can
has
his
facilities
for
upgrades
and
other
other
tooling,
and
it's
very
robust
tool,
but
just
optimize
slightly
differently
and
another
great
comparison.
B
We
get
often
is
well
what's
kudo
versus
helm
and
and
we're
specifically
talking
here
about
how
b2
with
tiller,
so
the
Kudo
really
I
mean
if
you
look
at
helmet,
tiller
helm
is
really
about
creating
a
releases
from
a
set
of
kubernetes
manifests
and
then
helm
steps
out
of
the
way,
and
it
is
done
so
you
don't
get
really
any
of
the
operator
benefits
of
something
monitoring,
your
application
for
change.
So
this
is
things
like
drip
detection.
You
know
any
repair
and
learning
that
you
want
to
do.
B
Helm
will
also
just
generate
out
a
bunch
of
resources
and
apply
them
all
at
once.
So
if
you
do
need
that
sequencing
for
these
really
really
complicated
applications-
and
you
find
yourself
with
helmet
tiller-
writing
a
lot
of
init
containers
to
try
to
get
things
to
happen
in
the
right
order,
who
don't
might
be
something
to
look
at
there
and
then,
like
I,
said,
we've
talked
about
this
a
lot,
but
Kudo
is
looking
at
really
higher
level
features
for
support
ability
as
well.
B
B
So,
looking
at
Kudo
a
little
bit
in
the
wild
and
just
doing
a
time
check.
Okay,
great,
we
have
a
bunch
of
community
operators,
zookeeper
Kafka,
MySQL
elastic,
there's
a
few
more
coming
soon
that
are
not
announced.
That's
a
fantastic
question
about
Tecton
I
will,
since
we're
on
the
topic.
I
would
address
that.
So
a
question
is
kudo
versus
Tecton
tech,
tongs
a
set
of
primitives
and
and
runners
for
CI
and
CD,
that's
being
donated
to
the
CD
foundation,
I
believe
and
I
they're
really
trying
to
solve
two
different
use
cases.
B
There
is
no
reason,
for
example,
you
couldn't
use
Tecton
to
deploy
Guto
operator
as
part
of
that
pipeline.
So
if
you
think
about
Tecton
tech
tongs
really
concerning
itself
with
continuous
integration,
continuous
deployment
pipelines
and
how
do
I
ship
my
software
versus
what
happens
now,
that
I've
actually
shifted
that
software
and
so
in
in
the
Tecton
world.
The
full
Kuno
operator
would
be
the
single
you'll
singular
unit
of
your
continuous
deployment.
B
B
So
Kudo
builds
on
top
of
queue
builder
and
controller
runtime.
So
we
we
sit
on
the
same
tools
as
other
tooling
standing
on
the
shoulders
of
giants.
We
work
with
those
teams
very
very
closely
and
really
we,
you
know
if
you,
if
you're
go
back
to
that
comparison
and
a
tool
like
Kudo
and
operator,
SDK
or
I'm,
sorry
cube
builder
and
operator,
SDK
builds
out
60,
you
know
50
60
%
of
good
practices.
Kudo
gets
you
70
80
%
of
the
way
there.
If
you're
able
to
follow
kudos
opinions
about
development.
B
It's
it's
like
looking
at
as
I
was
a
Ruby
on
Rails
tool,
very
productive,
a
bit
omeka
say
you:
can
you
can
open
up
the
hatch
if
you
need
to,
but
really
kudo
tries
to
tries
to
you
know,
be
a
little
cuckoo.
Doe
tries
to
finish
out
those
controller
implementations
for
a
certain
subset
of
projects,
but
we
stand
on
the
on
the
same
shoulders
as
these
other
tools.
B
B
B
Ya,
know
and
Ciardi
based
definitions
won't
go
away,
they
just
might
be
the
least
powerful
or
the
most
raw
of
those
options
operator.
Dependencies
are
in
progress
now,
and
so
what
this
is
really
about
is
if
I
have
Kafka
I
naturally
depend
on
zookeeper.
So
how
does
Kudo
fulfill
the
need
for
that
keeper
and
we've
identified
a
couple
different
personas
around
that
we're
right
now,
solving
the
output
variables
problem
around
it,
but
even
though
this
works
now,
we
want
to
automate
this
and
make
this
a
lot
easier
to
do
operator
extensions.
B
So
we've
talking
about
been
about
extensions,
but
we
want
to
be
able
to
allow
people
to
add
plans
without
without
having
to
fork
the
entire
operator
and
and
having
a
maintain
that
could
be
separately.
So
you
know
this.
This
enables
any
operator
be
enhanced
for
specific
environments
or
specific
monitoring
software
or,
if
you're,
using
Sto
or
linker
D
you
can.
You
can
maintain
these
versions
without
having
to
not
depend
on
the
base
tech
anymore.
The
upstream
base
tech.
B
B
The
other
before
I
come
back
to
that
one.
How
might
things
like
pod
disruption
budgets
fit
into
Kudo?
That's
a
great
question.
We,
if
you
look
at
some
of
our
operators,
we
actually
are
using
pod
restructuring
budgets
in
order
to
help
with
some
of
that
workload.
Life
cycles
so
for
deploy
we
may
set
it
set
a
pod
reception
budget
in
one
way
when
we
want
it
to
be
parallel
and
serial
when
we
want
to
handle
it
during
upgrade.
So
we
don't
upgrade
all
these
instances
at
once.
B
B
That's
a
that's
question
is
entirely
dependent
on
how
complected
your
applications
are
and
and
when
I
say,
complected
I
mean
in
the
sense
that
and
how
many
breeds
are
coming
strains
is.
Is
this
particular
application
tying
together
and
we're
talking
about
something
like
Cloud,
Data
functions
or
or
K
native,
or
something
like
that?
That
can
be
fairly
complicated
because
you
are
you're
bringing
many
concepts
together
and
I
find
typically
I
when
I'm
personally
developing
an
application
on
on
kubernetes
I'll
likely
start
with
a
helmet
r2
just
deploy
it
and
I'll
convert
it.
B
I'll
start
looking
at
an
operator
as
soon
as
I
need
to
need
things
to
start
happening,
that
I
don't
want
to
do
by
hand
or,
if
I
start
needing
to
do
some
higher-level
orchestration
or
multiple
components.
Invite,
like
I,
said
if
I
start
finding
myself
doing
a
lot
of
init
containers,
I'm,
probably
starting
to
consider
maybe
adding
into
my
orchestration
and
generating
out
something
with
queue
builder
or
even
or
even
cooter.
To
do
so.
B
Let
me
know
if
that
answers
your
question.
If
not,
we
can
discuss
it
more
and
just
checking
on
time.
Okay,
great.
We
got
a
few
minutes
left,
so
we'd
love
for
everyone
to
get
involved,
go
ahead
and
try
it
out.
Kudo
Deb
I'll
show
you
how
to
get
started
with
it.
It's
pretty
easy.
We
have
a
homebrew
package.
We
have
a
crew
package
super
easy
to
get
running
with.
It
feel
free
to
get
feedback
and
open
issues.
We
are
participating
in
October
fest
we've.
B
We've
got
a
bunch
of
issues
that
are
labeled
there
that
are
both
Oktoberfest
and
good
first
issue,
if
you're
interested
in
contributing
good
first
issue
means
that
you'll
have
a
kudo
core
team
member
there
to
help
you
get
used
to
the
code
base
and
understand.
What's
going
on,
we
also
have
our
operators
repo.
B
We
also
have
a
WWF
over
for
documentation
and
we're
in
the
Kuno
Channel
in
the
Cooper
Nettie
slack,
and
if
you
don't
aren't
in
the
Cooper
next
lock
today,
that's
where
you
can
go
to
get
an
invite
there
and
and
jump
in
so
with
that.
I
will
maybe
stop
for
some
lot
of
any
more
questions.
Real,
quick
and
then
I'll
show
a
quick
demo
and
turn
it
back
over
to
to
learning
or.
B
So
here
I
have
my
turn:
I
have
a
kubernetes
cluster
running
with
a
bunch
of
nodes
up
on
ec2.
This
is
using
the
one
of
our
distributions
of
kubernetes
called
convoy,
but
what
I'm
going
to
do
here
is
I
am
going
to
show
off.
We
have
the
cute
CTL
CUDA
plug-in.
This
is
installed
with
a
couple
different
ways
and
I
have
actually
did
not
include
in
my
demo
it's
in
our
documentation.
B
B
Brew
tap
could
a
builder
tap,
you
know
CLI,
it
will
alow
set
you
up
or
anything
even
khuda'
builder
tap
works,
but
anyway,
once
you
have
that
you'll
have
the
CLI
here.
You
can
also
do
it
via
crew,
be
acute
CTO,
crew,
install
Kudo,
I,
believe
yeah
it'll.
Do
it?
I
have
on
homebrew,
because
I
managed
to
maintain
a
custom
cap
internally,
but
you
can
do
it
through
there
and
just
get
the
plug-in
immediately.
So
kuno
depends
on
its
controller
manager.
B
If
you
want
to
install
the
controller
manager,
all
you
need
to
do
is
cube
CTL
kuno
in
it
and
it
will
install
the
CRTs.
The
default
service
account
and
the
controller
manager
and
it'll
do
all
that
in
the
controller
manage
or
in
the
Kudo
system
namespace,
and
it
deploys
that
as
a
stateful
set
as
well,
because
it
depends
on
being
the
only
one,
it
does
have
leadership
election,
but
that
is
that
needs
more
testing
before
we
GA
that
feature
in
AJ
Kudo.
B
Fortunately,
its
standalone,
it's
state
entirely
depends
on
kubernetes,
and
so
it's
pretty
compatible
against
against
a
wide
range
of
coo
brands
clusters.
We
test
on
even
even
kind,
which
is
cooper
days
and
docker,
and
we
test
on
mini
cube,
and
so
it's
works
in
about
every
environment
that
the
Cuban
it
is
scheduler.
Well,
if
not
everyone
I
just
haven't,
we
haven't
tested
it
to
full
exam
that
so
now,
if
I
want
to
go
and
install
safe,
zookeeper
and
I
won't
go
through
all
these.
B
B
So
we'll
install
Kafka
and
Kafka
has
deploy
serially.
So
what
we're
going
to
do
is
we'll
see,
Kafka
stand
up,
it'll
create
the
container
and
then
it'll
roll
through
and
create
the
other
two
replicas
as
soon
as
that
one's
ready.
So
in
the
meantime,
are
there
any
questions?
Anyone
has
will
that
deploys.
B
I'm
sure
they'll
take
to
tanked
out,
but
in
the
meantime,
I
will
actually
show
the
plan
status
to
for
this
one
7e,
and
so
we
can
see
here.
We
have
a
weird
custom
plan
there.
I
would
ignore
that
right
now,
but
we
we're
deploying
with
a
serial
strategy
and
it's
it's
showing
again
in
progress
and
as
soon
as
we
have
Kafka
well,
no
we're
done
and
it
should
show
that
plan
is
complete.
B
B
B
Thank
you
everyone
for
your
time.
That
is
Kudo
and
we
would
love
to
see
you
in
the
community.
I'll
put
up
those
slides
again,
so
everyone
can
see
them
and
I
turn
it
back
over
to
you.
You
are
oh
I,
do
have
one
more
question:
there
can
Kudo
do
roll
backs
rolling
back
a
complicated
set
of
services
can
be
very,
very
complicated,
so.
B
I'll
wear
as
I
like
that
feature,
I
think
our
team
would
like
that
feature.
A
lot
I
think
we
need
to
know
a
little
bit
more
of
the
use
cases,
because
it's
one
thing
to
roll
back
say
a
bad
release
of
a
Sinatra
application.
That's
another
thing
entirely
to
roll
back,
a
Casandra
upgrade
where
schemas
have
changed
on
the
underlying
disk.
So
would
love
for
you
to
join
and
talk
about
a
lot
more
about
your
specific
use
case,
and
we
can
find
ways
to
address
that
in
the
existing
system,
because
the
answer
might
be
yes.
B
In
the
case
of
the
words
not,
we
should
talk
about
where
we
can
add
features
for
those.
Sorry,
all
right,
one
more
question
here:
what
advantages
does
Kudo
offer
over
cube?
Ctl
the
cube
CTL
kudo
plugin,
just
wraps
together
a
bunch
of
opinionated
ways
of
doing
it
to
make
it
more
productive.
It
is
not
intended
to
replace
it,
so
every
action
you
do
should
be
doable
with
QC
TL
right.
So
if
I
were
to
look
at
these
CR
DS
look.
B
B
If
I
were
to
do
that,
open
that
up
again,
just
a
plain,
CR
d,
cube,
CTO,
Kudo
command
makes
us
easier
to
work
with,
but
everything
it's
our
position
right
now
that
everything
should
be
able
to
be
done,
some
away
with
cube
CTL
and
one
more
question:
can
we
integrate
CUDA
with
helm
by
default?
It'll
be
turned
on
in
zero,
eight
zero.
We
have
a
helmet
our
task
now,
but
and
we're
working
on
a
helmet
art
for
the
kudo
controller
itself.
B
But
to
answer
your
question
about
bringing
in
a
home
truck
yes
and
you'll,
be
able
to
what
that
will
do
will
create
just
a
default
deployed
plan
for
that
chart,
and
then
you
can
add
plans
on
top
of
that,
so
it
bakes
into
that
task
system.
We
there.
You
will
have
a
task
called
if
I
can
scroll
up
and
find
a
task
here,
you
will
have
a
task
called.
A
All
right,
Thank,
You,
Jared
mm-hmm,
so
thank
you
for
your
presentation
and
thanks
everybody
for
asking
their
questions.
We
don't
have
any
more
questions
today
and
we
can
give
you
back
10
minutes.
So
thank
you
for
joining
us
today.
The
webinar,
recording
and
slides
will
be
online
later
today.
We're
looking
forward
to
seeing
you
at
the
future
sensor
the
nurse
and
have
a
great
day
and
care.