►
From YouTube: Kubernetes SIG Apps Updates - Janet Kuo, Google; Kenneth Owens, Brex; Maciej Szulik, Red Hat
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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.
Kubernetes SIG Apps Updates - Janet Kuo, Google; Kenneth Owens, Brex; Maciej Szulik, Red Hat
SIG Apps is the special interest group covering deploying and operating applications in Kubernetes with a focus on the application developer and application operator experience. In this session the SIG Apps leads will provide an overview of what we’ve accomplished over the past year, including API promotions, controller improvements, leadership changes, subprojects status etc. They will also share the work that is being planned for the upcoming releases. The session will conclude with an open discussion and Q&A.
A
A
If
you're
interested
in
showing
your
cool
application
core
feature
that
you
build,
whether
that
will
be
a
third-party
controller
or
an
external
tool
that
we
use
this
kubernetes
api
sig
apps
is
the
place
that
you
want
to
present
that
kind
of
information.
We
are
basically
meeting
every
other
monday.
Like
I
mentioned
before
janet
ken
and
myself,
we
are
the
chairs
of
the
sea
gaps,
so
we
are
meeting
every
other
monday.
Our
next
meeting
will
be
on
october
18th.
A
The
call
is
happening
at
6,
00
p.m,
central
european
time
at
noon,
eastern
time
or
9
a.m.
Pacific
time
we
also
hang
out
on
kubernetes
slack
channel.
Segapps
is
the
channel
as
you
might
expect,
and
we
also
maintain
the
email
group,
so
you
can
always
reach
out
to
us
and
we
will
be
able
to
answer
your
questions.
C
Hi
thanks
janet,
so
the
two
new
features
that
we're
taking
to
ga
are
graduating
crime,
job
to
staple
and
graduating
pod
disruption.
Budgets
at
stacial,
stable,
pi
destruction.
Budget
is
kind
of
the
odd
duck
in
the
portfolio
of
sig
apps,
but
it
is
important
for
managing
intended
and
unintentional
disruptions
during
workload.
Rollouts
and
cron
job
is
the
last
piece
of
the
workloads
api.
C
So
things
that
we're
working
on
presently
we're
working
on
max
surge
and
demonsense,
one
of
the
limitations
in
demon
set
right
now
is
that
it
really
tries
to
optimize
to
provide
a
single
pod
per
node
during
rolling
updates,
and
this
can
somewhat
hamper
the
availability
of
administrative
or
infrastructure
workloads
that
are
running
on
the
node.
So
what
mac
surge
will
allow
you
to
do
is
to
launch
a
new
pod
prior
to
killing
the
old
pod.
This
adjustment
to
the
rolling
update
strategy
is
still
going
to
be
very
sensitive
to
scarce
resources.
C
So
that's
something
that
you're
going
to
have
to
manage
yourself,
but
we
found
via
survey
that
ultimately,
it's
better
to
provide
this
to
the
community
and
to
allow
people
to
manage
it
than
to
say
okay
because
of
scarce
resources
on
nodes
things
like
gpus
or
asics,
or
you
know
other
things
that
that
a
demon
set
might
use
because
that
it's
difficult
to
manage
those.
We
should
not
touch
it
at
all.
C
So
we're
moving
forward
with
that
min
ready,
safe
seconds
and
staple
set,
is
really
just
about
kind
of
polishing
the
workloads
api
surface
and
providing
the
same
readiness
functionality
that
we
do
for
the
other
controllers
for
staple
set.
If
you're
familiar
with
deployments
and
demon
sets,
they
all
have
a
min
ready
seconds
field
that
allows
it
to
like,
during
a
rollout
and
during
a
rolling
update,
to
determine
the
availability
of
the
workload
itself.
C
So
random
replica
set
down
scale
the
the
very
deterministic
order
in
which
replica
sets
down
scale.
Pods
is
kind
of
very
sensitive
to
failure
to
means
failing
concurrently
with
upscales
and
down
sales,
so
by
randomly
selecting
pods
that
we
terminate
during
a
downscale
we're
going
to
reduce
the
sensitivity
of
concurrent
infrastructure
failures
during
rolling
updates
and
during
downscales
to
make
sure
that
you
get
you
still
get
a
good
distribution
of
pods
across
your
failure.
Domains
and
replica
set
pod
deletion
cost.
C
So
this
allows
you
to
determine
which
pod
should
be
the
best
pod
to
delete
during
a
replica
set,
rolling
update
or
a
replica
set
down
scale.
The
the
thought
behind
this
is
that
sometimes
there's
an
optimal
pod
that
you
would
selected
during
a
downscale
and
there's
no
way
really
to
communicate
this
to
the
controller.
Presently,
this
feature
will
allow
you
to
be
able
to
do
things
like
if
there's
a
pod,
for
instance,
that
hasn't
been
running
for
very
long,
so
it
hasn't
been
able
to
pull
down.
C
A
A
First,
you
are
heavily
related
with
external
orchestration
orchestrators
that
will
allow
to
first
of
all
suspend
jobs
that
can
be
even
useful
for
for
regular
users.
If
you
know
that,
for
example,
your
cluster
is
less
busy
overnight,
you
can
either
do
it
manually
or
have
an
external
operator
that
will
manage
so
that
your
job
will
be
doing
it
its
task
overnight,
instead
of
during
the
day
day
time.
The
next
improvement
is
about
indexing
jobs.
A
So
previously,
when
jobs
were
being
run,
we
didn't
have
any
ordering
or
indexing
within
deposit
are
being
executed,
so
the
order
was
always
not
guaranteed.
With
index
jobs,
every
single
pod
will
be
given
will
be
assigned
a
particular
index
in
a
completion
so
that,
at
the
end
of
the
time
you
can
exp,
you
can
explicitly
assign
specific
parts
of
the
task
for
for
the
job
itself
and
finally,
the
biggest
one.
A
A
When
your
job
is
becoming
pretty
big,
I
don't
know
thousands
and
more
pots.
The
problem
is
that
those
pots
has
to
be
present
on
the
cluster,
even
in
completed
state
until
the
job
completes,
because
the
job
controller
relies
on
the
pots
being
present
to
properly
calculate
its
status
and
know
when
it
actually
finishes.
B
B
B
So
with
this,
we
can
add
that
functionality,
readiness
functionality
to
staple
set
and
align
it
with
other
workload
controllers.
The
next
feature
is
auto.
Remove
pvcs
created
by
staple
set
is
coming
in
in
the
next
release,
and
a
stateful
set
by
default
doesn't
clean
up
its
pvcs
after
you
delete
the
stable
set,
and
that's
because
that's
for
safety
reasons,
because
you
don't
want
your
data
to
be
removed
by
default,
and
then,
with
this
feature,
you
can
obtain
to
allow
the
storage
storage
to
be
cleaned
up
with
the
staple
set.
A
So,
there's
more
future
future
plans
that
we
just
recently
started
working
on,
so
if
you've
been
working
with
any
of
the
controllers
apis
before
you
probably
noticed
that
each
and
every
single
controller
has
its
own
status
to
say
that
it
is
ready
or
that
it
is
pending
or
that
an
upgrade
is
going
on
or
that
it
is
not
available.
Yet
the
problem
with
this
approach
is
that,
when
you're
trying
to
orchestrate
the
controllers,
you
always
have
to
write
your
own
logic
per
specific
controller.
A
On
top
of
that,
you
cannot
create
any
automation,
or
it's
even
hard
from
a
user
perspective,
to
figure
out
at
which
point
in
the
process
and
the
life
cycle.
Your
controller
currently
is.
Our
goal
is
to
change
that
and
to
have
a
unified
set
of
workload,
statuses,
or
at
least
the
conditions
for
starters,
so
that
it
doesn't
matter
whether
you
will
be
looking
at
daemon
sets
or
stateful
set
or
a
deployment
or
a
job.
You
can
easily
figure
out
at
what
point
in
the
life
cycle
of
a
particular
controller.
A
It
is
currently
at
so
we're
hoping,
and
this
will
work
in
both
ways.
It
will
help
with
a
lot
of
automation
that
is
built
on
top
of
the
kubernetes
controllers,
because
you
can
have
unified
conditions
and
you
can
easily
figure
out
where
we
are
at
and
additionally,
it
will
be
very
easy
for
newcomers
when
they
are
working
with
controllers
for
the
first
time
to
easily
jump
from
one
controller
to
the
other
and
figure
out
where
the
controller
is
at
what
might
be
the
problems
that
it
is
currently
struggling
with
and
so
forth.
A
A
This
will
be
definitely
something
that
will
take
a
little
bit
longer
because
even
when
the
enhancement
will
be
ready,
probably
we're
planning
for
124.
The
implementation
will
take
time
and,
as
we
are
implementing
those
features,
we
will
be
updating
the
enhancements
based
on
the
implementation,
because
on
one
hand,
yes,
we
will
go
through
all
controllers.
We
will
gather
all
the
data,
but
then,
at
the
same
time,
when
we
will
be
actually
implementing
them,
a
lot
of
other
edge
cases
will
probably
appear
that
we
will
have
to
take
into
account.