►
Description
Using Kubernetes and GitLab you can build a multi-team platform for streamlining CI/CD, policy management and developer onboarding across your organization and teams. We will demo common developer, operator, and security engineer tasks to show how the patterns can improve your company’s software delivery performance.
A
So
my
name
is
amir.
I'm
also
an
essay
solutions,
architect
here
at
google,
and
I
will
be
your
operator
for
the
rest
of
the
10
minutes
or
so
that
we
have,
let's
all
put
on
our
operator's
hats
and
let's
assume
that
our
developer
just
walked
up
to
us
and
said
hey.
I
have
this
new
go
app,
I'd
like
to
deploy
hi
miles.
How
are
you
awesome
and
then
so?
What
do
we
do
so,
like
any
other
platform
as
a
service,
we'd
start
with
the
cli,
which
is
what
you
see
up
here.
A
We
have
this
handy
dandy,
cli
tool
that
we
are
going
to
use
to
add
a
new
application
called
hello,
kubecon
1
into
our
cicd
platform.
Maybe
all
right,
let
me
just
make
sure
I'm
in
the
right
folder
back
out-
is
that
good,
no
one
more
one
more
all
right!
Cli
is
a
good
way
of
adding
an
application.
It's
nice
and
consistent
everybody
gets
to
the
same
way.
You
don't
make
any
kind
of
human
mistakes,
but
in
this
particular
case
we're
using
anthos
platform
cli.
A
The
name
of
our
application
is
just
going
to
be
hello,
cubecon
2019.
We
give
it
our
ci
cd's
hostname,
which
in
this
case
is
gitlab
the
password
and
then
the
the
template
right
so
again,
template
gives
you
kind
of
that
boilerplate
code
kind
of
already
made
up
right,
so
what's
happening
in
the
background,
I'll
just
quickly
explain
is
in
gitlab
it's
creating
a
group,
and
a
group
is
nothing
more
than
just
a
collection
of
repositories.
Just
like
an
organization
and
github,
and
in
this
case
it's
creating
those
two
repositories.
A
One
is
your
application
code
repositories,
that's
what
you
hand
off
to
your
developers,
that's
where
they
iterate
on
their
applications
and
then
the
other
one
is
your
operator's
repository
or
your
environment
repositories.
That's
where
all
of
the
kubernetes
resource
manifests,
reside
for
all
all
environments,
so
for
dev
stage
and
prod
keeping
those
two
separate
kind
of
keeps
the
ci
of
the
developer,
separated
from
the
cd
of
the
operator.
It's
a
nice
way
to
do
that.
Another.
A
Vic
mentioned
is
that
every
application
gets
deployed
in
its
own
namespace
on
every
single
cluster
and
as
part
of
that
namespace,
a
gitlab
runner,
which
is
just
a
deployment,
is
deployed
inside
of
that
namespace.
Now,
there's
a
couple
of
schools
of
thought
here:
one
is:
how
do
we
push
these
manifests
down
to
the
clusters,
so
there's
two
ways
to
do
that.
A
We
can
either
give
kind
of
the
credentials
to
the
git
repos
and
every
single
get
reboot
for
every
single
kubernetes
cluster
and
we
push
those
configs
down
so
the
credentials
kind
of
remain
outside
of
it,
or
in
this
case
we
are
giving
those
credentials
as
a
service
account
to
the
gitlab
runner
and
then
giving
the
git
lab
runner
the
get
credential.
So
it
can
pull
those
manifests
in
order
to
do
that,
we
have
to
give
this
gitlab
runner
access
to
pull
those
images
right.
A
So
I'm
going
to
click
on
this
link
and
I'm
just
going
to
create
some
credentials.
So
this
is
very
similar
to
just
creating
a
docker
login,
and
in
this
case
the
only
thing
it
really
needs
is
read
access
to
the
registry,
so
it
can
pull
the
images
so
I'll,
create
a
user
called
git
reader.
It
doesn't
matter
what
we
call
it
we'll
give
it
read:
registry
access
I'll,
create
the
deploy.
Token
and
it'll.
Give
me
this
username
and
password
we'll
copy.
A
So
let's
take
a
look
at
what
it
actually
got
created
in
gitlab,
so
I'm
going
to
go
into
git
lab,
go
to
groups
and
go
to
your
groups,
so
we
can
see
all
of
them.
So
the
first
thing
you
notice
is
that
we
have
this
new
group
created
called
hello,
cubecon
2019.
We
go
into
that
group.
We
have
the
two
repositories.
The
bottom
one
is
your
application
repository.
That's
the
one
for
your
developers,
the
top
one
is
your
end
or
your
environment
repository.
A
That's
the
one
for
your
resource
manifests
for
kubernetes,
we'll
inspect
those
here
shortly.
I'm
gonna
go
back
into
the
groups
and
I'm
going
to
look
at
this
group
called
platform
admins,
and
this
is
an
operators
group,
there's
quite
a
few
repositories
kind
of
in
here
right,
so
I'll
highlight
a
few
of
them.
The
first
one
are
these
templated
repositories,
so
the
golang
template
and
the
golang
template
and
again,
like
I
said
it
kind
of-
gives
our
developers
a
boilerplate
of
a
starting
point
of
something
they
can
code.
A
So
you
don't
have
to
do
this
every
single
time,
so
you
can
have
other
templates
for
java,
ruby
go
and
what?
What
have
you?
We
heard
about
antos
config
management
this
morning,
and
this
is
the
platform
that
sets
up
kind
of
the
foundation,
the
namespaces,
the
registries
and
stuff
like
that
inside
of
this
repository.
This
is
by
the
way
what
the
folder
structure
looks
like
there's
a
namespace
folder,
so
we
go
into
the
namespaces
folder
and
the
managed
apps
folder.
A
You
can
see
that
we
now
have
as
part
of
that
bootstrap
that
we
did
with
the
cli
command.
We
have
a
hello,
kubecon,
2019
folder,
we'll
go
into
that
folder
and
you'll
notice.
That,
like
I
said
it,
creates
the
namespace
for
that
application.
It
creates
that
registry
secret.
That's
that
docker
login,
that
we
just
created
and
it
feeds
that
to
all
of
the
gitlab
runners
in
each
namespace
for
each
cluster.
A
So
you
see
that
three
runners,
two
for
the
production
clusters,
prod
central
prod
east
and
the
staging
so
now
each
cluster
has
pull
permissions
to
pull
register,
pull
images
from
that
registry
and
if
we
want
to
look
at
what
that
looks
like
inside
of
the
cluster.
So
again,
I'm
in
the
cloud
console
we're
looking
at
the
kubernetes
engine.
Workloads
page
and
I've
already
put
a
filter
for
that
namespace
on
there
and
if
we
hit
refresh
you'll
notice
that
we
have
the
three
gitlab
runners,
we
also
have
something
else
deployed
and
we'll
talk
about
that
shortly.
A
But
I
really
want
you
to
focus
on
the
three
runners
that
are
scoped
to
that
namespace.
So
they're
running
within
that
hello,
cubecon,
2019
namespace
in
each
of
the
clusters,
the
two
production
clusters
and
the
one
staging
cluster
and
those
their
permissions
are
scoped
within
that
namespace.
They
can't
put
anything
outside
of
that.
A
So,
let's
go
back
to
our
platform,
admins
group.
Another
thing
I
wanted
to
show
you
was
the
shared
ci
cd
repository.
So
this
is
where
all
of
the
ci
cd
for
every
single
language
will
sit
here.
So
in
the
ci
folder,
for
example,
you'll
have
all
of
the
manifests
for
different
ci
files.
So
we
have
one
for
go
here
as
an
example,
and
you
can
see
it's
fairly
simple,
it's
doing
a
unit
test
which
is
go,
get
go
test
and
then
just
a
build
stage.
A
Right
again,
this
could
be
as
as
deep
as
you'd
like
it
to
be,
and
then
the
last
thing
I
want
to
mention
here
are
customize
bases.
These
are
the
shared
customized
bases.
Like
vic
talked
about
for
every
language
we
have
a
folder,
so
we
can
go
into
the
golang
folder
and
in
this
demo
we're
just
doing
a
deployment
and
a
service,
but
you
can
have
other
kubernetes
manifests
and
they
don't
look
scary
at
all.
A
They
look
just
like
a
vanilla,
kubernetes
deployment
and
things
like
we
can
change
our
environment
so
which
environment
they're
going
into
dev
stage
or
prod.
We
can
change
the
image
name
because
majority
of
the
time
you're
not
changing
the
entire
yaml
you're,
just
changing
a
few
things,
and
that's
where
that
patch
kind
of
comes
in
and
to
show
you
that
now,
let's
go
ahead
and
inspect
our
actual
application
group.
So
I'm
going
to
go
back
into
hello,
cubecon,
2019
group
and
we're
going
to
start
with
the
application
repo.
So
again,
this
is
the
boilerplate.
A
This
is
the
repository
that
gets
handed
over
to
the
developers
and
you
can
see
the
first
thing
we
just
gave
them
some
boilerplate
code.
This
is
just
a
simple
hello
world,
app
that
the
developers
can
start
iterating
upon
in
the
same
repositories.
We
have
the
docker
files.
This
is
what
builds
the
artifacts.
We
have
scaffold,
so
they
can
start
doing
some
development,
some
local
dev
testing
before
they
even
push
this
to
this.
To
this
particular
repo,
we
have
this
gitlab
ci,
which
is
their
ci
cd
file.
For
this
particular
repo.
A
This
pipeline
gets
kicked
off
anytime.
Somebody
commits
makes
a
commit
to
the
master
branch
of
this
application
repo,
and
I
already
showed
you
the
test
and
build
and
steve's
going
to
show
you
kind
of
how
the
deployment
piece
works.
What's
interesting
about
this
is
in
as
part
of
the
application
repo.
We
also
have
the
kubernetes
manifest,
so
the
developers
not
only
get
to
see
what
actually
gets
deployed.
They
also
have
influence
over
how
it
does
it
right.
So
inside
of
that
kate's
folder,
we
have
the
three
folders
for
the
three
environments.
A
So,
for
example,
if
we
go
to
the
staging
folder
first
thing
is
that
it's
pulling
that
shared
customized
basis
from
that
repo
that
I
showed
you
earlier
so
as
an
operator,
I
can
go
and
make
a
change
to
that
shared
base.
One
time,
if
let's
say
I
want
to
change
the
logging
level
or
if
I
want
to
add
resource
limits
or
something
I'll,
just
change
it
one
time
and
in
the
next
roll
out,
this
will
get
applied
across
the
board
and
then
here's
the
patch
the
deployment
patch
that
is
being
applied
for
this
particular
thing.
A
A
So
now
I
mentioned
that
every
time
a
commit
is
made
to
the
master
branch.
A
pipeline
is
kicked
off
so
here,
on
the
left
hand,
side
I'm
going
to
go
to
ci
cd
pipelines,
and
you
can
see
that
one
pipeline
because
of
the
initial
bootstrapping
was
kicked
off
and
let's
click
on
that
pipeline
and
it's
just
a
simple,
four-stage,
ci
cd
step
again,
this
could
be
as
complex
as
you'd
like
the
first
two
are
pretty
self-explanatory
and
I
already
kind
of
showed
you
those.
A
B
Yeah
all
right
cool,
I'm
steve
mcgee,
I'm
a
former
sre,
so
I
get
the
honor
slash
duty
of
pushing
this
thing
into
production,
so
great,
okay,
so
the
the
first
thing
we're
going
to
do
is
it's
still
part
of
the
ci
step,
but
it's
kind
of
the
beginning
of
cd,
which
is
hydrating
these
manifest.
So
these
are
these
yaml
files
that
we
talked
about
before
so
before
we
had
like
the
base
image
and
the
patches
and
you
kind
of
think
about
variables
and
templates.
B
B
The
first
step
is
just
to
build
those.
We
can
click
through
here
and
we
can
show
you
builds
them
all.
It's
very
simple.
It
builds
one
right
here.
It
runs
a
customized
command
for
customized
staging
and
then
it
does
it
again
for
production.
So
after
that,
we
have
these
two
files.
What
do
we
do
with
them?
We
just
push
them
over
to
another
repo
right,
so
now
we're
moving
from
the
code
repo
to
the
environment,
repo.
I
won't
really
show
you
this,
because
it's
just
like
copy-
it's
not
very
interesting.
B
So,
let's
back
out
into
the
group
and
we're
going
to
show
you
the
env,
repo,
the
environment,
repo
and
we'll
show
you
where
those
files
kind
of
end
up.
So
I
go
here.
Oh
my
gosh:
where
are
the
files?
Well,
we
forgot.
We
actually
pushed
it
to
a
branch
right.
We
pushed
it
to
the
staging
branch.
So
as
soon
as
we
move
over
there
here
we
go.
We've
got
our
two
files,
so
we
can
look
at
one.
Let's
look
at
staging
and
it
shouldn't
be
scary
in
any
way
it's
pretty
basic
right.
B
So
we
have
our
environment
label
staging
just
like
we
expect
it
has
the
name,
hello
cubecon.
So
all
those
things
that
looked
all
vanilla
before
have
all
been
filled
in
with
the
right
stuff.
Okay,
so
we
saw
before
that
there
were
three
runners
running
in
kubernetes
and
there
was
also
a
job
running.
There
was
the
actual
staging
app
right.
So
this
is
this.
Guy
right
here,
it
already
got
out
there.
How
did
that?
B
How
the
heck
did
that
happen
and
the
reason
why
that
happened
is
because,
when
we
made
the
the
first
commit,
we
pushed
this
file
all
the
way
to
the
environment
branch
into
the
staging
branch
and
our
friend
the
pipeline
ran
again.
So
let's
see
this
new
pipeline
that
ran
this
is
a
different
pipeline.
This
one
just
did
one
thing
it
deployed
to
staging,
so
we
can
click
in
here.
We
can
see
there's
this
job
that
ran
this
this
this
binary
that
runs
we're
using
something
called
gke
deploy
and
it's
think
of
it.
B
Just
as
like
cube
control
apply,
except
it
does
a
couple
other
little
fancy
things
and
it
waits
for
it
to
succeed
and
then
once
it
does,
it
sort
of
tells
you
here
go
look
at
your
job,
it's
running
it's
great,
so
we
can
see.
Yes,
indeed,
it's
running
so
at
this
point
the
developer
says
great.
My
job
is
what
I
expected.
The
feature
is
doing
the
featuring:
let's
push
it
to
prod
and
then
yessiree
shows
up
and
goes
like
you
got
it.
Let's
do
it.
B
You
know
the
schedule
is
correct,
we're
ready
to
go
and
then,
if
you
recall
from
the
kind
of
interesting
flow
chart
the
way
we
do
this
is
we're
going
to
do
it
by
promoting
the
the
environment
yaml
from
the
staging
branch
to
the
master
branch.
We
do
that
in
gitlab,
using
what's
called
a
merge
request,
which
you
probably
already
know
we're
going
to
make
a
new
merge
request,
we're
going
to
give
it
a
very,
very
descriptive
name
like
go.
B
Oh
no.
The
computer
stopped
computering,
okay,
broad,
okay,
so
we're
going
to
go
to
prod.
So
we
want
to
make
sure
we're
actually
going
from
staging
to
master.
That
looks
pretty
good.
We're
going
to
submit
a
merge
request.
Some
other
person
might
come
in
like
you
might
want
to
have
another
set
of
eyes.
Go
yeah.
This
looks
fine,
they
might
come
in
and
say
well,
let's
take
a
look
at
the
changes,
make
sure
they're
exactly
what
we
expect.
You
might
also
have
other
things
in
your
pipeline
like
to
make
sure
that
we
have.
B
You
know
the
right
amount
of
resources
in
place,
et
cetera.
This
is
really
boring
because
it's
just
like
a
blank
entry
but
let's
say
it
looks
good
we're
going
to
merge
it.
Let's
go
so
now
what
happens
in
this
process,
yet
another
pipeline
happens.
Of
course
it
does
that's
how
this
works
in
this
case
there's
one
step
for
each
cluster
so
for
each
production
cluster
and
it's
exactly
the
same
as
the
staging
one,
except
this
time
it's
pushing
to
production.
B
So
we
have
two
clusters
here:
one
is
just
in
central
one:
look
it
already
finished
and
the
next
one's
going
to
be
an
east
one.
You
might
have
another
step
in
here.
That's
like
wait
or
you
know,
check
the
canary
or
you
know
something
something,
but
we
just
did
something
very
simple.
So
let's
take
a
look
at
kubernetes
and
make
sure
it's
working
should
be
ready.
B
Oh
it's
working,
so
we
have
one
running
in
central
one
and
then
the
usc
one
is
coming
up
as
well.
So,
let's
take
a
look
at
the
logs
viewer
and
we're
gonna
see
if
it
is
really
running
so
for
each
cluster
we
should
be
able
to
see
the
health
checks
come
by
and
ideally,
what
we're
going
to
see
is
three
sets
of
apps.
All
running
kind
of
you
know
skewed
from
each
other
stream
stream.
This
is
it
guys
this
is
gonna,
be
it
and.
B
So
we
have
health
checks
in
staging,
we
have
it
in
prod.
We
have
it
in
prod,
central
and
eventually
we'll
have
ones
from
fraud
east
as
well.
But
that's
it.
You
know
our
code
is
deployed.
It's
in
many
places.
Another
thing
to
point
out:
fraud,
east
and
prod
central
could
be
two
different
types
of
kubernetes
on
two
different
platforms.
You
know
this
is
this.
Is
the
amazing
thing
about
anthos?
It
doesn't
care,
it's
just
kubernetes.
So
that's
it.