►
Description
Secrets management is a difficult challenge: How do you create, rotate and manage access? And how would you even do that at scale? With External Secrets Operator you can leverage existing solutions like HashiCorp Vault or AWS Secrets Manager that manage secrets for you and integrate them with Kubernetes.
Website: https://www.kubermatic.com/
Organized by @Microsoft @kubermatic7173 @SysEleven
Thanks to our sponsors @CapgeminiGlobal, @gardenio, @sysdig, @SUSE, @anynines, @redhat, nginx, serve-u
A
A
Okay,
so
the
agenda
for
today
is
I'll.
First
start
with
overview
of
qubit,
then
we'll
jump
into
the
main
Divine
principle
of
it,
which
is
the
separation
of
orchestration
capabilities
from
the
computation
functionalities
and
we'll
also
try
to
figure
out
so
what
why
and
how
of
it,
then
we'll
move
to
architecture
of
cube.
Edge
I'll,
try
to
explain
how
the
architecture
of
cube
Edge
Works,
how
the
how
the
cloud
and
Edge
components
are
communicating
between
each
other
and
how
the
Synergy
of
cloud
and
Edge
components
is
is
made
successful
in
the
queue
patch
okay.
A
So,
let's
start
with
what
so
Q
batch
is
a
cncs
incubating
project.
It
is
built
on
kubernetes,
which
means
developers
can
run
their
already
centralized
applications
anywhere
in
the
distributed
system.
So
when
it
comes
to
developers,
they
don't
need
to
make
any
changes
in
their
applications.
Then
they
are
multiples
in
order
to
run
those
applications
from
the
site.
A
What
I
mean
by
separation
is
the
control
plane,
components
which
resides
in
master,
which
includes
kubernetes,
API
server,
Etc
will
run
on
the
cloud
and
the
devices
and
applications.
For
example,
iot
devices
will
run
on
edge,
The
Edge
setup
can
be
as
small
as
an
arm
for
an
arm
system,
LS
verify
so
that
we
don't
need
much
of
resource
capabilities
on
the
S
side
and
the
network
in
the
site
could
be
private.
A
A
Okay,
let's
sum
into
why
why
the
separation
of
computation
orchestration
has
been
made,
we
can
discuss
about
the
three
main
points
which
is
if
making
the
edge
system
plug-in.
Pluggable
will
allow
us
to
provide
solutions
to
different
business
scenarios,
because
the
edge
Computing
caters
a
lot
of
different
use
cases
ranging
from
satellites
to
the
traffic
lights
to
the
sensors
iot
devices,
so
it
needs
to
be
flexible
enough
to
provide
and
fulfill
every
business
needs.
A
Third
thing
is
the
quick
decisions
which
needs
to
be
made,
for
example,
in
case
of
a
traffic
light.
The
switch
between
traffic
lights
is
a
quick
decision.
It
can
happen
on
their
side
with
the
small
computation
requirements,
but
the
heavy
computations
can
can
be
transferred
onto
the
cloud,
so
it
it
helps
in
building
and
utilizing
both
the
capabilities
of
the
cloud
and
keeping
it
simple
on
the
edge
keeping
a
simple,
autonomous
and
quick
converter.
A
A
So
the
first
one
and
the
most
important
one
is
the
lightweight
Edge
Edge
needs
to
be
lightweight,
because
the
edge
devices
could
range
from
a
small
box
to
sensors
to
raspberry
piers
Etc,
so
the
edge
has
limited
resources
and
but,
on
the
contrary,
kubernetes
need
significant
resources,
because,
given
it
is
at
least
needs
one.
Jp
tolerance,
the
out
of
the
box
cuminatives,
was
built
to
run
on
a
data
center
where
the
worker
nodes
will
be
close
to
each
other,
so
that
the
networking
is
efficient
and
it
runs
properly
to
solve
this
problem.
A
A
The
device
updates
is
that
an
device
updates
are
stored
in
this
meta
manager,
using
the
meta
manager,
which
is
a
massive
processor
on
the
database,
which
is
secure
life,
so
keeping
the
metadata
on
the
edge
allows
as
node
faster
recovery,
also
in
case
of
recovery
traditionally
list
and
wash
operations
needs
to
be
performed
which
are
which
require
huge
memory
sources,
but
because
of
this
local
meta
store
on
the
edge
side.
No
list
watch
is
needed
for
their
node
recovery
and
in
case
of
Edge
and
Cloud
disconnection.
A
Third
thing
is,
which
is
most
most
interesting,
is
in
Cube,
Edge
cloud
and
eyes
are
not
seen
as
separated
systems.
It
has
seen,
as
it
has
been
made,
such
that
the
Synergy
between
both
cloud
and
Edge
can
be
done,
the
best
of
the
Both
Worlds,
keeping
utilizing
the
orchestration
capabilities
of
kubernetes
and
scalability
of
clouds,
but
also
keeping
it
minimal
and
quick
on
the
aspect.
A
A
Now,
when
now,
we
have
discussed
that
how
integrating
kubernetes
orchestration
with
Edge
is
design
and
it
tries
to
remove
all
the
limitations
we
have
when
running
kubernetes
on
edge.
Now,
let's
jump
to
how
the
architecture
of
it
works
and
how
actually
the
communication
between
cloud
and
Edge
is
working.
A
A
A
A
We
can
see
a
meta
manager,
which
is
a
message
processor,
as
I
told
earlier,
that
I
did
not
a
data
store.
Local
data
store
keeps
metadata
to
be
able
to
run
Edge
nodes,
autonomously,
some
meta
manager,
stores
and
retrieves
that
data
when
required,
and
it's
a
link
between
the
edge
and
the
data
store.
So
what
is
Edge
s?
Is
it
a
lightweight
cubelet,
which
is
a
node
agent?
It
has
been
kept
lightweight
and
real.
A
A
You
can
see
that
on
edge,
the
port
application
can
be
deployed
just
like
we
did
on
kubernetes
worker
nodes.
Also,
a
multiple
container
runtimes
are
supported,
for
example,
docker
containerdy,
because
definitely
we
need
some
container
and
time
to
run
applications
right
now.
There
are
a
few
components
which
are
specific
to
devices
will
not
dwell
more
into
how
device
management
happens,
but
to
give
a
brief
overview.
A
All
right,
so,
to
summarize
this
up
the
control,
plane
and
controllers
run
on
the
cloud
side,
the
cubelet,
which
is
called
Edge
when
it
comes
to
cube
Edge
and
the
application
deployment
is
run
on
the
site
and
s.
Data
store
is
maintained
in
the
local
data
stores
and
devices
are
managed
and
communicated
using
mqtt
broker.
A
Let's
discuss
about
a
few
components:
these
are
the
components
I'll
I'll
just
give
give
a
brief
overview
of,
and
then
moving
on,
I'll
discuss,
more
components
which
are
important
for
the
communication
and
the
management
between
cloud
and
Edge.
First
is
meta
management,
as
I
told
Breezy
that
the
matter
manager
is
a
message
processor
between
us,
which
is
lightweight
cubelet
and
the
edge
hub.
A
It
is
also
responsible
for
storing
and
retrieving
metadata
from
the
lightweight
database
kept
in
site.
It
is
still
light.
Edge
controller
is
kept
on.
The
cloud
side
is
an
extension
of
the
kubernetes
controller,
which
manages
Edge
nodes
and
for
metadata
for
that
the
data
can
be
targeted
to
the
specific
Edge
nodes.
It
is
required
to
make
a
bridge
between
the
kubernetes
API
server
and
the
edge
nodes.
A
This
is
specific
to
devices
it's
an
mqd
decline,
which
is
which
interacts
with
the
server
which
is
mosquito
and
offering
a
published
substance
capability
device
train
is
also
used
for
storing
device
status
and
singing
device
status.
One
thing
too
important,
one
thing
important
note
do
not
hear
is,
and
this
set
of
cube
Edge
devices
are
created
and
stored
and
managed
similar
to
any
crd
and
kubernetes.
So
it's
easier
and
kubernetes
Native.
A
A
We
can
use
either
websockets
or
create
protocols,
but
now
I'll
I
only
talk
about
that
subject,
but
as
a
user
you
can
choose
to
use
websocket
or
break
so
the
main
thing
is
route
to
Club.
So
what
happens
is
beehive
is
a
messaging
framework
which
is
based
on
both
channels
for
communication,
between
different
modules
of
cube
Edge
in
the
route
from
Edge
to
Cloud.
A
The
Edge
have
received
messages
from
The
Beehive
context
from
different
modules
and
then
send
these
messages
to
the
cloud
you
can
see.
The
communication
made
between
the
edge
components,
which
is
meta
manager
and
Edge
hubs
event.
First
and
Azure,
is
maintained
through
beehive
framework,
but
because
they
are
situated
on
the
fitness
side
and
it
is
done
so
we
have
framework,
but
the
communication
between
ajab
and
Klaus
is
made
through
prep
software,
so
any
device
update
or
application
updates
made
on
the
site
is
string
to
the
cloud
site
using
this
setup.
A
So,
similarly
Edge,
sorry,
the
sending
of
messages
happens
but
from
route
to
Cloud
to
Edge.
The
update
are
received
from
Cloud
to
Edge
using
websocket.
For
example,
user
deploys
an
application
using
Cube
CTL
command
on
the
master
on
the
k8s
API
server
that
create
event
will
be
sent
to
that
edge
site
and
as
nodes
using
Edge
hub
and
ultimately
to
the
edge
and
stored
and
metadata
and
cache
is
stored.
A
A
The
name
metadata
is
fetched
from
no
matter
using
the
meta
manager
to
from
the
Google
data
Edge
controller.
Edge
controller
is
the
bridge
between
API
Servo
and
HBO.
Kubernetes
API
server
resides
Some
Cloud,
but
the
syncing
of
updates
is
required
to
deploy
and
manage
the
applications
for
that
two
controllers
are
created.
In
the
example,
first
is
Downstream
controller,
which
is
responsible
for
syncing.
Add
update,
delete
event
to
Edge,
which
means
if,
if
using
Cube,
CTL
a
user
is
adding
or
creating
an
application
or
updating
an
application
or
deleting
an
application.
A
A
A
A
A
A
Now,
when
you
see
that
that
edge
code
on
the
site
and
the
cloud
code
on
the
cloud
side,
including
a
lot
of
the
modules
which
I
mentioned
before,
are
running,
you
can
continue
to
join
the
edge
known.
The
request
will
be
made
from
the
site
and
will
be
communicated
to
the
cloud
group
using
the
IP
and
Port
mentioned
by
you.
Then
you
can
see
when
you
see
that
the
edge
node
is
ready,
then
you
can
go
forward
and
deploy
your
application
because
of
the
constraint
of
time.
A
Third
thing
is:
if
you
want
to
remove
or
delete
any
Cloud
processor
or
Edge
processor,
you
can
run
it
on
Master
node.
It
will
remove
the
cloud
purchases
from
the
cloud
side
and
it
will,
if
you
run
it
on
the
worker
node,
it's
shut
down
the
S
process
on
the
edge
okay.
Thank
you,
everybody
I
hope
I
was
clear
and
as
it
was
able
to
make
a
brief
overview
and
was
try
to
explain
how
the
separation
of
orchestration
and
computation
works.