►
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Level Unlocked: GitOps to the Edge and Infrastructure Provisioning - Katie Gamanji
ithin its 7 years of existence, Kubernetes has been the centerpiece of the cloud native landscape, elevating a pluggable system that led to the diversification of the technology ecosystem. As a result, multiple areas have developed in the industry, galvanizing solutions for components that introduce standardization, guidelines, and interoperability of the tools. To innovate the developer experience and delivery of the application, the community focused on restructuring and modernizing the CI/CD operations. This talk will outline how cloud native GitOps tools, such as ArgoCD and Flux, unlock the zero-touch deployment of infrastructure and applications at the edge. Attendees will acquire an understanding of GitOps usage in association with ClusterAPI for infrastructure provisioning and KubeEdge for the service propagation to the edge.
A
A
I
have
many
roles
within
the
community
and
one
of
them
is
being
a
member
of
the
advice
report
for
captain
which
currently
is
a
sandbox
cncf
project
as
well.
I
am
collaborating
with
open
uk
to
make
sure
that
open
standards
are
used
across
data
software
and
hardware
and,
as
part
of
my
motivation
to
make
cloud
native
ubiquitous,
I
have
collaborated
with
udacity
to
create
the
cloud
native
fundamentals
course
pretty
much.
This
course
is
constructed
to
take
anyone
with
little
programming
experience
on
the
path
and
journey
towards
cloud
native.
A
A
A
If
you'd
like
to
find
out
more
details
about
the
end
user
community
and
their
usage
of
cloud
native
visit,
the
cncf
dot
io
forward,
slash
end
user
as
well.
If
you'd
like
to
showcase
your
adoption
of
cloud
native
you'll,
find
all
of
the
details
here
of
how
can
you
join
the
end
user
community
today,
however,
I
would
like
to
talk
about
git
ups
but,
more
importantly,
how
it
unlocks
the
infrastructure,
provisioning
and
application
propagation
towards
the
edge,
and
to
do
so.
A
I
would
like
to
start
by
introducing
the
cloud
native
github
stores,
and
here
I'm
going
to
give
a
brief
introduction
of
tools
such
as
argo,
cd
and
flux.
However,
I
would
like
to
transition
into
using
github's
to
more
real
case
scenarios
such
as
infrastructure
provisioning.
When
I'm
going
to
talk
about
the
cluster
api
and
flex
cd
integration,
and
how
can
we
push
the
applications
towards
the
edge
by
using
the
association
between
cube,
h
and
argo
city?
A
A
We
had
tools
such
as
docusworm
apache,
mesos,
kubernetes,
corous
fleet
and
all
of
them
provided
a
viable
solution
to
run
containers
at
scale.
However,
kubernetes
took
the
lead
in
defining
the
principles
of
how
to
run
containerized
workloads.
Nowadays,
british
is
known
for
its
portability
and
adaptability,
but,
more
importantly,
for
its
approach
towards
the
clarity
of
configuration
and
automation,
and
we
can
see
this
represented
in
numbers
based
on
the
cncf
survey.
A
Last
year,
more
than
85
of
the
companies
are
using
kubernetes
in
production
when
we
transition
towards
the
contributor
community,
more
than
2500
engineers
are
actively
collaborating
towards
feature
build
out
and
bug
fixing.
Now,
when
we're
looking
to
the
end
user
community,
more
than
41
000
identities
were
registered
at
the
cucumbers
around
the
world.
Now
this
were
the
kubecon
virtual
in
europe
and
north
america,
and
this
has
been
extremely
beneficial
for
kubernetes,
because
over
time
multiple
tools
were
built
around
it
to
extend
its
functionalities
and
this
created.
A
Now,
currently,
the
cncf
landscape
provides
a
lot
of
tools
that
enables
further
functionalities
or
integrations.
However,
the
community
focused
into
enhancing
the
developer
experience
but,
more
importantly,
introducing
a
new
way
or
redefining
the
way
we
deploy
cloud
native
components,
and
this
is
how
the
kidops
model
came
to
be
about
one
referred
to
gitobs
pretty
much.
It
is
a
strategy
that
uses
git
repositories
as
the
source
of
truth
for
defining
the
desired
state
of
the
application
by
using
this
model
by
default.
We're
gonna
have
a
pr
based
rollout.
A
That
means
that
the
delta
between
your
local
environment
and
the
production
cluster
is
just
one
pr
away
as
well
with
githubs.
We
have
the
feature
of
automatic
reconciliation
with
the
github
stores,
they're
actually
going
to
watch
a
repository,
and
if
new
changes
are
identified,
they're
going
to
be
extrapolated
and
applied
to
the
cluster
straight
away,
but,
more
importantly,
with
gitobs,
we
have
a
version
state
of
our
cluster.
That
means
that
we
have
historical
data
points
when
we
know
our
application
was
up
and
running
and
using
git
commands.
A
We
can
easily
revert
to
that
state
when
you're
looking
into
the
cloud
native
ecosystem.
Currently,
this
area
is
led
by
tools
such
as
flux
and
argo.
Cd
flux
currently
has
is
an
incubation
cncf
project
and
has
been
donated
by
weave
works.
While
argo
city
has
been
donated
by
one
of
our
end
user
organization,
which
is
into
it
this
stage,
we
have
a
brief
introduction
of
the
cloud
native
tools
that
support
the
github
strategy.
A
I
would
like
to
introduce
cluster
api
just
to
make
sure
that
we
have
the
ground
knowledge
on
components
for
cluster
api
setup.
So
currently,
cluster
api
provides
a
set
of
declarative
apis
for
classic
creation,
configuration
management
and
deletion
across
multiple
cloud
providers
want
to
refer
to
cluster
api.
We
refer
to
c
cluster
lifecycle,
which
had
its
first
initially
released
in
april
2019..
A
I
was
mentioning
the
cluster
api
integrates
with
multiple
cloud
providers,
and
currently
we
have
a
dozen
of
them
from
which
some
of
the
major
club
providers,
such
as
aws
azure,
google
cloud
and
many
more
as
well.
The
metal
provisioning
of
the
cluster
is
currently
supported
by
packet
and
tinker,
and
we
even
have
support
for
chinese
providers
such
as
tencent,
baidu
and
alibaba
cloud.
A
Let's
look
in
a
bit
more
detail
how
cluster
api
works
supposedly
you'd
like
to
provision
a
set
of
clusters
in
different
regions,
different
cloud
providers.
The
first
step
is
to
provision
a
management
cluster
for
testing
purposes.
It
is
recommended
to
use
client
which
pretty
much
is
a
dockerized
version
of
kubernetes
and
it's
quite
lightweight,
and
you
can
even
run
it
on
your
local
class
in
your
local
machine.
A
Cluster
api
introduces
five
new
customer
service
definitions
and
will
require
a
controller
for
each
of
them
to
make
sure
that
we
can
add,
remove
or
reconcile
any
changes
to
it.
The
second
set
of
controllers
are
going
to
be
the
bootstrap
provider,
and
this
is
the
component
that
translates
the
yaml
configuration
into
cloud
unit
script
and
make
sure
to
add
the
instance
to
the
cluster
as
a
node.
A
Once
we
have
our
controller
managers
up
and
running,
we'll
be
able
to
provision
our
target
clusters,
and
these
are
going
to
be
the
clusters
we
will
provision
or
deliver
to
our
engineering
team
to
place
their
application.
On
top
of
these
are
going
to
be
the
clusters
that
the
customers
will
interact
with
when
consuming
a
product
or
a
service.
A
This
code
using
gamel,
so
the
first
resource
that
will
require
is
going
to
be
a
cluster
resource,
and
this
pretty
much
takes
care
of
the
networking
components
for
a
cluster
we'll
be
able
to
specify
the
cider
for
our
pods
or
any
dns
suffix.
If
you
have
any,
the
cluster
resource
by
default
is
going
to
be
associated
with
the
control
plane
resource
the
control
plane
resource
allows
us
to
declaratively
manage
a
set
of
master
machines.
A
As
you
can
see
here,
we
have
our
machine
resources
on
top
of
it,
which
is
pretty
much
the
configuration
for
a
node
for
an
instance
we'll
be
able
to
define
settings
such
as
the
instance
type.
The
version
of
kubernetes
and
many
more
once
we
have
our
cluster
and
control
plane
configured
we
might
require
to
have
a
data
plane,
so
these
are
going
to
be
the
worker
nodes,
we're
going
to
place
our
application
on
top
of.
Usually
this
is
going
to
be
managed
using
a
machine
deployment.
A
A
machine
deployment
resource
is
very
similar
to
a
deployment
pretty
much.
It
comes
with
a
very
powerful
rolling
out
strategy
between
different
versions
of
machine
sets.
Machine
set
is
very
similar
to
replica
set.
It
will
make
sure
that
we
have
an
amount
of
machine
resources
up
and
running
at
all
time
and,
lastly,
we're
going
to
have
the
actual
machines
for
the
actual
instances
which
pretty
much
will
define
our
nodes
within
the
cluster,
but
the
role
in
this
case
is
going
to
be
the
worker
nodes.
A
Before
I
move
forward
with
the
light
demo,
I
would
like
to
showcase
the
current
setup
that
I
have
now.
The
cluster
api
completely
introduces
a
new
concept
of
cluster
as
a
resource
we'll
be
able
to
define
our
infrastructure
using
yaml
manifest
once
we
have
our
manifest,
we'll
be
able
to
store
it
in
a
github
repository.
So
pretty
much
we'll
be
able
to
have
these
historical
data
points
of
different
versions
for
our
manifest,
and
we
can
either
introduce
an
extra
layer
of
abstraction
or
a
configuration
manager
such
as
helm
or
customize.
A
In
this
particular
demo,
I'm
going
to
use
helm
so
pretty
much
we'll
be
able
to
parameterize
our
manifest
using
a
helm
chart
to
deploy
all
of
these
resources.
I'm
going
to
use
flux
cd
so
pretty
much
if
we
have
any
new
changes
to
our
manifest
they're
going
to
be
identified
by
flux
and
applied
straight
away.
A
A
It
is
worth
to
mention
that
for
this
demo
I
have
provisioned
the
target
cluster,
mainly
because
it
takes
around
10
minutes
to
have
it
up
and
running.
However,
in
the
demo
I'm
going
to
change
the
amount
of
worker
nodes
we
have
within
our
cluster,
so
for
that
we're
going
to
change
our
yaml
manifests
and
move
through
the
home
chart.
A
A
So
here
we
defined
our
repository
but,
more
importantly,
we
def
we
represent,
or
we
specify
the
relative
path
towards
our
chart.
In
this
case,
our
chart
is
located
under
the
charts
forward,
slash
copy,
aws
folder
and
towards
the
end,
we
can
see
that
we
select
a
particular
values
file
for
our
home
chart,
so
pretty
much
what
input
variables
we
should
have
for
this
chart
and
in
this
particular
case,
all
of
the
variables
are
going
to
be
stored
within
the
values,
slash
demo.tml
file
and
without
any
further
ado.
Let's
see
how
this
actually
looks
in
action.
A
So,
as
mentioned
currently,
I
have
a
home
chart
in
this
repository.
I
have
a
helm
chart
for
templating
all
of
my
cluster
api
components.
So
if
I
look
within
the
templates,
folder
I'll
be
able
to
see
all
of
our
yammer
manifests.
So,
for
example,
we
can
go
to
cluster
resource,
so
have
a
cluster
resource.
We
define
a
slider
for
our
pods,
we
define
or
reference
our
control
plane
and
infrastructure
reference
which
is
going
to
define
it
as
an
aws
cluster.
A
A
Now
without
any
further
ado,
let's
introduce
some
changes.
So
if
I
go
to
the
values
demo
file,
I
would
like
to
change
the
amount
of
replicas
from
three
to
five
as
well
with
plugs.
It
is
important
to
change
the
charge
version,
and
this
is
because
this
is
the
only
way
for
flux
to
identify
that
there
has
been
new
changes
to
this
particular
helm
chart.
So
we're
going
to
change
our
chart
version
and
then
we're
going
to
commit
all
of
these
files.
A
A
A
I'd
like
to
start
with
a
short
explanation
of
what
qbh
represents.
Cubitch
is
built
on
top
of
kubernetes,
and
it
provides
synchronization
for
metadata
application
and
networking
synchronization
between
the
cloud
and
the
edge
using
cube
age
allows
us
to
have
seamless
communication
between
the
cloud
and
age
components.
A
A
Let's
look
into
the
cube
edge
architecture
briefly.
So
currently,
there
are
three
main
areas
that
I'd
like
to
identify
here:
cloud
edge
and
the
devices
it
is
worth
to
mention
that
the
edge
and
the
devices
here
actually
represent
the
edge.
However,
the
devices
are
the
physical
components
that
are
with
end
users
and
I'd
like
to
differentiate
that,
when
you're
looking
into
the
cloud
side
we're
going
to
have
a
current
this
cluster.
But
more
importantly,
this
is
going
to
be
integrating
or
communicating
with
the
cloud
core
components.
A
A
Currently
we'll
be
able
to
manage
our
containers
on
the
edge
using
a
runtime
such
as
docker,
container
d,
cryo
or
vert
lit
as
well.
The
h4
components
are
going
to
talk
with
the
mqtt
client,
and
this
will
pretty
much
ensure
that
we
synchronize
the
state
of
the
device
with
the
desired
state
that
we
have
on
the
edge
as
well
before
I
move
forward
with
the
actual
demo,
I'd
like
to
introduce
an
overview
of
the
current
setup.
A
A
A
This
particular
resource
is
used
to
define
where
we
store
our
configuration
so
pretty
much
the
source
and
we
define
the
destination.
So
we
would
like
our
components
or
infrastructure
application
to
be
deployed.
So
in
this
particular
case
we
have
an
application
crd
with
the
name
nginx
edge,
and
it's
going
to
be
deployed
within
the
argo
city.
Namespace.
A
If
you
look
into
the
specs
section,
I
have
trimmed
the
output
for
destination
just
to
shorten
the
output
within
the
slide
and
towards
the
end.
You
can
see
the
source,
and
currently
we
define
that
our
manifests
are
stored
within
the
cube
edge.
Our
lego
city,
demo
repository
and
it's
underneath
the
manifests
folder
and
we
can
see
this
defined
in
the
pal
variable
enters
the
end.
We
can
see
that
we
have
a
sync
policy
which
is
set
to
automated,
so
pretty
much.
A
Any
new
changes
that
are
going
to
be
identified
are
going
to
be
applied
to
the
cluster
straight
away.
As
all
of
our
goes
to
do,
we
have
an
option
for
manual
synchronization,
and
this
is
useful.
If
you'd
like
to
validate
the
changes
before
applying
them-
and
this
is
a
time
to
move
towards
the
second
demo,
so
if
I
go
back
to
my
terminal
as
mentioned
currently,
I
have
two
nodes,
one
of
which
is
going
to
represent
the
cloud
and
the
other
one
is
going
to
represent
the
edge
on
the
cloud
side.
A
As
mentioned,
we
have
a
kubernetes
cluster
up
and
running,
which
means
that
we'll
be
able
to
use,
skip
ctl
commands
to
interact
with
it.
So
if
I
do
a
quick
ctl
get
pods.
Currently
I
see
that
I
have
no
pods
no
applications
up
and
running,
however,
because
I
have
cube
edge
ready
installed,
I
can
get
the
nodes.
So
currently
you
can
see
that
I
have
two
nodes
present
or
available
for
this
cluster.
A
A
Now,
let's
deploy
something
to
argo
cd
before
I
move
forward,
I
would
like
to
showcase
our
application
crd
and
pretty
much
everything
we
had
in
the
slide.
We
have
an
application
crd
with
the
name
nginx
edge
here.
We
can
actually
see
the
definition
of
our
destination,
which
is
the
current
cluster,
so
we
deploy
our
application
to
the
current
cluster
and
you
can
see
the
source
pretty
much
where
we
store
the
representation
or
the
state
of
our
application.
A
If
we
go
into
github
we'll
be
able
to
see
that
within
the
manifest
folder,
we
have
an
nginx
deployment
pretty
much.
This
is
a
very
simple
deployment
over
here
that
deploys
and
one
replica
of
nginx
in
the
alpine
version,
so
pretty
straightforward
and
I
as
well
can
interact
with
rbcdy
and
currently
I
can
see
that
I
have
no
applications
defined
or
deployed.
A
A
Going
back
to
the
y,
we
can
see
that
application
has
been
created
and
it's
automatically
synchronized.
If
you
click
on
it,
we'll
be
able
to
see
that
we
have
our
deployment
for
engine
x
with
one
pod,
so
we
have
one
replica
of
our
application
going
back
to
the
terminal,
I
can
do
a
quick
ctl
get
pot
and
I
can
see
that
I
have
one
replica
of
our
nginx
application
up
and
running.
A
However,
if
I
choose
or
select
a
white
output
I'll
be
able
to
see
that
our
application
has
been
pushed
towards
the
edge
node
straight
away-
and
you
can
see
this
has
been
happening
30
seconds
ago,
and
we
can
further
confirm
that
by
looking
into
our
h
component.
So
as
mentioned
on
the
edge,
we
don't
have
kubernetes
installed.
So
if
I
do,
it
gives
a
tail
command,
we
not
be
able
to
identify
it,
and
this
is
because,
on
the
edge
we
manage
our
containers
using
docker.
A
So
if
we're
doing
a
docker
ps
we'll
be
able
to
see
a
bunch
of
containers,
the
we're
going
to
have
a
set
of
them
which
are
going
to
be
related
to
the
load
balancer
currently
using
traffic
to
provision
those.
However,
I
would
like
to
draw
your
attention
towards
these
two
containers,
which
have
been
created
just
wonder
and
one
minute
ago,
and
the
first
one
is
pretty
much
our
nginx
application
container,
which
is
running
and
that
one
is
going
to
be
the
pulse
container.
A
So
this
concludes
the
talks
and
the
examples
I
wanted
to
give.
Today.
We
started
by
introducing
the
cloud-native
github
stores,
such
as
argosidine
flux,
but,
more
importantly,
we
deep
dive
into
real
use
cases
of
using
github's
model.
As
such,
we
looked
into.
How
can
we
provision
our
infrastructure
with
cluster
api
and
flexity
and
as
well
towards
the
end
we
looked
into?
A
If
you
have
more
questions
about
today's
talk,
please
reach
out
I'm
going
to
write
a
medium
article
with
more
information
of
how
this
current
setup
has
been
done
and
you'll
be
able
to
follow
it
with
more
details
as
well.
If
you
have
questions
around
this
talk,
I'm
going
to
be
available
on
social
media
to
answer
them
such
as
twitter
and
linkedin,
enjoy
the
rest
of
the
conference.
Thank
you.