►
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 Kubernetes clusters and the application workload running on them is complex. Developers and teams should have a means of quickly shipping solutions into K8s and ensuring they can lifecycle those solutions. Tooling and complexity become problems that chip away at precious dev time. We’ll show you how this problem can be solved and unified in a way that makes it easy to manage clusters in public or private environments and their associated workload. This will be a demo rich webinar.
A
A
My
name
is
Josh
burkas,
I'm,
the
kubernetes
community
manager
at
Red,
Hat
and
I'm,
a
cloud
native
ambassador
in
which
context
I'm
hosting
today's
webinar
I'd
like
to
welcome
our
presenter
today,
Matt
Baldwin,
who
is
director
of
cloud
native
and
kubernetes
engineering
at
that
out,
so
welcome
Matt.
Thank
you
before
we
actually
start
I
wanted
to
give
a
few
housekeeping
items
number
one.
During
the
webinar,
you
will
not
be
able
to
talk
as
an
attendee
and
you
will
not
be
able
to
display
your
video.
A
Instead,
we
have
a
Q&A
panel.
If
you
click
the
small
Q&A
icon
at
the
bottom
of
your
screen,
it
will
open
up
a
separate
panel
where
you
can
post
questions,
some
of
which
will
get
answered
in
text
messages
by
the
NetApp
team
who
are
dialed
in
to
this
call,
and
some
of
which
will
get
answered
during
the
Q&A
phase
at
the
end
of
the
presentation.
A
A
B
Josh
I
love
the
beat
excellent,
can't
wait
for
that
movie
to
come
out
here
so,
like
I
said,
I
am
Matt.
Baldwin
I'm,
the
director
of
cloud
native
and
combination
engineering
and
prior
to
that
I
was
founder
and
CEO
of
a
company
called
stack
point
cloud
and
I
too,
am
a
CN
CF
ambassador
for
kubernetes
and
have
been
one
for
the
last
few
years.
B
What
we're
calling
cloud
native
anywhere,
which
is
a
concept
that
you
should
be
you
know,
continuing
the
concept
of
portability
with
kubernetes
workload,
is
that
your
cloud
native
environments
and
that
workload
on
those
environments
should
ultimately
be
able
to
run
anywhere
regardless
of
on-premise
or
off
premise
and
I'll,
show
you
some
tooling
of
how
that
can
work
in
a
demo
after
that
I'll
discuss
concept
called
cloud
native
app
management
of.
So
how
do
you
provide
developers
with
what
they
need
for
for
the
environments
that
they're
shipping
code
into
on?
How
do
you
take
you?
B
Take
you
know
kind
of
responsibility
off
of
the
developer
doesn't
need
to
understand
things
like
kubernetes
understand
things
like
Sto,
and
so
they
all
they
have
to
do
is
basically
push
code
to
deploy,
basically
push
code
to
deploy
their
application
into
into
running
environments,
and
so
I'm
going
to
talk
through
that
here
towards
the
end
of
the
presentation
and
provide
a
demo
as
well,
and
so
let
me
get
going
with
cloud
native
definition.
So
this
is
a
I'm
just
going
to
put
that
I'm
just
going
to
slide
linger
here.
B
B
B
You
know
services
solutions
that
you're
gonna
need
to
look
out
begin
to
adopt
on
your
journey
to
cloud
native,
and
you
know
just
like,
like
a
trail,
you
know
here
in
the
Olympics
here:
in
Seattle
trails
can
be
dangerous,
trails
can
be
hard,
trails
could
be
very
long
and
but
at
the
end
we're
trying
to
get
to
a
point
where
it's
a
minimal
toil
for
everybody.
So
we're
saying
you
know,
you're
gonna
need
some
type
of
container
ization
you're
gonna
need
orchestration
for
pretty
much
all
of
us.
That
is
kubernetes.
B
You
know
you
need
be
able
to
package
those
those
applications
up
and
some
type
of
definition
helm
for
most
of
us.
How
do
I
observe
all
this
have
I
do
see
ICD,
you
know
what
about
network?
What
about
service
meshes,
so
you
know,
do
I
need
to
use.
This
do
am
I
looking
at
one
for
D,
and
then
we
move
into
things
like
distributed
databases
and
then
storage,
and
so
these
are
all
pieces.
B
For
me,
as
a
user,
that
I
don't
need
to
learn
a
lot
of
new
things
effectively
where
I
would
like
to
head
in
the
space,
because
everybody
has
to
learn
new
things
now
you
know
there's
like
a
ton
of
stuff
on
everybody
plate
and
from
you
know,
with
customer
interactions
that
we're
seeing
there's
a
lot
of
mandates
coming
down
from
you
know
now
that
kubernetes
is
kind
of
out
there.
Cloud
native
is
now
circulating
more
in
the
mainstream
sea
level.
B
Sea
suites
are
starting
to
catch
winds
of
this
technology
and
we're
hearing
mandates
are
just
being
pushed
down
into
teams.
You
know
things
like
get
us
over
to
cloud
native
in
six
months
where
that
team
has
zero
knowledge
of
cloud
native,
and
so
you
have
six
months
to
go
from
zero
knowledge
to
being
an
expert
in,
and
this
tie
this
entire
trail
map.
So
what
we're
trying
to
do
in
that
app
is
try
to
deliver
tooling.
That
makes
easier
to
get
down
this.
This
trail
and
I'm
gonna
show
some
of
that
here
in
a
bit.
B
So
what
are
some
of
the
pillars
that
we
try
to
stand
on
when
it
comes
to
cloud
native?
The
first
pillar
is
the
workload
ultimately
should
always
be
portable.
It
should
be
ready
for
multi
cloud.
You
should
be
abstracted
from
your
cloud
provider.
You
should
be
abstracted
from
the
infrastructure,
because
the
idea
is
that
you
should
be
able
to
take
that
workload
and
I
should
be
able
to
have
that
live
on
premise.
I
should
be
able
to
move
that
to
say
a
public
cloud
provider.
B
B
It's
things
like
cloud
native
application
management
is
another
pillar
that
we
look
at,
and
that
is
a
way
of
thinking
about
how
do
you
deliver
and
run
and
manage
applications
inside
of
kubernetes,
not
necessarily
a
deployment?
But
how
do
you
take
the
group
of
deployments
and
create
an
application
taxonomy
around
those
and
say
these
deployments
together,
represent
my
application
and,
as
a
developer,
so
say,
I'm
in
a
persona
of
a
developer.
I
want
to
be
able
to
see
service
dashboards
for
that
application.
I
want
to
be
able
to
see
logs
for
the
application.
B
B
That
a
little
deeper
here
in
a
bit,
another
pillar
that
were
looking
at
with
regards
to
cloud
a
full
cloud
native
stack,
is
security
and
the
belief
is
that
security
needs
to
be.
You
need
to
have
security
at
rest,
so
there's
great
open-source
tooling
out
there
to
be
able
to
accomplish
that.
Angkor
comes
to
mind,
which
is
a
container
scanner
register
scanner.
It
could
be
used
in
place
of
Claire
if
anyone
out
there
knows
what
Claire
is
also,
we
believe
in
container
security
at
runtime,
open
source
tools
that
would
help
you
address.
B
That
would
be
things
like
Falco
from
Cystic
would
allow
you
to
begin
to
address
runtime
security
and
also,
you
know,
forensics
arounds
events
that
occur
in
that
container,
and
so
we
think
you
know
there
needs
to
be
a
lot
of
the
tooling
out
there.
All
that
needs
to
be
open-source,
but
there
needs
to
be
a
way
to
tie
all
this
together
so
that
you
have
a
consistent
user
and
management
experience.
Brown
these
tools,
the
problem
that
most
of
the
users
the
space
is.
B
Having
is
what
tools
do
I
use
and
how
do
I
symbol
them
all
together?
So
I
have
a
cohesive
what
we
would
call
a
cloud
native
stack.
The
solutions
to
work
with
you
know
how
do
I
ensure
that
all
my
see
you
know
all
my
you
know,
traffic
inside
my
cluster
is
secure
in
flight.
You
know
how
do
I
do
that
with
ISTE.
Oh,
is
that
by
default
you
know
how
do
I
digitize
that
you
know
there's
a
lot
of
that
tooling.
B
That
needs
to
be
composed
and
put
together
for
users
and
that's
what
we're?
What
we'll
be
showing
you
here?
Storage
is
another
big
one.
That's
a
cloud
native
puller
for
us
for
sure.
As
a
net
up
is
how
do
you
think
about
storage
and
inside
the
context
of
a
micro
service
improvement
running
in
kubernetes?
How
do
you
protect
that
storage?
How
do
you
move?
That's
that
data
from
point
A
to
point
B.
B
So
how
do
you
migrate
to
the
public
cloud
if
you're
on
premise
or
if
you're
in
public
cloud
and
when
to
move
back
to
on-premise?
How
do
you
do
that?
How
do
you
replicate
you
know,
production
get
data
into
tests,
workloads
so
that
you
can
actually
test
against
real
data,
and
so
these
are
a
lot
of
the
things
that
we're
thinking
about
when
it
comes
to
cloud
native
storage
and
how
we're
beginning
to
expose
five
native
storage
inside
of
minetti's
on
as
net.
B
If
we
actually
do
sit
inside
the
six
storage
and
participate
in
that
sig,
with
contributions
for
things
like
snapshots
and
tying,
you
know
symbol
our
technology
into
intranet
days
to
be
able
to
you
know
basically
surface
what
we've
ended
over
the
last
20-plus
years
on.
You
know
things
like
the
implications
stuff
like
that,
so
we're
very
heavy
into
the
storage
side.
With
the
you
know,
some
of
the
other
momentum
and
we're
moving.
B
You
know
we're
tying
kind
of
tying
storage
together
with
cloud
native
app
management
security
and
then
also
we're
thinking
about
managed
data
services.
So
how
do
you?
How
do
you
quickly
get
up
and
running
with
Kafka,
you
know.
So
how
do
you
get?
How
do
you
leverage
confluence
Kafka's
operator?
How
do
you
get
that
under
management?
How
do
you
get
support
for
that,
and
then
how
do
you
just
declare
that
you
need
that
he
in
your
environment
and
that's
some
of
the
stuff
that
we've
been
working
on
as
well?
B
What
tooling
would
they
wish
to
use?
And
so
my
hope
is
that
some
of
the
demos
I
show
will
will
map
to
those
answers.
This,
like
kind
of
digs
deeper
into
defining
these,
these
personas
operators
would
have
different
titles.
You
know
these
are
people
who
could
happy
an
IT
manager.
They
can
be
a
system
admin.
You
know
the
new
kind
of
s
Ari's
a
new
new
term
coming
out.
Not
all
enterprises
are
aware
of
what
it
s.
Re
is
I.
B
Think
it's
very
important
as
cloud
native
proponents
that
we
are
that
we
we
break
out
of
a
myopic
view
of
the
cloud
native
space
right
now
and
understand
that
most
of
the
enterprise
world
we're
talking
these
white
g100
size,
customers
most
these
customers
don't
really
understand
some
of
these
new
roles.
They
don't
know
what
an
SRE
is
they
don't
some
of
them
do
some
of
them.
B
Don't
some
of
them
are
very
early
in
their
cloud
native
journey
to
the
point
where
they're
just
beginning
to
containerize
some
are
very
very
far
along
in
their
journey,
but
the
antenna,
the
operator
role
persona
is
you
know,
people
who
are
managing
this
cloud
native
infrastructure
who
have
to
maintain
it
on
day
2.
You
know
who
have
to
you
know
manage
the
resources
that
their
developers
are
consuming.
Then,
on
the
flip
side,
we
do
have
the
developers-
and
these
are
you-
know
individual
contributors
inside
the
company.
B
They
have
different
titles,
like
software
engineer
or
software
developer
developer.
Some
people
call
these
guy
will
assign
a
DevOps
lead
role
to
them
if,
if
your
shop
goes
down
the
path
of
having
titles
for
DevOps,
so
we
do
see
a
lot
of
this
type
of
these
types
of
personas
in
the
markets
and
kind
of
just
going
back
to
the
myopic
idea.
I
think
there's
this
intent
inside
a
cloud
native
that
we
want
to
solve
all
these
problems
for
users
and
we
want
to
have
users
begin
to
build.
B
You
know
all
your
apps
need
to
be
Greenfield.
All
your
apps
need
to
be
micro
services
and
you
need
to
consume
and
be
monitoring
things
with
Prometheus,
so
you
need
to
use
elasticsearch,
Lindy
Cabana
and
when
you
sit
down
with
large
organizations-
and
you
say
that
to
them
they
have
may
have
220
and
3,000
applications
that
are
already
running,
and
so
the
journey
is
not
easy
for
organizations
adopting
this
technology
and
the
journey
isn't
it
doesn't
have
minimal
toriel
at
the
moment.
So
what
we're
trying
to
do
with
that?
Apps
tooling,
is
I.
B
Try
to
get
you
quickly
to
minimal
toil
so
that
you
don't
have
to
worry
about.
Most
of
that
trail
map
that
that
chrome
app
is
done
for
you
effectively.
So
this
leads
me
into
the
client
of
cloud
native
anywhere
concept,
which
is
you
should
be
able
to
have
your
your
infrastructure
should
be
able
to
be
maintained
and
managed
regardless
any
where
it's
at.
So
your
experience
should
always
be
the
same
of
managing
kubernetes
on,
say.
B
What
I'm
starting
to
see
is.
Customers
have
multiple
accounts
with
multiple
providers,
and
then
they
have
failed
over
at
those
providers
or
they
have
some
of
their
services
to
play
on
accident
some
of
their
services
to
play
it
on.
Why
and
that's
where
we're
seeing
kind
of
starting
to
seem
multi-cloud
go,
but
the
incarnated
sheep.
You
should
be
able
to
manage
that
environment
the
identical
way,
regardless
of
where
it's
running.
B
B
The
namespaces
across
multiple
clusters
and
I
need
an
easy
way
of
doing
that.
An
easy
way
of
visualizing
that
lastly,
I
need
to
be
able
to
scale
in
the
same
way
either
on
Primmer
off
prim.
So
how
do
I
do
audit?
You
know
automatic
node
cluster
node
scaling,
you
know
how
do
we
accomplish?
You
know
H
a
on
premise
off
firmus
things
like
that.
B
So
what
do
we
mean
in
context
of
NetApp,
when
we
start
to
talk
about
that?
So
within
our
tooling?
What
we
mean
is
support
between
Microsoft,
Google
and
Amazon
and
then
on-premise
for
things
like
HCI,
generalized,
VMware
and
FlexPod,
and
then
we
also
when
we,
when
I've,
been
talking
about
day
one
day,
two
type
of
operations
and
day
zero
operations.
One
thing
that
I've
started
running
into
is
people
tend
to
start
to
argue
about
like
what
happens
on
it.
B
You
know,
like
kind
of
like
there's
some
gray
area
with
some
some
end
users,
so
I've
been
started
to
find
this.
It's
just
any
day
tops,
as
in
your
tooling
needs
to
be
able
to
support
you
not
on
just
standing
up
the
cluster,
but
you
need
to
be
able
to
do
ongoing
management
of
that
cluster.
You
need
to
be
able
to
visualize
workload
in
that
cluster.
You
need
you,
village
of
visualize
load
logs
things
like
that.
B
You
need
be
able
to
upgrade
that
cluster
and
you'd
be
able
to
rotate
the
certificates
in
the
cluster
and-
and
you
also
should
be
able
to
manage
things
like
Prometheus.
On
top
of
that,
you
should
be
able
manage
service
national.
On
top
of
that,
so
I
try
not
to
parse
day
one
day
to
day
zero
type
of
conversation
and
I
just
call
it
all
any
day
tops.
B
You
also
should
be
able
to
manage
service
mesh
easily
developers
shouldn't
need
to
learn
how
to
write
a
traffic
management
rule,
so
the
intent
with
tooling
is.
It
should
make
it
so
easy
that
a
developer
can
easily
just
pick
up
the
tool
and
create
a
canary,
and
you
know
just
say:
I
have
a
and
service
B
and
I
want
to
run
a
canary
with
service.
B
and
I
went
to
pass
one
percent
of
my
breast
traffic.
B
It's
you
that
canary
mom,
where
I
wished
you
blue,
green
or
I'm
gonna,
do
an
a/b
and
the
intent
of
the
the
type
of
cooling
that
we've
been
building
is
to
remove
the
need
for
that
type
in
all
from
the
developer,
so
that
they
just
say
give
me
a
canary
and
then
the
system
manages
the
rules
for
them
behind
the
scenes.
You
also
need,
tooling.
That
makes
it
easier
to
manage
our
back.
It's
a
rule-based
controls
for
users
and
teams,
tooling.
B
That
ties
together,
GPU
support
with
you,
know,
regular
CPU
instances
and
then
twing
that
takes
you
from
being
able
to
scale
from
the
POC
to
a
high
availability
cluster.
So
you
know
some
tools
out
there
you
know
are
great,
for
you
know
just
quickly
standing
up
cluster
if
you
start
to
play
with
it,
but
if
you
need
to
begin
be
able
to
do
ongoing
management
of,
say,
X,
CD
or
the
Masters,
then
that
it
starts
to
fall
apart,
and
so
the
intent
is
to
create
tooling.
B
That
allows
you
to
easily
do
all
that
easily
go
from
you
know
and
I
have
a
test
cluster,
but
I.
You
know
maybe
I
want
to
scale
that
out
to
production
cluster
and
then,
lastly,
things
like
private
topology,
which
is
the
idea
that
there's
in
a
public
cloud
setup
that
you
don't
have
anything
like
a
public
IP
attached
to
any
of
those
nodes
that
you're
coming
in
through
a
bastion
host,
and
that
should
always
you
know.
Our
belief
is
that
you
know
all
clusters
should
be
built
as
private
apologies
that
you
shouldn't.
B
Have
you
know
public
inbound
access
directly
to
that
cluster?
Unless
that's
exposed
load
balancer,
you
know,
then
we
get
weird
problems
like
developers
declaring
a
load
balancer
without
the
IT
team
under
knowing
that
that's
happening,
and
then
you
can
actually
expose
a
security
issue
by
that
by
doing
that,
so
we
try
to
look
for
things
like
that
in
our
solution.
B
B
People
may
recognize
this
as
the
old
stack
point
ioq
tool,
it's
the
same
thing
just
renamed,
but
what
we're
trying
to
do
is
we're
trying
to
create
an
easy
way
to
basically
get
clustering
from
infrastructure
up
and
running
or
be
able
to
do
day,
two
type
operations,
and
so
here
I've
got
a
list
view
of
you
know:
clusters
running
on
each
cloud
providers
I
can
dig
in
and
I
can
actually
manage
them
if
I
wanted
to
I
can
see
liveness
probes.
So
these
all
the
green
dots
indicate
that
those
nodes
are
online.
B
B
The
idea
is
that
you
can
also
come
in
here
and
do
a
quick
upgrades
so
that
we're
making
you
so
you
don't
need
to
worry
about
cleese
or
command-line
tools.
We
don't
you
know
this.
Isn't
you
know
you
we're
not
replacing
cube
cuddle
crew
cuddle
works.
Fine
with
with
you
know
these
clusters.
These
are
all
upstream
clusters.
We
don't
we're,
not
a
fork,
we're
not
doing
anything
like
that,
but
an
upgrade
is
just
as
simple
as
choosing
you
know.
I
want
to
move
up
to
1.15
three
with
this
cluster
and
then
it
does.
B
It
basically
performs
an
in-place
upgrade.
We
try
to
make
it.
You
know
we
try
to
do
things
where
we're
saying
hey,
you
can
still
use.
You
know,
tooling,
that
comes
with
the
project,
and
so
we
want
to
be
able
to
say
hey,
you
can
use
the
command
X
dash
board,
but
we
don't
want
to
expose
that
dashboards.
You,
the
public
internet.
So
what
we
do
is
we
kind
of
let
it
through
our
our
tooling
so
that
you
can
just
you
know,
get
access
to
it.
B
But
what
we're
trying
to
say
was
we're
going
to
say
we
don't
really.
You
know
we
try
not
to
create
a
fork
of
these
clusters,
so
they
have
a
unique
way
of
managing
it.
If
you're
a
net
op
customer,
we
don't
want
you
just
to
be
a
net
app
customer.
We
want
to
be
a
kubernetes
user.
The
end
goal
is
that
we
want
to
make
it
easy
for
you
to
manage
Trinette
ease.
B
You
know
you
don't
have
the
purchase,
storage
or
anything
like
that
from
that
to
do
this.
This
is
the
wizard
that
makes
it
easy.
You
know,
there's
a
three-step
wizard
allows
you
to
create
a
cluster.
We,
you
know,
you
just
basically
walk
through
the
wizard
and
at
the
end
of
it
we
ask
you
one
more
question
of.
If
you
want
to
you
know,
do
you
want
to
make
any
changes
of
this?
If
not,
once
you
click
Submit,
it
begins
to
build
a
building
cluster.
B
On
premise,
the
VMware
experience
that
we
have
is
also
identical
to
to
our
our
pub
the
public
cloud
experience.
So
this
is
where
we're
trying
to
say
we,
we
believe
in
harmony
of
managing
cloud
infrastructure,
regardless
of
where
that's
running,
and
so
the
idea
with
the
tooling
also
is
to
walk
through
through
three
step
process,
and
you
have
a
cluster
running
on
your
VMware
environment.
B
If
you
have
a
FlexPod
environment,
three
step
process,
and
now
you
have
flex
pot
cluster
running
on
top
of
FlexPod
environments,
you
can
also
have
an
Amazon
cluster
running
alongside
that
as
well.
So
that's
the
the
quick
demo
of
the
question
infrastructure
side
of
this,
and
but
what
about
our
developers
so
that
whole
scenario
was,
you
know,
I'm,
a
ite
operator,
type
of
person,
I
needed,
create
infrastructure,
I
need
to
manage
infrastructure,
but
now
in
the
developer-
and
you
know
with
you
know
what
I
want
to
be
able
to
do
so.
B
I
want
to
be
able
to
push
code
and
I
want
to
be
able
to.
You
know:
I
just
wanted
to
do
a
git
commit
and
then
now
my
my
applications
up
and
running
inside
of
kubernetes.
So
in
this
next,
let
me
talk
through
what
we
mean
when
we
start
to
talk
about
cloud
native
app
management.
So
what
we
think
is
it
should
be
get
based
app
deployment
model
so
that,
and
it
should
be
able
to
support.
You
should
go
to
use
this
knowing
to
run
against
both
on-premise
clusters
and
off-premise
clusters,
so
public
cloud
clusters.
B
It
should
be
all
built
on
top
of
open
source
tooling.
So
we
we
implement
our
own
set
of
controllers
and
see.
Are
these
on
top
of
things
like
katana
and
Kenny
is
just
to
let
everybody
know
and
but
like
at
no
point,
do
we
want
to
build
custom,
tooling
cup,
of
custom
components
that
make
all
this
possible?
What
we're
trying
to
say
is
we're
gluing
it
all
together.
We're
composing
that
entire
cloud
native
Road
trail
map
for
you,
so
that
you
don't
actually
have
to
think
through
that
trail
map.
B
B
We
provide
tooling
that
allows
you
to
set
resource
quotas
and
limits
on
that
project,
so
that
you
know
whatever
users
are
deploying
into
that
project
are
capped
and
we
allow
you
to
times
of
users
to
that
project
and
then
flow
that
team
down
to
kubernetes
are
back
so
that
that
team
could
subsequently
log
in
and
pull
down.
If
you
can
config
file
to
attach
that
namespace,
you
know.
We
also
believe
in
this
idea
that
you
have
a
choose-your-own-adventure
with
how
you
want
to
deploy
workload
into
interview.
The
cluster.
B
You
know,
there's
the
standard
to
cuddle
could
cuddle
apply
my
Amal
to
my
running
environment,
cool
I.
Have
it
all
online
or
I'm,
using
helm
to
do
a
helm,
install
the
helm
charts
into
my
environment,
where
I'm
I
want
to
be
able
to
do
it,
get
commits
and
then
see
my
application
come
up
inside
the
environment
or
I'm
gonna.
Do
a
git
commit
on
a
change
and
see
that
change
come
online
in
the
environment.
I
want
to
be
able
to
lifecycle
this
application,
so
I
should
be
able
to
upgrade
this.
B
You
know
I
should
be
able
to
see
metrics
attached
to
this
application,
so
I
should
have
service
dashboards.
I
should
go
see
logs
if
I'm
outputting
logs
to
standard
out
I
should
be
able
to
see
that,
and
the
other
idea
is
that
we
want
to
make
it
easy
for
as
easy
as
a
developer
when
they
were
working
with
her
Roku.
That
kubernetes
becomes
that
simple
to
work
with
asset
developers.
Is
it's
a
it's
a
Heroku
like
experience,
but
a
little
bit
further
than
we're
karoku
left
off.
You
know
also.
B
We
want
to
make
sure
that
IT
teams
can
manage
the
auto
scaling
for
applications
their
developers
pushing
into
without
the
developers
having
to
worry
about
those
those
management
settings.
So
we're
gonna
see
so
I'm
going
to
show
you
the
concept
of
projects,
the
solutions
that
we
place
into
those
projects
and
the
kind
of
the
dashboards
for
things
like
metrics
and
then
I'm
gonna
do
a
demo
of
delivering
a
surrogate.
So
a
project
is
basically
a
buckets.
It's
a
namespace.
Our
thinking
is
that
you're
gonna
be
working
a
single
project.
B
You
know
that
would
be
an
application.
So
this
is
the
taxonomy
here
for
an
app
WordPress
is
the
example
I've
been
using
to
describe
you
know.
Wordpress
has
multiple
components
to
an
end-user.
Wordpress
is
the
application,
but
behind
the
scenes
you
have
Mike
my
sequel,
you
have
a
front-end
and
you
maybe
have
some
other
components,
but
the
idea
is
that
project
would
contain
all
that.
B
B
The
concept
here
is
the
tooling
allows
you
to
deploy
a
solution
into
your
kubernetes
cluster
in
three
different
ways:
tracker
being
how
we
support,
you
know,
bring
your
own
tooling,
so,
like
coo,
cuddle,
get
work
flow,
which
is
how
do
you
you
know,
do
continue
to
use,
get
to
manage
your
workload
and
then
a
way
of
deploying
helm,
Tarson
to
environment,
and
we
actually
never
required
tiller.
I,
and
with
with
this
solution,
we
were
out,
we
replaced
tiller.
B
Do
a
quick
demo
of
this
piece
here
so
so
here
I
have
a
going
kind
of
going
back
to
the
idea
of
simplicity,
we're
trying
to
probably
provide
with
this
tooling
just
a
simple
dashboards.
For
you
just
see
what
is
the
health
of
my
clusters
where
there
are
the
health
ways,
the
health
of
my
projects
and
where
some
average,
you
know
metrics
coming
off
these
things.
B
You
know
so,
like
my
average
CPU
and
my
average
memory
across
all
my
clusters,
and
so
this
is
all
real
time,
and
so
we're
saying
you
know
two
projects
and
all
the
objects
inside
of
those
namespaces
are
online.
You
know
we
allow
you
to
dig
deeper
into
this
and
start
to
kind
of
break
them
down
and
say
I
want.
You
know.
I
can
start
to
see.
B
What
solution
should
we
have
deployed
inside
of
this
environment
on
and
then
I
just
quickly
highlight
how
those
three
components
I
was
talking
about
work.
We've
made
it
simple
or
simple:
to
use
the
tools
to
take
advantage
of
those
components.
So
tracker
again
is
something
if
I'm
going
to
apply
put
my
own
workload
into
the
environment.
I
could
come
into
this
piece
of
the
toiling
and
add,
say
I'm
running
this:
is
the
label
I'm
using
I'm
using
you
know
app
test?
B
Is
my
label
so
go
ahead
and
when
I
create
this
tracker,
then
our
controllers
will
watch
for
your.
So
your
applicator,
your
solution
in
the
environment
and
they'll,
pull
it
all
together
inside
of
this
view,
so
that
when
you
come
back
into
the
app
you'd
actually
be
able
to
see
metrics
and
logs
for
that
yamo
that
you
deployed
on
to
the
environment.
B
The
other
idea
is,
you
know,
very
simple,
like
marketplaces,
here's
I'm
just
showing
the
dena
me
marketplace
where
you
know
we
have
the
capacity
to
ingest,
helm,
repos,
either
from
public
or
private
repositories,
and
this
is
actually
I've
set
it
up
to
just
ingest
the
bitNami
market.
Bitnami
chart
marketplace
into
my
private
accounts
so
that
I
have
a
private
marketplace.
B
As
my
user
logged
into
into
this
into
this
system
versus
other
users,
we
also
provide
things
like
trusted,
charts
that
we've
gone
through
and
verified,
and
so
this
is
one
way
you
know
you
deploy
these
into
the
environment
and
it
you
would
also
again
see
kind
of
metrics,
dashboard
and
logging
dashboards
for
that.
I
have
Redis
deployed
right
here.
The
last
way
of
doing
this
is
what
we
call
a
git
workflow,
which
is
you
know
what
I'm
doing
here
is
I'm
an
IT
manager
and
I
want
to
create
a
custom
application.
B
B
Forget
I
want
to
make
sure
that
there's
always
you
know
five
replicas
for
them
and
they
can
max
to
15
and
we're
gonna
go
ahead
and
trigger
on
70%
CP
utilization
when,
when
I
create
this
application,
this
is
going
to
create
just
a
very
small
number
of
objects
inside
of
the
Cooper
inside
of
the
Cooper
nice
cluster,
and
then
what
we
have
a
controller
that's
going
to
watch
for
when
you
do
the
first
gift
push
and
then
once
that
happens,
we
build
a
deployment
around
the
container.
That
was
so.
B
So
I
already
have
that
deployed
right
here
and
the
other
thing
that
we
do
is
we
give
you
kind
of
a
quick
dashboard,
I,
sorry,
not
a
dashboard,
but
a
vanity
URL
that
you
can
check
so
that
when
you
make
a
change,
you
could
go
ahead
and
say
cool.
This
is
what
my
my
app
looks
like
so
I
have
a
hold
on
me.
I'm,
going
to
just
go,
make
a
quick
change
and.
B
B
So
you
know
when
I
do
it
get
commit
and
that
containers
has
to
be
built.
I
want
to
be
able
to
target
my
Harbor
registry
inside
of
my
service
cluster,
for
it
to
be
stored.
There
I
want
to
be
able
to
use
things
like
Angkor
to
lockdown
policy
and
a
lock
down
those
containers
inside
of
harbor,
so
that
when
a
CBE
you
know
there's
a
CV
that
is
reported
for
one
of
the
containers
that
there's
a
policy
that
does
not
allow
that
container
to
be
pulled
out
into
to
runtime,
and
so
we
do
have
Tulane.
B
A
B
B
Okay,
so
one
of
the
questions
was
about
downgrades
of
kubernetes
clusters
and
we
don't
so
we
don't
currently
account
for
that
on.
You
know
we've
so
our
history
with
upgrades,
so
we've
been
supporting
companies
upgrades
since
1.1.11
and
so
for
us.
It's
been
difficult
to
kind
of
support
downgrade
now
that
we
move
moving
into
more
of
a
standardized
way
of
doing.
Cluster
builds
Kubb
ADM.
This
is
what
we
would
use
beyond
the
scenes
on.
We
would
look
at
you.
Don't
support
that,
but,
right
now
we
don't.
A
Yeah,
and
actually
one
of
the
things
I'll
add
to
that
is
one
of
things
we
have
going
on
in
the
kubernetes
community
is
that
currently
nobody
is
maintaining
the
end-to-end
tests
for
downgrade.
So
officially
is
a
Bearnaise
project.
We
don't
have
any
official
support
for
downgrading
and,
if
that's
a
use
case
that
matters
to
you,
you
might
want
to
think
about
having
some
of
your
QE
engineers
contribute
to
the
project
so
that
it's
something
that
we
can
actually
test
at
the
upstream
levels.
B
Yeah
I
think
what
the
pattern
that
we're
seeing
is
that
customers
like
a
lot
of
enterprise
lot.
Larger
customers
are
starting
and
just
run
one
or
two
versions
behind
on
kubernetes
versus
you
know,
jumping
into
the
new
version
each
time
in
ships
and
I.
Think
that's
gonna
become
a
more
of
a
persistent
story.
That's
we're.
Gonna
have
most
most
enterprises,
gonna
run
at
a
version
or
two
behinds.
Okay,.
A
B
A
Okay,
so
Howard,
if
you
can
actually
retype
your
question
in
the
Q&A
panel,
we'll
pick
it
up
in
a
minute.
In
the
meantime,
let's
go
on
to
Dennis's
question
I
know
that
was
Dennis.
What's
the
downgrade
there's
a
second
question,
which
is
the
UI
tool
and
everything
you
just
demonstrated:
is
this
open
source
so.
B
Some
of
our
components
are
open
source
and
some
of
our
just
free
use,
so
you
can
just
go
and
login
and
trial
the
UI
tooling
itself,
and
then
we
have
other
open
source
components
as
well
that
we
have
on
our
github
repo
okay,
like
like,
if
you're
interested
in
some
of
the
storage
work,
that
we're
doing
behind
the
scenes
in
that
tool.
That's
an
open
source
project,
that's
called
trident
and
that's
basically
how
we're
solving
storage
inside
for
the
nineties,
okay,.
A
A
B
With
the
commercial
version
a
net
app
is
selling
I.
Guess
we
we're
selling
on
enterprise
support
with
that,
so
it's
bundled
in
with
the
commercial
version.
So
there's
you
don't
have
to.
Basically
with
the
commercial
version
you
don't
have
to
pay
for
support.
You
get
the
same
level
of
support
that
NetApp's
provided
to
its
storage
customers.
A
A
B
So
Federation's
a
touchy
topic,
as
you
can
imagine,
in
the
space
we
re.
Originally,
we
supported
Federation
v1
and
we
worked
with
Google
actually
to
enable
to
ensure
that
support,
but
because
v1
is
now
kind
of
into
life
and
v2
is
kind
of
kind
of
a
shitshow.
At
the
moment
we
are
kind
of
taking
the
approach
of
writing
our
some
of
our
own
IP
and
leveraging
sto
as
well.
It's
kind
of
coupling
our
own
IP
that
we're
combining
with
this
do
and
then
propose
ascending
proposals
up
to
this
do
community
on
things
like
CP.
B
So
how
do
we,
you
know
so
with
our?
How
we
federated
clusters
now
is
using
some
IP
that
we
wrote
that
were
that
we
just
sent
upstream,
which
is
how
do
you
connect
to
this?
Do
service
messages
together
and
then
how
you
route
traffic
between
those
two?
So
that's
how
we're
doing
it
is
I
would
say.
Tl
DR
have
a
bit
of
custom
IP
combined
with
this
do,
but
all
that
custom
IP
is
open
sourced.
A
Okay,
so
one
question
I
asked:
if
you
have
plans
to
work
with
IBM
and
Red
Hat
I
mean
I
would
say
actually
working
with
red
hat,
but
the
because
we've
collaborated
with
you
guys
and
stuff.
The
the
the
question
I
guess
would
be
on
what
particular,
because
we
all
collaborate.
A
lot
on
this
do
I
know
I.
B
Where
we're
looking
at
our
collaboration
inside
of
the
ISTE
o
world
is
MCP
well,
the
cluster
the
multi
cluster
protocol
is
what
we're
focused
and
look
with
broadly
with
IBM,
though
we're
also
talking
about
you
know,
support
IBM
cloud
but
I
know
with
Red
Hat.
We
do
a
lot
of
different
work
with
Red
Hat's,
so
it
depends
on
the
area
of
Red,
Hat
yeah.
A
B
Know
I
think
it
one.
It
depends
on
where
what
your
area
of
expertise,
area
of
expertise,
if
it's
just
about
I,
want
to
learn
how
to
deploy
and
run
microservices
on
top
of
kubernetes
because
I
one
of
them
down
in
this
whole.
How
do
I
refactor
my
application
to
run
in
this
world?
I?
Don't
want
to
be
probably
an
IT
manager
of
this
platform,
so
I
would
use
a
tool
like
ours.
I
would
use
you
know
gke.
B
Maybe
you
know
like
ask
Google
for
a
two
hundred
dollar
gift
card
gift
card,
$200
credit
and
they'll,
give
you
one
and
they
just
enough
gke
and
then
play
around
with
a
you-
know,
workload
their
you
can
plug
that
into
ours
as
well.
You
know
and
then
like
with
ours,
you'd
be
able
to
play
with
more
than
just
kubernetes
you'd,
be
able
to
use
ISTE,
oh
and
get
experience
with
things
like
prometheus
and
all
that
other
stuff.
B
But
if
you
want
strictly
kubernetes,
I
feel
like
Google
with
gke
and
they're
$200
credits
might
be
a
quick
way
for
a
nudey
to
get
going
without
having
to
spend
any
money.
Outside
of
that,
you
know,
you're
gonna,
be
speaking
a
bit
of
money,
not
a
lot
of
money,
but
a
POC
cluster
would
cost
you
something
all
the
providers.
Okay,
if
you
wanted
to
go
the
hard
route
we
I
would
all
you
know
persistently,
recommend
the
Kelsey
Hightower
talk
again.
Yeah.
A
B
A
lot
of
thoughts
around
helm,
so
we
we
are
where
we
took
our
tooling,
is
where
home
went
with
300.
So
our
where
our
pain
is
going
to
come
in
as
we're
gonna
have
to
refactor
some
of
the
tooling
to
account
for
helm
3.0,
because
we
were
dealing
with
helmet
2.0
and
we
actually
replaced
the
need
for
tiller
in
the
environment
on
2.0.
B
I
would
say
that
would
be
the
biggest
thing
with
3.0
is
the
removal
three
dotto,
but,
as
a
you
know,
as
a
packaging
format
in
general,
I
think
it
can
still
stand
some
work
but
we're
a
weight
attendant
where
I
helped
some
at
this
insight
in
a
few
weeks
you
know
so
we're
attending.
You
know
I'm
trying
to
participate
there
as
well.
Yep.
A
The
okay,
well!
Thank
you
very
much
for
a
terrific
presentation
per
the
chat.
The
recording
the
webinar
and
the
slides
will
be
posted
shortly
in
the
CN
CF
events
page
on
the
webinars
page.
So
if
you
can
review
any
material,
if
you
missed
something
as
part
of
this
presentation
and
once
again
thank
you
Matt
for
sharing
and
demonstrating
that
with
us,
you're.