►
From YouTube: Kubernetes as Control Plane for Hybrid Cloud Clayton Coleman Red Hat OpenShift Common Gathering 2021
Description
OpenShift Commons Gathering 2021
Upstream Keynote: Kubernetes as the Control Plane for the Hybrid Cloud
Guest Speaker: Clayton Coleman (Red Hat)
https://commons.openshift.org/index.html#join
A
So
good
morning,
everyone
thank
you
for
being
brave
enough,
encourage
yourself
and
feeling
safe
enough,
hopefully
to
show
up
in
person.
This
is
my
first
conference
since
the
world
changed,
and
so
I'm
actually
pretty
excited,
although
I
suspect
it's
going
to
take
us
a
while
to
feel
like
this
is
totally
normal.
So
I
appreciate
you
showing
up
today
and
hopefully
what
I'll
talk
about
is
something
that
you
could
have
found
any
other
way,
but
you
know
being
an
openshift
commons
being
at
kubecon.
A
This
is
an
important
time
for
us
because
we're
starting
to
think
about
you
know
what
comes
next,
like
as
as
architecture,
red
hat.
I've
been
involved
in
openshift
since
the
very
beginning
and
I've
been
with
kubernetes
since
the
beginning
of
that
project,
we've
learned
and
achieved
a
huge
amount.
You
know
karina
was
working
through
all
of
the
you
know,
things
that
have
come
at
open
shift
after
20
releases
of
open
shift.
Three
and
four,
I
guess
adding
together
20
releases
of
kubernetes
21.
I
don't
know.
A
A
A
So
the
talk
is
kubernetes
as
the
control
plane
for
the
hybrid
cloud.
If
you
attended
kubecon
virtually
in
may
joe
fernandez,
and
I
gave
a
little
bit
of
a
teaser
for
this-
and
I
also
gave
a
keynote
where
I
talked
about
some
of
the
ideas
that
lead
into
this.
But
now
that
we've
had
an
extra
three
or
four
months
to
work
through
those.
A
I
want
to
talk
a
little
bit
about
the
broader
context
and
try
to
tie
it
together
for
you
in
a
way
that,
even
though
this
is
still
very
early
for
us
thinking
about
what
comes
next
is
an
important
part
of
my
job,
and
so
I'd
like
to
share
it
with
you.
So
there's
a
bunch
of
problems
that
we
all
face
and
there's
problems
that
we
can
face,
that
we
can
fix
by
adding
something
the
additive
approach
to
adding
a
feature
or
adding
a
new
component
to
open
shift
or
adding
a
new
technology.
A
There's
a
lot
of
commonalities
between
these
open
source
drove
every
single
one
of
these
or
as
a
fundamental
part
about
how
we
reach
it.
Most
of
these
are
key
parts
of
our
lives
today.
Obviously,
if
you're
here
at
kubecon,
I
hope
kubernetes
is
a
key
part
of
your
life,
but
the
common
factor
that
I
think
I
wanted
to
reinforce
is
all
of
these.
A
A
Have
we
been
successful
at
kubernetes,
so
this
is,
if
you're
not
familiar
with
it,
this
is
the
cncf
landscape
chart.
I
had
to
shrink
it
to
make
it
show
up
on
one
page,
there's
point
we
all
make
plenty
of
we
get.
We
get
laughs
about
how
complex
this
diagram
is,
but
one
way
that
I
like
to
prefer
to
look
at
this
is
these
are
solutions
to
real
problems.
A
We
may
not
all
agree
on
which
the
actual
fix
should
be.
We
might
say,
oh
no,
no,
no,
that
that
technology
is
not
for
me,
I'm
much
more
interested
in
this
other
technology,
but
some
of
us
all
of
us
have
contributed
to
the
breadth
of
this
ecosystem
and
every
one
of
these
technologies
or
tools
or
certified
platforms
or
service
is
something
that
helps
us,
build
and
run
applications,
and
all
of
these
are
possible
because
of
the
layers
below
us
we're
able
to
deal
with
more
we're
able
to
solve
more
problems.
A
You
know
a
great
example
which
you
can
just
barely
see,
because
again
this
is
almost
too
big
to
fit
on
a
even
a
high
resolution.
Laptop
observability
observability
has
been
a
huge
open
source
transformation
in
the
last
five
to
ten
years.
There
were
capabilities
before
that
that
made
observability
easy.
A
That's
something
that
we're
still
coming
to
terms
with
that
problem
is
a
consequence
of
how
successful
we
have
been
at
building
and
running
more
and
so,
ultimately,
every
time
we
go
up
a
level
of
abstraction,
we're,
adding
more
we're
adding
more
things
to
deal
with.
We
have
more
technologies,
we
need
to
understand
or
integrate,
and
so
I
like
to
think
that
a
part
of
my
job-
and
I
think
I
suspect,
a
lot
of
the
folks
in
this
room's
job.
A
A
Another
way
of
describing
hybrid
cloud
is
hybrid
cloud
is
the
problem
which
is
there's
too
much
of
everything.
How
do
we
bring
it
together
in
a
way
that
makes
sense
that,
what's
the
simplifying
assumption?
What's
the
simplifying
abstraction
that
takes
everything
on
that
cncf
landscape
chart
boils
it
down
to
something
that
we
can
all
appreciate
and
address
without
worrying
too
much
about
all
of
the
details
all
at
once.
A
So
if
that's
the
problem,
how
does
it
connect
to
our
day-to-day?
So
I
talked
to
customers
and
community
members
to
partners
to
technologists
to
individuals.
I
listen
to
what
the
product
organization
hears
from
customers.
I
listen
to
what
customers
say
about
the
product
organization's
priorities
and
I
look
at
the
places
where
what
we're
trying
to
do
is
move
above
kubernetes
we're
all
above
kubernetes.
You
know
karina
in
the
in
that
very
first
section.
We
talked
about
the
breadth
of
the
things
that
exist
above
kubernetes
and
that
basically
boils
down.
I
think,
to
three
questions.
A
It
might
be
questions
like
how
do
I
go
beyond
the
limits
of
a
region?
We're
just
you
know.
Kubernetes
fundamentally,
is
a
technology,
that's
designed
to
solve
a
simple
problem,
a
close
co-located
set
of
computers,
running
software
in
a
manner
that
hides
the
details
of
those
individual
machines,
but
it
doesn't
give
you
a
solution
for
what
happens
when
you
want
to
run
an
application
across
seven
geographies
at
once.
What
happens
when
your
workload
follows
the
sun?
What
happens
when
your
workload
has
to
deal
with
a
large
failure?
A
And
so
these
are
questions
that
we
all
answer
and
we're
all
coming
up
with
approaches.
The
second
question:
how
do
you
integrate
you
integrate
more?
Obviously,
the
cloud
native
landscape
was
about
new
technologies,
but
there's
also
services.
Whether
those
are
the
you
know.
We
think
about
one
of
the
biggest
transformations
in
the
last
10
years
as
well
has
been
delegating
to
others
to
do
things
on
our
behalf
through
an
api
infrastructure
is
code.
Api
is
our
infrastructure
as
api
asking
someone
to
take
on
a
portion
of
the
problem
to
give
them
that
responsibility.
A
So
you
don't
have
to
worry
about
it.
So
you
can
accomplish
more,
and
so
there
are
more
services
than
ever
before
that
we
integrate,
where
someone's
taking
on
the
responsibility
for
keeping
that
running
it's
our
problem.
We
do
this
internally,
we
do
this
within
organizations.
Vendors
increasingly
form
are
moving
from
package
software
to
managed
services.
This
translation,
this
transition
will
only
accelerate
because
again,
another
way
to
deal
with
complexity
at
scale
is
to
put
the
problem
in
a
box
and
talk
about
it
from
the
outside.
A
A
So
the
solutions
for
these
problems
are
out
there.
Openshift,
as
part
of
our
ecosystem,
focuses
on
things
that
we
can
stand
behind,
but
we
can't
stand
behind
everything.
There's
a
huge
ecosystem
of
partners
and
vendors
here
at
kubecon
today,
who
track
and
solve
problems
open
source
communities
are
even
larger
than
that
people
scratching
taking
a
problem
that
they
know
how
to
solve
and
solving
it
in
a
way
that
others
can
consume.
A
In
fact,
the
set
of
patterns
that
we
use
nothing
is
wrong
with
the
approach
that
we've
taken,
which
is
we
all
solve
our
individual
problems
and,
at
some
point
all
of
us
end
up
solving
very
similar
problems.
We
talk
about
ci,
cd,
continuous
integration
and
continuous
deployment.
We
talk
about
doing
that
across
clusters.
We
might
bring
abstractions
in
like
service
mesh,
which
has
been
one
of
the
hottest.
You
know.
Hot
topics
observability
allows
us
there's
disagreements
about
how
we
do
this
different
use
cases.
A
It
applies
to
my
problem,
or
maybe
I
can't
approach
it
or
maybe
I
don't
even
know
about
it,
about
the
fact
that
someone
else
solved
the
same
problem
as
me
and
so
open
source.
Is
I
like
to
think
of
it
as
a
bit
of
a
relentless
wave?
We
all
batter
bash
our
heads
into
the
wall
and
write
some
code
and
share
it
with
the
world.
We
move
a
little
bit
forward.
We
try
all
the
paths
and
occasionally
you
know
some
smart
person
somewhere
will
they'll
get
ahead
of
everybody
else
to
be
like
ci
cd.
A
This
is
brilliant
I'll,
start
a
lecture
circuit
and
make
lots
of
money
on
sharing
my
knowledge
with
others.
I
would
be
a
private
vendor
who
gets
a
great
idea,
but
that's
just
one
smart
person
or
10
smart
people
or
100
smart
people
for
every
one
of
those
people.
There
are
a
thousand
others
who
are
also
smart
and
also
solving
that
problem.
They
just
don't
necessarily
have
the
time
to
focus
on
that.
A
So
as
a
group
both
here
in
this
room
in
the
openshift
community
and
in
kubecon,
we're
always
working
on
common
problems
and
trying
to
move
them
forward,
and
we've
been
doing
this
long
enough
and
the
cncf
charts.
I
think
cloud
native
in
general
kind
of
speaks.
That
is,
we
can
start
to
ask
what
are
those
common
problems
that
all
of
us
are
trying
to
solve
that
if
we
stepped
back
looked
them
at
the
same
way
and
said
you
know.
Actually
our
problems
are
the
same.
A
We
can
simplify
if
we
could
agree
that,
maybe
we
don't
get
everything
we
want
or
if
we
can
pick
90
of
the
things
that
we
all
agree
on.
We
arrange
those
together
into
something
that
streamlines,
unifies
the
lines
and
the
answer
may
be.
No,
maybe
we
have
to
wait
for
another
smart
person
to
come
up,
but
as
part
of
my
job
I
sit
and
I
sit
all
day
and
I
go.
What
are
we
all
doing?
A
That's
very,
very
similar
that
maybe
just
maybe,
if
we
bring
two
or
three
or
five
or
15
separate
problems
together,
they
actually
all
are
one
problem,
and
if
we
simplify
that
problem,
we
might
be
able
to
make
and
share
that
simplification
with
others.
Just
like
every
layer
of
the
stack
has
done
before
us
so
describing
the
problem.
We
talked
about
layers
problems
that
can't
be
solved
by
just
bi,
adding
more
so
imagine
an
abstraction,
that's
application.
Centered
kubernetes
is
application.
Centric
linux
is
application
centric.
A
A
There
has
to
be
a
payoff
for
kubernetes
to
be
worth
it
for
you
to
adopt
it.
What
is
that
payoff?
So
I
think
the
most
obvious
payoff,
but
it's
always
good.
You
know
it's
not
always
obvious
to
everyone
who's
new
to
the
ecosystem
and
after
we
work
on
kubernetes
for
a
while,
we
forget
about
it,
which
is
for
the
most
part.
A
If
we
could
share
that,
if
we
could
put
that
consistency
in
place,
we
wouldn't
ever
have
to
solve
that
problem
again.
Hopefully,
we
wouldn't
have
to
solve
that
problem
that
let
us
move
up
to
a
higher
level.
Let
us
focus
on
what
do
we
actually
need
to
do?
Well,
we
want
to
deliver.
You
know
hundreds
of
thousands
of
cloud
native
applications
we're
bringing
new
geographically
distributed
capabilities,
we're
supporting
global
services.
A
We
need
20,
24,
7
uptime.
We
need
to
be
able
to
survive
failures
of
data,
centers
regions
geographies
or
sometimes
we
just
had
tens
of
thousands
of
developers
who
increasingly
were
solving
different
problems
that
all
needed
to
come
together
and
we
just
had
to
make
sense
of
all
of
that
and
kubernetes
gave
us
a
way
of
standardizing
a
part
of
the
problem.
A
So
what
are
the
kinds
of
standardizations?
That
would
be
useful?
I
don't
have
a
complete
answer
for
this.
In
fact,
I'll
stand
up.
We
talked
about
hybrid
cloud
being
the
problem
too
much
of
everything
I'm
going
to
talk
about
one
possible
approach
that
feels
right
to
me.
Looking
at
the
problems
that
we're
all
facing
and
it
starts
incrementally,
it
has
to
build
off
what
we
do.
So
I'm
going
to
give
three
examples,
and
these
are
going
to
be
pretty
basic
examples.
You
might
say
clayton,
that's
not
obvious
at
all.
A
Go
back
to
the
drawing
board,
you
should
be
smarter
and
that's
okay
and
I'm
going
to
frame
it
as
a
constraint,
an
opportunity
or
a
superpower,
and
a
consequence
of
that
and
I'll
talk
a
little
bit
about.
You
know
how
we're
how
we're
thinking
about
this
and
how
you
can
get
involved.
So
I
think
the
the
fundamental
constraint
is
that
standing
here
is
kind
of
no
duck
kind
of
thing.
If
I
stand
here
at
kubecon-
and
I
say
hey,
we
need
to
do
something
new.
A
Go
rewrite
everything
you're
all
going
to
laugh
at
me
right
you.
In
order
to
give
that
benefit,
I
would
have
to
give
you
a
10x
improvement
in
some
area.
Right
generally,
the
rule
of
thumb
is
nobody's
going
to
change
anything.
Unless
the
benefit
is
so
obvious,
it
is
staring
you
in
the
face
and
the
bigger
the
hill.
You
have
to
climb
the
bigger
the
benefit.
So
I
definitely
know
that
in
this
room,
if
I
told
you
you
had
to
throw
away,
kubernetes
you'd
probably
be
like
we
don't
love
kubernetes.
A
You
know
like
there's
some
problems
with
it,
we're
all
totally
psyched
to
go
out
and
rebuild
everything.
We
do
that's
kind
of
an
unstarter.
So
this
is
a
very
useful
constraint
because
it
eliminates
a
huge
class
of
possible
approaches
and
it's
incremental,
which
is,
if
I
can
promise
you
that
you
can
take
most
of
your
applications
and
get
the
benefit
just
by
adding
one
thing.
I
am
adding
one
thing
to
the
ecosystem.
A
I'm
trying
to
boil
this
down
to
the
very
essence,
because
again
we
don't
know
exactly
what
the
future
looks
like,
but
one
of
the
things
that
I
like
to
think
about
is,
if
there's
one
problem,
that
everybody
in
kubernetes
agrees
with:
it's
that,
if
you
want
to
keep
something,
truly
isolated
and
truly
isolated
means
to
the
utmost
level
of
paranoia,
you
have
to
give
them
their
own
space
and
there's
a
couple
reasons
for
that.
One
actually
is
that
kubernetes
is
a
collaborative
environment.
A
If
you
don't
like
what
someone's
doing
on
the
cluster,
you
can
catch
it
using
acs
or
other
technologies
and
that's
a
part
of
the
price
we
pay,
because
we
brought
together
the
problem
and
standardized
it.
So
I'm
going
to
start
by
saying
if
we
could
tease
apart
different
teams,
but
the
problem
is:
is
that
if
you
give
every
team
a
cluster,
you
just
end
up
with
too
many
clusters?
That's
not
what
kubernetes
was
about.
Kubernetes
was
not
about
running
tens
of
thousands
of
clusters.
A
A
A
This
comes
with
a
whole
host
of
of
abstraction
challenges.
We've
actually
many
people
in
the
ecosystem
have
built
or
tried
things
like
this.
Every
time
you
use
get
ups
you're,
basically
working
in
a
mindset
that
uses
this
argo
emulates
parts
of
this
pattern,
acm
emulates
parts
of
the
pattern
we're
all
building
similar
tools.
Can
we
take
the
idea
strip
it
down
to
its
bare
essence
and
look
at
it
from
a
different
lens,
something
that
gives
us
a
new
opportunity?
A
So
if
you
have
someone
who
thinks
they're
on
a
cluster
well,
obviously
they're
going
to
say:
okay,
I
want
to
control,
apply
my
service
and
my
deployment.
I
want
to
apply
a
helm
chart.
I
want
to
use,
get
ops.
I
want
a
ci
cd
process.
I
expect
somewhere
a
container
runs.
So,
obviously,
as
part
of
this
constraint,
we
would
have
to
take
a
workload
that
someone
specifies
at
a
fairly
high
level
and
make
sure
it
runs,
but
the
best
outcome
would
be.
A
The
team
doesn't
actually
want
to
care
about
what
a
cluster
is,
because
I
think-
and
this
is
something
I
think
all
of
us
fall
victim
to
from
a
we
are
technologists.
We
think
about.
I
have
a
technology,
I
will
solve
a
problem
with
it.
When
we
talk
when
we
come
to
kubecon,
we
show
icons
of
technologies,
but
the
point
isn't
the
technology.
The
technology
is
a
tool
that
gets
us
to
the
next
step.
What's
an
abstraction
that
takes
away
the
cluster
from
kubernetes,
because
the
cluster
isn't
the
point.
The
applications
are
the
point.
A
A
I
expect
a
service
to
be
running
somewhere
from
the
low-level
problem.
I've
got
to
go,
maintain
and
run
a
cluster
someone's
still
going
to
be
doing
that
right
at
the
end
of
the
day,
there's
still
a
physical
machine
running
a
bit
of
software,
but
we're
kind
of
getting
to
the
point
where
I
just
don't
care
about
that
problem
anymore.
A
That's
a
low
level
detail
that
someone
can
abstract
for
me
and
if
we
do
this
right
and
again
like
this
is
a
constraint.
We
don't
necessarily
know
that
we
can
do
this
in
a
perfect
fashion,
but
if
I
can
start
with
a
service
and
deployment
and
not
care
what
cluster
it
runs
on
and
to
me,
as
a
user,
I
don't
see
the
difference.
Then
all
my
tools
still
work,
my
user
experiences
work
and
yeah.
There
may
be
some
tweaks,
you
know
nothing.
A
Bad
things
happen
and
again
all
of
us
to
some
degree
have
to
deal
with
this
approach.
We
build
solutions
that,
let
us
say
which
cluster
an
application
runs
to.
I
suspect
many
people
using
a
git
ups
flow
or
a
ci
cd
flow
you've
got
a
mapping
somewhere.
That
says
this
application
goes
to
this
cluster.
These
aren't
new
ideas,
but
we
also
have
those
ideas
when
we
were
just
talking
about
machines
and
software
moving
across
them.
A
A
A
How
would
we
get
the
superpower
of
not
caring
about
a
cluster,
a
geography,
a
region,
a
cloud
half
of
our
data
center
infrastructure,
a
key
vendor?
How
do
we
build
the
abstractions
that
let
us
test
tolerate
and
try
failure
on
a
much
larger
scale?
How
do
we
go
through
that
in
a
common
way,
so
that,
when
you
add
a
new
person
to
your
team,
they
don't
have
to
learn
your
way
of
doing
application
mobility,
but
they
come
in
with
a
common
understanding
of
a
common
problem.
A
That
probably
isn't
absolutely
isn't
going
to
be
the
perfect
solution
to
the
problem,
but
it's
a
common
problem.
It's
a
common
solution
and
that's
again,
what
open
source
is
about
grinding
down
all
of
the
problems
we
have
into
these
nice,
smooth
pebbles
that
we
can
all
fit
together
and
move
on
to
solving
our
real
problems.
A
So
you
know
in
this
example,
you
know
this
level
of
abstraction
is
really
about
trying
to
hide
the
fact
that
there's
two
different
clusters
underneath
sometimes
you
can't
hide
that
right
at
the
end
of
the
day,
we're
still
running
software
somewhere,
but
if
we
as
a
group
as
a
as
an
ecosystem
as
a
community,
are
doing
this
the
same
way
that
becomes
the
center
of
gravity,
it
becomes
the
path
well
traveled.
It
becomes
the
downhill
path
that
gets
better
and
better
and
better.
A
That
is
infrastructure.
That
is
not
infrastructure
agnostic,
but
for
all
the
other
parts
for
all
the
other
bits
of
the
application.
We
don't
want
to
focus
on
how
our
applications
are
special
or
actually.
No.
I
take
that
back.
We
do
want
to
focus
on
how
our
applications
are
special
and
let
all
of
the
other
problems
be
common
problems.
A
So
something
special
is
when
an
application
isn't
cloud
agnostic
or
cluster
agnostic
when,
where
something's
running
matters,
how
do
we
break
those
into
smaller
and
smaller
problems
so
that
at
a
high
level
we
say
this
is
an
application.
I
don't
care
where
it
runs.
I'd
be
willing
to
wager
that's
about
97
98
of
all
the
applications
that
run
on
kubernetes
today,
the
other
two
percent
which,
judging
by
you
know
talking
with
openshift
customers,
is
90
of
openshift
customers.
There's
always
something
special.
A
I
need
hardware,
I'm
running
network
infrastructure,
I'm
the
backbone
of
an
important
payment
processor,
and
this
has
to
run
a
specific
regulatory
area.
Those
are
the
unique
characteristics
of
the
app
not
what
cluster
it
runs
on
a
consequence
of
this
abstraction
is
we
actually
have
to
start
thinking
about
how
applications
connect
with
each
other.
A
We
actually
do
this
today,
there's
at
least
15
or
30
or
75
service
mesh
projects
out
there
that
talk
about
the
abstractions
that
help
us
link
up
services
together
and
large
organizations,
because
that's
what
we
do
is
we
build
upon
and
connect
and
integrate
these
different
bits
of
technology,
the
characteristics
of
a
service
mesh
every
one
of
us
approaches
the
problem
slightly
differently,
because
we
have
slightly
different
requirements.
Service
mesh
is
an
organizational
construct.
A
It
is
the
ability
to
scale
services
and
applications
across
a
wide
enough
group
that
it
all
doesn't
just
collapse
into
a
flaming
pile
of
ashes.
The
technology
helps
us,
but
unless
we
address
at
the
same
time,
we
address
the
surface
mesh
problem,
the
organizational
problem
policy
control
placement.
We
are
unable
to
truly
solve
the
whole
problem
and
in
fact,
a
lot
of
times
when
you
know
I
look
at
the
the
information
we
gather
about
how
people
are
using
service
mesh,
the
biggest
problem.
A
Isn't
the
service
mesh,
it's
how
they
get
and
pick
a
pattern
that
that
service
mesh
is
used,
and
so
this
is
an
area
where,
if
we
can
consolidate
and
come
together,
we
can
find
common
approaches
that
allow
us
to
not
just
use
the
technologies
for
cross
cluster,
but
figure
out
the
common
way
that
most
applications
across
all
footprints
should
run.
And
again
we
don't
know
all
of
the
details
here.
In
fact,
I'll
be
quite
honest.
You
know.
Is
this
the
future
of
kubernetes
a
diagram
like
this
that
lets?
A
This
is
a
technology
if
you
use,
but
this
is
a
pattern
that
we
all
agree
on,
that
simplifies
standardizes
and
aligns
where
we're
going
and
so
we're
very
early
in
this
process.
In
fact,
it's
really
too
early
to
even
pretend,
like
I'm,
going
to
talk
about
a
road
map,
but
what
we
are
doing
is
we're
prototyping
these
ideas
in
the
open,
we're
talking
about
them
here
in
the
community
as
part
of
our
our
one-on-one
we're
trying
to
work
concretely
the
list
of
features
that
karina
showed
around
multi-cluster.
A
Rob
zumski
is
pm,
who
is
helping
coordinate
the
early
parts
of
what
we
talk
about
here?
The
kubernetes
is
the
control
plan
for
our
hybrid
cloud.
The
project,
the
the
prototype
that
we
have
is
called
kcp
cube
like
control
plane,
although
we're
very
cagey
about
whether
that's
what
it
actually
means,
but
if
you
are
interested
in
these
ideas,
if
you
have
use
cases,
if
you
think
that
your
problem
is
a
problem,
you'd
like
to
see
another
layer
that
feels
cube-like
that
standardizes
those
we
want
to
gather
feedback
over
the
next
over
the
next
year.
A
This
is
going
to
be
a
very
active
area
of
investigation
for
us,
so
I
hope
you'll
come
along
for
the
ride
and
I
hope
that
the
ideas
and
concepts
here
are
ideas
you
can
take
and
ask
questions
of
us
of.
Why
aren't
you
helping
us
converge
and
why
aren't
you
helping
us
simplify
what
you're
doing
so?
Thank
you
very
much.
I
hope
you
all
have
a
great
kubecon
and
if
you
would
like
to
talk
about
any
of
these
ideas,
I
will
be
here
all
week.