►
From YouTube: Argo and Tekton: Pushing the Boundaries of the Possible on Kubernetes - Alex Collins & Jason Hall
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.
Argo and Tekton: Pushing the Boundaries of the Possible on Kubernetes - Alex Collins, Intuit & Jason Hall, Red Hat
Kubernetes isn’t just a platform for running apps anymore. Increasingly, it’s also becoming a platform for platforms, some of which challenge the idea of what Kubernetes can and should be used for. Tekton and Argo are two such projects, there are more, and there will be many more to come. These projects run unconventional workloads which often have quite different needs to running vanilla deployments. They often need to manage large amounts of data, manage massive parallelism, and special lifecycle requirements, none of which Kubernetes provides by default. In this talk, you’ll hear from the technical leads on the Tekton and Argo projects about how they’ve pushed the boundaries of Kubernetes to provide this new functionality. You’ll hear how users have benefitted from this work, how you can apply these same techniques, and how we can further improve Kubernetes as a platform for this kind of workload.
A
Hi,
we're
here
from
argo
and
techton
to
talk
about
pushing
the
boundaries
of
what's
possible
on
kubernetes,
so
who
are
he
well?
I'm
alex.
I
work
at
intuit,
I
specialize
in
kubernetes
and
kind
of
oltp
stuff
and
the
lead
engineer
on
argo,
workflows,
argo
events
and
argo
labs,
dataflow
and
I
like
coffee
and
cycling.
Ideally,
a
bike
ride
to
a
nice
coffee
shop
is
my
kind
of
ideal
sunday.
B
B
B
B
Why
did
we
decide
to
build
on
kubernetes
when
building
a
workflow
service?
There
are
two
well,
there
are
a
lot
of
problems.
Two
of
the
biggest
ones
are
node
management,
just
managing
the
resources
to
that
will
be
doing
the
work
and
another
is
workload
scheduling.
So
when
a
user's
request
comes
in,
I
want
to
do
this
work,
putting
that
on
one
of
those
nodes
to
do
the
work.
B
B
Kubernetes
also
has
a
great
a
great
resource
in
custom
resources.
This
lets
us
build
flexible,
extensible,
apis
inside
the
kubernetes
api
server
and
ecosystem,
and
we
basically
get
our
back
for
free.
Our
back
is
another
huge
source
of
work.
If
you
don't
have
one
already
built
for
you
and
kubernetes
built
that
for
us,
so
we
love
it
and
then
there
is
the
long
tail
of
just
community
stuff.
That's
all
of
you!
That's
everyone
outside!
B
Client
tooling,
for
all
of
these
things
and
multi-tenancy
concerns
and
policy
enforcement
and
tons
and
tons
and
tons
more.
All
of
these
things
are
things
that
if
we
didn't
build
on
kubernetes,
we
would
have
to
build
ourselves,
and
that
would
be
a
massive
amount
of
work
and
largely
pretty
wasteful
and
instead
we
get
to
sit
back
and
work
on
features
while
kubernetes
improves
underneath
us
every
day.
Thanks
to
all
of
you,
however,
kubernetes
was
not
really
designed
for
this.
It
was
more
designed
for
long-running
serving
workloads
things
like
deployments
and
services
and
ingress.
B
You
know
the
the
the
usual
suspects,
these
things
assume
long-running
pods.
Well,
we
have
relatively
short-running
pods
and
they
assume
long-running
containers
and
we
have
fairly
short-running
containers
and
they
assume
no
control
over
the
life
cycle
of
the
containers,
starting
and
stopping
they
just
sort
of
assume
they
run
forever.
Well,
we
need
to
start
and
stop
these
things
a
lot
and
they
have
no
convention
for
passing.
Data
from
one
pod
to
another.
Pods
are
pretty
isolated
on
purpose
in
the
kubernetes
ecosystem.
Well,
we
need
to
pass
data
between
these
things
a
lot.
B
So
these
are
the
the
sort
of
four
main
points
we're
going
to
talk
about
container
life
cycle,
starting
and
stopping
especially
with
regards
to
how
side
cars
are
involved,
container,
ipc,
inter-process
communication,
talking
between
containers
and
a
pod
cross-pod
communication
talking
between
pods
in
a
workflow
and
custom
resource
proliferation,
which
turns
out
to
be
a
gigantic
pain.
And
with
that
I
will
hand
it
off
to
alex
to
talk
about
container
lifestyle.
A
A
We
actually
can
do
things
like
modifying
the
graphs
at
runtime,
so
in
the
way
that
you
specify
in
your
pod
spec
what
containers
that
you
want
to
run
in
that
pod,
without
our
workflows
and
our
graphs,
we
don't
necessarily
even
know
what
the
containers
are
going
to
be
when
we
start
it-
and
you
know
we
have
some
nice
simple
ones,
but
we
also
have
some
pretty
big
graphs
that
we
run.
You
know
20
30,
000,
pod
graphs,
sometimes-
and
this
is
an
example
from
the
community.
A
A
So
what
we
want
to
do
is
shut
down
the
containers
in
a
specific,
controlled
order.
You
know
stopping
container
b
before
stopping
container
a
and
when
they
stop
when
they're
shut
down,
they
need
to
be
able
to
do
some
kind
of
graceful
termination.
You
know
clean
up
flushing
their
buffers
that
kind
of
stuff
and
that
shut
down
really
needs
to
work
with
standard,
kubernetes
shutdown,
and
so
the
way
that
kubernetes
shuts
down
a
pod
is.
Firstly,
you
get
a
sig
term
to
the
root
process.
Then
you
get
30
seconds
configurable.
A
Yes,
I
know
followed
by
a
sig,
kill
a
hard
shutdown,
so
you
need
to
work
nicely
with
sig
term,
so
the
way
that
we
do
this
the
primary
way
that
we
do.
This
is
what
we
have
termed
the
command
up
pattern,
which
we
termed
wednesday
last
week.
That's
why
you've
not
heard
of
it,
but
you
probably
know
this
better
in
tecton
as
the
entry
point
rewriting
or
in
argo
workflows
as
the
emissary
executor,
which
is
very
heavily
influenced
by
tecton.
A
A
What
we
want
to
do
is
we
want
to
replace
the
user's
command
with
our
own
command,
that
forks,
the
user's
command
as
a
sub-process,
and
the
way
that
we
do,
that
is
we'll,
have
an
init
container
and
both
the
init
container
and
the
main
container
will
share
an
empty
directory
volume,
and
the
init
container
will
just
copy
that
binary
onto
that
volume
and
then
that's
made
available
to
us
in
the
main
container.
So
so
they
don't
need
to
be
baked
into
the
image
of
the
container.
A
We
can
actually
capture
the
sub
processes
standard
in
standard
out
and
exit
code,
and
you
can
actually
do
things
like
remap
the
exit
code
to
a
different
exit
code.
If
you
want
to,
we
can
also
wait
for
a
condition
before
shutdown,
which
is
pretty
neat
for
debugging.
So
the
the
user's
main
process
can
finish
that
sub
process
finishes
and
then
the
content
is
held
open
still
running.
While
you
can
connect
with
cubex
to
do
some
debugging
and
the
great
thing
is
it
that
is
very
difficult
with
two
containers
in
the
pod.
A
A
If
you're
going
to
delay
the
start
of
that
sub
process
based
on
some
condition,
then
that
container
is
still
going
to
be
running
and
it's
going
to
be
consuming
memory
and
it's
going
to
be
costing
you
money
as
a
result
of
that
and
that'll
be
set
by
your
resource
requests.
And
typically
this
kind
of
commandlet
doesn't
need
very
many
resources
at
all.
A
It
could
be
pretty
pretty
skinny
pretty
lightweight,
but
your
main
container
maybe
do
some
really
heavy
lifting
it
might
have
some
high
cpu
memory,
gpu
requirements,
so
that
could
be
costly
and
you
can
mitigate
that
by
working
with
resource
requests
and
the
other
thing
it
doesn't
really
allow
us
to
do
is
we're
still
tied
to
pod
specs.
So
we
can't
dynamically
add
containers
to
the
graph.
A
A
It,
has
the
downsides
that
the
pod
is
deleted.
So
you
can't
inspect
the
pod
afterwards
can't
look
at
its
status
afterwards,
once
it's
deleted
and
you
can't
you
know
unless
you've
archived
the
logs
you
lose
access
to
the
logs
and
the
other
one
is
to
use
cube.
Ctrl
exec
kill
one,
but
I
hope
some
people
can
realize
the
problems
with
that.
A
So
it's
I
mean
it
sounds
like
a
great
way
to
kill
a
pod,
but
it
has
three
big
drawbacks.
Most
pods
don't
have
a
kill
binary
on
them.
They
might
be
a
scratch
or
distralis
images,
because
security
is
more
important
now.
I
think
for
many
people
than
a
year
ago,
and
so
those
images
are
much
more
common
or
it
could
be
something
like
debian,
where
the
kill
isn't
a
binary.
It's
a
built-in
shell
built
in
it
doesn't
necessarily
work
with
shell
scripts,
particularly
well.
A
This
can
be
hard
to
kill
a
shell
script
and,
if
it
gracefully
shut
down
and
finally,
if
you're
running
this
non-root,
your
root
process
won't
be
started
with,
pin
number
one
so
kill
one
I
mean
won't,
do
anything
at
all
in
those
containers.
I
think
it'll
return
an
exit
code
then
so
here
are
a
couple
of
mitigations
for
that
one
is
to
use
dominic.
So
there
are,
I
think
there
are
two
or
three
implementations
of
this.
A
The
one
I
know
is
of
is
by
yelp
and
that
provides
an
init
process
which
handles
those
sync
terms
correctly
and
that
can
fix
your
shell
script
forking
and
get
those
guys
to
shut
down
correctly,
like
we
did
for
the
entry
point,
you
can
have
your
init
container
copy,
a
kill
binary
onto
the
onto
the
image
onto
that
shared
directory,
and
then
you
can
actually
just
invoke
that
directory.
You'll
know
the
path
to
that,
and
actually
you
can
write,
kill
in
about
20
lines
of
go.
A
You
can
write
your
own
kill
command
and
to
mitigate
the
the
pig
one
issue.
You
can
use
the
pit
off
command
to
figure
out
which
pit's
doing,
and
there
are
various
other
ways
to
do
that
now.
I
can't
talk
about
this
with
just
saying
if
you
want
to
find
out
more
about
this
jason
and
christy
wilson
spoke
about
this
in
depth
at
kubecon
2019,
which
feels
like
a
very
long
time
ago
and
there's
a
there's
a
link
there
in
the
slides.
If
you
want
to
find
out
in
like
a
load
more
depth
about
it,.
A
It's
hard
to
talk
about
writing
your
own
controller
and
creating
pods.
I
think,
without
talking
a
little
bit
about
side
cars,
so
a
little
bit
of
revision
for
anybody
who
doesn't
know
what
a
sidecar
is.
A
sidecar
is
just
a
container
that
runs
next
to
your
main
container
provides
some
kind
of
facility,
it's
usually
some
kind
of
cross-cutting
concern.
A
The
problems
with
side
cars
is
how
we
don't
control
them
and
they
can
become
quite
unruly.
You
know,
we
don't
know
how
to
behave.
We
don't
know
if
they're
going
to
accept
sig
term
correctly
and
and
run
it.
We
don't
even
know
if
they
have
an
init
process,
they're
a
bit
of
a
black
box
to
us
and
it
gets
kind
of
even
worse.
A
When
we
talk
about
injected
side
cars
like
those
that
come
with
istio
and
vols,
so
an
ejected
cycar
is
a
term
we
use
to
describe
a
a
container,
that's
added
to
the
pod
spec
after
creation
by
a
mutating
web
hook,
controller,
and
because
it's
added
by
that
mutating
web
controller,
we
just
don't
we
don't
have
any
information
about
it.
We
can't
intercept
it
or
change
it.
We
can't
rewrite
the
entry
point
now.
Istio
does
provide
a
quick,
quick,
quick
end
point.
A
I
think:
that's
how
you
pronounce
it
quick,
quick,
quick,
but
it's
not
really
a
standard,
and
our
solution
today,
certainly
for
workflows,
is
if
people
have
issue
or
vault
running,
we
say
well,
disable
it
and
that's
a
shame,
because
people
want
to
use
those
technologies
for
really
good
reasons
and
we'd
really
love
to
be
able
to
support
them.
Doing
that.
A
A
So
why
would
we
want
to
do
container
ipc
and
what's
our
use
cases
for
it?
Well,
it's
about
typically
about
sharing
data
between
two
containers.
So,
for
example,
you
want
to
download
a
file
from
s3
or
some
other
kind
of
bucket
storage
and
make
it
available
for
that
main
container,
or
you
might
want
to
do
some
kind
of
remote
procedure
calls
between
the
two
containers
or
you
might
want
to
do
some
kind
of
streaming
data.
A
You
know,
get
messages
from
kafka
and
provide
those
the
main
container
amongst
you
know
quite
a
few
different
use
cases
I
would
say
now.
Container
ipc
is
just
it's
just
nick's
ipc
and
there
are
about
five
to
seven
to
nine
different
ways
of
doing
nyx
ipc,
and
I'm
going
to
talk
about
a
couple
of
them
that
we've
found
that
work
really
well
with
our
systems.
A
The
first
one
that
both
argo
and
tekton
use
is
this
ubiquitous
shared
empty
volume
alex.
What
how
do
I
solve
this
problem?
Well,
I
think
it's
probably
solved
by
a
shared
empty
directory,
but
any
argo
workflows
users
know
that
it's
not
too
far
from
the
truth,
so
the
shared
entry
directory
allows
you
to
contact,
communicate
between
two
processes,
typically
using
some
kind
of
marker
file.
A
So
one
of
the
two
processors
will
write
a
marker
file
into
that
directory
and
the
other
process
will,
let's
sit
there
polling
for
changes
to
that
file
and
when
that
file
has
changed
it's
going
to
raise
the
contents
and
perform
some
kind
of
option.
Obviously,
on
a
shared
empty
directory,
you
can
you
can
mount
a
fifo
using
mk
fifo
or
you
know,
whatever
your
language's
fifo
creation.
Api
is,
and
that's
quite
quite
fast
if
you
want
to
just-
do,
read
and
write
of
bytes,
but
it's
not
particularly
proven.
A
If
you
look
out
there,
there's
not
too
much
documentation
on
that,
but
the
nice
thing
about
shared
empty
directory
volumes.
Is
that
they're
really
simple?
I
mean
just
so
simple
they're
super
secure
and
they're
really
robust.
So
they're
great
for
what
I
would
call
slow
ipc
where
that
you
don't
have
a
lot
of
data
going
through
and
those
messages,
don't
change
a
lot.
A
But
if
you
want
something
faster,
then
there's
another
really
great
tool
in
the
toolkit
to
use
and
that's
just
http
http
has
these
great
benefits
of
being
well
known
and
easy
to
implement.
Most
programming
languages
come
with
http
server
and
http
client
built
into
them.
So
you
don't
have
to
worry
about
checking
your
dependency
tree
for
those.
You
know
problematic
security
issues.
It's
just
part
of
the
of
the
core
sdk.
You
need
to
define
an
api
contract,
not
particularly
difficult
the
nice
thing
about
this.
Is
it's
actually
relatively
secure?
A
You
actually
don't
need
https
between
two
containers
within
a
pod
because
they
have
their
own
network
name
space.
You
can
just
use
http
and
it's
actually
pretty
fast.
It's
pretty
fast,
especially
if
you
are
using
http
keeper
live
so
the
socket
you
have
the
socket
establishment
cost
and
you're
using
unix
domain
sockets
as
well.
You
can
get
a
pretty
nice
performance
and
throughput
benefit
from
using
those
and
well
when
we
rehearsed
this
earlier
on.
I
was
telling
jason
how
java
16
now
supports
unique
domain
sockets
and
it
turns
out.
A
A
Now
are
there
other
ways
of
doing
container
ipc,
so
these
are
some
of
the
examples
of
the
kind
of
tps
messages
per.
Second,
you
can
get
with
some
of
the
other
technologies
out
there,
so
things
like
pipes,
message,
queues,
posix
and
csv
message,
queues,
shared
memory
and
memory
map
files,
and,
if
you,
if
you
just
take
a
look
at
this
graph,
you
can
see
that
the
throughput
you
can
get
from
memory
map
files.
A
Is
you
know
what
is
that
of
20
times,
20
times
faster,
so
there's
like
it,
there
are
other
ways
much
much
faster
than
tcp,
but
these
are
kind
of
unproven
and
in
the
kind
of
research
that
I've
done
on
this
topic,
it
has
been
a
bit
hereby
dragons
on
the
internet
and
I'd
love
to
hear
from
anybody
who
has
looked
at
memory
map
files
between
containers
to
be
fascinated
to
know
what
their
results
were
back
to.
My
colleague
jason.
B
For
example,
the
canonical
use
cases
for
this
are:
if
a
task
does
a
git
clone
of
some
revision
of
some
repository,
it
might
need
to
pass
the
commit
that
was
actually
checked
out
to
the
next
task
in
the
pipeline
or
if
it
built
a
built,
a
container
image.
It
would
need
to
pass
the
digest
to
the
next
task
that
signs
it
or
scans
it
or
does
something
else
with
it.
B
We
also
need
to
expose
that
information
up
to
the
user,
that's
looking
through
the
api
or
the
ui
or
cli,
and
these
are
all
short-lived
containers
that
we
don't
necessarily
control.
So
we
don't
have
a
lot
of
options
for
having
users
request,
http
endpoints
directly
on
those
containers
to
get
that
information,
and
so
in
techton
at
least
we've
found
a
fun
little
work
around
using
little
known
technology
called
termination
messages.
Not
a
lot
of
people
know
about
this
or
I
don't
think
they
do.
B
So
this
is
a
little
way
to
ferry
information
out
of
your
pod
out
of
your
container
through
the
pod
up
to
the
api
server
and
it's
configurable
with
the
the
container's
termination
message
path.
So
yeah,
the
more
you
know
so
the
way
that
tekton
uses.
This
is,
if
a
container,
if
a
step
container,
writes
to
slash
tecton
slash
results,
something
the
injected
entry
point
that
alex
talked
about
before
will,
after
the
step
is
complete,
it
will
scan
all
of
tekton
results
and
see.
If
there's
anything
in
there,
it
will
collect
that
information.
B
It
will
stuff
it
into
a
json
string
and
write
it
to
its
termination
message
path
that
gets
collected
by
kubelet
written
up
to
the
api
server.
The
controller
watching
that
pod
pulls
out
that
json
and
then
puts
it
into
the
task
run
status
where
it
goes,
and
this
lets
us
pass
that
data
on
to
other
tasks
and
show
it
to
end
users.
B
But
ultimately,
if
the
4k
limit
is
there
you're
going
to
hit
it
one
way
or
another
eventually,
so
something
we
started
to
look
into
is
instead
of
writing
to
that
termination
message
path.
We
will
have
the
injected
entry
point
contact
the
api
server
and
write
to
a
config
map.
The
config
map
max
size
is
much
much
larger
than
12k,
and
so
for
every
test
run
that
will
run
we'll
create
a
config
map
to
hold
its
results.
B
The
entry
point
will
write
that
data
to
the
config
map
and
we
can
tightly
narrowly
scope
the
r
back
to
that
results,
object
to
so
that
the
entry
point
is
only
allowed
to
write
to
it
and
the
controller
is
the
only
one
allowed
to
read
from
it.
So
you
can't
have
cross-task
contamination
in
the
results
and
that's
basically
exactly
what
argo
workflows
does
so
it's
nice
to
have
proof
that
that
works.
B
There
are,
however,
some
disadvantages.
If
we
want
to
use
config
maps,
we
can
use
configmaps
if
we
wanted
to
use
our
own
type
that
we
define.
We
now
have
to
define
that
type
and
manage
that
type
and
version
and
upgrade
and
validate
that
type
and
the
sort
of
bigger
concern
is
the
additional
load
on
the
api
server.
B
So,
instead
of
just
writing
to
the
pod
that
we
already
use
and
update
all
the
time,
we're
also
making
frequent
rights
to
this
to
this
config
mapper
another
custom
resource,
and
we
have
to
create
our
back
for
that
on
every
new
task
and
every
new
execution
and
manage
it
and
delete
things
when
they're
done
so
they
don't
leak
and
it's
it
can
get.
It
can
get
difficult.
B
At
the
end
of
the
day,
crds
are
just
writing
to
etcd
and
ncd,
while
also
really
great
is
not
magic.
It's
not
the
key
to
unlocking
free,
infinite,
scalable
storage,
and
if
you
try
like
some
people,
do
you
will
hit
limits,
and
when
you
hit
those
limits,
you
will
experience
pain.
You
will
start
to
experience
pain
in
a
few
dimensions.
One
way
you
can
mess
up
etcd
is
to
write
too
many
bytes
like
I
said
it's,
not
an
infinite
storage.
B
You
will
eventually
hit
some
limit
and
scd
will
start
to
fall
over
if
you
create
a
lot
of
tiny
objects
too
many
tiny
objects.
However
many
bytes
total,
it
is
doesn't
matter
too
many
objects
at
cd
will
start
to
fall
over
and
if
you're,
just
constantly,
writing
requests
to
etcd
through
the
api
server
and
constantly
updating,
ncd
won't
like
it
and
will
fall
over
destabilizing.
Scd
is
really
really
really
bad.
The
cluster
just
sort
of
starts
to
act
funny
and
things
don't
work
and
requests
start
to
time
out
and.
B
We
have
some.
We
have
discovered
some
mitigations
for
this.
One
really
easy.
One
is
don't
use
jobs
when
you
really
just
want
pods.
If
you
create
a
job,
it
will
just
create
a
pod
for
you
and
now
you've
created
double
the
resources
and
double
the
qps,
because
when
the
pod
updates
it'll
update
the
job,
and
then
you
read
the
job,
so
that
was
an
easy
one.
That's
like
50
off
right.
There
avoid
unnecessary
updates
to
your
objects.
B
If
you
can
in
your
reconcile
loop
instead
of
making,
you
know,
10
requests
to
update
the
status
of
something
batch,
those
until
the
end
and
make
one
update
at
the
end,
avoid
duplicating
the
same
information
across
a
bunch
of
objects.
So
tekton
actually
doesn't
do
this.
Well,
today,
when
a
task
run,
a
test
run,
status
is
actually
copied
and
aggregated
into
the
pipeline
run
status
for
ease
of
the
user,
but
that
means
that
we
have
to
make
two
updates
every
time.
B
Argo
actually
has
a
really
interesting
feature
that
I
didn't
know
about
until
earlier.
Until
we
were
working
on
this
talk,
which
is
that,
if
the
status
of
an
argo
object
gets
too
big,
it
will
the
controller
will
offload
it
to
another
database
and
just
give
it
a
pointer
to
that
give
you
so,
instead
of
your
status,
you
just
say
like
go
chase
this
pointer
to
the
real
database
to
go
get
that
information.
So
that's
really
interesting.
B
Other
mitigations
we've
had
for
for
custom
resource
proliferation
are
just
enforce
reform
resource
quota
in
a
name
space
you
can
say
this
namespace
is
not
allowed
to
have
more
than
a
thousand
task
runs
ever
and
if
you
try
to
create
a
thousand
in
first,
it
will
fail.
You
might
also
want
to
prune
old
resources.
We
do
this
in
tecton
a
lot
today,
but
the
question
there
is
always
like:
do
you
want
to
prune
by
age?
Do
you
want
to
say
something?
B
I
only
want
to
keep
the
last
week
of
history,
or
do
you
want
to
prune
by
number
of
resources?
I
only
want
to
keep
the
last
10
000
requests,
whether
or
not,
however
old
they
are,
but
fundamentally
users
don't
want
to
lose
this
data,
especially
if
it's
security
sensitive
like
what
did
we
deploy
three
months
ago?
B
Well,
sorry,
we
needed
that
space,
so
we
deleted
all
record
of
that
deployment
ever
happening
is
not
a
good
answer
for
users.
So
techton
and
argo
have
also
solved
this
in
a
similar
way
or
planning
to
solve
it
in
a
similar
way.
In
tecton
we
have
a
techton
results
project
and
in
argo
they
have
argo,
workflow
archive,
which
effectively
runs
another
controller
to
watch
for
these
executions
when
they
finish
it
copies
that
data
to
another
relational
database
and
then
prunes
that
object
from
the
kubernetes
api
server.
B
This
also
gives
us
an
opportunity
to
have
better
indexing
and
searching,
and
you
can
search
for
failed
test,
runs
that
took
more
than
30
minutes
in
the
last
20
days,
which
is
not
something.
As
far
as
I
know,
you
can
do
with
the
kubernetes
field
selector
today,
but
unfortunately,
this
means,
like
we
lose
all
of
the
some
of
the
nice
ecosystem,
stuff
of
like
kube
control,
doesn't
work,
and
all
of
these
things
need
to
be
sort
of
custom
built
to
support
that.
B
A
It
we're
gonna
okay.
What
so?
What?
What
can
we
do
about
this?
Well,
we
could
do
nothing,
which
is
my
first
option.
I
always
present
everybody
in
my
organization.
What
what
does
doing
nothing
mean,
keep
going
around
it
yeah
we
just
keep
working
around
it,
it's
kind
of
value-added
for
both
tecton
and
argo.
You
know
because
kubernetes
doesn't
support
this
out
of
the
box.
We
get
to
add
that
value
to
it
and
if
it
was
supported,
we
wouldn't
get
to
that.
What
we
could
do.
A
We'll
never
do
that
again,
so
what
it
would
be
great
to
kind
of
add
some
additional
features
to
kubernetes.
So
one
of
the
things
would
be
an
api
to
start
and
stop
containers
that
would
be
fantastic
like
a
container
sub
resource
or
something
on
those
sort
of
lines.
Where
you
can
say,
stop
the
container
start,
the
container
don't
start
this
container
just
yet
it
would
be
nice
to
be
able
to
declare
the
daggers
a
dependency
tree
with
inside
the
container.
Spec,
so
say,
container
two
is
dependent
on
container
one.
We
could
have
that.
A
A
That
would
allow
you
to
use
kubectl,
exec
or
curl
to
just
invoke
commands
on
it,
and
it
would
deal
with
it
for
you
and
for
resource
quota,
so
people
use
resource
coders
to
limit
the
number
of
custom
resources
in
a
name,
space
typically
used
for
limiting
number
of
pods,
but
you
can
use
it
for
customer
resources,
but
it'd
be
nice.
If,
in
that,
we
could
specify
what
to
do
when
there
are
too
many.
A
You
know
some
kind
of
strategy
saying,
for
example,
delete
the
oldest
one
of
these
custom
resources
and
kind
of
clean
up
afterwards.
I
think
that
would
be
pretty
neat.
I
guess
we
freestyle
a
lot
of
these
ideas.
Don't
we
yeah
yeah,
so
I
think
it's
kind
of
like
an
interesting
space
to
kind
of
think
around
in
it
yeah.
B
So
the
question
was
given
the
a
common
use
case
for
tecton
at
least,
is
clone
some
source
from
a
repo
and
then
build
it
run
tests
do
other
stuff
scan
it
do
you
know,
let's
say
five
other
things
in
parallel.
Currently
today
we
we
would
ask
you
to
make
a
pvc
to
have
one
task
right,
write
that
data
to
a
pvc
and
then
share
that
pvc
read
only
to
the
other
ones.
There's
some
and
obviously
there
are
downsides
to
that
of
now.
You
have
this
pvc.
B
You
have
to
clean
up
or
at
least
have
a
round,
and
it
can
limit
your
schedule
ability
of
those
things.
There's
some
interesting
work
going
on
in
being
able
to
run
all
of
a
pipeline
in
one
pod
so
effectively
that
would
you
would
have
one
big
pod
that
does
all
the
resources
of
all
of
those
things
and
they
would
run
in
one
shared
on
the
same
node.
But
in
that
way
you
wouldn't
have
to
write
the
persistent
data
outside
of
the
execution
of
that
pod.
There's.
B
Yeah,
so
so
you
can
also
do
the
sorry.
The
follow-up
was
instead
of
using
pvcs.
Could
you
write
to
some
external
object,
store,
s3
gcs,
whatever?
Absolutely
that's,
that's
absolutely
an
option.
It
has
more
or
less
all
the
same
problems
as
pbcs.
You
have
to
write
this
data
somewhere
and
it
costs
money
while
it
sits
there
and
costs
money
to
delete
it
and
it
costs
money.
Or
you
know
it's
management,
overhead.
B
A
A
B
Don't
I
think
we
did,
I
mean
it
has
all
of
the
same
api
server,
scalability
problems
right
like
if
that's,
if,
if
that's
your
message,
bus,
if
the
way
you
communicate
between
containers
in
a
pod
or
pods
in
a
workflow,
it's
sort
of
you
might
be
able
to
get
by
with
it.
But
it's
going
to
going
to
be
plagued
by
all
the
problems
we've
described
here,
which
is
it's
not
built
for
this?
It's
not
designed
for
that
scale,
so,
maybe
like
by
all
means
we
can
experiment
and
see
what
what
falls
over.
A
B
A
A
Might
want
the
resources
and
I
feel,
like
the
one
contractual
promise
kubernetes
gives
you
is.
I
will
kill
your
pod
at
some
point.
I'm
going
to
kill
your
pod
when
you
don't
want
it
and
it's
a
really
hard
problem
to
solve,
because
we're
trying
to
run
really
reliable,
robust
workloads
on
kubernetes
and
those
two
things
are
a
diametric
opposition
yeah.
They
they
are
fighting
against
one
another
and
there
are
kind
of
mitigating
actions
you
can
take
like
a
pod
disruption
budget,
for
example
in
workflows.
A
The
main
thing
we
do
is
allow
you
just
retry
those
steps
automatically
and
things
like
retry
them
on
a
different
node
within
your
cluster
chain
change
where
it
gets
through
one.
That's
the
main
thing
that
we
do
and
the
good
thing
to
do-
and
I
don't
know
if
the
case
with
tekton
is
is-
is
don't
have
very
long
running
processes
which
take
an
hour
to
run
cost
an
absolute
fortune
and
if
they
get
55
minutes
into
that
being
terminated
gracefully.
A
A
B
I
mean
in
fundamentals,
so
so
this
points
to
another
like
way
in
which
kubernetes
was
not
designed
for
this
kubernetes
is
designed
for
replicated
serving
workloads
where,
if
somebody
unplugs
a
node,
it
should
be
fine
right.
We
very
much
need
that
pod
to
finish
for
the
next
one
to
start
and
things
to
work
so
sort
of
a
difference
of
assumptions
between
what
kubernetes
assumes
and
what
we
assume
yeah.
A
Good
we're
good,
okay,
any
more
questions,
all
right.
So
just
one
more
thing,
if
you
want
to
find
out
more,
oh,
has
the
size
gone
a
bit
strange
on
this,
yes,
never
mind.
I
don't
know
why.
That
text
is
so
small.
You
can
I'm
at
the
intuit
booth
today
we're
in
zone
stage
I'll
be
on
the
booth
from
3
30.