►
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Multi-Tenant Clusters with Hierarchical Namespaces - Adrian Ludwin, Google
The multi-tenancy working group is developing new building blocks in Kubernetes to better support multi-tenant use cases, such as hosting multiple teams in large enterprises and enabling multi-single-tenant deployments in SaaS. Namespaces are one of the most important foundations of multi-tenancy in Kubernetes. In this talk, we introduce a new building block called Hierarchical Namespaces that allow policies like RBAC and Network Policies to be consistently inherited across trees of namespaces. Based on our experience working with customers, we believe this new technique will simplify namespace management in Enterprise and SaaS use cases. This talk will show how you can use hierarchical namespaces to safely and easily share your cluster across teams and deployments within an organization. Hierarchical Namespaces are an open source project currently incubating in the Multi-tenancy working group. You can check out the code and get involved in the project here: https://github.com/kubernetes-sigs/multi-tenancy/tree/master/incubator/hnc
https://sched.co/Zeuh
A
A
So
there's
a
at
a
brief
overview.
There's
a
couple
things
we'll
be
covering
today.
The
concept
of
hierarchical
namespaces
is
quite
new,
so
I'll
spend
a
little
bit
of
time,
explaining
both
what
multi-tenancy
is
how
hierarchical
namespaces
can
be
used
to
provide
a
multi-tenant
cluster
and
also,
if
you're
interested
in
contributing
to
the
project,
because
it
is
all,
of
course,
a
part
of
the
open
source
ecosystem.
How
you
can
help
us
out,
so
here's
the
topics
we're
going
to
go
through
today.
I
will
talk
about
why
you
should
be
interested
in
multi-tenancy.
A
I
will
talk
about
the
foundation
of
multi-tenancy
in
kubernetes,
which
is
namespaces
and
how
these
are
being
extended
to
become
hierarchical.
Then
we're
going
to
talk
about
the
product
called
the
hierarchical,
namespace,
controller
or
hnc,
which
implements
these
hierarchical
namespaces,
and
I
will
give
a
slideware
demo,
which
is
much
easier
than
a
live
one.
On
this
recorded
session.
I'll
talk
a
little
bit
about
some
advanced
hnc
topics,
and
then
we
can
talk
about
how
you
can
contribute
how
you
can
get
involved,
how
you
can
get
hnc
and
try
it
out
for
yourself.
A
So
first,
let's
talk
about
why
to
use
multi-tenancy
I'd.
Imagine
if
you
are
listening
to
this
session.
You
probably
have
some
idea
of
why
you
want
this
anyway,
but
let's
go
over
it
because
sometimes
different
people
come
to
this
topic
for
different
reasons,
and
there
are
a
wide
variety
of
reasons
that
you
might
be
interested.
A
So
most
companies
care
about
two
things
called
mainly
cost
and
velocity,
and
if
this
seems
a
little
bit
reductive
well,
you
can
take
an
expansive
view
to
both
of
these
costs
and
velocity
encompass
all
kinds
of
other
concerns,
such
as.
If
you
have
a
bunch
of
teams
that
are
tripping
over
each
other's
feet,
that's
going
to
impact
both
your
cost
and
velocity,
but
it
does
of
course,
include
the
sort
of
more
basic
concerns
such
as
how
much
you
pay
your
cloud
provider
and
how
quickly
you're
able
to
develop
new
features.
A
One
of
the
problems
that
you
can
have
is
that
if
too
many
different
teams
are
running
trying
to
do
too
much
on
their
own,
they
end
up
impacting
both
of
these,
and
so
let's
look
at
how
this
works
with
kubernetes
kubernetes
works
really
well.
For
out
of
the
box
for
one
or
a
small
number
of
users,
so
you've
got
a
user,
the
user
uses
either
the
command
line,
interface,
cube
cuddle,
which
we
all
know
and
love,
or
the
api
or
some
kind
of
graphical
user
interface.
To
talk
to
the
control
plane.
A
The
control
plane
then
communicates
in
turn
to
the
nodes
via
the
cubelets,
and
everybody
is
pretty
happy.
This
also
scales
up
well
to
small
teams
and
usually
when
you
start
talking
about
terms
like
tenants,
the
kind
of
tenant
that
you
have
in
mind
is
a
team.
Now
there
are
other
definitions
of
tenancy
as
well.
Sometimes
you
can
think
of
an
application
as
being
a
tenant.
A
A
A
They're
part
of
the
open
source
ecosystem
includes
the
multi-tenancy
working
group
and
it
was
formed
to
categorize
and
understand
and
then
solve
these
kinds
of
multi-tenancy
problems
in
the
ecosystem,
and
so
there's
another
sig
called
the
multi-cluster
sig,
which
is
trying
to
solve
the
problem
of
having
lots
of
clusters.
But
we
are
trying
to
solve
the
problem
of
reducing
the
number
of
clusters
that
you
need
to
have.
There's
a
couple
of
projects,
that's
run
by
this
group.
One
of
them
is
hnc
which
I'll
be
discussing
in
this
presentation.
A
Other
ones
include
virtual
clusters
and
a
benchmark
or
a
compliance
project.
I'll
talk
a
little
bit
more
about
the
working
group
at
the
end
of
this
presentation.
But
if
you
are
looking
through
these
slides
on
your
own
there's
a
link
that
you
can
click
or
you
can
just
search
for
us-
we're
easy
to
find.
A
A
But
what
I
found
kind
of
funny
is
that
you
don't
actually
hear
people
talking
about
them
very
much.
So
let's
talk
a
little
bit
about
namespaces,
because
then
we
can
see
why
it's
important
that
we
can
make
them
hierarchical
now,
so
namespaces
seem
boring.
We
don't
actually
talk
about
them.
A
lot
they're
a
little
bit
like
the
walls
in
your
apartment.
They
are
not
in
and
of
themselves
very
complicated,
but
they
make
a
lot
of
other
things
possible.
A
The
most
obvious
thing
that
comes
to
mind
when
you
think
of
a
namespace
is
just
that
it
allows
you
to
organize
your
objects.
So,
for
example,
in
namespace
a
and
b
I
can
have
objects
that
otherwise
have
the
same
name,
which
would
conflict
but
they're
differentiated
by
the
namespace
name.
That's
great!
You
could
probably
do
that
by
hand
if
you
really
wanted
to,
but
namespaces
actually
do
a
lot
more
than
that,
especially
when
it
comes
to
the
area
of
multi-team
tenancy.
A
A
Now
I
should
note
before
I
go
on
any
further
that
the
name
spaces
constructs
only
isolate
the
control
plane,
not
the
data
plane.
So
if
you
put
two
pods
into
two
different
name
spaces,
they
can
land
on
the
same
node
and
because
containers
are
not
a
security
boundary,
something
that
escapes.
If
you
have
a
malicious
workload
that
can
escape
its
container,
it
can
attack
other
it
can
attack
other
workloads
running
on
the
same
node
or
even
the
rest
of
the
cluster.
A
There
are
a
lot
of
good
presentations,
especially
from
kubecon
san
diego
2019,
that
talk
about
this,
so
name
spaces
are
great
for
the
control
plate.
They
are
not
sufficient
to
protect
your
data
plane.
You
need
to
look
into
sandboxing
technologies
such
as
gvisor
or
catacontainers,
to
defend
the
data
plane,
but
those
are
out
of
the
scope
of
this
presentation.
A
A
Unless
you
want
to
go
to
the
entire
cluster
level,
I
should
say-
and
even
if
you
want
to
look
at
other
privileges
such
as
reading
objects
or
updating
or
deleting
objects
in
theory,
you
can
use
rbac
at
the
per
object
level,
but
this
is
quite
brittle
doesn't
scale
very
well.
So
really,
you
want
our
back
to
apply
at
the
name
space
level
in
the
vast
majority
of
situations.
A
This
applies
to
many
other
things
as
well.
Resource
quotas
and
limit
ranges
aren't
really
about
security,
they're
more
about
resource
sharing,
but
again
they
work
best
at
the
name,
space
level,
or,
I
think,
only
apply
at
the
name
space
level
network
policies.
Similarly,
they
can
be
finely
targeted
using
labels,
but
they
work
best
using
the
namespace
boundaries
by
default.
Now
one
caveat
is
that
of
network
policies.
A
Is
that
is
that
if
you
are
looking
at
traffic
coming
from
another
namespace,
the
way
to
select
that
namespace
is
to
use
labels
and
labels
are
a
problem
because
they're
not
actually
secure
anybody
who
can
edit
any
namespace
can
modify
any
label
that
is
on
that
namespace.
And
what
that
means
is
that,
if
labels
are
part
of
your
your
security
policy,
there
is
no
differentiation
between
any
user
on
your
cluster,
who
is
able
to
edit
any
namespace.
A
Now
that
talks
about
why
you
should
scope
things
to
name
spaces,
but
what
happens
if
you
want
policies
that
are
across
different
name
spaces,
usually
you're,
going
to
need
some
kind
of
tool
and
a
source
of
truth
that
is
outside
of
kubernetes.
So
you
can
use
ci,
get
ops
tools
like
flux
or
argo.
If
you
are
in
gke,
you
can
use
tools
such
as
configsync
or
athos
config
management.
All
of
these
look
at
what's
in
a
repo,
typically
in
git
and
can
propagate
things
to
the
cluster
and
typically
across
multiple
namespaces.
A
There
are
other
solutions
that
are
fully
in
clustered
that
add
some
kind
of
concept
of
accounts
or
tenancy.
One
of
them
is
called
kiosk,
which
I
haven't
actually
played
with
myself,
but
I
want
to
look
into
it.
Another
one
is
called
the
tenant
crd,
which
is
actually
also
run
by
the
multi-tenancy
working
group.
A
But
what
we
felt
when
we
were
starting
hnc
is
that
there
was
a
need
for
solution
that
was
both
fully
kubernetes
native,
so
no
dependencies
on
git
and
they
didn't
introduce
a
new
concept
because
both
kiosk
or
the
tenant
crd,
they
have
a
fairly
well
defined
idea
of
what
a
tenant
should
be.
But,
as
I
mentioned
at
the
beginning
of
this
presentation,
there's
a
great
many
different
types
of
tenants
and
so
having
something
that's
at
one
level
lower
than
that
can
be
really
useful.
A
This
brings
us
to
hierarchical
name,
spaces,
hierarchical
name,
spaces
are
name
spaces.
They
are
kubernetes
namespaces,
but
they've
added.
This
concept
of
ownership,
which
you
can
see
here
by
the
arrows
and
what
this
ownership
provides,
is
the
ability
to
delegate
certain
operations
and
the
ability
to
impose
policies
that
were
on
a
parent
namespace
into
a
child
or
a
descendant
and
hierarchical
namespaces
are
an
add-on.
They
are
provided
by
the
hierarchical
namespace
controller,
which
I'll
talk
about
in
a
moment.
A
But
let's
talk
about
how
they
work,
as
I
said,
they
express
ownership.
But
on
top
of
that,
what
they
do
is
you
can
create
some
name
spaces
without
cluster
level.
Privileges
name
spaces
are
great,
but
if
you
want
to
allow
a
team
to
create
a
name
space-
that's
limited
by,
for
example,
the
policies
of
its
parent.
There's
no
way
to
do
that.
A
A
So
first
I'm
going
to
enable
it
on
my
cluster,
because
I'm
on
gke
I'm
going
to
use
a
feature
called
hierarchy
controller,
which
is
part
of
config
sync,
so
I'm
going
to
edit
the
operator
manifest
and
I'm
just
going
to
set
hierarchy.
Controller
is
enabled
and
hierarchy
controller
includes
hnc.
If
you're
on
oss
no
worries,
it's
just
a
one-line
cube,
call
apply.
You
can
find
that
from
our
github
repo.
A
So
now
hnc
is
installed.
You
wait
a
few
moments
and
let's
create
a
couple
of
regular
name
spaces
and
I'll
come
back
to
what
normal
means
in
a
moment,
we'll
have
a
more
precise
definition
for
that.
So
we've
we've
created
these
namespaces
called
parent
and
child,
and
if
we
get
the
list
of
namespaces,
you
can
see
they've
shown
up,
but
there's
nothing
special
about
them.
A
They
are
completely
normal
top
level
name
spaces,
and
what
I'm
going
to
do
now
is
I'm
going
to
look
at
a
plugin,
a
hierarchical,
namespace,
hns
plugin,
which
is
a
cubecuttle
plugin,
which
is
part
of
the
project
and
I'm
going
to
use
the
tree
command
and
dash
a
to
see
all
name
spaces
to
see
what
is
the
hierarchical
structure
of
this
cluster
and
there
is
none.
You
get
exactly
the
same
output
as
what
we
had
before,
because
we
have
not
set
up
any
hierarchical
relationships.
A
So,
let's
talk
about
article
relationships:
let's
use
that
plugin
the
hms
plugin
to
set
a
property
on
normalchild
we're
going
to
set
its
parent
to
normal
parent,
and
if
we
go
again
and
run
that
command,
we
can
now
see
that
child
shows
up
as
a
child
of
normal
parent.
Now,
what
do
I?
As
I
said,
what
is
this
normal
business
that
I've
been
talking
about?
Well,
what
we're
going
to
see
is
that,
because
we
created
these
these
name
spaces
in
the
normal
way,
you
can
arrange
them
into
hierarchies.
A
We
call
these
in
hmc.
We
call
these
full
name
spaces,
the
opposite
of
full
name.
Space
is
a
sub
name
space,
which
is
a
lot
more
limitations
that
don't
require
cluster
level
privileges
to
create
and
I'll,
be
demonstrating
those
in
a
minute.
So
now
that
you
have
these
hierarchical
name
spaces,
what
can
you
do
with
them?
Well,
let's
create
an
arbac
role,
so
we're
going
to
create
an
our
back
rule
called
parent
sre
and
we
are
going
to
put
it
into
the
parent
namespace,
so
that's
created
now.
A
I
should
add
that
by
default
agency
does
propagate
only
our
back
objects,
so
roles
and
rules
bindings,
but
it's
easy
to
configure
to
propagate
any
other
type
of
object.
You
like,
although
I
wouldn't
recommend
propagating
pods
or
the
like.
That's
for
things
like
network
policies,
resource
quotas,
limit
ranges
and
so
on.
A
So
now,
let's
talk
about
the
opposite
of
a
full
namespace,
which
is
a
sub-name
space,
so
here
we're
going
to
use
that
plugin
again,
but
instead
of
creating
a
namespace,
we
say
hns
create
and
we're
going
to
create
a
sub
namespace
child,
and
so
this
creates
something
called
a
sub
namespace
anchor.
It
is
a
namespaced
object
in
the
parent
namespace,
and
if
we
look
at
the
tree
of
the
parent
namespace,
we
now
see
that
it
has
two
children.
A
One
is
the
normal
one,
and
one
is
the
subname
space
now,
what's
a
little
bit
hard
to
appreciate,
maybe
from
just
looking
at
the
slide
is
that
you
didn't
need
any
cluster
level
privileges
to
create
this.
You
only
needed
the
ability
to
create
a
subname
space
anchor
in
the
parent
name
space,
and
so
you
could
give
people
privileges
to
create
this
in
some
name
spaces,
but
not
in
others,
but
once
that
namespace
has
been
created,
it
is
a
full
kubernetes
namespace,
but
you
can't
manipulate
it
directly.
You
can't
delete
it
directly
to
do
that.
A
A
A
If
you
look
at
the
namespace
itself,
you
will
see
that
there
are
a
couple
of
labels
that
have
a
bit
of
an
odd
structure.
They
start
with
the
name
of
another
namespace,
and
then
they
have
this
kind
of
tree
suffix,
and
what
this
does
is
this
encodes
the
hierarchy?
So
what
we're
seeing
here
is
that
subchild,
the
namespace
we're
looking
at
has
a
depth
of
zero
to
itself
and
a
distance
of
one
to
its
parent.
A
What
this
allows
you
to
do
is
it
allows
you
to
select
entire
sub-trees
of
name
spaces.
So,
for
example,
in
your
network
policy,
if
you
wanted
to
allow
traffic
in
or
out
of
any
name
space
owned
by
the
same
team,
where
team
is,
has
a
parent
namespace,
you
can
create
that
selector
now
I
said
before,
labels
are
not
safe
for
security
policies,
because
anybody
who
has
access
to
edit
the
namespace
can
modify
them.
What
hnc
does
is
it
prevents
you
from
doing
that?
A
If
you
try
to
modify
one
of
these
labels,
it
will
be
rejected
and
if
you
somehow
bypass
the
web
hook,
the
reconciler
will
get
rid
of
it.
So
you
can
trust
these
labels
because
hmc
enforces
them
any
other
labels
are
fine.
You
can
you
can
modify
any
label
that
doesn't
begin
with
hnc
dot,
executes
dot,
io
or
sorry
have
that
in
the
suffix,
but
these
labels
are
protected.
A
In
fact,
agency
was
inspired
by
it
in
part,
but
that
hierarchy
works
in
a
very
different
way,
instead
of
being
present
on
the
the
cluster,
what
configsync
and
which
is
the
same
as
xanthus
config
management.
What
config
sync
does
is
it
allows
you
to
define
a
tree
of
directories
in
git
and
you
can
create
a
bunch
of
yaml
files
in
them
and
these
leaf
directories
in
this
case
team,
a
team
b
and
team
c.
A
A
A
How
is
this
possible,
given
that
I
said
that
these
labels
are
trusted
well
agency
defines
an
extension
point
called
managed
by
that
you
can
use
to
extend
the
hierarchy
in
ways
that
agency
doesn't
natively
understand.
So
in
this
case
we
have
told
hnc
that
there
is
this
other
system
called
config
management,
dot
gke,
that
is
managing
this
root
name
space
and
we
have
told
it
what
its
additional
hierarchical
hierarchical
information
is.
A
In
this
case,
you
can
see
acmeorg
and
tb,
which
is
the
namespace
itself,
and
there
are
a
bunch
of
things
in
place
that
stop
you
from
adding
this
managed
by
annotation
unless
in
ways
that
can
can
damage
security,
and
so
what
that
means
is
that
those?
What
that
means
is
that
these
labels
are
usable
by
by
any
other
system,
such
as
network
policies,
that
the
regular
agency
labels
are
can
use
as
well.
A
You
can
also
create
a
sub
namespace
underneath
them,
so
here
we're
using
hnc
to
create
a
service,
that's
owned
by
tv
called
service
one
and
now,
let's
look
at
another
extension
point:
let's
run
a
small
application
inside
of
that
inside
of
that
new
service
name
space,
so
we're
gonna
run
that
and
it
creates
a
service
in
a
pod,
and
if
we
look
at
the
pod,
what
we'll
see
is
another
extension
that
we've
built
again.
This
one
only
works
in
gke
for
reasons
that
we'll
see
in
a
second
we
can
see.
A
All
of
those
labels
have
been
copied
down
to
the
pod.
The
reason
we've
done
this
is
that
logging
in
gcp
is
based
on
labels
that
are
put
on
top
of
pods,
and
so
this
a
lot.
What
this
does
is.
This
allows
us
to
go
into
our
logging
system
and,
in
our
case
it's
stackdriver
logging
and
filter
and
route
and
analyze
these
logs,
based
on
the
hierarchical
structure
and
other
logging
systems,
will
have
similar
abilities,
but
they
might
integrate
in
slightly
different
ways
again.
A
So
let's
have
a
look
at
one
of
these
labels,
so
this
is
we're
going
to
look
at,
for
example,
every
log
that
came
out
of
the
engineering
organization
on
this
cluster
so
on
in
gcloud
in
gcp.
The
way
to
do
this
is
you
create
a
filter
which
is
pretty
straightforward,
we're
going
to
say
that
the
kubernetes
labels
must
include
this
label
entry
agency.
A
You
can
see
the
name
got
mangled
a
bit,
but
with
the
depth
having
any
value,
and
if
we
run
that
we
can
see
that
we
are
reading
the
logs
that
came
from
that
deployment
of
nginx
that
we
put
into
that
pod.
So
again,
the
details
here,
don't
matter
very
much,
because
it's
going
to
be
different
in
every
system.
It's
going
to
be
different
on
other
cloud
providers
on
bare
metal
on
prem.
Whatever
your
logging
solution
is.
A
This
is
obviously
dangerous
operation
and
shouldn't
be
allowed.
Unless
you
have
access
to
those
secrets
already,
we
can
do
cascading
deletion
of
subname
spaces,
and
so,
if
you
delete
a
parent
name
space,
all
the
anchors
in
that
name's
piece
got
deleted,
which
deletes
the
subname
species
and
so
on.
Obviously
this
is
dangerous,
and
so
there
are
a
variety
of
methods
that
we
have
in
place
to
make
sure
you
don't
do
this
on
purpose.
A
That's
right
by
accident.
You
can
monitor
agency
itself
via
open
census,
plus
the
objects
that
it
creates
in
each
namespace
and
at
the
cluster
level,
have
a
status
section
that
you
can.
You
can
use
to
ensure
that
everything's
working
the
way
you
expect,
and
finally,
we've
put
a
bunch
of
thought
into
how
you
uninstall
this.
You
wouldn't
want
all
of
your
sub
namespaces
and
all
of
the
objects
in
them
to
disappear.
A
If
you
delete
hnc,
and
so
we've
put
effort
into
making
sure
that
you'll
get
a
pleasant
experience,
if
you
try
it
out
and
it
doesn't
work
for
you
how,
in
terms
of
how
you
should
actually
use
this
for
simple
organizations
or
in
dev
clusters,
it's
pretty
easy
to
understand
how
you
can
use
this.
You
can
give
teams
control
over
their
own
namespace
hierarchy
without
letting
them
which
includes
letting
them
create
their
own
namespaces,
without
giving
them
the
ability
to
modify
or
impact
anybody
else.
A
A
A
You
can
search
for
a
hierarchy
and
client
space
controller
or
if
you
are
looking
at
these
slides,
you
can
click
on
that
link
to
go
to
github,
follow
through
to
the
releases,
and
you
will
find
the
latest
version
of
hmc
and
it's
a
one-line
install
to
get
it
onto
your
two-line
install
to
get
it
onto
your
cluster.
Another
couple
of
lines
to
download
that
plug-in.
A
We
are
interested
in
contributors,
there's
a
bit
of
a
laundry
list
of
features
that
we
are
considering
adding
to
agencies,
such
as
exceptions,
we're
looking
at
a
way
to
implement
namespace
crds,
which
sounds
like
a
contradiction
terms,
but
contact
me
later.
If
you
want
to
talk
about
that
and
improve
production
productionization
such
as
prometheus
support
and,
of
course
we
are
always
happy
for
people
to
test
and
help
document
the
product.
A
Finally,
if
you're
interested
in
multi-tenancy
as
a
concept,
please
come
and
join
the
multi-tenancy
working
group,
we
have
a
variety
of
products,
projects
that
we
are
leading,
not
just
our
people
name
spaces.
This
includes
virtual
clusters,
the
tenant,
rd
and
benchmarking,
and
this
effort
is
led
by
tasha,
druid,
vmware
and
sanji
franco
at
cisco.
It's
a
really
friendly
community.
We
meet
every
two
weeks
on
tuesdays
and
please
come
to
the
our
repo,
where
you
can
find
all
the
information
to
join
the
mailing
list
and
to
join
our
bi-weekly.
A
A
Hi
there
it
is
now
wednesday
august
the
19th
I've
been
standing
here
for
three
weeks
in
the
same
shirt
and
I'm
ready
to
answer
some
questions
now.
So
the
first
question
comes
from
a
guy
with
a
really
good
name:
adriano
pizzuto
asks
it
looks
like
there's
a
competing
project
in
the
same
sig
called
the
tenant
crd.
A
I
just
mentioned
that
actually
on
one
of
the
the
last
slides,
it
is
not
a
competing
project.
It
is
a
more
opinionated
solution.
It's
at
a
higher
level
of
the
stack.
What
I
would
think
what
I
would
hope
at
some
point
in
the
future
is
that
it
might
actually
be
rebased
onto
hierarchical
namespaces,
but
it's
a
very
it's
got
a
very
different
purpose.
Basically,
if
you
look
at
that
user
model-
and
it
works
perfectly
for
you
that's
great-
I
don't
think
it's
got
as
much
activity
on
it.
A
My
email
is
there,
you
can
see
my
on
slack
and
there
are
lots
of
places
to
reach
me
and
by
the
way,
I'm
sorry
for
anyone
who
was
looking
for
the
slides
who
can't
see
them
on
shed.
If
you
look
for
my
name
adrian
ludwin
on
speaker
deck,
I
have
uploaded
them
there
as
well.
I'm
hoping
they'll
pop
up
on
shed,
but
they
haven't
been
turning
up
yet
daniel
asks.
Can
you
scope
cluster
scoped
things
to
hns
like
crds,
for
example?
As
I
said,
no
is
the
short
answer.
A
A
I
think
I
may
have
watched
that
one
if
that
was
the
one
about
running
lots
of
different
api
servers
on
one
cluster.
That
is
a
great
solution.
If
you
need
that
kind
of
hard
multi-tenancy
virtual
clusters,
which
are
being
run
through
the
multi-tenancy
working
group,
are
another
solution.
If
you
need
shared
nodes
as
well
as
surety,
as
well
as
as
multiple
api
servers,
I
apologize
if
I'm
responding
with
the
wrong
one,
but
but
basically
hnc
is
not
really
for
the
harder
use
cases.
A
It
really
is
for
the
more
kind
of
cooperative
use
cases
which
is
not
to
say
you
cannot.
You
cannot
put
in
policies
that
add
for
your
safety.
That's
the
whole
point,
but
it's
not
really
for
like
mutually
hostile
tenants,
at
least
not
at
this
point.
It
would
take
probably
several
years
of
hardening
before
we
could
get.
There
is
hierarchical
resource
quota
management,
part
of
the
agency
roadmap.
It
is
something
that
is
asked
for
quite
frequently.
However,
we
have
some
other,
let's
say
more
pressing
concerns.
A
This
is,
as
I
mentioned
in
that
second,
to
last
slide.
Let's
see
if
I
can
there,
we
go
hierarchical
resource
quota
second
from
the
bottom
there.
Yes,
that
is,
that
is
a
feature
that
we
would
be
happy
to
accept
some
contributions
from.
It's
certainly
something
that's
come
up
in
discussion
and
yeah.
If
you
are
interested
in
contributing,
we
are
happy
to
hear
it
as
far
as
the
roadmap
goes
it
is
on.
A
A
I
wish
it
did
the
we
had
to
set
a
lot
of
that
stuff
up
ourselves,
because
owner
refs
only
work
within
a
namespace,
because,
as
I
mentioned,
namespace
is
the
default
boundary
for
a
lot
of
stuff
in
kubernetes,
and
so
since
we
could
not
have
references
across
namespaces.
There
was
no
good
way
to
use
ownerref
to
make
this
work.
If
you
go
to
our
repo
and
check
out
the
design,
the
original
design
dock,
I
think
we
cover
like
we
looked
into
that
and-
and
we
explained
why
that
wasn't
possible.
Unfortunately,.
A
K-Nay
kate's
native
resources.
Sorry,
this
is
max
asking
kate's
native
resources
are
dealing
with
h
c,
how
about
opa
or
linker
g.
I
must
confess
I
have
not
looked
at
linker
d
at
all,
and
that
includes
in
relation
to
to
hnc
now
opa.
I
know
relatively
well,
especially
in
its
form
as
gatekeeper
and
that
those
labels
that
I
showed
the
tree
labels.
A
That
is
an
extension
point
that
we
could
write
some
policies
in
rego
based
off
of,
and
actually
that's
on,
my
list
of
things
that
I
want
to
try
out
in
the
next
month
or
two.
I
talk
with
a
bunch
of
the
gatekeeper
folks,
pretty
frequently
and
so
yeah.
I
do
want
to
try
that
out,
but
that
is
how
you
would
integrate
a
gatekeeper
and
opa
with
hmc
is
that
you
would
go
based
off
of
the
labels
on
the
name
spaces
if
we
need
more
than
that.
A
So,
for
example,
if
we
wanted,
let's
say
a
constraint
template
in
gatekeeper,
which
is
to
say
a
policy
that
applied
only
to
assumption
of
namespaces,
we
need
to
do
a
bit
more
work
there,
because
right
now
everything
in
gatekeeper
is
cluster
level.
So,
first
we
would
have
to
get
a
namespace
level
of
constraints
into
gatekeeper,
not
an
impossible
task,
but
not
a
completely
trivial
one
either
and
then
you
they
would
naturally
propagate
along
with
everything
you
could.
You
could
set
agency
up
to
propagate
them
very
easily.
A
No,
you
can't
the
idea
of
having
what's
called
a
cold
labels
or
or
acl
so
access
control
list
on
labels
is
a
tricky
problem
to
solve
in
general,
but
it
would
be
yeah
if
you
have
a
use
case.
For
that,
please
give
me
a
shout.
We
could
do
something
at
the
code
level,
but
it
would
be
a
one-off
solution.
A
Is
there
any
reference
for
setting
up
with
git
ops
tools
like
flex
or
argo,
so
at
the
moment
no
there
isn't.
I
haven't
tried
it
with
anything.
I
haven't
even
tried
it
with
config
syncing,
to
be
honest,
but
kubernete,
but
h
c
objects
are
simply
like
any
other
kubernetes
objects,
and
so
you
can
simply
check
them
into
your
into
your
repo.
At
some
point
it
would
be
actually
that
would
be
a
great
place
to
make
a
contribution.
A
If
you
wanted
to
try
that
out,
write
a
medium
post
or
a
blog
post
or
a
or
contribute
to
our
own
documentation,
that
would
be
great.
We
would
welcome
that.
How
do
you
manage
cluster
capacity
in
namespace
quotas?
I
think
I
covered
this
already
hierarchical.
Namespace
quotas
are
something
that
we
would
be
interested
in
adding
if
we
had
any
contributors.
A
Let's
see
I've
we're
running
a
little
bit
low
on
qa
I'll
get
is
I'll
get
through
as
many
as
I
can.
But
again
please
do
contact
us
on
slack
or
on
the
multi-tenancy
mailing
list.
Oh
and
I'm
sorry,
we
are
at
time
so
I
apologize
to
james
bertha
and
lassie
and
max
who
I
was
not
able
to
get
to
your
questions,
but
please
do
contact
us
on
soccer
on
the
mailing
list
and
I'll
answer
you
there.
So
thank
you
very
much
for
joining
us
and
I'll
see
you
later.