►
From YouTube: Deep Dive: CNCF Cross-Cloud CI – Denver Williams, Debian & Taylor Carpenter, Vulk Coop
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
Deep Dive: CNCF Cross-Cloud CI – Denver Williams, Debian & Taylor Carpenter, Vulk Coop
The CNCF CI Working Group was asked to demonstrate best practices for integrating, testing, and deploying projects within the CNCF ecosystem across multiple cloud and bare metal providers. The Cross-Cloud CI project continually validates the interoperability of each CNCF project, for any commit on stable and head, running on Kubernetes clusters which are provisioned to all supported cloud providers. The results of each testing stage are published to the cncf.ci status dashboard. This Deep Dive session will discuss how to implement CNCF projects (for build and e2e testing) and cloud providers (for Kubernetes provisioning). It may include an interactive walk-through of adding a new project or cloud provider to the Cross-Cloud CI system.
To learn more: https://sched.co/Greb
A
A
A
We
have
eight
cloud
providers
that
are
supported
on
the
platform
that
we
can
deploy
to.
So
the
CNC
FCI
is
an
instance
of
the
cross
cloud
CI
project.
That's
has
the
dashboard
showing
and
it's
refreshed
at
3
a.m.
Eastern
daily,
to
show
all
the
projects
that
are
currently
active
and
wanting
to
be
tested,
as
well
as
as
cloud
providers.
A
A
You
have
that
bill
pipeline
kubernetes
provisioning
pipeline,
that's
cross
cloud
where
we're
gonna
be
focusing
today
and
then
cross
project
which
does
the
app
deployments,
and
then
all
of
these
can
run
different
tests,
including
integration
and
Dan
tests.
Whatever
we
have
to
work
with
from
the
project,
so
on
that
kubernetes
provisioning,
we
can
build
and
use
different
kubernetes,
artifacts
and
releases
take
those
and
deploy
them
to
different
cloud
providers,
and
then
we
can
run
the
tests
like
say
conformance
test.
A
If,
if
we
would
like
four
or
different
flags
for
the
providers
and
then
update
the
dashboard,
so
this
is
showing
this
releases
on
the
dashboards
for
CNCs
CI
we're
doing
the
stable
and
head
of
master,
and
then
we
provision
the
clouds
with
those
releases.
So
these
are
all
individual
clusters
and
then
we
use
helm
to
deploy
the
apps
to
all
of
those
clusters.
A
So
a
quick
overview
of
the
whole
system.
Right
now,
underneath
we
use
get
lab
to
run
different
jobs
of
the
software
like
actually
running
the
cross,
lot
components
and
then
pulling
back
information
helm
for
both
app
deployments
and
running
ete
tests,
which
we
usually
put
in
containers
and
the
cross.
Clad
itself
is
a
mixture
of
terraform
which
allows
us
to
target
multiple
cloud
providers
easily.
There's.
A
Usually
the
provider
code
is
maintained
by
the
clouds
and
then
cloud
in
it
is
normally
used
to
kick
off
the
bootstrapping
of
kubernetes
with
her
cloud
manifest
and
configuration,
and
then
all
of
this
is
driven
from
git
and
the
ML
configuration
so
the
CNF
project
well
similar
to
datacenter
and
everyone's
trying
to
move
towards
been
move
moving
towards
the
cloud
centric
type
of
methodologies.
There's
a
move
in
a
fee
world
to
do
that,
and
this
project
is
creating
reference
code
and
test
comparisons
and
helping
with
collaboration
using
the
cross
cloud.
See.
A
A
So
how
do
we
get
to
see
I
for
nfe
testing?
We
look
at
creating
a
neutral
test
environment
so
by
that
we're
saying
commodity
Hardware,
ideally
for
this
base
testing
and
looking
at
public
clouds
and
open
environment.
So
Linux
Foundation
has
a
the
FDI
au
project
and
a
C
set
lab
and
then
packet
has
bare
metal.
A
And
then
we
look
at
software
everything's,
Henner
percent,
open
source
for
us,
the
nfe
world
you're
going
to
have
both
that
we're
looking
at
how
do
we
get
people
to
collaborate
on
these
type
of
open
testing,
vanilla,
kubernetes,
for
what
we're
looking
at
today?
That's
going
to
be
across
the
board
when.
A
Like
OpenStack
or
KVM,
using
helm
and
then
trying
to
work
with
different
groups,
kubernetes
network
service,
mesh,
the
FDI
au
project
for
VPP
software
and
other
things
once
we
have
that
kind
of
as
our
target,
and
how
do
we
reproduce
make
reproducible
infrastructure,
so
servers
switches,
setting
up
all
the
networking
and
connection
on
the
server's
themselves,
and
this
is
an
example
of
packet.
So
a
lot
of
content
here.
This
would
be
one
of
the
machines.
This
em--to
extra
large,
it's
adele
happens
to
be
dealt
with
them.
A
We
can
configure
all
this
or
provision
it
initially
with
terraform,
so
that
gets
us
part
of
the
way
we
can
deploy
a
cluster
with
different
numbers
of
compute
nodes
and
worker
nodes
and
and
master
whatever
we
want.
So
this
works
kind
of
out
of
the
box
with
cross
plot.
We
can
decide
on
size
of
the
resources
and
those
sort
of
things,
but
what
about
layer?
Two
networking,
so
this
isn't
something
that's
currently
supported
in
kubernetes,
but
there's
a
lot
of
effort
to
move
towards
that.
We
need
to
do
the
wiring.
A
We
have
all
the
host
configuration
that
you
have
to
handle.
Then
we
want
to
connect
the
different
network
functions
in
different
topologies.
So
how
do
we
do
that?
Well,
we
extended
cross
cloud
to
support
different
things
that
we
need
right
now
and
try
to
keep
this
pluggable
so
right
now.
This
means
adding
the
support
for
an
ansible
terraform
plugin,
so
that
we
can
use
roles
and
other
things
that
we're
using
for
OpenStack
and
KVM.
We
can
pull
down
stuff
from
other
groups.
A
We
added
support
for
CPU
management
policies
and
some
other
specific
kubernetes
things
so
that
we
can
isolate
the
hardware
usage,
which
is
really
important
for
performance
in
this
side
and
then
all
services
that
were
running
for
this
or
bare-metal
important
for
specifically
for
Network
function,
testing
and
then
we're
connecting
the
layer
to
network
with
VPP.
So
this
is
an
open
source
software.
That's
it's
a
stack
that
you
can
configure
to
do
what
you
would
do
with
maybe
a
juniper
switch
or
Cisco
or
whatever
you
want.
A
It'll
handle
a
lot
of
different
configurations
and
it
does
very
high-speed
networking.
So
we
use
this
at
the
hosts
layer
for
what's
called
the
V
switch
and
and
then
within
the
containers
himself.
We're
also
using
VPP,
but
that
would
be
a
separate
thing.
The
main
thing
here
is
the
host
switch,
so
normally
with
kubernetes
you're
gonna.
Let
Linux
kernel
handle
all
of
the
connections.
So
for
this
we
have
to
decide.
A
Maybe
the
public
internet
pieces
are
going
to
be
handled
by
kubernetes,
just
as
you
would
have
it,
and
then
the
extra
interfaces
that
we
add
to
the
containers
we
hand
off
to
VPP
and
that
lets
us
get
that
high
speed,
and
this
is
where
the
ansible
and
other
pieces
kind
of
tie
in
and
right
now
that's
configured
kind
of
outside.
So
it's
in
collaboration
with
we
configure
kubernetes,
and
then
we
build
out
the
host
networking
and
they
kind
of
meet.
There's
other
projects
like
network
service
mesh
that
are
helping
to
provide
those
as
services.
A
So
we've
made
this
pluggable
so
that
we
can
add
those
in
later.
The
other
part
here
that
I'm
showing
is
the
connecting.
How
do
you
connect
these
we're
not
using
the
normal
networking
we're
using
high
speed
mm
I
have
sockets
so
here's
some
of
the
features
that
we've
added
to
cross
cloud
and
it
was
using
core
OS.
As
the
base
host
OS
now
we
have
support
for
core
OS
and
abun.
A
We
can
use
reserved
and
that
packet,
so
it
was
doing
on
demand
for
everything
AWS
wherever
so
for
packet.
You
can
use
both
the
on
demand,
as
well
as
reserved
instances
which
may
be
configured
differently
with
the
reserved
instance.
You
can
go
into
the
BIOS
and
do
additional
items
and
the
CPU
management
policies
and
other
things
for
isolation
of
the
hardware
and
then
a
few
other
items
on
rebooting.
A
Well,
there's
some
general
challenges
with
moving
from
virtualized
network
functions
that
are
running
in
VMs
to
the
cloud
native
equivalents,
reproduce
along
with
infrastructure.
So
that's
before
we
put
maybe
the
platform,
kubernetes
open,
sack
and
then
the
actual
clusters.
How
do
we?
How
do
we
make
those
work?
A
So
here's
a
lot
of
content
and
this
actually
from
Dan
Kahn
talking
about
the
move
from
physical
hardware
to
virtualized,
you
have
the
ability
to
use
custom,
kernels
custom
drivers
in
the
in
the
virtual
machines,
and
you
can
do
a
lot
of
other
things
there
to
make
sure
it
works
and
you
get
the
high
performance.
When
you
move
to
containers,
you
don't
have
the
same
abilities
you're
using
the
same
kernel
as
the
hosts
and
other
things.
So
how
do
you?
How
do
you
deal
with
that?
A
The
layer
2
networking
with
virtual
machines
you
can
create
whatever
interfaces
you
want.
This
is
different
there.
So
there's
those
sort
of
challenges
on
the
infrastructure.
We've
seen
a
lot
of
different
things.
This
is
probably
stuff
you're
going
to
see
on
any
providers
so
and
the
AP
is
so
there's
there's
things
that
we
ran
into
pretty
quickly
where
maybe
the
on
packet.
A
They
have
it
in
an
API,
but
they
don't
support
it
in
their
the
libraries,
because
these
aren't
things
that
other
people
are
doing
so
we're
kind
of
driving
those
early
earlier
access
to
configuration
of,
say
the
switches
and
we
may
be
able
to
update
something
on
the
API.
But
we
can't
actually
go
retrieve
something
in
a
list,
so
we
have
to
go
somewhere
else
in
the
API
to
pull
something
and
somewhere
else,
put
it
all
together
and
come
up
with
what
we
wanted.
A
And
so
that's
that's
one
of
the
things
that
we
ran
into
pretty
quick
the
switch
configuration.
So
what
am
I
talking
about
here,
for
it
doesn't
work
as
expected.
So
for
that
layer,
two
configuration
any
of
the
physical
switches
are
likely
to
be
able
to
set
up
the
layer,
two
configuration
that
people
want.
If
you
have
direct
access,
we
have
an
API,
that's
external,
to
that
and
trying
to
limit
problems.
So
some
of
the
things
that
you
would
expect
to
be
able
to
do
on
this
switch
may
not
work.
A
As
expected,
you
start
having
limits
on
what
you
can
do.
So
that
means
your
configuration
and
setup
of
the
cluster
and
the
machines
is
going
to
be
different,
then
expect
it
and
then,
if
you're
going
to
compare
to
another
environment,
say
pack
it
to
the
fdic
set
lab
now
you
may
say:
well
we
need
to
set
that
up.
Can
it
be
set
up
the
same,
so
those
sort
of
things
and
limits
within
the
provider
to
make
sure
resource
utilization
is
kept
to
a
point
where
all
the
customers
get
what
they
expect.
A
So
we've
run
into
stuff
like
the
amount
of
VLANs
that
you
can
create,
so
those
virtual
networks
for
layer
two
within
a
project.
Maybe
the
facility
does
have
as
many
of
a
type
of
device
those
sort
of
things.
So
those
further
limit
how
the
clusters
and
everything
that
you're
going
to
set
up
doesn't
stop
its
used,
have
to
start
being
creative
or
decide
that
maybe
you're
gonna
do
a
different
use
case.
A
The
from
the
open
sex
side,
we
really
want
similar
to
kubernetes,
so
this
is
for
comparison,
kubernetes
KVM,
anything
we're
looking
at.
We
would
like
for
other
people
to
be
able
to
reproduce
and
provide
feedback
on.
Is
this
something
that
would
be
standard
within
the
context
of
what
we're
using?
Is
this
best
practices?
So
we're
wanting
that
reproducible
and
we
found
it's
difficult
to
have
something:
that's
more
general-purpose
for
an
open
set
clusters,
and
we've
started
with
many
different
paths
for
this,
including
using
code
and
deployments
from
other
projects.
A
We've
provided
a
lot
of
updates
on
those.
Nothing
was
quite
getting
us
to
bare
metal,
something
that
we
could
say
uses
a
che
controllers
and
compute
nodes
that
are
going
to
be
comparable
to
to
a
kubernetes
cluster,
and
so
that's
been
very
difficult
and
we've
pushed
through,
and
in
the
last
couple
of
months
we've
we've
got
to
a
point
where
we
have
reproducible
OpenStack,
that's
not
yet
high
performance
and
that's
where
these
next
part
comes
in
the
host
OS.
A
So
we
can
have
a
lot
of
it,
working
if
say
you're
on
CentOS,
but
then
maybe
something
else
doesn't
work
with
packages.
So
then
you
are
looking
at
a
bun,
2
or
whatever
on
those.
What
are
the
pieces
that
we
need
for
this
so
dealing
with
those
dependencies
has
been
and
that's
across
the
board,
not
just
OpenStack
the
standard
plugins.
A
This
ties
in
with
the
hyper
for
months,
one
of
the
things
that
we're
trying
to
do
is
make
sure
to
use
the
same
software
where
possible,
unless
there's
a
standard
already
in
that
community,
so
I
was
showing
earlier
VPP
for
that
high
performance
networking
you
can
use
VPP
and
OpenStack
and
KVM
and
other
places
for
OpenStack.
They
have
a
VPP
Neutron
plug
in,
and
you
would
ideally
use
that
for
your
configuration.
So
it's
going
to
be
similar.
It's
going
to
be
the
standard,
it's
how
you
would
set
up
Neutron.
A
Unfortunately,
the
software
versions
that
we
need
for
supporting,
say
drivers
on
a
particular
machine
on
packet.
They
they
don't
match
the
built-in
packages
that
you
would
use
for
the
VPP
with
VPP,
Neutron
and
stuff,
at
which
point
you
have
to
make
the
call
that
we're
gonna
do
source,
builds
and
kind
of
go
down
that
path.
It's
not
a
blocker.
A
So
what's
next
we're
working
with
a
lot
of
different
groups,
network
service
mesh?
We
have
pull
requests
from
different
folks
for
trying
to
make
updates.
This
is
back
to
cross
cloud,
so
the
provisioner
itself,
the
kubernetes
provisioner.
We
have
different
enhancements
requests
and
updates
from
different
folks
we're
trying
to
gather
more
feedback
from
everyone
on
this,
as
well
as
the
cross
cloud
CI
project
as
a
whole,
which
has
other
components.
A
B
B
A
And
helping
to
drive
some
of
the
features
and
tests,
so
that's
one
of
the
pieces
where
we
think
we're
going
to
be
adding
support
for
looking
at
adding
layer,
2
configurations
support
with
other
providers
so
outside
of
kubernetes.
You
have
the
infrastructure
we
care
about,
reproducible
there,
so
we'll
be
looking
at
other
providers
like
what
does
it
look
like
on
a
vws
bare-metal?
A
So,
there's
a
CI
working
group
there's
a
lot
of
different
projects
that
are
coming
on
there,
including
open
labs
cross
clot
CI,
would
be
one
of
the
topics.
Here's
the
github
for
the
Cross
Cloud
provisioner,
so
this
the
kubernetes
provisioner,
if
you're
interested
in
the
cross
cloud
CF
project
in
general,
there's
a
lot
of
other
components.
A
C
A
Right
now,
it's
kind
of
a
high
level
of
something
Pat
it
all
past
is
green
right
or
something
felled,
and
then
that
includes
antenna
tests.
Then
it
can
include
end-to-end
tests.
So
if
for
a
project,
for
instance,
that
could
be
running
an
integration
test
and
for
kubernetes
it
could
be
we're
running
the
conformance
test.
We
could.
It
could
be
any
of
this
and
then,
when
you
see
a
failure,
so
if
you're,
actually
on
the
dashboard,
if
you're
on
the
dashboard,
you
can
click
through,
so
I
could
go
and
look
at
this
is
for
a
build.
A
C
Do
you
have
antenna
tests
for
each
component?
The
reason
why
I
asked
like
I've
been
looking
at
the
source
code
last
month
or
two
I'm
for
my
own
district
use
case
right
and
yeah
I
didn't
it
was
hard
for
me
to
see
beyond
so
there's
a
cross
cloud
and
cross
project
and
then
there's
the
get
lab
files
for
running
the
antenna
tasks
as
far
as
I
could
tell
it,
and
maybe
I'd
haven't
get
pulled
recently.
It
basically
would
install
the
helm
charts
for
the
component
that
you're
testing
so
envoy
Prometheus,
whatever
yeah.
A
A
This
is
tying
in
with
the
collaboration
and
kind
of
how
we
want
to
work
going
forward
and
talked
about
this
in
the
intro
yesterday.
So
we're
planning
it
a
kind
of
a
big
rework
in
iteration
for
going
next
year,
where
we
would
like
to
have
more
projects
maintaining
a
lot
of
this
and
that's
been
a
goal
so
we're
looking.
How
do
we
make
that
entry
for
them
to
do
that?
A
A
Yeah
we've
we've
run
some
in
the
past
and
there's
been
kind
of
some
confusion
on
what
does
this
do?
Accordion
s
would
probably
be
an
easier
one,
because
you
could
there's
a
lot
of
ways
to
testing
this,
whether
it's
core
dienes
or
any
project.
As
you
start
looking
at
the
other
projects,
it
gets
a
little
bit
hairier
and
one
of
the
the
goals
that
we
have
next
year
is
doing
integration
between
the
projects
so
not
just
and
in
the
end
tests
on
components.
There's
a
there's.
We've
been
hearing
a
lot
of
feedback
on.
A
How
do
you?
How
would
you
use
those
projects?
So
then
you
may
say:
Prometheus
core
DNS.
You
know,
there's
a
Postgres
database
and
some
other
piece
and
you
have
all
those
running
and
then
run
a
full
integration
test.
But
this,
which
would
be
a
lot
more
interesting
and
as
part
of
that,
the
dashboard
itself
that
we
were
looking
at
will
end
up
getting
reworked.
A
So
there's
going
to
be
screens
that
are
more
of
a
focus
on
projects
and
then
we
could
say:
here's
the
different
integration
test
and
stuff
that's
running
and
as
far
as
the
end-to-end
test
on
specific
components,
we'd
love
to
have
have
those
contributions
as
well,
and
we
can
turn
those
on
pretty
easy
like
right
now.
If
we
had
any
okay.
C
B
So
something
that
I've
been
looking
at
with
respect
to
testing
more
kubernetes
broadly,
that
would
be
related
to
the
talk
it
was
very
informative.
Thank
you.
Have
you
looked
at
integrating
ovn
into
cross
cloud
at
all,
especially
seeing
that
there's
this
new
focus
on
network
functions
and
and
networking
as
an
area
ovn
seems
to
be
it.
B
You
know,
nsx
is
in
part
based
on
OVS
Nov
ends
the
open
implementation
of
it
and
not,
and
there's
really
no
deployment
right
now
that
uses
it
and
I've
I've
been
looking
at
integrating
it
into
some
of
my
deployment
tools
and
I
was
just
wondering
because
of
this
new
focus
on
networking.
If
that's
something
that
you're
exploring
as
well.
A
From
the
MIS
so
from
kubernetes
deployments
itself,
clusters
for
cross
cloud
and
stuff
we're
definitely
interested
in
testing
different,
different
configurations,
similar
to
different
CNI
plugins
and
all
that
for
the
CNF
project.
So
the
network
functions
himself.
There's
gonna
be
a
lot
of
different
contrasting
comparisons
that
we're
gonna.
Do
we
have
OBS
for
the
OpenStack,
but
that's
more
of
the
functional
testing.
So
if
you
look
at
the
own
app
project,
one
of
the
reese's
called
a
CPUs
case
has
a
lot
of
different
components
and
you
could
use
you
could
use
OBS.
A
B
Ovn,
please
correct
me:
I
think
I'm,
probably
wrong
here,
but
I
thought
ovn
was
an
implementation
of
the
idea
of
OBS
and
maybe
OpenStack
also
has
a
project
called
OBS,
which
is
a
datian
of
OBS,
but
I
thought
ovn
was
you
know
implementing
the
idea
of
the
open
virtual
switch
and
it
could
be
deployed
on
any
Linux
system
that
supports
IPV,
confusing
acronyms.
At
this
point,
no.
A
I'm
sorry
I
was
talking
about
with
regard
to.
If,
if
we're
looking
at
we're,
mainly
looking
at,
is
platforms
and
then
potentially
plugins
and
for
the
telco
world
and
there's
a
one
of
the
biggest
focuses
on
performance,
so
we're
pretty
limited
on
what
can
be
the
Livi
switch
unless
you
get
a
non
open-source
solutions.
I
understand.