►
From YouTube: Russian Doll: Extending Containers with Nested Processes - Christie Wilson & Jason Hall, Google
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Russian Doll: Extending Containers with Nested Processes - Christie Wilson & Jason Hall, Google
Kubernetes extensibility has gone mainstream. From CRDs to admission controllers to custom schedulers, as a platform builder you have access to a powerful toolbox! But what about the humble Pod and its hardworking containers? What if you want to extend them? What tools are at your disposal? In this talk you’ll learn how to extend a container by overriding its binary. This inventive approach is used by Prow (the CI/CD system that tests Kubernetes itself) and systems built on Tekton Pipelines (a Kubernetes based CI/CD platform) like Jenkins X and OpenShift Pipelines. You’ll see how you can control the order of container execution within a Pod, stream logs to a persistent store at scale, and gracefully handle the appearance and lifecycle of injected sidecars. You’ll learn some of the benefits and drawbacks, as well as how to overcome the hurdles.
https://sched.co/Uaco
A
Okay,
so
my
name
is
Tanya
Rico
I'm
in
Community
Development
at
Red
Hat
and
yes,
that's,
my
actual
name.
I
didn't
change
it
because
of
this
industry.
Like
repository,
it's
only
a
rebound
I
heard
all
of
the
jokes,
so
I'm
excited
to
be
here
and
introduce
you
today
with
Christie
Wilson
and
Jason
hall,
from
Google,
with
Russian
doll,
extending
containers,
witnesses
processes
just
as
a
kind
reminder
for
you
guys,
you
can
rate
the
session
after
words
we're
at
the
end,
so
it's
shed
calm.
A
B
C
B
D
B
B
D
Hey
I'm
Christie
I'm,
lead
engineer
at
Google
on
Tecton
I've
worked
in
a
bunch
of
different
industries
over
the
years
like
mobile
foreign
currency
exchange,
triple-a
video
games
with
at
least
one,
if
not
more,
people
in
the
audience.
In
fact,
the
first
person
I
ever
did
a
talk
like
this
with
it's
in
the
audience.
Thank
you.
Michael
yeah.
D
So
what
we're
going
to
do
today
is
tell
you
about
how
we
have
extended
pods
to
so
that
we
could
add
ordering
to
them.
We're
still
not
really
sure
ourselves.
If
this
is
like
a
really
cool
thing
or
a
really
horrible
hack,
it's
probably
a
bit
of
both
of
them,
but
either
way
we
think
it's
really
powerful.
So
we
wanted
to
show
you
just
in
case
it's
useful
to
you,
and
maybe
eventually
this
could
become
a
full-blown
feature.
D
First,
let's
take
a
look
at
what
we're
going
to
be
talking
about
today,
so
we're
going
to
start
off
with
an
explanation
of
Tecton
at
a
super
high
level
so
that
you
can
understand
the
problem
that
we
had
to
solve.
Then
we'll
talk
about
some
of
our
initial
approaches
and
why
they
didn't
work
so
well.
Finally,
we
will
share
our
horrible
hack.
I
mean
magic,
amazing
thing
that
we
did
with
you
so
that
you
could
do
it
too.
B
All
right,
so,
first
we're
gonna
start
with
the
Tecton
101.
Tecton
is
a
project
that
defines
CI
CD
building
blocks
for
kubernetes.
These
building
blocks
are
things
like
tasks
pipelines
that
stitch
together
tasks,
pipeline
resources
that
represent
things
like
git,
repos
and
pull
requests
and
container
images
in
a
registry.
The
idea
of
Tecton
is
maximum
plug
ability.
You
should
be
able
to
define
your
own
workflows
and
plug
it
into
Tecton
very
easily.
B
Tecton
API
is
a
kubernetes
style
API
with
a
kubernetes
implementation
that
builds
on
top
of
some
kubernetes
primitives
and
provides
higher
level
abstractions
for
CI
CD
workflows,
the
first
one
er.
The
main
thing
we're
going
to
talk
about
today
is
tasks.
So
tasks
are
a
workflow
template.
You
can
define
it
once
and
run
it
over
and
over
and
over
again
you
can
parameterize
tasks
so
that
you
can
passing
args
for
each
time.
You
run
to
pass
a
different
argument.
B
Each
time
tasks
are
comprised
of
containerized
steps
which
run
sequentially
mostly
an
example
of
a
task
is
something
that
would
get
cloned
your
repo
run
covet
goal
in
go,
build
and
go
test.
This
is
an
example
of
a
very,
very
simple
task:
it
runs
it
uses
the
go
image.
The
go
line
container
image
it
runs,
go
build
on
whatever
source
is
available,
that's
a
very
simple
task,
but
unfortunately
it's
just
not
enough
yah
mph
or
khoob
khun.
So
we
have
to
kick
it
up
a
notch.
That's
better!
That's
that's
why
we
all
came
here.
B
We
came
to
see
beautiful,
slides
of
llamó.
This
is
an
example
of
a
build
packed
task.
Build
pecs
is
another
CN
CF
project.
You
don't
actually
have
to
know
anything
about
build
pecs
specifically
to
understand
this
task,
but
it's
here
as
an
example.
So
the
build
pecs
task
defines
multiple
steps
that
each
run
an
important
part
of
the
build
pack
process.
The
first
step
prepares
the
workspace.
The
second
step
detects
what
language
you're
going
to
use.
The
third
step.
Analyzes
looks
for
details
of
previous
builds
to
be
able
to
possibly
reuse
those.
B
Then
it
builds
the
source.
Then
it
exports
that
to
a
container
image
registry.
Then
it
writes
data
to
a
cache
to
potentially
use
next
time
again,
you
don't
have
to
know
how
build
PEX
does
any
of
that
or
really
what
any
of
that
means
you
just
have
to
know
that
they
must
run
in
order.
If
you
ran
this
task
without,
if
you
try
to
export
something
before
building
it
or
build
it
before
detecting
what
language
you're
gonna
build.
B
You're
gonna
have
a
bad
time,
so
ordering
is
really
really
important
detect
on
and
how
do
we
get?
How
are
we
going
to
run
this
on
kubernetes?
So
like
a
lot
of
things
in
kubernetes?
It
all
just
boils
down
to
a
pod.
Most
things
are
a
lot
of
things
in
kubernetes
are
just
you
know,
wrappers
around
improvements
upon
the
kubernetes
pod,
things
like
jobs
and
deployments
and
daemon
sets
and
replica
sets,
are
just
wrappers
around
pods
effectively
and
pods
are
great
but
they're,
pretty
purposefully
built
for
serving
scenarios.
B
Things
where
you
want
to
start
a
container
run
it
for
a
long
time.
You
don't
expect
it
to
finish.
If
it
ever
does
finish,
usually
you
want
to
restart
it.
So
that's
great
for
kubernetes
serving
scenarios,
and
it's
not
great
for
what
we
need
it
for
in
particular,
we
need
to
run
these
containers
in
order
and.
D
It
turns
out
it's
just
not
that
straightforward
to
run
a
bunch
of
containers
in
order.
So
let's
start
with
a
little
bit
of
a
story
about
how
we
initially
tackled
this
and
I.
Think
everyone
knows
before
you
write
something
you
have
to
start
with
the
requirements
right
like
you,
don't
ever
just
make
something
before
the
requirements
or
like
figure
out
the
requirements
afterwards
right.
Definitely
definitely
so,
let's
start
with
the
requirements
for
tasks,
we
have
to
run
multiple
containers.
D
But
how
do
you
get
a
bunch
of
containers
to
share
data?
There's
a
few
options
so,
like
Jason
was
saying
the
most
natural
unit
in
kubernetes
for
doing
this
is
a
pod,
because
all
the
containers
in
a
pod
run
on
the
same
node,
so
they
can
actually
share
the
same
physical
disk.
If
we
wanted
to
use
separate
pods,
we
have
a
couple
of
options.
D
Sometimes
people
ask
us
why
we're
not
using
jobs,
and
it's
true
that
they
do
have
a
lot
of
the
features
that
we
need
from
tasks.
You
can
run
them
to
completion.
You
can
specify
a
deadline.
You
can
retry
them
if
they
fail,
but
they
still
don't
solve
the
problem
of
running
a
bunch
of
containers
in
order
and
letting
them
share
disk,
but
they're,
just
like
Jason
was
saying
an
abstraction
over
pods.
So
ultimately
we
decided
to
use
pods
as
our
unit,
but
we
might
eventually
rethink
that
and
maybe
we
would
use
jobs
underneath.
D
D
Well,
that
brings
us
to
our
first
iteration
of
how
we
tried
to
solve
this
I
knew
something
was
familiar
about
that
in
knit
containers
it
turns
out
that
in
knit
containers
are
actually
containers
that
run
an
order
on
a
pod
they're
designed
for
things
like
initializing,
the
environment
of
the
pods,
like
fetching
some
credentials
beforehand,
and
they
run
in
the
order
that
they're
specified
so
I
think
you
know
I
think
that's
it.
We're
done
all.
D
D
Yeah
sidecars
yeah,
so
it
we
did
use
init
containers
initially
and
it
worked
for
a
little
while.
But
then
we
started
running
into
other
stuff
that
we
wanted
to
do
like
supporting
sidecars
side
cards
as
a
term
is
something
that
doesn't
really
have
like
a
clear
definition.
It's
kind
of
you
know
it
when
you
see
it,
but
it's
basically
some
container.
D
We
might
have
a
user
who
wants
to
run
a
bunch
of
steps,
and
maybe
they
have
a
service
they're
testing
that
they
want
to
run
alongside
and
run
tests
against,
or
maybe
they
want
to
proxy
all
the
requests
to
do
things
like
recording,
recording
the
requests
as
they
come
in
and
none
of
this
works
with
the
NIC
containers.
You
cannot
run
sidecars
alongside
init
containers,
so
init
containers
did
not
work
for
us
so
and
there's
no
real
good
built
in
solution
in
kubernetes
for
running
a
bunch
of
containers.
In
order.
B
Which
brings
us
to
the
terrible
hacks
I
mean
magic
sauce.
We
change
that.
We
change
the
slides.
The
magic
sauce
is
natural,
hacks,
so
yeah,
so
we
needed
some
way
to
have
containers,
wait
for
a
previous
container
to
finish
and
then
run
and
then,
when
it
finished
run
to
the
next
one
sort
of
like
revealed
like
a
relay
race.
B
The
first
thing
we
had
to
do
to
understand
how
to
solve
this
was
can
understand
container
entry
points,
so
containers
specify
what
to
run
when
they
start
there's
two
ways
this
can
be
done.
One
is,
it
can
be
baked
into
the
container
image
in
a
docker
file.
You
see
that
the
the
directive
entry
point
that
says
when
this
container
image
starts
run
this
command
and
the
other
way
is
in
when
you
specify
a
container
in
a
pod.
B
For
instance,
you
can
set
the
command
that
overrides
the
entry
point
in
the
image
and
runs
that
instead,
so
this
is
a
natural
place
to
start
hooking
in
our
own
logic,
which
we
did
by
overloading
the
entry
point.
First,
we
override
whatever
entry
point,
the
user
specified
with
our
own
entry
point
that
we
control.
B
B
But
in
order
to
do
this,
we
need
to
be
able
to
inject
our
entry
point
binary
somehow,
and
this
took
again
another
level
of
terrible
hacks.
So
what
we
do
is
we
run
it
in
a
container
before
all
the
steps
start
that
contains
the
binary
that
we
write.
We
copy
it
into
a
volume
at
in
context
on
its
slash
builder,
slash
tools
and
that
container
that
volume
is
shared
across
all
containers
in
the
steps.
B
So
the
entry
point
binary
that
we
wrote
is
a
statically
linked,
go
binary,
which
means
it
doesn't
depend
on
anything
else
being
available
in
the
container.
It
would
run
in
something
that
doesn't
have
any
other
tools
available.
I
think
we
stole
most
of
this
logic
from
prowl
yeah.
So
how
do
we
support
sidecars
in
this
mode?
B
B
We
use
the
downward
API
to
project
the
annotations
of
the
pod
into
a
volume
in
the
in
the
pod
yeah
into
a
volume
in
each
container.
The
downward
API
exposes
any
metadata
about
a
pod.
Two
labels
annotations
things
like
that
as
files
and
so
step,
0
waits
to
see
that
ready,
annotation
to
start
running,
and
then
it
does
whatever
it
needs
to
do.
And
then
it
writes
a
file
to
two
signals,
step
two
to
start
and
so
on,
and
so
on.
B
There's
actually
really
exciting
change
in
the
works
for
better
more
official
support
for
sidecars
cap
753
is
what
is
called.
Kep
stands
for
kubernetes
enhancement
proposal.
This
is
actually
really
going
to
help
for
sidecar
cases
that
aren't
tacked
on
things.
Like
the
SDO,
sidecar
and
and
other
proxies
like
that,
if
you
label
or
sorry,
if
you
tell
kubernetes
that
this,
that
this
container
is
a
sidecar,
it
will
start
all
of
the
sidecar
containers.
B
First
make
sure
that
they're
up
and
then
run
the
rest
of
the
containers
in
the
pod
and
then,
when
all
of
the
regular
containers
in
the
pod
finish,
it
will
gracefully
exit
all
of
the
sidebar
containers.
But
even
with
this
cap
side,
cars
don't
run
until
after
the
unit
containers.
So
we
still
can't
like
use
init
containers
and
get
ordering
for
free.
B
Also,
this
cap
is
targeted
for
alpha
in
kubernetes
1.18,
which
means
we'll
be
waiting
a
little
bit
to
be
able
to
use
it
in
regular
usage,
but
it'll
be
really
great
for
some
of
for
some
use
cases.
There
are
also
some
caveats
about
what
we,
what
terrible
hacks
we
employed
to
solve
this
problem.
The
containers
all
start
at
the
same
time,
according
to
the
pod,
the
pod
says,
start
all
of
my
containers,
the
first
ones,
entry
point
binary,
runs
and
then
the
second
ones,
entry
point
binary
runs
but
to
the
pod.
B
All
of
the
containers
started
at
the
same
time,
which
means
we
don't
get
a
good
signal
about
when
each
when
each
container
started.
We
also
need
to
to
be
able
to
look
up
the
entry
point
if
it
was
specified
in
the
image
config.
We
have
to
reach
out
to
the
registry
to
get
that
metadata
which
might
require
credentials
and
now
we're
talking
image,
pull
secrets
and
it's
just
tax
upon
tax
upon
tax
and
with
that,
it's
time
for
a
demo.
D
D
E
B
Okay,
so
this
is
the
this:
is
the
PUD
that
I
originally
ran
to
create
the
garbled
out
of
order
kiddie
that
we
saw
before
so.
This
runs
a
container
to
print
the
outer
top
layer
and
then
the
middle
top
layer
and
then
the
inner
top
layer
and
then
that
middle
cat
in
the
middle
that
says,
meow
and
then
the
inner
bottom
middle
bottom
and
outer
bottom
and
then
print
all
of
the
doll
that
we've
created
so
far.
C
B
Is
taking
quite
a
long
time
demo
goods?
Oh
there,
we
go.
It's
gonna,
wait
five
seconds
to
wait
for
the
pod
to
come
up
and
yeah.
We
see
another
garbled
out-of-order
cat,
no
matter
how
many
times
I
run
this.
It
is
very
unlikely
to
run
all
the
containers
I
asked
for
in
the
necessary
order,
and
here's
it
to
us.
B
B
C
B
D
Cool,
so
I'm
gonna
go
through
what
you
just
saw
in
just
a
little
bit
more
detail,
so
you
can
see
the
details
of
what
we
did,
but
one
thing,
I
think
is
pretty
cool.
That
I
want
to
stress
is
that
we
we
did
do
something
very
hacky,
but
fortunately
our
users
don't
really
have
to
deal
with
that
because
we
implemented
it
for
them.
So
that
means
that
you
can
just
specify
a
bunch
of
things
you
want
to
run
in
order.
D
You
know,
run
an
order
and
then
later
on,
once
the
side
car
cap
is
passed
or
we
actually
have
support
for
running
containers
in
order
in
kubernetes
itself,
then
we
can
just
swap
the
logic
out
and
it
won't
affect
our
users
at
all.
So
that's
pretty
cool
unless
they
were
looking
at
the
status
of
the
pause,
in
which
case
they'll
be
very
confused,
which
is
what
I'm
going
to
show
you
now
so
as
sort
of
a
high-level
view
of
what
we
were
doing.
This
was
like
a
relay
race
between
the
containers
that
we
were
executing.
D
We
had
several
containers
outer
top
middle
top
in
her
top
and
some
other
ones
and
they're
kind
of
coordinating
who's
doing
what,
when
bypassing
files
between
each
other.
So
here
you
can
see
the
tasks
that
Jason
was
running
alongside
the
pod
that
ended
up
running
underneath
it.
So
the
first
step
that
we
wanted
to
run
was
using
the
doll
image
and
the
outer
top
command,
and
over
here
you
can
see
the
pod
that
we
actually
ran
so
first.
D
The
first
thing
you
might
notice
is
that
the
binary
that
we're
actually
running
is
our
binary
that
we
injected
into
the
container.
You
can
see
that
we're
passing
as
an
argument
to
that
binary
what
the
user
actually
wanted
to
run,
so
it's
Dalda
SH
with
the
outer
top
command.
But
if
you
look
at
the
step,
you
can
see
that
doll,
dot,
SH
isn't
actually
in
there,
because
that
was
the
entry
point
of
the
doll
image
that
was
already
built.
D
So
our
controller
had
to
actually
retrieve
the
metadata
about
that
image
and
inspect
it
to
figure
out
what
the
entry
point
was
going
to
be.
So
it
could
pass
it
to
our
binary
and
then
the
rest
of
these
arguments
tell
our
binary
to
wait
for
the
controller
to
signal
with
the
downward
api
that
all
of
the
side
cars
are
up
and
ready,
and
they
tell
it
to
once.
It's
done
to
write
the
file
that
will
signal
to
the
next
step.
That
needs
to
run,
and
this
is
what
the
next
step
looks
like.
C
D
So,
let's
finish
off
by
looking
at
some
of
the
stuff
that
we're
hoping
we
can
do
with
this
in
the
future,
so
the
first
thing
I
think
Jason
touched
on
a
bit,
which
is
that
if
you
look
at
the
pod,
it
looks
like
everything
started
at
the
same
time,
because
technically
everything
did
start
running,
but
the
user
probably
wants
to
know
when
their
particular
command
actually
started.
So
we
need
to
improve
that
so
that
when
you
look
at
the
status
you
can
see
when
things
actually
started.
D
D
But
if
we
added
a
sidecar
in
that
was
like
a
super
supervisor
sidecar,
then
we
could
use
that
to
coordinate
the
execution
of
the
containers
and
then
we
would
have
complete
control
over
the
life
cycle
of
all
of
the
containers
inside
the
pod
and
specifically
for
Tecton,
which
is
a
CI
CD
system.
And
you
know
what
CI
CD
systems
things
often
go
wrong
and
you
find
yourself
wanting
to
debug
them
and
figure
out.
What's
going
on.
We
could
use
this
to
add
a
debug
mode.
B
We
didn't
come
up
with
this
hack
on
our
own.
A
number
of
people
helped
and
are
implicated
in
its
terribleness.
There
are
some
of
their
names
right
here
and
with
that
in
closing,
if
you
want
to
go
see
this
code
and
see
how
terrible
it
is
in
real
life,
it's
not
terrible.
It's
not
that
bad.
It's
all
of
the
Tecton
pipeline
code
is
that
tectonics
re
github.com,
slash,
Tecton
save
each
slash
pipeline.
If
you
want
to
see
more
example,
tasks
like
the
build
packs
tasks
that
I
showed
you
before.
B
You
can
see
that
at
the
Tecton
CD
catalog,
if
you
are
using
Tecton
or
are
interested
to
see
how
other
people
are
using
Tecton,
you
can
become
a
friend
and
file
or
tell
us.
How
do
you
do
that
at
Tecton,
CD,
/
friends?
And
if
you
have
any
questions
you
can
join
us
on
our
slack
and
ask
questions
at
that
short
link
there,
or
you
can
ask
questions
here
in
person.
A
F
So
I
might
be
armchair
over
engineering
here
and
if
so,
it's
perfectly
okay
to
say
yes,
you
are,
this
is
the
kind
of
thing
that
I
would
think
would
be
an
ideal
case
for
something
like
a
message.
Q
did
you
look
at
maybe
putting
a
message
queue
in
as
part
of
Tecton
itself,
or
did
that
strike
you
as
like,
too
heavy
weight
for
this
kind
of
solution?
When.
D
F
B
I
think
I
mean
first
of
all,
there
is
no
such
thing
as
over-engineering
when
we've
just
described
how
this
works
right.
You're,
not
gonna,
you're,
not
gonna,
impress
us
too
much,
but
I.
Think
the
the
nice
thing
about
having
files
is
that
they're,
very
low
dependency,
like
you,
just
need
to
write
a
file
or
read
a
file
we
can
improve
like
currently
we're
like
polling.
Every
second
is
the
file.
B
There
is
the
file
that
we
can
improve,
that
we
could
use
all
kinds
of
better
things
right,
then
than
what
we
have
I
think
something
that
talks
outside
of
the
pod
to
get
data
back
into
the
pod.
It
seems
like
it
might
introduce
more
dependencies
than
like
it.
You
basically
in
order
to
change
how
we
do
it.
You'd
have
to
prove
that
it's
more
reliable
than
writing
a
file
and
reading
a
file
which
I'm
not
saying
it's
impossible,
but
it
seems
like
a
like
a
high
like
high
bar
and.
D
I
mean
I
think
something
like
that
is
something
that
we're
looking
into
for
more
like
at
the
level
of
coordination
between,
like
maybe
pipelines.
So
when
you
execute
one
pipeline,
you
might
want
to
emit
an
event,
and
then
you
might
want
to
have
something.
That's
consuming
that
event
and
then
executing
another
pipeline.
E
B
Don't
have
timeouts
per
step
today.
We
could
add
that
we
could.
You
know
because
the
entry
point
binary
is
the
one
that's
actually
running
what
the
user
asked
for.
We
could
have
timeouts
in
there
if
the
step,
if
the
thing
that
the
user
asked
to
do
crashes,
then
the
entry
point
binary
watching
it
will
say.
Oh
you
crashed
I'm
gonna
crash
and
then
the
whole
pod,
like
blows
up.
D
E
G
So
my
question
is
related
to
the
health
checks,
so
how
does
it
happen
as
I
understand?
Probably
the
health
check
happens
like
per
container
bases,
but
it
is
reported
for
the
entire
pod
in
this
case,
since
things
happen,
sequentially
so
does
it
affect
the
health
checks
or
how
does
it
work
in
this
case,
the.
G
B
Health
check,
that's
a
much
better
question
for
the
for
the
use
cases.
We're
talking
about
the
steps,
don't
tend
to
specify
a
health
check
in
theory.
You
could.
Oh,
this
isn't
a
fact
you
could.
You
could
sort
of
come
up
with
a
way
to
timeout
steps
using
a
health
check
like
if
you
have
a
health
check,
that
weights
10
minutes
and
then
says,
I'm
unhealthy,
you
should
kill
me,
you
could
use
that
to
simulate
a
timeout.
Don't
do
that!
Nobody
do
that,
but
basically
yeah.
B
H
B
B
Just
needs
to
be
some
dumb
thing
that
that
is
very
reliable
and
very
fast
I
wouldn't
want
it
to
emit.
You
know
outside
of
the
pod
to
a
thing
and
then
have
to
come
back
in
to
find
it,
but
we
have
talked
about
like
having
the
entry
point
binary
right,
a
log,
a
specific
log
message
that
that
something
else
reads
to
get
that
I'd
love
to
hear
more
ideas
about
it
because
we
haven't
written
it
yet,
but.
H
I
This
awesome,
hack,
I've,
seen
it
multiple
times
now
and
I
think
that
the
logic
of
you
know
determining
what
the
entry
point
is
and
then
wrapping
that
in
the
binary
and
passing
the
arguments
into
it,
I
think
that's
a
good
candidate
for
a
general
purpose
library,
because
you
have
the
same
logic
as
the
bansuri
cloud
vault
secrets
web
book.
They
use
exactly
the
same
logic.
So
maybe
there's
an
opportunity
to
you
know
polish.
This
awesome
AK
yeah.
D
Yeah
and
I
think
another
thing
that
we
wanted
to
look
into
too
is
potentially
even
so,
I
think
making
a
library
that
does.
That
makes
a
lot
of
sense.
Ensuring
that
we're
also
thinking
about
potentially
proposing
I,
wouldn't
say
that
this
is
something
we're
going
to
do
necessarily
but
proposing
this
in,
like
another
kept
as
a
feature
in
kubernetes.
That
could
be
pretty
cool,
especially
if
lots
of
people
are
trying
to
do
the
same
kind
of
thing.
D
Great
well,
thank
you
all
very
much
and
there's
going
to
be
a
meet.
The
maintainer
x'
for
Tecton
at
the
google
open
source
lounge
on
thursday
I.
Think
it's
from
like
noon.
Till
2:00
p.m.
you
can
also
check
the
detect
on
Twitter
account
for
more
information
about
that
and
other
cool
Tecton
stuff
and.