►
From YouTube: Scaling Pipelines with Tekton - Andrea Frittoli, IBM
Description
Scaling Pipelines with Tekton - Andrea Frittoli, IBM
Speakers: Andrea Frittoli
There are many dimensions to scalability in the context of continuous delivery (CD). Authoring, maintaining and executing tasks, pipelines and complex CD workflows all have their flavour of scalability challenges. In this talk, we discuss how Tekton tackles each of those areas. We present the scalability challenges we faced when using Tekton to continuously deliver Tekton itself, and the solutions we built and continue to develop to make tasks and pipelines practically reusable, maintainable and scalable at runtime.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
A
A
A
We
have
two
links
like
the
cli
called
dkn,
a
nice
dashboard
and
then
open
it
or
operator
to
manage
the
installation
and
upgrades
of
tecton
for
discovery
of
tasks.
We
have
catalog
and
hub
we'll
discuss
about
them
later
more
details,
and
we
also
have
several
add-ons
like
the
results,
project
chains
and
multiple
experiments
that
we
are
running
a
bit
of
history.
A
A
So,
let's
dive
into
authoring
with
tactile.
So
let's
say
that
you
want
to
automate
a
certain
task
you
will
use
protect
on
some
steps.
Steps
are
basically
off-the-shelf
containers
container
images
that
you
can
announce
with
small
scripts
in
any
programming
language
that
you
might
find
useful
and
then
a
task
is
a
sequence
of
such
steps
that
solve
a
specific
problem
like
running
unit
tests
against
a
repository
or
building
a
container
image
or
deploying
an
artifact
somewhere.
A
So
if
you
work
as
part
of
a
team
in
an
open
source
project
or
in
a
large
organization,
then
it
makes
sense
for
this
task
to
be
shared
across
the
organization
which
allows
for
to
distribute
the
maintenance
work
on
this
task.
So
it
allows
to
to
scale
the
work
of
writing
and
maintaining
the
task
so
that
each
team
does
not
have
to
run
rewrite
their
own
and
reinvent
the
wheel
continuously.
A
A
A
A
One
aspect
to
keep
in
mind
as
well
is
portability.
This
is
an
area
that
we
are
also
still
exploring,
because
we
do
have
support
for
multiple
architectures
for
tecton,
for
running
the
tecton
controller,
on
top
of
different
architectures
and
but
it's
important
as
well
to
have
tasks
that
use
container
images,
and
that
includes
scripts,
which
can
be
run
against
multiple
architectures,
and
you
may
remember,
when
we
introduced
tecton,
that
we
talked
about
task,
but
also
about
pipelines.
A
Pipelines
are
a
combination
of
tasks
that
can
be
run
sequentially
or
in
parallel
and
but
can
pipeline,
be
reused
or
shared.
Well,
if
you
think
of
a
short
pipelines
like
the
one
highlighted
in
green,
you
might
have
a
very
common
sequence
where
you
clone
a
repository
and
you
build
a
containment
container
image
out
of
it.
Maybe
you
sign
it,
and
then
you
push
it
a
container
registry
and
this
kind
of
pipeline
can
be
used
as
a
as
a
reusable.
A
Block
and
you
could
use
some
things
like
conditionals
that
are
supported
by
tecton
or
optional
inputs
to
make
this
pipeline
even
more
portable.
If
you
look
at
this
picture,
for
instance,
the
clone
build
push
pipeline
is
great,
but
in
this
case
you
might
only
want
to
have
build
and
push
because
you
want
to
clone
the
reaper
one
once
and
then
use
it
to
run
multiple
things
like
build
and
push
and
test
so
having
a
conditional.
There
will
help
for
large
pipelines.
A
So,
as
I
said
you
might
want,
you
might
have
teams
that
are
responsible
for
environments
which
are
touched
by
different
parts
of
your
pipeline.
They
might
need
to
run
in
different
namespaces
or
even
in
different
clusters
or
through
different
platforms.
Maybe
some
part
of
your
pipeline
isn't
tactile,
but
maybe
you
have
other
parts
of
the
pipeline
that
maybe
already
run
in
other
platforms.
A
So
it's
a
good
idea
to
break
down
the
new
pipeline
in
multiple
pieces
and
you
can
add
small
pipelines
like
the
one
that
I
mentioned:
clone
build
boosh
and
then
every
team
can
own
the
pipeline
they're
responsible
to,
but
then
you
still
want
to
have
one
workflow.
So
how
can
you
achieve
that?
So
we
have
one
experimental
feature
which
allows
you
to
run
pipelines
in
pipelines,
so
you
can
have
a
pythons
where
you
trigger
some
pipelines
basically,
and
that
is
a
way
to
compose
the
pipelines
together.
A
An
example
of
events
could
be
a
pull
request
or
an
image
was
published
to
contain
a
registry
or
something
was
stored
in
object.
Storage,
so
triggers
has
several
components:
event
listener,
which
is
basically
the
sync
that
receives
the
events,
filters
or
interceptors.
That
allows
you
to
define
rules
on
whether
to
accept
or
not
accept
events
and
maybe
alter
or
add
something
to
the
body
and
then
binding
and
templates
which
allow
you
to
extract
information
from
the
binding
and
then
inject
them
into
the
resources
through
the
templates.
A
A
A
So
you
could
have
a
team
that
handles
the
production
environment
that
takes
care
of
the
pipeline
on
the
right-hand
side,
which
is
using
captain
as
a
platform.
And
then
you
could
have
a
team,
a
qa
team
which
is
responsible
for
tests
running
on
the
staging
environment
and
they
might
want
to
add
tests
more
tests
dynamically,
and
they
can
do
that
now.
If
they
listen
to
the
cloud
events
generated
by
the
initial
pipeline,
they
can
add
more
tests
without
having
to
change
the
overall
pipeline.
A
A
You
will
need
some
tooling
to
be
able
to
see
what's
going
on
from
the
beginning,
to
the
end
of
your
overall
workflow,
which
might
be
going
across
different
platforms,
and
the
other
issue
is
that,
because
you
might
have
different
platforms,
they
may
understand
different
kind
of
events,
so
you
may
have
tacked
on
generating
cloud
events
with
a
certain
payload.
Then
you
need
to
make
sure
that
captain
or
jenkins
understand
that
payload
and
understand
what
what
these
events
are
about
to
solve
this
kind
of
problems.
A
A
So
is
this
a
scale
issue
because
of
the
kubernetes
nature
of
tectons,
because
tecton
runs
on
top
of
kubernetes
resources
are
reconciled,
which
means
that
every
time
a
reconcile
happens,
the
dag
needs
to
be
recalculated,
and
if
you
have
hundreds
of
nodes
and
connection
that
could
be
computationally
heavy,
but
in
fact
it
is
not,
and
it
does
not
pose
a
scale
issue.
So
we
had
some
issue
in
the
beginning,
but
we
optimized
the
code
for
building
the
dac,
and
now
we
are
happily
running
very
large
pipelines
with
no
significant
overhead.
A
Secondly,
we
allow
for
scaling
up
all
of
our
controllers.
We
use
a
mechanism
called
leader
elections,
so
even
for
cases
where,
like
the
techno
controller,
there
is,
there
are
resources
that
needs
to
be
reconciled.
We
can
scale
up
and
have
multiple
instances
of
the
controller
and
they
will
not
step
on
each
other
and
they
can.
They
are
able
to
share
the
load
in
terms
of
utilization
of
cluster
resources.
A
A
Also,
it
is
possible
to
optimize
the
execution
runtime
so
the
way
that
tasks
are
mapped
into
pods.
If
we
make
that
optimal,
we
can
reduce
the
number
of
the
amount
of
resources
used
by
the
cluster
and
then
scale
better
when
we
have
very
large
pipelines,
so
many
pipelines
running
in
parallel,
an
option
that
we
also
can
see.
There
is
writing
custom
scheduler
for
tecton.
That
would
be
optimized
to
the
way
tecton
nucleus
utilizes,
kubernetes
resources.
A
In
practice,
we
use
tacton
for
tecton-owned
ci
cd,
so
we
run
thousands
of
tasks
a
month
in
this
kind
of
environment.
We
also
run
a
service
at
ibm
and
on
top
of
tech
contact
on
as
a
service
which
runs
windows
of
containers
per
month,
with
no
issue
at
all.
In
that
kind
of
environment
we
use
profiling
as
well
as
upstream
and
for
security
too.
We
don't
want
to
allow
people
creating
pipelines
without
any
limitation
and
another
issue
that
we
see
when
running.
Multiple
pipelines
is
clustered
pollution
where
multiple
resources
are
created.
A
So
the
history
of
the
execution,
history
stays
on
the
cluster
and
that
creates
problems
all
the
time
and
that's
for
these
reasons.
We
created
the
text
and
results
project
which
allows
to
store
the
execution
history
of
cluster,
and
eventually
it
will
allow
to
clean
up
resources
as
well
once
they
are
stored
in
the
database
of
cluster.
A
A
So,
in
terms
of
roadmap
from
a
scaling
point
of
view,
well,
we
continue
to
run
to
dog
food
tecton
so
to
run
tecton
at
scale
to
cicd
tecton
itself,
and
we
have
a
few
features
that
we
are
working
on.
Like
pipelines
and
pipelines
that
I
mentioned,
there
is
step
60,
which
is
for
remote
resource
resolution,
which
the
idea
is
to
extend
the
concept
of
oci
bundles
and
allow
tasks
to
be
stored
and
shared
through
arbitrary
mechanism.
A
A
A
A
Hello,
everyone-
hopefully
you
can
hear
me,
and
so,
if
you
have
any
more
questions,
please
ask
them
in
the
q
a-
and
I
will
start
going
through
some
of
the
questions
that
were
asked
during
the
presentation,
and
so
the
first
question
was
steps
must
run
in
parallel.
Yes,
so
that's
the
model
that
takes
within
a
task.
Your
steps
are
implemented
as
different
containers
in
a
pot
and
they
are
executed
in
para,
england
sequence,
so
they
cannot
run
in
parallel,
but
we
do
support
having
a
side
car.
A
So
you
could
have
a
part
of
the
container
that
runs
through
your
task
and
there
was
a
question
about
where
to
learn
more
about
tecton.
So
we
do
have
some
scenarios
that
you
can
run
catacotas
scenarios
from
the
tecton.dev
website,
as
well
as
we
have
the
documentation
from
all
the
projects
hosted
on
the
website
as
well,
and
if
you
dig
into
the
different
repositories
like
technology
pipelines,
we
have
examples
that
we
use
for
testing,
but
you
can
also
use
them
for
reference.
When
writing
your
pipelines.
A
A
Okay,
so
tactile
and
open
shift,
so
there
is
openshift
pipelines
is
a
distribution
of
tactile
that
you
can
find
on
top
of
open
shift
and
tactum
versus
jenkins,
kubernetes
plugin,
so
the
kubernetes
plugin
in
jenkins,
as
far
as
I
remember,
allows
you
to
run
to
get
kubernetes
bots
as
nodes
for
your
jenkins
execution.
So
if
you
combine
it
with
other
plugins
and
pipelines
or
type
configuration
as
code,
you
could
do
similar
things
and,
of
course,
tekken
is
born
in
the
kubernetes
ecosystem.
A
A
A
A
I
know
at
ibm
we
have
a
host
attacked
on
as
a
service
and
we
run
the
order
of
millions
and
it
works
pretty
well,
there
are
other
public
offering
like
relay.sh
from
puppet
that
I
know
about.
I
don't
know
the
scale
numbers
for
that,
but
if
you
have
interesting
scale
stories
about
titan,
I
would
be
really
happy
to
hear
about
those.
A
And
there
was
a
question
about
dag:
can
you
could
you
elaborate
a
bit
more
on
the
dhg
you
mentioned,
how
do
you
calculate
them
and
what
do
you
actually
use
the
dags
for
okay?
That's
a
great
question:
thanks
a
mill.
So
within
a
pipeline
we
have
tasks
and
tasks
by
default.
It
would
be
run
all
in
power
level
at
once,
but
you
may
use
inputs
and
outputs
if
we
call
parameters
for
inputs
and
results
for
outputs
to
create
dependencies
between
between
tasks.
A
So
you
could
say,
for
instance,
that
certain
task
emits
an
output
and
then
that
output
is
used
as
an
input
to
another
task
or
you
can
define
specific
dependencies
between
tasks
as
well.
So
you
can
say
this
stuff
should
only
run
after
this.
Other
task
has
been
executed
and
so
what
the
techno
controller
does
it
takes
all
this
either
implicit
relationship
between
inputs
and
outputs
or
explicit
and
puts
them
together,
and
it
builds
a
graph
directed
a
cyclic
graph.
It's
a
dag
and
it
uses
that
basically
to
schedule
the
tasks.
A
Every
time
a
reconcile
cycle
is
executed.
It
looks
at
the
current
status
of
running
tasks
and
if
there
is
any
new
tasks
that
could
be
started
from
the
dag,
I
hope
that's
the
answer,
and
there
was
another
question
about:
would
you
also
see
pipelines
of
pipelines
as
the
aegs
yeah?
So
the
way
we
implemented
pipelines
as
pipelines?
A
Experimental
for
now
is
to
consider
a
pipeline
as
a
specific
type
of
task
and
we
use
concept
of
custom
tasks,
and
so
in
that
sense
the
pipeline
also
exposes
results,
and
you
could
have
the
same
kind
of
relationship
between
the
pipeline
task
and
other
tasks.
So
the
pipeline
in
a
pipeline
will
become
part
of
the
eag.
A
There
is
question
from
krishna:
does
argo
cd
compete
with
tactics,
I
wouldn't
say
so?
Actually
they
are
often
combined
together,
and
so
you
could
use,
for
instance,
tecton
to
run
a
build
or
a
ci
job
and
then
use
it
to
trigger
a
deployment
via
argo
cd
or
you
could
use
argo
cd
to
synchronize
tecton
resources
on
your
cluster.
So
there
are
different
ways
you
can
combine
them
together.
A
One
of
the
things
that
is
characteristic
of
tekton
is
that
it's
very
non-opinionated,
so
it's
pretty
vanilla.
It
allows
you
to
create
your
task
and
the
pipelines
in
any
way.
You
want
and
build
your
workflows
in
any
way.
You
want
other
resolution
of
a
more
opinionated
approach
that
can
fit
or
not
fit
what
you
need
and
because
of
that,
it's
often
the
case.
A
A
In
fact,
it's
a
question
that
we
are
discussing
a
lot
in
the
community.
There
is
a
tab.
We
call
it
tecton
announcement
proposal
about
being
able
to
rerun
a
single,
a
single
task
within
a
pipeline
when
it
failed,
but
yeah
that
we
also
discussed
about
the
the
whole
concept
of
restarting
a
pipeline
from
a
failure.
A
It
may
require
some
snapshotting
functionality
or
you
might
not,
depending
on
how
deep
we
go
with
the
implementation,
but
it's
definitely
something
that
we
are
interested
into
and
it
would
be
you
or
your
team
would
be
very
welcome.
Of
course,
if
you
want
to
join
the
community
and
share
your
use
cases,
you
can
do
that
joining
the
working
groups
or
create
a
github
discussion
or
comment
on
existing
tabs
in
the
electrocity
community.
A
A
A
A
On
slack,
I'm
often
on
the
tecton
slack,
and
also
in
this,
the
slides
are
available
and
in
the
slides
I
included
a
lot
of
links
and
how
to
connect
to
tecton
and
myself.
There
is
one
more
question.
Maybe
running
side
operation
on
kubernetes
could
be
challenging
many
test
tools
like
moca
and
chest
for
js
parallelized
test
run
based
on
pro
securing
phone
number
within
the
pot.
This
file
contains
the
node
values
which
will
cause
over
parallelism,
and
you
guys
encounter
this
issue.
A
That's
a
very
good
question.
I
don't
have
an
answer
for
that.
I
have
not
encountered
this
issue
myself,
but
I
would
invite
you
to
if
you
will
open
a
github
discussion
on
the
tectum
gita
and
we
could
continue
the
conversation
from
there
and
yeah
thanks
again
for
joining
the
the
session
and
yeah
have
a
great
conference.
Everyone
bye.