►
From YouTube: Lessons Learned Evolving K8s Extensions: The Future Of Tekton Pipelines - Lee Bernick, Google
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
Lessons Learned Evolving K8s Extensions: The Future Of Tekton Pipelines - Lee Bernick, Google
When extending Kubernetes, how do you map extensions to Kubernetes resources? You may have heard of Tekton, a cloud native CI/CD framework built with Kubernetes CRDs. Today, the specification of a Tekton resource is tightly coupled to its execution in Kubernetes. A Step is run in a Container, a Task is run in a Pod, and a Pipeline is run in a set of Pods. This coupling introduces challenges including optimizing resources, moving data through Pipelines, and distributing workloads. Users need more flexibility.
In this talk, you’ll hear lessons learned from decoupling Tekton resources from their execution in Kubernetes. In particular, Tekton is experimenting with allowing entire Pipelines to be executed in a Pod. We’ll demonstrate how executing a Pipeline in a Pod can improve execution times and the user experience of passing data through a Pipeline. You’ll also hear about challenges we’ve encountered along the way, and gain clarity on the future of Tekton Pipelines.
A
A
The
tecton
mission
is
to
be
the
industry
standard
platform
for
ci
cd
and
because
it's
meant
to
be
a
platform
rather
than
just
a
product,
it's
meant
to
be
really
flexible.
This
is
what
one
user
had
to
say
about
it.
I
always
compare
tecton
to
a
buffet
where
you're
given
the
raw
ingredients,
but
you
have
to
cook
it
yourself
versus
a
buffet
of
pre-made
items.
You
have
more
flexibility
but
more
work
to
do
so.
A
So
this
presentation
is
going
to
be
about
this
tweet
why
this
user
is
so
frustrated
and
some
ongoing
experimental
work
that
we're
doing
to
try
and
fix
this
and,
if
you're,
already
a
techton
user.
You
might
be
familiar
with
this
problem,
but
I'm
going
to
spend
a
couple
minutes
just
catching
up
on
why
this
is
necessary
in
tecton
today.
A
So
as
an
example,
if
we
have
a
nightly
release
pipeline,
that
might
include
a
clone
task
with
a
single
step
that
clones
a
repo
and
then
a
build
and
push
task
with
two
steps:
one
that
builds
a
docker
image
and
one
that
pushes
that
image
to
a
repository
tasks
and
pipelines
are
meant
to
be
generic.
So
they
don't
do
anything
by
themselves.
You
have
to
run
them
in
task
runs
and
pipeline
runs.
A
So
here's
what
a
pipeline
run
might
look
like
for
a
nightly
release
pipeline.
It
has
a
reference
to
the
pipeline.
We
want
to
run
and
it
has
some
inputs
that
the
pipeline
needs
to
do
its
job,
so
the
repo
that
we
want
to
clone
and
the
image
that
we
want
to
build
today.
Users
kind
of
need
to
understand
how
their
tecton
workflows
are
run
on
kubernetes,
and
so
currently
we
run
each
task
run
in
its
own
pod.
A
A
If
you're
familiar
with
pods,
you
might
notice
that
there
is
something
I
haven't
explained,
which
is
that
pods
don't
share
data
storage
by
default.
So
how
does
the
repo
that
was
cloned
on
the
first
pod
make
its
way
onto
the
build
and
push
pod
in
tecton?
The
abstraction
for
this
is
called
workspaces
which
allow
each
task
in
a
pipeline
to
specify
where
they
want
to
read
data
from
and
write
data
to.
A
So
here
our
clone
task
would
write
to
a
workspace
that
holds
this
repo
and
the
build
and
push
task
would
read
from
that
workspace
in
kubernetes.
This
translates
to
a
persistent
volume
claim,
which
is
a
request
for
some
persistent
storage
that
is
mounted
to
both
of
these
pods,
and
it's
worth
noting
that
our
build
and
push
task
run
has
two
steps
in
it,
as
opposed
to
being
two
separate
tasks,
because
docker
kind
of
abstracts
away
this,
where
the
where
the
files
are
stored.
A
A
We
specify
that
we'd
like
tekton
to
create
for
us
a
persistent
volume
claim
with
one
gigabyte
of
storage
and
a
read,
write
once
access
mode,
which
means
that
this
persistent
volume
claim
will
be
readable
and
writeable
from
one
node
at
a
time
putting
it
all
together.
Here's
the
pipeline
run
I'll
be
showing
in
the
demo
today
it
has
the
parameters
and
the
workspaces
that
I
discussed
so
I'll
quickly
show
what
this
looks
like
so
first
thing
is
we'll
apply
our
pipeline
run
to
the
cluster
and
observe
its
progress,
and
the
pipeline
run.
A
Controller
creates
task,
runs
for
each
task
in
the
pipeline.
So
let's
take
a
look
at
those.
We
can
see
that
there's
a
clone
task
run
and
once
that's
completed,
you'll
see
this
build
task
run
being
created
to
run
the
second
task.
The
task
run.
Controller
is
responsible
for
creating
a
pod
to
run
each
of
these
task
runs.
A
A
A
So
that's
really
the
user
experience
that
we're
trying
to
address
with
this
proposal,
similar
to
how
docker
was
able
to
abstract
away
this
idea
of
where
the
files
are
stored.
We
similarly
would
like
to
kind
of
improve
our
abstractions,
so
users
don't
feel
like
they
have
to
glue
tasks
together
in
this
way.
So
it's
not
so
difficult
to
feed
data
through
your
pipeline.
A
Another
element
of
the
user
experience
that
we're
trying
to
improve
that
is
not
immediately
obvious
from
our
api
is
a
problem.
With
these
persistent
volume
claims.
Persistent
storage
is
not
always
writable
for
multiple
nodes.
Depending
on
what
your
provider
offers
in
the
example
that
I
used
today,
we
saw
that
the
persistent
volume
claim
used
a
read,
write
once
access
mode,
so
readable
and
writable
from
one
node
at
a
time.
What
this
means
for
tekton
is
that
it
can
be
difficult
to
use
parallel
tasks
that
share
the
same
workspace.
A
The
user
is
essentially
forced
to
choose
between
truly
running
these
tests
in
parallel
and
allowing
them
to
be
scheduled
to
whatever
node
makes
the
most
sense
to
hold
them,
even
though
that's
not
immediately
obvious
from
our
api.
So
that's
another
user
experience
challenge
that
we're
trying
to
address
in
addition
to
these
user
experience
challenges
there.
Also,
there
are
also
some
performance
implications.
A
A
A
The
first
of
these
solutions
is
the
ability
to
schedule
task
run
pods
to
the
same
node,
and
this
is
actually
a
feature
that
already
exists
in
tekton
is
called
the
affinity
assistant
and
it
automagically
schedules
task
runs
that
share
workspaces
to
the
same
node,
and
so
this
allows
you
to
run.
These
task
runs
in
parallel,
but
it
doesn't
address
this
user
experience
challenge
of
having
to
understand
why
that's
necessary,
and
it
also
doesn't
allow
the
kubernetes
scheduler
to
schedule
these
pods
to
where
they
make
the
most
sense.
A
The
next
feature
request
that
I
want
to
discuss
is
a
feature
request
for
parallel
steps,
and
I
think
that
the
motivation
behind
this
feature
request
was
wanting
to
combine
multiple
pieces
of
functionality
in
flexible
ways.
The
way
we
allow
users
to
combine
tasks
in
a
pipeline,
but
to
do
it
all
in
one
pod,
and
with
this
we
were
concerned
that
people
would
try
to
stuff
an
entire
pipeline's
worth
of
functionality
into
one
pod
or
into
one
task,
and
that
people
would
be
confused
about.
A
When
should
I
write
a
task,
and
when
should
I
write
a
pipeline,
so
we
decided
not
to
pursue
this
feature
request
the
last
alternative
solution
that
I'll
discuss
today,
although
this
is
not
an
exhaustive
list,
is
allowing
tasks
to
contain
other
tasks.
This
is
also
implemented,
but
it's
not
part
of
the
tecton
pipelines
api
right
now.
A
So,
going
back
to
this
example
of
cloning,
a
repo
and
running
tests
in
parallel,
you
could
write
this
as
the
unit
test
task
containing
a
clone
task
and
the
lint
task
also
containing
a
clone
task.
But
then
you
have
a
git
clone
running
twice,
so
the
solution
doesn't
work
quite
as
well,
for
these
more
complex
use
cases,
which
is
why
we
probably
won't
be
bringing
this
into
our
api.
A
The
co-located
here
is
meant
to
signify
that
all
these
tasks
run
in
a
co-located
manner,
and
it's
really
inspired
by
this
data
locality
problem
that
we're
trying
to
address
and
here's
what
a
co-located
pipeline
run
might
look
like.
So
similarly
to
the
pipeline
run.
It
has
a
reference
to
the
pipeline.
We
want
to
run.
It
has
the
parameters
that
we've
seen
before,
but
one
of
the
main
differences
is
this
workspaces
field.
A
So
it
would
be
great
if,
instead
of
having
to
specify
where
you
wanted
your
data
to
be
stored,
if
tecton
could
just
create
a
volume
for
any
workspaces,
you've
declared
in
your
pipeline
and
just
kind
of
handle
that
for
you,
this
isn't
what
I'll
be
showing
today
today
I'll
be
showing
the
current
experimental
iteration
of
this
proposal,
and
for
this
we're
using
a
tekton
api
extension
called
a
run.
This
can
be
any
type
here.
A
It's
a
kind
co-located
pipeline
run
and
it
can
be
embedded
within
a
pipeline
and
integrates
nicely
with
tecton
in
other
ways,
and
we
see
that
we
still
have
this
workspaces
field,
so
we're
still
asking
people
to
declare
where
they
want
to
store
their
data,
but
we're
using
an
empty
der
volume
which
shares
a
lifetime
of
the
pod.
And
it
doesn't
have
some
of
these
same
problems
with
being
slow
to
spin
up
in
the
same
way
that
a
persistent
volume
claim
would
be
so
I'm
going
to
go
ahead
and
show
what
this
looks
like.
A
And
take
a
look
at
the
run
that
is
created,
and
here
there
are
no
task
runs,
there's
just
the
one
pod,
so
we
can
kind
of
observe
this
pod's
progress
and,
just
as
we
have
a
pipeline
run,
controller
that
manages
pipeline
runs
and
a
task
run.
Controller
that
manages
task
runs
here.
We're
just
using
a
co-located
pipeline,
run
controller
that
manages
this
co-located
pipeline
run
and
while
each
step
is
still
run
in
its
own
container,
each
task
now
corresponds
to
a
group
of
containers
rather
than
a
full
pod.
A
So,
for
example,
we
could
take
a
look
at
the
container
that
is
running
the
clone
step.
The
logs
of
that
container.
This
looks
reasonable
what
I
would
expect
from
a
git
clone,
and
if
we
take
a
look
at
artifact
registry,
we
can
see
that
there
is
now
an
image
push
that
is
tagged.
Co-Located
pipeline
run.
A
Lastly,
I
wanted
to
see
what
would
happen
if
we
really
pushed
up
the
number
of
tests
tasks
in
this
pipeline,
so
I
created
a
pipeline
with
50
tasks.
This
is
actually
not
unrealistic.
There
are
some
techton
users
that
are
running
pipelines
with
this
many
tasks
and
each
of
these
tasks
just
waits
for
five
seconds,
so
the
ideal
run
time
of
the
pipeline
should
be
five
seconds.
A
Of
course,
that's
not
what
actually
happens
a
pipeline
run
takes
almost
a
minute,
and
a
co-located
pipeline
run
saves
about
half
of
that
time.
So,
there's
definitely
a
lot
of
promise
here
for
improving
performance
with
this
co-located
pipeline
run,
but
we
need
to
do
more
work
to
understand
where
the
biggest
performance
improvements
are
coming
from,
if
it's
creating
fewer
pods,
not
creating
these
persistent
volume
claims
reducing
the
load
on
the
api
server
or
something
else,
or
some
combination
of
all
these
things.
A
There
isn't
really
a
good
way
to
create
tasks
after
the
pipeline
has
started
executing.
We
have
to
know
what
all
the
tasks
will
be
at
the
start
of
the
pipeline
and
so
where
the
pipeline
run
might
be
able
to
create
tasks
depending
on
what
happened
in
previous
tasks.
That's
something
not
something
we'd
be
able
to
do
with
a
collocated
pipeline
run.
A
A
A
So
all
the
information
about
the
status
of
the
various
containers
and
things
like
that,
and
what
we
saw
was
that
this
custom
resource
definition
got
really
big
started,
running
into
size
limits
and
increased
the
load
on
the
api
server
and
we've
offloaded.
Some
of
the
information
to
task
runs
to
fix
this
problem,
but
there's
not
an
equivalent
fix
that
we
could
do
for
co-located
pipeline
runs
so
there's
some
concerns
that
we
might
run
into
these
size
limits
again
and
so
we'll
need
to
experiment
a
little
more
with
this
to
see
how
that
works.
A
That
brings
me
into
the
future
work
that
we
have
planned
for
this
project.
So,
as
I
mentioned,
we
really
want
to
dog
food.
This
more
extensively
see
what
aspects
of
the
user
experience
it
improves
and
what
aspects
could
use
a
little
more
polishing,
and
I
would
love
for
everyone
here
to
be
dog
footing
it
as
well.
That
would
be
really
cool.
A
A
This
project
has
taken
quite
a
bit
of
work,
and
so
I
just
want
to
take
a
minute
to
thank
some
of
the
contributors
who
have
helped
make
this
possible,
and
some
are
here
today
and
you
could
be
one
of
them
too.
So
if
you
have
feedback
on
this
project,
please
feel
free
to
contact
us
on
slack
or
contact
me
directly
and
please
feel
free
to
try
this
project
out
on
our
github.
A
A
A
A
A
A
If
there's
a
way
we
can
set
compute
resources
for
a
task
itself,
and
here
we're
going
to
have
to
think
about
how
to
combine
these
compute
resources
when
you
can
run
multiple
tasks,
both
sequentially
and
in
parallel
in
one
pod.
So
that's
definitely
another
challenge
that
we'll
need
to
address
and
think
about
how
that'll
work.