►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. 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.
Predictions from the Technical Oversight Committee (TOC) - Liz Rice, Chief Open Source Officer, Isovalent & Chair, Technical Oversight Committee & Lei Zhang, Staff Engineer, Alibaba Cloud & Member, Technical Oversight Committee
A
A
A
We
talked
about
chaos,
engineering,
kubernetes
for
the
edge
service
mesh
web
assembly
and
the
ebpf
and
developer
and
operator
experience
now.
You'll
find
talks
about
every
single
one
of
those
areas
at
this
week's
kubecon
and
there
was
a
co-located
event
on
almost
all
of
these
topics,
so
they're.
Clearly,
technologies
and
topics
you're
interested
to
discuss,
but
are
we
really
seeing
these
technologies
manifesting
in
the
form
of
cloud
native
projects?
A
A
We
have
one
ebpf
based
project
in
the
sandbox,
but
it's
worth
noting
that
there
are
incubating
and
graduated
projects
now
innovating
with
these
technologies
too.
We're
also
aware
of
a
lot
of
webassembly
runtime
projects
that
have
been
speaking
with
the
runtime
tag,
but
by
far
the
area
where
we're
seeing
the
most
experimentation,
at
least
as
measured
by
the
number
of
sandbox
projects,
is
developer
and
operator
experience,
making
it
easier
for
developers
and
operators
to
build
and
run
cloud-native
applications.
B
Hi,
thank
you
leeds.
Yes,
so
I
will
continue
to
talk
about
the
trend
of
clone
native
from
application,
development
and
deployment
yeah.
This
is
right
that
the
new
chain
of
clone
native
is
trying
to
make
sure
that
developing
software
be
very
easy,
authoritative
stack,
and
this
is
actually
enabled
by
widely
adapted
pattern,
which
is
known
as
study
card
pattern
on
kubernetes.
It's
really
important,
because
sidecar
is
essentially
a
small
container
that
is
running
alongside
of
your
application
container,
so
in
that
case
it
will
handle
all
the
inbound
traffic
of
your
application.
B
So
in
that
case
your
application
does
not
need
to
really
care
about
how
to
handle
this
traffic.
It
just
focus
on
its
bmx
logic,
which
is
the
most
valuable
for
developers
and,
on
the
other
hand,
infrastructure
such
as
kubernetes
and
platform
engineers
will
use
sales
mesh
and
similar
technology
to
handle
the
traffic
part
by
leverage
in
a
proxy
system
enabled
by
invoice.
B
In
that
case,
your
application
will
be
able
to
focus
on
its
own
thing
and
let
infrastructure
handle
all
the
traffic
management,
security
and
observability
parts
and
what's
more
important,
with
projects
like
dapper.
Now
you
actually
have
another
power
to
even
to
consume
the
cloud,
resources
and
services
based
on
static
car,
so
in
that
case
your
application
can
just
talk
to
localhost
to
consume
a
cloud
resources,
for
example.
Already.
B
This
also
enables
you
to
deploy
applications
to
anywhere,
regardless,
where
these
cloud
resources,
whether
it's
on
aws
or
google
cloud
it
doesn't
matter,
it
can
even
be
a
local
maintenance
radius
instance,
because
your
application
only
talked
with
the
local
host
and
laid
this
study
card
to
handle
the
rest
of
the
resource
consumption
and
will
add
the
service
binding
by
leveraging
the
depth
runtime.
And
this
is
new
chain,
and
this
is
really
game
changer.
B
We
call
that
it
is
the
local
host
oriented
program,
because
application
now
really
need
to
care,
but
really
don't
need
to
care
about
the
dependencies.
The
external
resources,
just
the
focus
on
your
application
deployment
and
speaking
of
the
application
deployment.
It's
actually
another
change
that
the
cloud
native
is
trying
to
make
it
easier
because
we
already
saw
there
are
a
lot
of
platforms
tool
that
is
trying
to
fix
this
problem,
because
you
know
deploying
deploying
application
is
really
really
matters.
B
If
you
want
to
have
a
consistent
way
to
maintain
your
software,
but
if
we
also
notice
a
trend
is
that
these
platform
tools
are
not
trying
to
create
a
new
abstraction
on
top
of
kubernetes
or
trying
to
give
you
a
restricted
product.
I
don't
need
to
do
that,
because
the
leverage
in
new
technology,
which
is
so
called
the
xs
code
since
in
these
platforms,
the
capabilities
of
the
delivery
system
are
defined
as
code
domain,
specific
language
or
hemp
template.
So
they
are
categorized
as
renewable
component.
B
This
actually
enables
developers
to
assemble
them
into
application
deployment
and
then
deploy
software
to
these
to
kubernetes
or
any
kind
of
infrastructure,
and
this
confidence
of
deployment
is
then
in
turn
maintained
by
github's,
workflow
or
by
kubernetes
controller
itself.
This
is
really
game
changer,
because
in
that
case,
no
application
deployment
will
never
cause
something
like
configuration
drift,
which
is
normal,
which
is
normal
issue
in
the
transition
instruction
code
system.
This
will
never
happen
in
kubernetes,
and
this
essentially
make
your
platform
to
work
and
grow
with
your
application
needs
growth.
B
There
will
never
be
restrictions
in
capability.
There
will
never
be
restrictions
in
abstractions,
because
everything
today
is
programmable.
We
see
there
are
a
lot
of
existing
projects
that
are
trying
to
make
this
happen,
for
example,
kubernetes
from
alibaba
cd
kubernetes
from
aws,
and
there
are
also
more
and
more
yet
to
come.
This
is
the
world
and
the
chain
we're
calling
that
programmable
application
deployment,
the
speaking
of
deployment
the
developers
are
not
just
they
want
to
deploy
and
that
they
actually
want
to
deploy
continuously.
That's
why
we
have
continuous
development.
B
Git
ops
is
actually
a
natural
extension
of
a
kubernetes
control
loop
because
it
gives
a
way
to
maintain
the
consistency
between
design
status,
which
you
maintain
in
the
github
repo
and
the
real
world,
and
the
real
world
actual
status,
which
is
running
instances
in
your
cluster
and
git
and
engage,
is
a
tool
that
you
maintain
this
kind
of
workflow
by
just
doing
whatever
you
are
familiar
with
like
pull
request
and
send
out
issues,
I
commit
the
change.
This
is
all
what
happening
by
trigger
a
github's.
B
Deploy,
workflow
and
githubs,
actually
give
you
the
way
to
have
the
consistency
and
accuracy
in
the
automation
of
deployment.
So
you
can
do
it
repeatedly
repeatedly
and
you
are
viewing
the
tools
which
your
developers
are
familiar
with
for,
for
example,
git.
Nothing
needs
to
know
need
to
learn,
and
this
also
enables
you
to
build
highly
extensible
deployment
workflow.
You
don't
need
to
have
something
like
traditional
pipelines
to
do
that.
B
This
is
github's.
This
is
how
the
cloud
native
trying
to
improve
your
developers
to
deploy
and
continuous
deploy
software
with
a
consistent
and
with
confident
approach.
So
you
can
see
the
chain.
Inclinative
is
very
easy
to
understand
now
in
trying
to
make
sure
that
deploy
developing
software
deploy
software
and
the
continuous
deploy
software
way
easier
with
high
efficiency,
and
there
are
a
lot
there
are
a
lot
of
projects
that
are
trying
to
make
that
make
this
happen.
We
see
that
argo
cd
from
intuned
we
see
there
is
already
is
flux.
Cd
from
reworks.
B
We
see
there
are
a
project
named
captain
from
die
chains
which
can
give
you
more
power
to
do
an
observability
and
a
use
of
availability
matrix
to
drive
your
workloads.
This
is
nutrient
of
declinative.
We
are
talking
about,
and
I
will
then
head
over
to
liz,
to
talk
about
the
next
step
of
cloud
native.
Okay,
thank
you.
Liz.
A
A
A
Another
area
that
lends
itself
very
naturally
to
running
in
the
cloud
is
machine.
Learning
organizations
are
renting
compute
in
the
cloud
to
handle
massive
amounts
of
data
and
to
train
their
machine
learning
models.
So
it
makes
sense
to
leverage
cloud
native
approaches
for
these
kinds
of
applications
and
we
expect
to
see
more
projects
in
this
area.
Coming
to
the
cncf.
A
A
The
cncf
is
centered
on
open
source
community
projects,
but
we
want
to
see
healthy
business
ecosystems
around
those
projects
with
vendors,
large
and
small
able
to
build
successful
businesses.
Competition
is
healthy.
We
see
it
between
projects
and
between
vendors
and
competition
encourages
innovation.