►
From YouTube: What a Life! - Understanding the Lifecycle of a Tekton Pipeline - Vibhav Bobade & Billy Lynch
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
What a Life! - Understanding the Lifecycle of a Tekton Pipeline - Vibhav Bobade, Lifesaver Inc & Billy Lynch, Google
Tekton leverages Kubernetes to execute user CI/CD workloads -- but how does this work? In this talk, we will dive into how Tekton processes Tasks -- how they are transformed into running Pods, how steps coordinate with each other, what security considerations Tekton puts in place, and how other Tekton tools hook into this lifecycle for debuggability and software supply chain security. Come get a better understanding of how Tekton Pipelines work today, and get a peek at what problems we want to tackle next to further secure user workloads.
A
A
B
B
B
You
can
also
see
that
each
task
has
a
bunch
of
steps
defined
in
them
which
actually
carry
out
the
workloads,
and
these
are
just
like
logical
boundaries
that
have
been
drawn
to
make
it
easier
to
create.
These
resources
where
pipeline
is
compose
is
composed
of
tasks
and
tasks.
Individual
tasks
compose
steps.
B
B
So
when
I
said
earlier
that
tecton
creates
his
own
resources
such
as
tasks
task
runs,
pipeline
pipeline
runs.
What
do
I
even
mean
by
that?
So
in
kubernetes
you
have
your
own
native
resources
such
as
pods
or
daemon
sets
stateful
sets.
Similarly,
you
can
create
your
own
resources
using
custom,
resource
definitions
and
techton
does
something
similar.
B
In
this
case,
we
have
an
example
here,
where
we
have
a
pipeline
run
where
we
have
given
the
specification
of
the
pipeline
and
instead
of
referencing
a
task
inside
we've,
also
given
a
specification
of
a
task
with
a
single
step
where
we
are
running,
the
task
called
echo
message,
which
runs
a
step
of
executing
the
echo
hello
world
script
in
a
ubuntu
image
to
give
us
output
hello
world
in
the
container.
So
when
you
have
a
lot
of
tasks
and
pipelines
running
in
your
cluster,
you
would
definitely
consider
using
reusable
resources
right.
B
So,
in
this
case,
you
can't
always
define
all
the
tasks
in
your
cluster,
so
it'll
it'll
be
easier
if
you
could
just
like
reference
a
task
from
a
you
know,
third
party
registry
somewhere.
So
in
this
case
you
can
see
that
in
the
first
actually
the
second
task
defined
here,
which
is
called
echo
world.
In
this
example,
you
can
see
that
task
graph
has
something
called
a
bundle
which
is
being
used
which
is
defined
as
registry.example.com
echo,
and
basically,
what
is
being
done
is
the
task
is
not
defined
in
the
kubernetes
cluster
itself.
A
All
right,
so,
let's
take
a
quick
look
at
how
a
resource
is
created,
so
this
applies
to
any
tectonic
resource.
Whether
it's
a
pipeline
pipeline
run
task
run
anything
like
that
and
if
you're
familiar
with
kubernetes
crds,
then
this
should
be
pretty
familiar.
So
all
of
these
resources
go
through
are
created
through
the
kubernetes
api,
so
tekton
itself
is
agnostic
to
where
these
come
from,
so
it
could
be
the
user
calling
it
directly
with
client
go
cubecontrol
or
it
could
be
another.
A
You
know
piece
of
software,
calling
it
tactile
triggers
jenkins
x.
Anything
like
that.
This
goes
to
the
criminals
api,
which
does
some
basic
rbac
checks,
so
you
can
define
policies
for
who's
allowed
to
create
runs
whose
later
query
pipelines,
edit
them
and
so
on
from
there.
It
goes
through
a
mutant
and
emission
web
hook.
So
this
is
a
book
that's
installed
by
tekton,
and
these
this
does
things
like
set
defaults,
sort
of
set
some
other
common
basic
values
within
the
resource
that
you're
creating.
A
Then
that
is
sent
to
the
validation
emission
webhook,
which
then
validates
the
object,
make
sure
that
everything
looks
good
and
then,
finally,
that
object
is
persisted
to
scd
and
eventually
from
there.
The
controller
will
pick
it
up
and
start
its
scheduling.
Let's
take
a
look
at
how
the
scheduling
works,
so
tecton
uses
a
controller
to
take
tecton
resources
and
reconcile
them
into
kubernetes
resources
that
actually
run
the
build
tactile,
watches
for
any
changes,
acts
on
them
and
then
applies
any
status
updates
back
to
the
original
crd
object.
A
So
let's
dig
into
some
of
the
things
that
the
controller
does
once
that's
done.
Another
thing
the
controller
needs
to
do
is
resolve
any
images
referenced
in
the
run,
spec
and
pin
those
to
the
exact
hash
that
was
used.
So
this
is
important
for
a
few
reasons.
One.
We
want
to
make
sure
that
everything
in
a
run
uses
the
same
image,
even
if
it's
say
like
a
pipeline
run
that
might
run
for
several
hours
so
being
able
to
pin
that
next
exact
shot
means
that
we
can
ensure
a
consistent
version
of
any
given
image.
A
Another
thing
that's
super
useful
is
for
forensics.
If
we
sort
of
need
to
look
back
at
a
run
and
see
what
was
used
so
this
could
be
for
debugging
right,
you
want
to
be
able
to
say
hey
this
image
failed.
Let
me
go
check
it
out
locally
and
see
what's
going
on
or
it
might
be,
for
hey.
There
is
an
exploit
in
this
particular
version
of
this
image.
Was
our
ci
pipeline
vulnerable
to
it
or
not?
A
So,
by
pinning
to
that
version
we
can
actually
run
that
sort
of
queries
and
analysis,
so
the
controller
actually
does
a
lot
more.
But
probably
the
most
interesting
piece
is
how
tactile
objects
actually
get
ran
on
a
grenade's
cluster,
so
for
every
task
run,
tactile
will
create
a
matching
pod
to
actually
run
the
build.
A
A
This
process
is
exactly
the
same
for
pipeline
runs,
so
techton
will
spawn
a
task
run
owned
by
the
pipeline,
run
for
each
task
of
the
spec,
and
then
each
of
those
will
be
converted
to
podge
just
like
before
all
right.
So
let's
walk
through
an
example
of
what
it
actually
looks
like
to
schedule
a
pipeline
run
on
a
user
cluster.
So
here
we
have
an
example.
A
Pipeline
runs
pretty
simple,
two
tasks
right
that
will
run
one
after
the
other,
so
this
will
come
in
the
technical
controller
will
see
it
it'll
resolve
any
refs
it'll
resolve
any
images.
It'll
say
all
right:
we
are.
We
are
ready
to
start
to
start
scheduling
things
so
we'll
start
with
task
number
one.
A
This
is
going
to
create
a
subtask
run,
that's
owned
by
the
pipeline
run
from
there.
The
attack
type
controller
will
see
the
task
run
and
say
hey.
I
need
to
go,
create
a
pod
in
response
to
this,
so
that
pod
will
execute
it'll,
run
the
user
containers
and
then
once
that's
done
that
will
get
cleaned
up
the
tech
time
controller
will
see.
Oh
hey,
the
pod
is
done,
so
the
task
run
is
done
so
it'll
clean
that
up
then
it'll
say
all
right.
A
A
A
So
what
we're
really
going
to
do
now
is
is
dig
into
what
it's
doing,
what
it's
writing,
how
that
works.
So
a
lot
of
this
is
controlled
by
a
special
directory
that
tech
time
reserves.
So
it's
called
slash
tech
time
that
can
be
found
on
the
container
file
system,
and
this
file
system
has
a
bunch
of
data
related
to
tools
that
tech
time
provides,
as
well
as
some
of
the
status
data
that
the
user
containers
will
write
back.
So
we're
gonna
step
through
this
step
by
step
and
and
learn
more
about
it.
A
So
tekton
has
something
called
the
entry
point
or
entry
pointer.
So
this
is
the
main
binary
that
runs
on
the
container
within
the
pod
for
each
step,
that
sort
of
coordinates
how
this
container
is
actually
gonna
run.
So
one
of
the
difficulties
with
with
user
containers
is
that
kubernetes
wasn't
meant
to
run
containers
sequentially.
A
So
we
need
to
do
a
little
bit
of
custom
logic
here
to
make
sure
that
everything
runs
runs
smoothly.
So
the
entry
points
are
responsible
for
a
few
different
things.
It's
responsible
for
this
ordering
it's
responsible
for
if
users
provided
scripts,
making
sure
that
those
are
made
available
to
the
user
container
and
are
actually
executed
and
then
finally,
it
also
takes
the
output
of
of
the
of
the
step
and
sort
of
formats
in
a
way
that
we
can
make
it
available
to
the
controller
again.
A
A
So
here's
an
example
of
basically
how
this
flow
works
right.
So
each
step
has
its
own
container.
Each
container
has
its
own
entry
point.
Every
entry
point
is
configured
to
basically
wait
for
a
particular
file
to
be
present
and
be
populated,
basically
as
its
signal
for
the
container
to
start
running
or
the
user
command
to
start
running.
A
So
from
the
very
start,
the
tactican
controller
will
populate
a
file
in
via
the
downward
api,
which
is
an
api
made
available
to
pods
for
propagating
crd
and
object
information
down
to
the
actual
running
pod.
So
tekton
uses
this
as
basically
the
starting
point
for
saying:
hey
ghost
go
start
running
this
thing,
so
this
is
configured
for
the
first
step
step.
Zero
it'll
wait
for
this
file
once
that's
ready,
it'll,
say:
okay,
let's
go
over
in
the
user
command
and
when
it's
done
it
will
output
the
next
file.
A
So
this
will
be.
You
know,
slash
tech
time,
slash,
run,
step
zero
because
of
the
first
step,
slash
out
and
then
step
the
next
step
step.
One
is
configure
to
wait
for
that
file
to
exist
as
its
signal
to
then
start
running.
The
next
step-
and
so
this
is
configured
in
a
chain,
and
so
you
can.
This
can
be
as
long
as
you
want
and
it
will
just
keep
going
down
until
you
know
all
steps
have
executed.
A
So
one
of
the
problems
about
sort
of
this
file
based
approach
is
because
containers
running
on
the
same
pod
can
have
access
to
the
same
file
system.
This
is
actually
a
little
bit
problematic
because
you
can
imagine
some
scenarios
where,
if
you
have
a
malicious
container,
that
is
say
populating
output
files
that
it
shouldn't
be
say
for
other
steps
or
their
exit
codes
right,
you
can.
A
You
know
this
can
cause
some
problematic
situations,
because
now
you
can't
necessarily
trust
the
output
that
you're
getting
from
these
steps,
or
you
can
have
you
know,
a
malicious
container
causing
all
other
containers
to
run
at
once,
which
would
break
some
of
the
assumptions
about
that
ordering
that
we
had
before
so.
The
tecton
has
done
some
work
to
basically
ensure
some
isolation
between
steps,
and
so
basically
what
happens
is
within
these
run.
Folders
every
step
is
assigned
their
own
folder,
which
is
backed
by
their
own
volume.
A
Local
to
to
that
pod,
and
so
for
every
step
they
have
a
matching
volume
which
only
they
have
read,
write
access
to
any
other
step
that
wants
access
to
to
the
data.
There
say
for
the
weight
files
or
for
anything
else,
they
are
only
ever
granted
read-only
access,
so
this
doesn't
necessarily
stop
a
container
from
outputting
bad
results
for
its
own
step.
But
what
it
does
prevent
is
one
container
sort
of
mucking
with
the
state
of
other
of
other
steps
within
the
same
task.
B
So
the
results
that
we
saw
back
in
the
tecton
directory
over
there
we
can
see
that
these
results
are
written
into
a
particular
directory,
sorry
in
in
a
particular
path
in
the
tecton
directory.
Now
these
results
can
be
read
from
written
by
tasks
and
read
by
tasks
themselves.
Now
you
can
see
examples
over
here
on
the
operations
that
we
can
do
for
the
results.
B
B
What
you
can
do
is
you
can
use
a
debugging
feature
in
tecton,
so
this
feature
is
available
as
an
alpha
feature
for
task
runs
itself
right
now,
and
there
is
support
for
break
point
on
failure,
which
means
that
if
your
task
fails
at
that
point,
the
task
run
will
halt
and
you
will
be
able
to
ssh
or
like
get
remote.
Shell
access
into
the
task
run
container
that
you
want
to
debug,
and
then
at
that
point
you
can
just
go
ahead
and
debug
your
task.
B
So
what
happens
here
is
when
your
container
starts
running.
If
the
previous
step
has
failed
or
the
the
step
currently
running
step
has
failed.
What
happens
is
instead
of
moving
on
to
the
next
step,
the
container
basically
hauls,
and
then
it
keeps
running
it
does
not
send
out
the
exit
codes.
It
does
not
exit
it
keeps
running.
This
is
this
is
because
of
the
way
the
entry
point
is
made
that
it
has
to.
B
It
has
to
have
an
output,
and
only
then
the
entry
point
will
kind
of
you
know
stop
running,
and
you
know
go
ahead
to
the
next
step.
So
for
that,
what
me
what
it
means
that
the
post
file
has
to
be
written
and
only
then
the
next
container
will
know
that
okay,
the
post
file
has
been
written,
that's
the
file
I've
been
waiting
on
and
then
I
should
start
executing.
B
On
the
left
hand
side
you
can
see
that
the
debug
mount
that
is
done
in
the
container
during
debugging
contains
the
information
on
the
index
of
the
con
of
the
step
that
we
are
looking
at.
So
in
this
case
we
are
trying
to
debug
a
task
run
which
is
failing
on
the
second
step,
which
is
index
one.
So
you
can
see
that
the
info
has
the
one
volume
over
there
and
this
changes
from
step
to
step.
B
So
this
is
what
basically
info
is,
and
the
scripts
over
here
that
you're,
seeing
basically
a
debug,
continue,
will
say
that
okay,
I'm
done
debugging
the
container,
I'm
done
debugging
the
step,
and
I
want
to
move
on
to
the
next
step,
and
you
would
only
do
this
if
you
have
gone
through
the
entire
volume.
You
know
what
is
wrong,
you
fixed
it
and
then
you
know
you're
going
ahead
else.
You'll
do
debug
fail,
continue
and
in
this
case
the
in
the
first
case
actually
debug
continue.
B
The
step
will
be
marked
as
a
success,
whereas
in
the
dework
field
continue,
the
step
will
be
marked
as
a
failure.
Now,
when
these
scripts
run
what
is
exactly
happening,
which
is
triggering
the
success
and
failure
or
the
exit
of
this
break
point,
what
is
happening
is
when
you
run
debug
continue.
We
are
writing
the,
as
you
can
see
here,
zero,
the
step,
the
previous
step
index.
Zero
has
out
and
out.breakpoint
exit
already
written.
So
basically
it
was
something
that
was
debugged
and
then
it
was
marked
as
a
success.
B
So
that's
why
out
was
written
and
that's
why
out
dot
breakpoint
exit
was
written.
Out.Breakpoint
exit
wouldn't
be
here
if
debug
continue
scripts
weren't
run,
so
we
once
we
run
debug
continue
our
debug
fail
continue.
We
will
have
outputs
in
the
run
directory
for
the
directory
with
index
one,
and
you
will
see
out
dot
error
if
you
run
debug
field
continue.
If
you
run
debug
continue,
you'll
see
out
and
out.breakpoint.exe
to
run
these
debug
steps.
B
A
Okay,
so
at
this
point
the
pod
is
done,
the
task
run
is
completed,
but
there's
actually
more
to
the
life
cycle
than
just
sort
of
what
runs
within
the
pod
itself.
So
there
could
be
many
many
things
that
sort
of
run
after
the
fact.
So,
if
you're
interested
in
supply
chain
security,
there's
projects
like
tecton
chains,
that
will
basically
look
at
hey
what
what
actually
ran
what
was
produced.
A
Can
we
sign
these
things
and
can
we
sign
the
build
config
itself
as
sort
of
an
attestation
for
what
ran
so
this
would
be
sort
of
after
the
fact
you
could
have
actions
that
that
happen
afterwards.
So
you
know,
say:
hey
fire
off
a
cd
event
to
say
that
this
was
completed
or
depending
on.
If
it
passed
or
failed,
hey,
go
update
my
commit
status
either
on
github
or
the
other
thing
that
might
happen
is.
A
It
wasn't
really
meant
for
a
historical
log
of
every
ci
run
that
ever
ran
on
the
cluster,
and
so
that
you
know
this
is
potentially
an
issue,
because
if
you
run
ci,
you
know
eventually
days
months
weeks
after
the
fact
you're
eventually
gonna
hit
a
point
where
etcd
just
can't
handle
it
and
your
cluster
just
sort
of
grinds
to
a
halt,
because
there's
just
so
many
objects
that
it's
storing
so
there's
projects
like
tecton
results.
That
will
say
hey.
A
You
know
for
runs
that
are
you
know,
recently
completed
and
we're
reasonably
confident
that
they
are
done.
Let's
go
archive
those
into
a
different
database
that
can
be,
you
know,
searched
and
queried
later
on
and
then
also
in
a
similar
vein.
We
also
get
asked
quite
a
lot
about
okay.
What
about
log
exporting?
A
How
do
I
make
sure
I
preserve
my
ci
logs
either
for
in
you
know,
investigations
after
the
fact
or
anything
like
that,
so
the
nice
thing
about
tectonic
kubernetes
is
that
any
sort
of
log
exporting
tools,
fluenty
grafana,
anything
like
that
that
work
with
pods
also
work
with
tekton.
So,
even
though
tekton
doesn't
necessarily
have
its
own
baked
in
solution
for
log
exporting,
you
know
in
a
lot
of
ways
we
don't
have
to,
because
there
are
already
so
many
other
great
tools
that
are
around
this
purpose
already.
A
A
There's
also
a
lot
of
really
really
cool
work
going
on
for
extending
you
know,
extending
runs
for
other
custom
types,
things
that
don't
run
at
kubernetes
clusters
with
with
custom,
runs
spiffy
spire
support,
hermekton
for
further
locking
down
supply
chain
security
and
the
capabilities
that
ci
has
access
to
within
your
cluster,
I
think
is
gonna
be
huge
as
well
as
some
other
nifty
things
around.
How
do
we
schedule
things?
Can
we
schedule
multiple
tasks
on
the
same
pods
stuff
like
that?