►
From YouTube: GitLab Kubernetes Agent: introduction, demo and roadmap
Description
This video present the GitLab Kubernetes Agent. Please, provide your feedback either in https://gitlab.com/groups/gitlab-org/-/epics/3329 or in a customer call
A
A
In
this
short
video,
I
would
like
to
provide
you
a
brief
motivation.
Why
we
are
building
the
agent
and
would
like
to
invite
you
to
try
it
out
and
provide
us
feedback,
so
we
can
be
a
valuable
product
for
your
use
cases
and
needs.
Why
are
we
building
the
agent?
The
previous
kubernetes
integrations
are
great
for
people
who
are
just
getting
started
with
kubernetes,
but
they
often
lack
customization
possibilities
and
have
requirements
that
might
not
be
acceptable
in
many
situations.
A
A
The
first
release
of
the
agent
is
already
available
on
self-managed
gitlab
instances,
and
we
are
working
hard
to
enable
it
on
gitlab.com
too.
I
believe
that
by
the
by
the
13.7
release,
the
agent
will
be
ready
for
quite
a
few
enterprise
use
cases,
and
I
will
provide
a
quick
overview
of
our
roadmap
at
the
end
of
this
video.
So
you
can
know
what
to
expect
in
the
coming
months.
A
Let's
see
the
agent
in
action.
The
agent
is
composed
of
two
components:
the
kubernetes
agent
server
that
sits
together
with
git
lab
and
the
component
that
sits
in
the
cluster.
We
often
call
it
agent
k,
as
already
mentioned
gitlab
command's
agent
is
not
supported
yet
on
gitlab.com,
but
it's
already
available
on
our
staging
environment.
So
I
will
use
that
for
a
demo.
A
A
And
you
can
see
here
that
the
agent
following
industry,
best
practices,
is
configured
in
code.
Actually,
let's
see
how
to
say
that
this
diagram
shows
how
the
agent
behaves
for
a
demo.
It's
important
to
understand
that
the
agent
is
configured
in
code
using
the
agent
configuration
repository
seen
here
on
the
left
on
the
right
and
the
agent
watches
a
manifest
repository,
and
whenever
we
update
our
kubernetes
manifest
in
this
manifest
repository
as
the
agent
finds
new
manifest.
It
applies
them
in
our
cluster.
A
So
we
will
need
to
configure
the
agent
in
a
configuration
project
install
the
agent
into
our
cluster
and
connect
it
with
gitlab
and
provide
a
manifest
repository
that
it
can
watch
and
it
can
apply
in
our
cluster.
I
will
start
with
the
manifest
repository
as
for
this
demo.
That's
really
simple.
My
manifest
repository
actually
contains
just
this
config
map
that
you
can
see
right
now
here
in
the
config
map.
You
can
see
a
few
things
like
this
manifest
gml
file,
and
this
is
what
I'm
going
to
apply
in
the
cluster.
A
A
So
in
the
documentation.
I
can
see
that
to
set
up
the
configuration
repository,
I
have
to
create
a
file
dot,
gitlab
agent,
an
agent
name
and
the
config
demo,
and
that
file
should
contain
a
pointer
reference
to
the
manifest
repository
that
will
be
itself.
So,
let's
do
that
dot,
gitlab,
slash
agents,
slash
local
k3s,
slash
config.yml.
A
A
A
A
I
see
it's
on
the
staging
side,
so
I'm
going
to
add
a
agent
demo
perfect.
It
requires
api
scope,
I'm
creating
the
access
token
copying
it
and
pasting
it
the
agent
configuration
project.
I
have
it
here
at
the
top.
It's
the
same
that
I
added
to
the
config
file
and
the
agent
name,
which
is
the
local
k3s
from
this
name.
You
can
already
figure
out
that
this
will
be
a
k3s
based
installation,
I'm
going
to
install
the
agent
later
in
this
k3s
cluster.
A
So,
let's
see
what
happens
now
as
I
hit
enter
okay,
I
have
received
a
token
here
in
this
cli
and
I
received
a
small
helper
how
to
apply
it.
If
I
don't
want
to
customize
it
in
other
ways,
and
it
provides
me
a
pointer
to
our
documentation
that
I
have
already
opened
I'm
going
to
close
this
now,
so
let's
continue
with
creating
the
command
secret.
It
just
tells
me
that
I
have
to
create
the
namespace
I'm
going
to
use
very
simply
create
namespace
gitlab
agent.
A
A
A
This
is
a
previous
example,
so
this
one
just
made
so
we
are
just
running
cube
city.
I
create
secret
in
the
gitlab
agent
token
namespace
that
we
just
created
go
and
we
pass
the
token
that
was
generated
for
us,
oh
and
the
default
here
is
to
in
the
documentation
is
the
agent
names,
because
I
have
to
change
that
to
gitlab
agent,
because
I
want
to
use
that
namespace
instead
perfect
now
it's
created,
and
I
have
everything
set
up,
so
I
can
move
on
and
install
the
agent
into
the
cluster.
A
A
So
I
have
to
change
the
image
version
and
the
address
of
the
kubernetes
agent
server,
the
staging
of
gitlab.com
runs
version
13.6
of
gitlab.
I
need
to
use
the
13.6x
of
the
agent
I'm
now
going
to
use
version
13.6.1,
as
I
know
that
that's
the
most
recent
one,
so
I
will
have
to
change
this
latest
to
v1361
for
our
staging
server.
A
A
A
A
But
what's
important
is
that
if
we
move
to
the
other
from
legend
locks,
we
can
set
found
a
new
version
in
that
manifest
strap
when
it's
applied
in
the
cluster.
So
let's
see
the
default
namespace,
where
I'm
applying
the
config
map.
If
we
have
it
there.
Yes,
the
configure
is
here
and
it
has
the
same
value
that
we
have
in
code.
A
A
A
A
A
If
I
refresh
this
page,
you
can
see
that
here
I
have
the
manifest
cmu
that
was
deployed,
and
I
have
the
agent
defined
there.
Currently.
This
is
the
preferred
way
to
setting
up
the
agent
today.
This
project
has
to
be
public,
but
from
13.7
on
you
can
use
private
projects
as
well
for
managing
your
agent
and
having
your
manifest
below
that
same
project.
A
Moreover,
I'm
looking
for
customers
who
would
be
open
to
share
the
authorization
setups
around
the
kubernetes
workflows
with
us,
so
we
can
provide
great
experience
for
multiple
manifest
projects
that
are
used
by
the
same
agent
today.
The
agent
requires
you
to
use
pure
kubernetes
manifest
in
the
manifest
project.
As
I
have
shown
you
here
with
this
config
map,
we
believe
that
this
is
the
best
workflow
to
move
forward,
but
we
understand
that
many
of
you
might
use
gitlab's
outstanding
cicd
engine
to
deploy
to
your
clusters
in
a
push-based
way.
A
In
my
example,
I
have
used
a
single,
manifest
yaml
file
to
describe
what
the
agent
should
deploy.
If
I
switch
branches
here
from
13.7,
a
single
repository
might
contain
a
hierarchy
of
manifests,
organized
into
directories
and
subdirectories.
As
you
can
see
it
here,
we
still
have
the
configuration
up
there,
but
here
we
have
environments,
production
directory
that
contains
miami
my
manifest,
and
from
now
on
from
3.7
on
it
doesn't
have
to
be
a
manifest
yammer,
but
it
can
be
any
named
yaml
fighter.
A
We
have
many
other
items
as
well
on
our
roadmap,
but
I
believe
that
these
are
the
most
important
ones.
This
concludes
this
demo.
Video.
If
you
found
this
approach
interesting,
we
are
investing
heavily
in
kubernetes
and
would
like
to
see
better
integration
with
gitlab.
I
would
like
to
hear
your
feedback
and
speak
with
you
about
your
use
cases
and
needs.
Thank
you
for
your
attention.