►
From YouTube: Lightning Talk: GitOps, A Slightly Realistic Situation on Kuberne... Laurent Grangeau & Ludovic Piot
Description
Lightning Talk: GitOps, A Slightly Realistic Situation on Kubernetes with Flux - Laurent Grangeau, Google & Ludovic Piot, theGarageBandOfIT
You're tired of talks that deploy hello-worlds to demonstrate the relevance of the younameit tool. That's good news: what we're interested in is trying out a slightly realistic DevSecOps situation. So we're going to build a step-by-step enterprise scenario where devs and ops collaborate on a daily basis around a GitOps workflow based on Kubernetes and Flux. The dev teams deploy / update / rollback Pokémon WebApps using Kustomize and/or Helm charts. On the Ops side, we take care of the platform's security issues by implementing Kyverno: segregation of team rights, WebApps network flows and control of activities on the cluster. And we monitor everything via Prometheus and Grafana. Finally, we will see how to articulate upgrade and configuration while respecting the blue/green pattern and canary deployment, thanks to Istio. At the end of this hands-on, you may have discovered some technologies. But above all you will have seen how to implement them in a dev-to-prod process that resembles a real case.
A
So,
as
I,
as
I
told
you
earlier,
this
this
session
is
a
talk
shortened
from
a
long
long,
a
long
workshop,
three-hour
long
workshop.
So
we
shorten
some
things
a
bit
so
when
it
comes
to
to
deploying
on
kubernetes
in
a
traditional
in
a
traditional
way,
we've
got
using
ups
teams,
use
cube
cattle
or
elm
to
deploy.
A
Okay,
fine
and
it
comes
with
several
issues,
and
that's
why
githubs
do
exist.
We
don't
have
a
traceability
on
several
cluster
scale.
We
don't
have
tracking
of
the
the
history
of
our
changes
and
we
have
most
of
most
of
all.
We've
got
security
issues.
We
have
to
keep
secret.
We
have
to
transmit
this
this
secret
to
our
cicd
tool.
A
We
have
to
get
connections
between
the
runner,
the
the
the
skyrunner
and
the
cluster,
the
equipment
test,
cluster
and
so
on.
So
it's
quite
a
back
practice
and
then
come
get
ups,
as
you
may
say,
as
you
may
know,
and
what
is
git
ups
github
is
first.
First
of
all,
github
is
a
way
to
deploy
by
keeping
a
single
source
of
truth
in
git,
and
so
as
it
comes
with
git,
it
comes
with
every
pattern.
Every
collaboration
pattern
that
we
can
have
in
gibbs,
so
pr
branches
tagging
blaming
and
so
on.
A
A
A
A
A
A
In
addition
to
this
to
these
components,
there
is
a
single
cli
which
is
used
mostly
to
bootstrap
files,
as
we
can,
as
we
can
see
as
we
can
see
later.
During
this.
This
talk
mostly
we've
got
three
operators
that
are
the
source
controller,
which
is
just
watching
several
kind
of
sources,
mostly
git
git
sources,
git
git
services
like
github,
beatback,
gitlab
and
so
on
also
get
a
single
git,
repo
locally
or
remotely,
and
we've
got
a
source
controller.
That's
a
watch
that
is
able
to
watch
charge.
B
So
three
personas
developer
teams,
operation
teams,
security
teams,
every
teams
has
their
own
focuses
like
the
developers
wants
to
ship
features
faster.
They
want
to
fix
bugs
fixes
bugs
they
want
to
to
be
autonomous
and
and
in
isolation,
but
they
don't
have
any
operation
or
run
in
mind
and,
of
course,
not
not
security
in
mind.
Also,
on
the
other
side,
we
have
operation
teams.
B
B
B
We
we
will
talk
about
kiverno
or
open
policy
agents
and
we
will
try
to
create
some
security
security
policy
on
top
of
that,
and
so
they
have
their
own
repo
in
which
we
will
create
some
policies
and
just
apply
that
with
flux.
This
is
this
is
the
workflows
that
we
are
trying
to
to
create
and
to
push,
and
to
do
that.
B
B
For
this
example,
we
will
just
create
a
boost,
create
some
yaml
file
on
github,
and
it's
the
only
moment
that
flux
will
pin
the
api
of
github
to
just
interact
with
github,
to
put
some
some
maintainer
roles
on
the
repo,
for
example,
for
the
dev1
and
f2
team.
We
will
create
some
maintenance
on
top
of
that,
so
we
can
just
have
some
some
developer
workflows,
like
pr
pull
request
reviews.
B
B
Then,
as
I've
already
told
you
in
this
context,
we
will
try
to
create
one
namespace
per
application,
because
we
will
have
like
one
cluster
for
a
production
and
one
cluster
for
non-production
and
in
france.
That's.
We
have
seen
that
in
lots
of
companies
yeah,
of
course-
and
we
don't
want
to
manage
hundreds
of
hundred
of
cluster
and
one
cluster
per
application,
because
it's
it's
not
no,
it's
not
it's
too
expensive.
A
B
Yeah,
so
for
setting
up
the
tenants,
we
have
the
tenant.cml
file
created
with
flux,
so
it
just
create
some
some
lines
inside
the
tenant's
html
file
to
create
for
this
example
the
staging
cluster
and
just
say
that,
okay,
you
will
just
watch
the
github
represe,
the
git
replace
series
that
is
called
flux
system
and
it's
our
senior
source
of
truth.
It's
based
on
git.
B
On
top
of
that,
we
will
have
to
create
physically
the
tenants,
so
we
are
creating
the
airbag
file
system.
So
you
see
that
it
creates
the
namespace
dev1.s
the
service.
Second,
then
they
have
one
that
they've
won
seven
seconds
and
we
create
some
airbag.
On
top
of
that
to
be
sure
that
only
the
several
seconds
have
one
have
access
to
the
namespace
and
to
not
be
able
to
conflict
with
each
other
on
the
application.
B
So
that
is
the
the
content
of
the
tenants.tml
file.
But
of
course
we
will
have
to
add
some
some
applications,
some
some
some
policies
around
that.
So
we
will
add
some
cluster
role
and
you
see
that
the
cluster
role
of
dev1.s
is,
of
course,
full
access,
but
you
can
customize
it
with
some
more
restricted
cluster
and
we
will
have
some
deployments.
Replicas
set
pos
list
watch
create
update
stuff
like
that,
and
now
we
have
like
our
namespace.
B
Our
service
accounts,
our
cluster
role,
ready
to
be
deployed,
and
it's
time
to
onboard
the
the
developer
with
customize.
So
to
sum
up,
we
have
created
with
flux
and
to
and
with
only
git
push
on
the
cluster.
The
namespaces,
the
service
accounts
the
git
source,
and
now
we
have
to
create
a
new
source
repo
to
to
point
to
the
to
the
developer
team.
B
So
we
are
onboarding
the
dev
team
and
we
are
creating
a
new
yaml
file
in
the
tenants
and
I'm
not
sure
if
you
are
familiar
with
customize,
but
just
it
relies
actually
on
customers
and
customers
have
this
kind
of
overlays
and
base
that
you
can
override.
Yes,
overwrite
some
some
parameters,
so
you
create
the
base
file
system
on
customize.
B
Just
saying
that
here
is
my
application.
It
relies
on
the
gita.com1
community,
slash
dev1,
sp
cut
application
and
it
creates
a
new
git
repository
source
and
you
can
just
push
it
on
on
git
and,
of
course,
flux
will
just
prove
the
new
yaml
file
and
reconciliate
that
on
the
cluster,
you
have,
of
course,
to
have
some
customization
with
flux,
so
you
create
a
new
customization
and
you
will
say
that
okay,
this
customization
will
only
deploy
the
application
is
named.
B
Dev1.Ns-
and
you
put
some
service
account
name
to
be
able
to
deploy
on
that
namespace,
because
only
they
have
one
clusterrule
dev173
we'll
have
access
to
the
development
dashiness.
So,
for
example,
if
another
team
wants
to
deploy
a
new
application
in
this
namespace
in
particular
that
one
it
will
not,
it
will
not
have
access
because
they
don't
have
access
to
their
one,
the
service
accounts,
and
they
don't
have
access
to
this
particular
namespace.
B
B
And
because
it
relies
on
customize,
you
have
to
add
some
overlays
on
top
of
customize,
and
here
you
can
create
some
overlays
to
deploy
a
new
patch.
So
here
we
have
created
a
new
patch
that
basically
does
nothing
just
to
have
some
patch,
and
then
we
told
customization
customize
for
it
to
deploy
that
patch
to
be
able
to
have
the
database
deployments.
B
And
on
top
of
that
to
have
the
overlay,
it
will
be
useful
if
you
want,
for
example,
to
add
some
requests
or
limits
on
top
of
the
application.
If
you
are
informed,
if
you
want
to
add
like
secrets,
because
you
know
that
developers
don't
have
access
to
secrets
for
databases,
for
example,
but
only
operations
have
access
to
that.
So
operation
can
override
parameters
of
the
application,
only
creating
yammer's
files
and
to
to
be
applied
by
flux.
And
so
you,
you
have
clear
isolation
between
developers
and
operations.
B
I
know
that
working
with
devops
who
are
trained
to
to
the
two
teams
to
talk
to
each
other,
but
here
we
have
a
tool
that
relies
on
on
flex
on
github
on
githubs,
to
be
able
to
have
some
collaboration
between
developers
and
operation
without
the
without
the
the
needs
to
to
to
just
talk
to
each
other.
Yeah.
A
So
yeah,
what
we?
What
we
show
you
very
quickly,
is
how
to
configure
a
flux
component
and
then
how
to
configure
and
maintain
a
cluster
and
even
a
group
of
cluster
and
have
a
different
configuration
derivated
from
the
same
base,
the
same
configuration
base
and
then,
on
top
of
that,
we've
got
a
configuration
to
deploy
here
and
a
single
application
for
dev1
team.
But
this
is
this
might
be
replicated
for
a
lot,
a
lot
of
lots
of
applications.
A
So
we've
got
the
first
configuration,
which
is
the
the
configuration
of
of
the
flux
component,
which
is
in
the
folder
flux
system.
Here,
as
we
have
seen
before,
and
this
configuration
targets
the
tenants.yaml
file,
which
is
the
which
is
the
the
description
of
the
tenant
that
will
be
the
base
of
the
configuration
for
our
cluster
and
our
cluster
is
just
is
just
configurated
by
this.
A
B
B
Of
course,
you
can
have
also
a
canary
strategy.
If
you
want
to
test
like
a
new
version
of
eco,
a
new
version
of
prometus,
you
can
just
have,
for
example,
a
service
dash
blue
service,
green
and
just
point
to
the
right,
folder
and
just
apply
some
customized
patches
to
be
able
to
replace
some
plugin
deployment
to
be
able
to
demonstrate
that
we
will
try
to
create
some
we'll
try
to
install
some
promote
use,
chat
and
help
chat.
B
B
B
We
have
created
before
just
to
install,
promote
use
and
to
configure
parameters
more
easily,
all
based
on
the
git
repo
git
repo,
and
you
can
see
that
the
values
file
points
to
the
to
the
folder.
My
cluster
slash
cube,
parenthesis
text,
slash
value,
and
here
we
can
also
work
with
the
security
team.
To
install,
like
I
say,
eco
prometheus
here
on
install
kivano
cubano
is
like
open
policy
actions.
B
So
application
or
operation
cannot
deploy
applications
without
a
service
account
name
to
enforce
policy,
and
you
can
just
create
some
policies
based
on
a
network,
security
policy
or
tags
or
whatever,
and
you
just
apply
this
policy
with
customization.
So
that's
the
same
mechanism
that,
before
you
create
some
yaml
files,
you
get
pushed
to
that
and,
of
course,
it's
being
deployed
on
the
cluster,
but
you
can
also
benefits
from
the
developer.
Workflows
like
security
team
can
just
create
some
yaml
file,
create
a
pull
request
on
github
with
the
dml
file.