►
From YouTube: Kubernetes Environments Visualisation and How We Do It at GitLab by Anna Vovchenko and Viktor Nagy
Description
How do you visualize your environments when some loads are deployed with push-based approaches from your CI/CD pipeline while others are managed by GitOps? How can you manage access when your teams live primarily in your Git tool, not in the Kubernetes cluster? At GitLab, we tried tackling this problem with different strategies, leveraging the Kubernetes API, user impersonation, and more RBAC strategies. Join this talk to learn more about the iterations we made on the way: From talking to hundreds of users to leveraging the GitLab platform to come up with a solution for environment visualization. This talk will walk you through environment management in GitLab and visualizing cluster resources for users. We will dive into the frontend framework in detail, and show you how to use it for your use cases.
A
Let's
get
started
so
for
some
software
developers
based
on
the
interviews.
Environments
are
a
little
bit
like
a
myth.
App
developers
are
often
used
to
be
it
a
container
type
commit
and
then
move
on
to
their
next
issue.
Now
this
is
great
in
many
ways,
as
it
allows
them
to
focus
on
writing
the
apps
for
the
business.
A
Unlike
the
issues
that
the
shorter,
the
better
there
are,
various
processes
around
the
environments
sometimes
say
that
they
deploy
to
production.
What
others
say?
Actually
they
promote
from
staging
to
production,
and
this
promotion
verb
itself
shows
that
deployments
are
not
one-off
events.
They
have
a
history
both
in
terms
of
the
pipeline
and
in
terms
of
the
target
infrastructure
itself.
A
Environments
should
incorporate
all
these
information
with
respect
to
environment.
There
are
natural
questions
that
developers
might
want
to
know
about
the
resources
that
they
are
responsible
for
infrastructure
people
today
need
to
provide
tooling
and
access
to
information,
so
devs
can
actually
own
the
applications.
A
typical
setup
is
to
have
a
shared,
the
funnel
instance,
for
example,
and
provide
access
there,
but
developers
spend
a
lot
of
time
in
gitlab
already,
so
they
are
familiar
with
the
UI.
As
a
result,
we
had
this
question
like.
Could
we
have
them
there
within
gitlab?
B
B
B
This
powerful
tool
provides
a
secure,
bi-directional
connection
between
a
gitlab
instance
and
the
kubernetes
cluster.
So
how
does
the
gitlab
agent
for
kubernetes
work?
Essentially,
it
is
composed
of
two
components:
hfk
and
cats
short
for
gitla
Agent
K
is
a
slim
and
lightweight
cluster
side
component.
It
is
responsible
for
establishing
a
connection
to
a
gas
instance
and
waiting
for
requests
to
process.
It
is
proxy
requests
from
guest
to
cube
API.
B
It
may
also
actively
set
information
about
cluster
events
to
cast
while
Agent
K
is
actively
communicating
with
the
cluster
cast,
on
the
other
hand,
represents
a
gitlab
server-side
component.
It
is
responsible
for
accepting
requests
from
Agent
K
authenticating
agent
key
requests
by
querying
gitlab
backend
fetching
the
agents
configuration
from
a
corresponding
git
repository
using
gitly
and
Poland
manifest
repositories
for
GitHub
support
by
using
the
gitlab
agent
for
kubernetes.
B
There's
a
full
proxy
flow
from
the
front
end
to
a
cluster
starts
with
the
user
browsing
to
the
desired
gitlab
project
and
accessing
the
cluster
agents
page.
Once
the
user
selects
an
agent,
a
browser
cookie
is
generated
and
forwarded
as
a
separate
header
to
cast,
along
with
the
correct,
csrf
token
and
gitlab
added
ID
upon
receiving
the
request.
Cash
checks,
the
user's
authorization
by
calling
the
authorized
proxy
user
gitlab
endpoint
with
the
provided
user
credentials
and
agent
ID.
B
If
the
credentials
are
valid
and
the
user
has
the
necessary
access,
which
is
at
least
developer
rights,
physical
project,
the
request
is
enriched
with
information
from
the
authorization
response
and
forward
it
to
Agent.
K
Agent
K
in
turn
makes
an
actual
request
to
the
cube
API
applying
the
appropriate
impersonation
configuration.
B
B
B
This
is
due
to
the
fact
that
the
kubernetes
client
library
is
intended
to
be
used
within
a
server-side
environment
and,
as
a
result,
it
relies
on
certain
features
that
are
not
available
in
the
browsers,
such
as
network
sockets
and
file
system
access.
Therefore,
to
interact
with
kubernetes
apis
from
the
front
end.
Alternative
libraries
must
be
used
that
are
specifically
designed
to
work
in
a
browser
environment.
B
These
libraries
can
be
based
on
the
official
kubernetes
client
Library
write
an
adjusted
to
function
properly
in
the
browser
to
solve
this
problem.
We
developed
our
own
library
that
can
be
used
to
interact
with
the
kubernetes
API
through
the
gitlab
UI.
It
uses
an
open,
API
generator
in
a
similar
way
to
kubernetes
client,
but
without
the
dependency
on
Note
fetch,
which
makes
it
compatible
with
the
browsers.
B
We
have
explored
several
JavaScript
and
typescript
generators
and
settled
on
using
the
typescript
access
generator,
which
produces
clean
code
that
can
be
tree
shaken
and
is
already
compatible
with
access.
A
library
we
use
in
the
front
end.
The
gitlab
cluster
client
Library
simplifies
the
process
of
retrieving
information
from
the
kubernetes
API
endpoints
and
execute
in
commands.
B
We
are
currently
working
on
integrating
it
with
watch
API,
which
will
allow
the
client
to
receive
updates
on
cluster
changes
as
they
occur,
eliminating
the
need
for
frequent
endpoint
poly.
This
will
significantly
improve
the
performance
and
efficiency
of
the
cluster
client
Library,
resulting
in
a
better
environment's
integration
experience.
B
Integrating
the
gitlab
cluster
client
library
on
the
front
end
is
straightforward:
it
contains
an
API
object
and
a
configuration
objects
that
can
be
used
to
set
the
correct,
API
URL
and
the
proper
header
to
ensure
authentication
works.
As
expected,
the
development
of
the
cluster
client
library
has
allowed
us
to
overcome
the
limitations
of
the
official
kubernetes
client
library
and
provide
a
smooth
and
efficient
integration
experience
with
gitlab
and
kubernetes
with
this
library
and
our
ongoing
efforts
to
improve
it.
B
B
Diamond
sets
stateful
sets
replicas
at
job,
scrunchups
and
other
resources.
This
allows
users
to
quickly
identify
any
issues
of
bottlenecks
and
take
appropriate
action
by
tracking
the
resource,
usage
and
health
of
the
applications.
The
environment
page
integration
can
ensure
that
the
cluster
is
operated
optimally
and
efficiently
and
take
proactive
steps
to
address
any
potential
issues
before
they
cause
downtime
or
other
problems.
B
Now
that
we've
touched
on
the
gitlab
agent
for
kubernetes
and
cluster
client
library
that
created
a
base
for
the
environment's
page
integration,
let's
take
a
look
at
a
quick
demo
to
see
it
in
action
in
system
will
check
the
add-in
cluster
connection
and
will
use
the
environments
page
to
view
the
status
of
our
running
application,
including
Bots
services
and
deployments
I've
already
created
an
urgent
for
our
demo.
The
agent
called
demo
agent
is
available
from
the
infrastructure.
B
B
B
It
specifies
the
access,
as
required
field,
which
can
have
one
of
two
values:
urgent.
That
means
connecting
using
the
agent
service
account
and
user
designed
as
a
premium
feature
that
impersonates,
the
authenticated
user
for
our
current
demo.
I'll
use
the
agent
service
account,
so
the
access
S
is
said
to
be
an
edge.
B
B
We
will
obtain
the
gitlabcast
cookie
from
here,
and
it
is
an
essential
part
for
the
client
cluster
connection
with
see
from
the
activity
stream
list
that
the
agent
was
created
and
successfully
connected
99
hours
ago.
We
should
be
good
by
now
created
NMR
to
add
a
basic
app.
It
has
a
deployment,
a
service
and
an
Ingress.
B
B
B
B
It
shows
the
same
information
that
we've
already
seen
via
Cube
style.
It
defines
the
cluster
as
healthy
as
we
don't
have
any
failed
resources.
It
shows
the
agent
that
is
used
for
the
gitlab
to
Cluster
connection.
We
are
already
familiar
with
this
one.
We
can
see
pods
deployments
and
replica
sets
here
as
well
as
the
service
you've
created
recently
with
some
basic
information
about
it.
B
B
B
B
Yeah
now
we
can
see
the
number
is
set
to
just
a
single
part,
I,
really
like
how
the
cluster
looks
healthy
and
happier,
but
for
the
experiment.
Let's
also
try
to
mask
things
up
a
little
prepared,
a
configuration
that
is
most
definitely
fail.
It
contains
a
file
deployment
and
a
failed
pod.
Let's
merge
it
and
see
what
happens.
B
So
we
can
observe
that
there
is
a
failed
pod
now
and
this
failure
has
also
updated
the
environment
health
status
to
unhealthy,
and
we
see
a
new
label
for
the
deployments
indicating
that
there's
a
failed
one.
I'll
remove
those
two
failed
resources
for
now,
as
I'd
always
like
to
see
my
clusters,
housing.
B
In
conclusion,
the
integration
between
gitlab
and
kubernetes
offers
developers
an
intuitive
and
streamlined
workflow
for
deploying
and
managing
applications
by
leveraging
the
gitlab
UI
developers
can
monitor
the
status
of
their
applications
and
quickly
respond
to
any
favors
without
having
to
switch
between
multiple
tools.
This
integration
not
only
streamlines
the
development
process,
but
also
helps
teams
deliver
code
faster
and
with
greater
confidence,
whilst
the
integration
is
currently
in
development
I'm
hanging
over
to
Victor,
who
will
be
happy
to
guide
anyone
interested
in
getting
started
with
the
environment's
integration.