►
From YouTube: Intro to GitLab's Kubernetes Management/Integration work
Description
- Docs: https://docs.gitlab.com/ee/user/clusters/agent/
- Main epic: https://gitlab.com/groups/gitlab-org/-/epics/3329
- Reverse tunnel with CI: https://gitlab.com/gitlab-org/gitlab/-/issues/280563
- How to authorize manifest repo access? https://gitlab.com/gitlab-org/gitlab/-/issues/220912
- GitLab Managed/Integrated applications: https://gitlab.com/groups/gitlab-org/-/epics/4280
A
Hi,
my
name
is
victor
neugen,
I'm
the
product
manager
of
the
configure
group.
Here
at
gitlab
we
are
developing
the
gitlab
schematics
integrations,
including
the
gitlab
competitors
agent,
and
before
our
meeting
I
I
thought
I
will
give
you
a
bit
of
an
update.
How
I
see
it
and
there'll
be
plenty
of
links
in
the
description
of
this
update,
so
you
can
read
more
or
even
ask
before
before
we
meet.
A
So
this
is
just
docs.
If
you
haven't
heard
about
the
gitlab
screen
this
agent,
a
quick
run
through
it's
an
active
component
sitting
in
your
cluster,
so
the
agent
is
in
your
cluster,
it's
configured
by
code
in
a
gitlab
repository
and
it
grabs
its
own
configuration
from
the
agent
config
repository
this
agent
config
repository
describes
the
manifest
repositories
where
cubans
manifest
files
are
stored
and
the
agent
watches
those
repositories
continuously
and
updates
the
state
of
your
cluster.
A
A
A
A
We
just
have
a
list
today
of
the
available
agents
in
a
given
project.
The
best
experience
today
is,
if
you
use
an
agent
project
and
the
manifest
project
together.
So
if,
if
the
the
manifest
project
and
the
agent
configuration
project
are
the
same,
if
these
are
separate
repositories,
then
we
have
to
figure
out
how
we
authenticate
with
the
agent
to
the
manifest
repository.
How
do
we
allow
the
manifest
supposed
to
be
read
by
the
agent
and
as
these
could
be
managed,
but
two
totally
separate
teams?
This
is
not
a
an
obvious
question.
A
This
issue
is
actually
about
this
authorization
topic.
So
if
you
have
anything
to
add
here,
if
you
have
ideas
workflows
that
you
use
internally,
there
are
some
teams
at
nasa
that
who
manage
the
cluster
like
you,
and
there
are
items
who
just
can
provide
the
manifest
files
for
them
and
have
no
access
to
the
agent
configuration
project.
This
would
be
something
that
we
are
really
interested
in.
A
Another
topic
here
is
the
how
we
in
general,
connect
with
the
manifest
projects,
because
today
you
have
group
level
clusters
and
instance,
level
clusters
and
project
level
clusters.
The
agent
by
nature
is
configuring
projects,
so
it's
kind
of
a
project
level
idea
and
we
want
to
make
it
possible
to
have
group
level
agents
as
well
and
perhaps
instance,
level
agents,
but
those
might
be
less
important
and
for
the
group
level
agent.
A
A
Okay,
what
else
do
I
want
to
speak
about
group
level?
Agents?
That's
okay,
together
with
these
developments,
we
are
actually
deprecating
and
removing
the
one
click
managed
applications,
and
even
some
of
the
ci
based
applications,
and
we
truly
want
your
feedback
around.
This
martial
will
provide
some
feedback
in
the
in
the
comments
here.
A
So
our
idea
is
that
today
you
can
install
prometu's,
set
manager,
nginx
ingress,
k
native
and
a
few
other
applications
with
a
few
clicks
using
gitlab.
We
are
going
to
remove
these
simple
click
based
installations
and
provide
either
probably
mostly
documentation
around
that.
So
this
is
something
where
we
would
be
happy
to
hear
your
feedback.
What
do
you
think
about
this?
The
other
big
question
that
we
have
with
respect
to
the
agent
we
started
this
manifest
repository
idea.
A
So
what
should
we
do
there?
Do
you
have
any
ideas
around
ham
support?
It's
not
that
important.
So
this
was
my
quick
summary.
The
basic
questions
we
have
is
authorization
rights.
How
to
how
would
you
manage
authorizations
with
manifest
repository
agent
configuration
repository,
various
tools
that
that
you
see
in
your
organization
to
be
used?
Let
it
be
kpt
or
helm
or
tanzu
or
whatever?
No,
that's
that's
different
anyway.