►
From YouTube: Installing the GitLab Kubernetes Agent
Description
Installing the GitLab Kubernetes Agent
This demo shows the installation of a GitLab instance on GKE using helm, the installation of the Kubernetes Agent Server on the GitLab instance and the installation of the agent on the GKE. Finally, it shows how changes/updates to a GitLab project are automatically detected by the agent and enacted upon the K8s cluster.
A
Hello,
my
name
is
cecil
cevedra,
I'm
a
technical
marketing
manager
at
gitlab.
In
this
video
we're
going
to
cover
the
installation,
configuration
and
use
of
a
brand
new
githubs
capability
called
gitlab
kubernetes
agent.
Let's
get
started
the
gitlab
kubernetes
agent
is
an
active
in
cluster
component
for
solving
gitlab
and
kubernetes
integration
tasks
in
a
secure
and
cloud-native
way.
A
It
enables
the
integration
of
gitlab
with
a
kubernetes
cluster
behind
a
firewall
or
an
or
a
network
address
translation.
It
implements
a
pool
based
ci
cd,
get
ops
deployments
by
leveraging
the
github's
engine
open
source
project
and
it
provides
real-time
access
to
api
endpoints
within
the
cluster.
A
Presently,
the
gitlab
kubernetes
agent
can
only
be
deployed
through
our
helm
chart.
So
in
order
to
do
this,
we
need
to
first
install
gitlab
using
helm,
so
we're
going
to
follow
the
instructions
in
the
documentation
to
install
gitlab
and
we're
going
to
be
using
this
script
right
here.
It's
a
bootstrap
script
that
will
install
gitlab
on
gke.
A
The
domain
names
domain
name
is
get
glab1
dot,
tenuki.host.
A
Go
and
now
we're
gonna
be
doing
a
helm
repo
at
gitlab,
and
I
already
added
it
it's
already
there
and
we're
gonna
do
a
helm,
repo
update
next
and
now
we're
going
to
do
a
helm
upgrade
install,
and
this
is
the
step
that
will
be
rolling
out
or
installing
a
pod
in
the
gke
cluster
with
the
actual
agent
we
pass
it.
Some
parameters,
including
the
domain
and
the
ip
address.
A
The
cert
manager
is
your
email
as
well,
and
the
globalcast
enable
we
set
that
to
true,
and
that
way
we
install
the
agent
within
this
gitlab
instance,
all
right,
so
the
helm
upgrade
has
taken
place.
Let's
check
the
running
pods
some
are
initializing,
so,
let's
check
again,
okay,
good.
So
the
web
service,
which
is
the
main
console
the
login
console,
is
up
and
running.
A
A
A
A
Very
good,
so
now
we
have
two
projects:
kubernetes
agent
and
github's
project
in
the
gitlab
instance.
A
So
now
what
we
need
to
do
is
we
need
to
configure
and
instantiate
basically
deploy
the
agent
itself
to
the
cluster
and
one
way
to
do
that
is
through
the
rails
console.
But
to
get
to
it.
We
first
need
to
log
in
to
the
runner
pod,
so
we're
now
inside
the
runner
pod,
and
then
we
execute
a
command
to
get
into
the
rails
console
and
from
there
we
can
create
a
project
which
is
pointing
to
the
kubernetes
agent
project
we
defined
earlier.
A
So
then
we
create
a
namespace
in
the
cluster
called
gitlab
agent
and
we
create
a
secret
and
we
use
the
token
from
the
rails
console
that
we
created
earlier
so
now
we're
gonna
go
to
the
documentation
and
make
a
copy
of
the
resources.
Yaml
file
example
file,
and
this
yaml
file
is
the
configuration
of
the
agent
that
we
we
will
be
deploying
to
the
kubernetes
cluster.
A
A
So
we
apply
this
resources
yaml
to
the
cluster.
Now,
let's
see
the
parts
already
up
and
running
the
gitlab
agent.
A
A
A
And
to
show
you
how
fast
the
the
modifications
take
place
and
how
fast
the
agent
detects
these
modifications,
like,
let's
increase
the
number
of
replicas
from
two
to
three
say
this,
and
let's
go
back
to
the
cluster
and
check
the
pods,
and
we
will
see
a
third
nginx
deployment
pod
up
and
running.
So
the
agent
is
basically
using
a
pool
based
cicd
approach.
A
A
A
A
So
it's
monitoring
the
changes
in
the
getups
project
in
this
case
and
making
sure
basically
observing
the
manifest
manifest
yaml
file
to
see
if
there
are
any
changes
or
updates.
A
A
They
will
likely,
you
know
most
likely
be
separate
clusters,
one
cluster
running
gitlab
and
a
separate
cluster
running
an
application
with
with
this
agent
right
here
and,
as
you
can
see
in
the
log,
this
every
summit
so
many
seconds,
the
agent
checks
with
the
agent
server
and
to
see
if
there
have
been
any
updates
or
changes
to
the
project
that
is
being
observed
in
this
case
is
the
project
called
get
up
project
and
as
changes
happen,
the
agent
is
communicated
of
these
changes
and
then
the
agent
applies.
These
changes
to
the
local
cluster.
A
You
can
see
in
these.
In
these
messages,
the
first
two
instances
of
the
engine,
nginx
server,
that
were
deployed
and
started
as
pods.
A
And
also
the
last,
the
third
edition
of
it.
So
in
this
demo
you
have
seen
the
installation
of
gitlab
and
gitlab
kubernetes
agent,
that
is
our
pool
based
ci
cd
for
githubs,
which
allows
corporations
and
organizations
to
take
advantage
of
our
github's
approach
without
having
to
expose
their
clusters
to
the
internet.