►
From YouTube: Sharing is Caring: Your Kubernetes Cluster, Namespaces, and You - Amy Chen & Eryn Muetzel, VMware
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Sharing is Caring: Your Kubernetes Cluster, Namespaces, and You - Amy Chen & Eryn Muetzel, VMware
Kubernetes namespaces partition workloads into virtual clusters, so multiple teams or applications can safely share a physical cluster. Today, there is no consensus on how to use namespaces in relation to identity, resource limits, and security. This leads to vulnerable applications and inefficient usage of cluster resources. As the number of teams, clusters, and namespaces grows, it becomes difficult to maintain coherence. By aligning identity, resource limits, and your application’s security posture, cluster operators can get more organizational mileage out of Kubernetes namespaces. In this talk, we will… · Walk through common scenarios of how organizations use namespaces today · Show how to enforce RBAC, resource limits, and your application’s security posture (e.g. networking, service accounts) within namespaces · Outline friction in existing namespace management workflows
https://sched.co/MPXl
A
B
B
So
you
know,
as
the
number
of
teams
and
clusters
and
namespaces
grows,
this
can
become
a
really
big
problem
and
it's
really
difficult
to
maintain
any
kind
of
coherence
across
your
organization.
So
today
we're
gonna
start
with
some
examples
from
some
organizations
and
how
they
use
namespaces
we're
going
to
talk
about
some
policies
that
you
can
think
through
and
where
you
should
apply
those
whether
it's
at
the
cluster
level
or
the
namespace
level
and
then
finally,
we're
gonna
talk
through
some
concepts
that
you
can
consider
as
your
organization
scales.
A
So
what
exactly
is
a
namespace?
According
to
the
official
criminais
documentation
currently
supports
multiple
virtual
clusters,
backed
by
the
same
physical
cluster.
These
virtual
clusters
are
called
two
namespaces,
so
let's
go
ahead
and
break
down
this
definition.
Physical
cluster.
That's
definitely
a
very
tangible
idea
right.
So
clusters
come
with
a
lot
of
baggage.
You
can
upgrade
and
downgrade
at
the
cubelet
control,
plane
and
worker
nodes
that
backup
the
cluster
and
there's
fancy
ways
you
can
deploy
cluster.
You
can
provision
notes
for
that
cluster
there's
a
whole
thing.
A
A
cluster
has
a
whole
lifecycle
that
you
can
manage,
in
fact,
there's
a
say
group
that
I
currently
work
on
internally
that
targets
that
that
upstream
team.
So
just
trust
me
when
I
say
that
cluster
lifecycle
management
is
for
hard.
So
a
virtual
cluster
namespaces,
don't
exactly
need
to
concern
themselves
with
these
details
and
namespaces
are
a
great
way
to
logically
split
up
your
cluster.
Now,
why
exactly?
Would
you
want
to
split
up
your
cluster?
More
practically
you
organize
your
workloads
and
group
them
together.
A
A
So
when
I
originally
tweeted
that
Aaron
and
I
were
going
to
present,
this
talk,
Nick
Young,
who,
at
the
time
worked
at
Atlassian,
responded
with
this
tweet.
So
he
actually
now
works
at
VMware
and
I
thought
it
was
pretty
funny
and
it's
been
spectacular.
So
he
said
remind
me
to
tell
you
a
funny
story.
Sometime
about
the
time
we
accidentally
created,
80,000
namespaces.
So
what
actually
happened
was
they
had
a
production
cluster
that
was
constantly
deleting
creating
and
creating
namespaces,
and
they
made
a
change
that
caused
cascading
deletions
to
fail.
A
So
the
reason
those
deletions
failed
was
because
they
added
an
encore
resource
through
the
aggregated
API
server,
and
this
is
a
known
Korean.
Ladies
issue,
like
based
off
of
some
kubernetes
versions,
that
causes
garbage
collection
to
fail
and
they
ended
up
needing
to
clean
up
an
STD
database
that
hid
its
2.1
gigabyte
limit.
So
I
thought
it
was
just
like
a
pretty
funny
example.
We
can
take
away
from
so
Aaron.
Can
you
go
ahead
and
break
down
how
some
organizations
use
namespaces.
B
Sure
so
yeah
there's
really
two
common
ways
that
organizations
tend
to
map
their
people
structure
to
their
infrastructure.
So
the
first
one
is
one
team
per
cluster,
so
in
this
case
the
cluster
is
likely
to
be
potentially
provision
and
managed
by
the
development
team.
That's
using
it.
You
know
there
may
or
may
not
be
a
central
operations
team,
and
this
can
start
to
look
like
shadow
IT
and
it's
very
common
for
a
development
environments.
So
what
are
some
of
the
pros
and
cons
of
this
model?
B
One
Pro
is
really
the
simplicity
in
terms
of
the
self
service
of
an
for
structure,
so
the
teams
that
are
using
the
clusters
are
creating
the
clusters
in
the
environment.
That's
best
for
that,
given
application
the
other
Pro
about
this,
is
you
really
don't
have
to
worry
as
much
about
security
risks?
So
when
you
have
one
team
and
one
application
for
cluster,
you
don't
have
to
necessarily
worry
about
different
teams,
stepping
on
each
other's
toes
within
a
given
cluster.
B
In
terms
of
the
downsides
of
this
approach,
one
team
per
cluster
is
really
that
it
can
be
very
inefficient.
So
it's
really
difficult
to
get
the
best
utilization
out
of
your
clusters
when
you
have
a
small
team,
basically
spinning
up
resources,
it's
also
becomes
really
difficult
to
maintain
coherence,
especially
as
the
number
of
clusters
grows.
So
you
can
think
about.
You
know
like
managing
policy
across
clusters.
It
becomes
very
difficult
when
you
have
all
these
teams
creating
their
own
clusters.
B
So
we'll
talk
a
little
bit
about
more
about
that
later
and
then,
as
organizations
grow,
you'll
be
more
likely
to
see
something.
That
looks
like
this
scenario,
so
this
is,
you
know
where
you
basically
have
multiple
teams
sharing
clusters
and
thus
creating
namespaces.
This
doesn't
necessarily
mean
you
have
these
like
massive
clusters
and
you
have
everybody
sharing
a
Devon
prod
cluster,
just
like
that's
literally
on
the
slide,
but
it
you
know
you
could
still
have
many
many
clusters
across
your
organization.
So
why
would
you
want
to
share
your
cluster
across
teams?
B
The
first
is
really
a
separation
of
concerns,
so
you
can
have
a
central
operator
team.
That's
really
focused
on
managing
the
lifecycle
of
clusters,
the
policies
against
the
clusters,
and
then
the
development
team
can
really
live
in
the
land
of
the
namespace,
and
so
it
provides
some.
You
know
a
lot
more
freedom
or
they
don't
necessarily
need
to
worry
as
much
about
the
underlying
infrastructure.
B
Another
benefit
of
this
just
like
was
a
con
of
the
previous
approach.
The
pro
here
is
the
cost
effectiveness.
So,
as
you
have
teams
sharing
clusters,
it's
much
easier
to
get
much
higher
utilization
out
of
those
clusters
and
in
the
save
costs
and
then,
finally,
in
terms
of
speed.
So
if
your
development
team
you're
getting
started
on
new
application,
you
want
to
get
access
to
resources
as
quickly
as
possible
so
far.
The
way
that
the
moment
teams
have
done
that
is
basically
just
by
go
often
go
on
gke
and
create
their
own
cluster
right.
B
It
then
becomes
very
difficult
for
development
teams
to
have
the
right
level
of
self
service
and
speed
to
move
quickly.
So
for
the
rest
of
this
presentation,
we're
gonna
be
talking
mostly
about
this
use
case
too,
and
we're
gonna
walk
through
how
you
can
think
about
utilizing,
namespaces
and
applying
policies
to
these
clusters.
Thanks.
A
Sorry,
thanks
Aaron,
so
sharing
clusters
can
definitely
get
pretty
complicated
pretty
quickly
and,
let's
revisit
why
we
wanted
to
share
clusters
by
creating
namespaces
on
the
shared
physical
cluster
in
the
first
place.
Remember
again
that
namespaces
allow
us
to
abstract
away
the
workloads
from
the
physical
cluster
so
that
the
developer
doesn't
need
to
worry
about
the
cluster
lifecycle
and
in
order
to
split
up
the
cluster
to
draw
boundaries,
there's
some
characteristics
from
a
physical
cluster
that
we
need
to
duplicate.
A
In
order
to
do
this,
so,
for
instance,
we
need
to
be
able
to
control
who
is
able
to
use
each
virtual
cluster.
So
this
includes
like
what
permissions
people
have
in
each
virtual
cluster,
and
we
also
need
to
be
able
to
freely
change
the
membership
of
these
permissions
for
each
virtual
cluster.
So
this
is
under
the
topic
of
our
back.
Another
characteristic
is
that
we
need
to
be
able
to
limit
the
amount
of
physical
resources
the
physical
cluster
is
able
to
use.
A
So
before
we
go
into
more
detail
about
policies
and
things
like
that,
we
figured
why
not
give
some
examples
of
how
some
of
our
actual
customers
are
using
namespaces
today.
So
these
are
actual
examples
that
we've
anonymized
from
some
fortune
500
company
through
like
talking
to
or
actual
customers.
So
it's
pretty
awesome,
so
the
first
example
is
creating
namespaces
per
team.
A
In
our
second
example,
this
company
created
namespaces
per
team
per
environment
so,
for
instance,
an
example.
Namespace
would
be
like
named
Stacy
one
team,
one
eks
dev,
so
they
actually
built
an
API
to
automate
creating
these
namespaces
and
they
also
have
a
template.
Ipod
security
policies,
network
policies,
along
with
other
kubernetes
policies.
A
So
for
this
example,
though,
their
developers
don't
actually
have
a
concrete
way
to
create
new
namespaces.
For
a
third
example,
which
is
a
more
mixed,
namespace
per
team
example,
they
some
of
their
teams,
have
like
each
name
stays
can
have
many
applications.
Some
teams
have
a
separate
namespace
per
application.
A
So
this
process
sets
up
their
namespaces,
are
back
policies,
quotas,
default
limits
and
requests,
and
for
a
final
example,
this
company,
they
created
a
namespace
per
application
or
category
of
application,
so
they
are
Prometheus
and
elasticsearch
instances
where
each
in
their
own
namespaces
and
all
of
their
namespaces
were
created
by
the
platform
operator.
They
weren't
yet
at
a
stage
in
their
company
where
individual
developer
teams
were
able
to
have
their
own
namespaces,
though.
B
Okay,
so
what
are
the
comps
some
of
the
common
characteristics
between
all
these
examples
that
amy
was
sharing?
These
are
really
three
examples
for
how
you
might
structure
your
organization
against
namespaces
and
I'll
talk
through
some
of
the
pros
and
cons
of
each
of
them,
so
the
first
one
is
basically
a
namespace
per
team.
The
benefit
of
this
approach
is,
it
really
provides.
You
know
self
management
and
a
autonomy
by
delegating
certain
responsibilities
to
the
team.
That's
developing
against
the
namespace
in
terms
of
cons,
there's
not
too
many.
B
This
is
actually
like
a
pretty
sane
approach.
The
second
major
way
to
structure
your
clusters
is
by
creating
one
namespace
per
application.
This
actually
starts
to
look
just
a
lot
like
namespace
per
team.
The
difference
is
as
by
specifying
the
application
as
the
unit
you
can
more,
you
know,
create
more
refinement
in
terms
of
the
policies
that
you
apply
to
a
given
namespace
that
are
aligned
with
the
application,
the
specific
application
needs,
and
then
the
third
is
namespace
for
environment.
So
this
is
more
common.
B
When
you
look
at
smaller
teams-
and
it's
essentially
a
way
to
get
more
use
out
of
a
smaller
fewer
number
of
clusters,
so
basically
each
namespace
is
logically
discrete
and
the
development
teams
can
work
with
it
within
this.
Basically
isolated
development.
Namespace.
The
benefit
of
this
as
well
is
that
the
naming
of
software
components
can
be
maintained
without
collision
across
these
different
environments.
B
There
are
some
cons
with
this
model,
so
a
lot
of
the
policies
that
will
talk
through
for
namespaces
should
in
this
case,
should
really
be
set
at
the
cluster
level.
So
it's
really
difficult
to
achieve
the
right
security
posture
by
setting
these
kinds
of
policies
in
the
namespace
level.
Also,
if
you
do
follow
this
model,
it's
really
still
best
to
create
basically
a
development,
namespace
and
a
test,
namespace,
etc
by
applications.
So,
instead
of
having
one
development,
namespace
you'd
have,
like
a
you,
know,
project
a
development
namespace,
a
project
B
development,
namespace,
etc.
B
Okay,
so
how
do
we
actually
start
thinking
about
how
to
set
the
right
controls
at
either
the
cluster
level
or
the
namespace
level?
So,
as
mentioned
in
the
previous
discussion
of
creating
a
namespace
per
environment,
there
are
certain
controls
that
are
much
better
set
at
the
cluster
level
versus
the
namespace
level.
So
in
a
shared
cluster
environment,
the
cluster
is
really
kind
of
the
land
of
the
operator
right.
So
some
of
the
policies
that
the
operator
is
going
to
want
to
set
in
this
case
are
things
like
cluster
access.
B
B
So
this
is,
you
know,
really
defining
like
what
the
boundaries
of
the
cluster
itself
need.
To
look
like
an
example
is
pod
security
policies
right,
so
you
can
set.
Basically,
the
weather
clusters
are
allowed
to
access
privileged
pods
cluster
quota.
Basically,
how
big
can
the
cluster
be
right
so
setting
some
definitions
around
that?
That's
usually
done
at
the
underlined
infrastructure
level
and
then
finally,
cluster
configuration.
So
should
this
should
all
my
clusters
be
H
a
should
they
always
have
Prometheus
installed.
B
These
are
some
of
the
things
that
you
want
to
think
about
at
the
at
the
cluster
level.
So
then,
moving
on
to
the
namespace
so
again
in
a
shared
cluster
environment,
namespace
is
really
the
land
of
the
application
or
the
development
team.
So
again,
here
thinking
about
namespace
access
via
our
back.
So
what
can
developers
do
with
them
within
this
namespace
application
security
is
similar,
which
is
basically
based
on
the
needs
of
the
application.
B
What
are
some
of
the
policies
that
you
should
be
thinking
about
for
the
namespace
and
amy
is
going
to
go
into
that
and
a
lot
greater
depth
and
namespace
quota
as
well.
So
you
know
how
much
resources
should
development
teams
be
able
to
use
so
that
they
don't
step
on
each
other's
toes
and
Amy's?
Gonna
spend
a
lot
more
time
on
that
as
well.
Finally,
namespace
configuration
so
are
there
certain
characteristics
of
namespaces
that
you
want
to
enforce
across
your
clusters?
B
A
Awesome
so
let's
go
ahead
and
tie
the
topics,
erin
discovered
with
more
specific
recommendations,
so
before
I
start
I
just
want
to
say
we're
not
here
to
be
prescriptive
or
offer
like
like
like
prescriptive
recommendations.
These
are
more
just
like
things
you
can
think
about
and
apply
them
to
what
works
for
your
we're.
Gonna
put
your
organization.
A
So
how
do
you
configure
your
namespaces
to
meet
your
security
and
compliance
right
requirements?
These
are
a
set
of
key
policy
types
that
you
should
consider
for
your
namespaces.
So
under
the
topic
of
cluster
and
namespace
access,
the
main
thing
you
should
be
thinking
about
our
art
is
our
back,
so
you
can
go
ahead
and
enable
user
and
workload
access
to
you
either
the
cluster
through
cluster
roll
bindings
or
to
namespaces
through
regular
roll
bindings.
So
access
control
is
apparently
the
highest
priority
policy
that
you
need
to
configure
from
the
start.
A
So
common
general
roles
include
admin
edit
and
view
the
admin
role.
These
roles
are
all
pretty
self-explanatory,
but
I'll
keep
on
going
to
more
detail,
so
the
admin
role
it
allows,
read
and
write
access
to
most
resources.
The
namespace,
including
the
ability
to
create
roles
and
role
bindings
within
the
namespace.
It
does
not,
however,
allow
you
to
write
access
to
resource
coda
or
to
the
namespace
itself.
A
So
you
should
probably
use
the
admin
role
relatively
sparingly
and
you
should
only
use
it
for
the
applicator
operator
or
DevOps
type
of
persona,
because
they
are
responsible
for
providing
access
and
maintaining
your
security
controls,
but
like
most
organizations
and
giving
this
role
to
everyone.
So
maybe
it's
something
to
pay
more
attention
to
and
be
careful
of.
A
The
second
role
is
read
and
write
permissions.
This
allows
access
to
most
objects
in
a
namespace
and
it
doesn't
allow
viewing
or
modifying
roles
or
role
bindings
and
finally,
for
read-only
permissions.
It
allows
access
to
see
most
objects
in
the
namespace
and
it
does
not
allow
being
roles
or
role
bindings.
It
also
does
not
allow
being
secrets.
A
Under
the
topic
of
infrastructure
and
application
security,
there's
a
few
different
roles
that
you
can
a
few
different
policies
that
you
can
think
about,
and
the
three
are
pod
security
policies,
network
policies
and
image.
Policies
for
pod
security
policies
kubernetes
by
default,
allows
anything
capable
of
creating
a
pod
to
run
a
fairly
privileged
container.
That
can
compromise
a
system
which
is
not
good.
Obviously.
So
what
exactly
is
a
pod
security
policy?
It
is
an
urban
oddities
API
object
that
declaratively
defines
what
users
and
service
accounts
are
allowed
to
create
within
their
clusters.
A
So
this
protects
clusters
from
privileged
pods
by
ensuring
the
requester
is
allowed
to
create
the
pod
as
configured
the
policies
are
enabled
by
an
admission
controller,
the
cube
controller
man,
your
modifications,
as
well
as
our
back
additions
for
more
details
about
this,
though
you
should
definitely
check
out
the
community's
kubernetes
documentation.
It's
definitely
adequate
and
more
detail
than
we
can
go
into
for
this
30-minute
talk.
A
So
the
main
thing
I
wanted
to
cover
for
pod
security
policies.
Are
these
two
main
concepts
which
is
the
the
first
concept,
is
defining
a
default
policy
which
provides
restrictive
access?
So
this
ensures
that
your
pods
can't
be
created
with
privileged
settings
such
as
using
the
hosts
network,
and
you
should
absolutely
start
by
creating
this
restrictive
policy
that
will
act
as
a
default
for
you
to
fall
back
on
to
the
second
is
creating
the
concepts
of
an
elevated
permissive
policy.
So
what
this
allows
is
for
privileged
settings
to
use
to
be
used
for
certain
pods.
A
So,
for
instance,
you
can
probably
assign
this
pod
security
policy
for
things
created
than
cube
system
namespace.
So,
while
restrictive
access
is
like
enough
for
most
pod
creations,
a
permissive
policy
is
needed
for
pods
that
require
elevated
access,
so,
for
instance,
again
in
the
cube
proxy
example,
it
needs
the
host
network
to
be
enabled.
A
On
the
topic
of
network
policies,
they
are
used
to
configure
how
groups
of
pods
are
allowed
to
communicate
with
each
other
and
with
other
network
points
which
is
again
pretty
self-explanatory
network
policies,
so
in
other
words,
it
creates
firewalls
between
pods
running
in
a
kubernetes
cluster.
So
there's
there's
three
general
network
policy
strategies.
A
The
first
is
default,
deny
so
for
this
all
traffic
will
be
dropped
unless
you
set
a
policy
to
allow
your
traffic
through
for
the
second,
you
can
allow
traffic
through
based
on,
like
general
characteristics,
so,
for
instance,
allow
all
traffic
to
an
application
from
namespace
X
or
allow
traffic
from
external
clients.
So
these
are
pretty
broad
characteristics
and
finally,
another
strategy
is
allowing
traffic
based
on
labels.
So,
for
instance,
let's
say
you
assign
the
label
to
date
based
service,
and
then
you
sign
another
label
to
application.
A
You
can
create
a
rule
that
says
everything
in
this
application
can
talk
to
you
anything
with
this
specific
database
label
and
the
third
one
is
is
pretty
short
and
sweet
so
for
image
policies.
It
just
allows
you
to
specify
certain
registries.
You
can
pull
your
images
from
so
obviously,
if
you
pull
your
images
from
an
edge
trust,
untrusted
registry,
that
can
cause
bad
things
within
your
production,
cluster.
A
Under
the
topic
of
cluster
and
names,
taste
configuration,
you
can
mostly
focus
on
label
policies,
so
you
can
create
certain
policies
to
require
specific
resources
to
have
a
label.
What
labels
allow
you
to
do
is
to
be
able
to
filter
resources,
understand
your
resource
by
some
specific
attribute
or
identify
resources
for
your
policy
application.
So,
for
instance,
here
are
some
examples
you
can
define
things
like
all
clusters
must
have
labels,
XY
and
Z,
or
all
kubernetes
objects
must
have
a
owner
label.
And
finally,
you
can
say
something
like
I
want
all
related
service
foreign
applications.
A
And
this
is
on
the
topic
of
cluster
size
and
namespace
quota.
So
remember,
the
point
of
all
these
policies
are
to
divide
up
visible
clusters
into
namespaces.
In
doing
so,
operators
need
to
be
able
to
divide
and
limit
the
resources
each
namespace
is
allowed
to
use.
So
this
ensures
that
each
team
can
get
their
fair
share
of
resources.
They
also
need
a
degree
of
security
to
protect
the
resources
from
the
physical
cluster
from
being
depleted
by
misconfigured
workload.
A
So,
for
instance,
a
misconfigured
job
can
cause
a
cluster
to
crash
by
causing
a
stream
string
of
job
creations
before
each
job
is
able
to
successfully
terminate
and
release
the
source
resources.
So
you
definitely
want
some
level
of
constraint
there
to
make
sure
that
your
cluster
is
not
completely
just
like
depleted
of
of
all
its
resources,
so
the
kubernetes
object.
We
can
use
to
divide
up
these
physical,
the
physical
clusters,
resources
is
resource
quota,
so
this
provides
constraints
that
limit
aggregate
resource
consumption
per
namespace.
A
It
can
limit
the
quality
of
quantity
of
your
objects,
I
think
that
can
be
created
in
a
namespace
by
type,
as
well
as
a
total
amount
of
compute
resources
that
may
be
consumed
by
resources
that
project.
So
how
exactly
do
you
use
resource
quota?
So
what
you
should
do
is
have
your
administrator
create
a
resource
quota
per
namespace
users
can
create
resources
such
as
pods
and
services
in
the
namespace,
and
then
the
quota
system
will
track
usage
to
ensure
that
it
does
not
exceed
hard
resource
limits
defined.
A
The
different
types
of
quotas
are
CPU
limits,
CPU
requests,
memory
limits
and
requests
object
and
total
object
counts
towards
request.
These
are
all
things
that
you
can
definitely
check
out
in
more
detail
in
the
communities
documentation.
So
putting
this
all
together.
Examples
of
policies
that
can
be
created
using
nice
aces
and
quotas
are
in
a
cluster,
with
a
capacity
of
64
gigabytes
of
RAM
and
32
cores.
A
So
I
talk
a
lot
of
a
lot
of
detail
about
policies
which
again
is
something
that
you
should
go
into
more
detail
about
and
the
community's
documentation.
But
how
exactly
do
you
enforce
individual
policies
across
clusters
and
that's
where
admission
controllers
come
in
and
mission
controllers
they?
What
they
do
is
the
intercept
requests
to
the
kubernetes
api
server
after
the
request
is
authenticated
and
authorized,
as
you
can
see
in
this
very
broad
photo,
there's
two
main
kinds
of
admission
controllers.
A
A
The
second
kind
of
admission
controller
is
validating
and
mission
controllers,
so
what
they
do
is
they
reject
and
accept?
Kubernetes
objects.
So
remember
how
we
were
talking
about
pod
security
policies.
They
actually
needed
mission
controllers
to
be
enabled
to
be
able
to
use
pod
security
policies.
So
a
related
example
is,
you
can
say
something
like
deployments
that
do
not
need
this
specific
pod
security
policy
are
rejected
from
your
cluster.
B
So
you
know,
in
this
case,
like
it's
trying
to
spin
up
the
entire
stack
on
on
your
develop
machines
is
going
to
be
more
and
more
difficult
and
it's
necessary
at
this
point
to
use
multiple
clusters
or
and
or
multiple
namespaces
and
then
moving
to
a
large
company.
Basically,
not
everyone
knows
who
everyone
else
is
you
know.
Teams
are
working
on
features
that
other
teams
don't
even
know
about.
In
this
case,
you
definitely
want
to
have
multiple
clusters
and
multiple
namespaces
and
then
finally,
moving
to
the
enterprise.
B
So,
as
you
move
to
this
enterprise
scale,
things
can
get
super
complicated
like
very
quickly
so
oftentimes.
What
you
end
up
having
happen
is
the
individual
development
teams
go
off
and
create
their
own
clusters
right,
so
everybody's
seen
this,
it
can
get
really
challenging
and
it
can
get
really
out
of
control
quickly
and
there's
a
few
challenges
with
this
right.
B
So
first
is
like
operators,
don't
necessarily
have
the
control
that
they
need,
so
they
don't
have
the
control
over
policies
in
terms
of
what
these
clusters
look
like,
and
they
don't
have
control
to
ensure
that
resources
are
being
used
efficiently.
The
second
major
problem
is
CIOs
and
IT
managers.
They
don't
have
visibility
into
this
system
right,
so
they
can't
actually
say
whether
compliance
needs
are
being
met.
They
can't
say
whether
they're,
using
their
resources
and
and
money
effectively.
B
So
to
close
out
this
talk,
we're
going
to
present
a
few
ideas
for
how
to
think
about
structuring
your
organization
against
your
infrastructure,
as
your
organization
grows
and
at
VMware
we're
doing
a
lot
of
work
in
this
area.
I
think
Joe
bata
has
a
really
great
analogy
here
that
he's
been
using,
which
is
basically,
you
know
that
kubernetes
allowed
us
to
move
beyond
thinking
about
individual
nodes
right,
but
now
we
actually
need
to
move
beyond
thinking
about
individual
clusters
and
treat
our
entire
resources
as
a
fleet
of
resources.
B
But
when
we
scale
there's
some
concerns
that
we
need
to
address
so
in
large
organizations,
there's
usually
two
primary
personas.
You
have
developers
on
the
one
hand
and
operators.
On
the
other
hand,
developers
obviously
are
responsible
for
developing
applications.
Operators
are
responsible
for
maintaining
the
security
posture,
ensuring
that
resources
are
being
used
efficiently,
and
these
two
teams
really
have
some
competing
priorities,
so
developers
want
self-service,
they
want
to
move
as
quickly
as
possible.
B
Operators
want
control
and
they
want
to
ensure
they
have
control
over
that
environment,
and
this
balance
between
these
two
groups
is
really
difficult
to
achieve,
and
in
addition
to
that,
a
lot
of
times,
the
interaction
between
these
two
groups
is
through
tickets.
So
there's
basically
two
two
goals
that
we're
trying
to
solve.
One
is
provide
development
teams,
self-service
access
to
infrastructure,
that's
not
ticket
driven
and
second
provide
operators,
the
control
they
need
over
over
things
like
security,
compliance
and
resources
usage.
B
So
here's
one
model
that
we're
thinking
about.
Looking
that
we're
looking
at
it
VMware
for
how
to
do
this,
so
the
first
step
is
really
to
create
groupings
of
clusters,
so
this
is
really
to
set
a
set
consistency
once
you
start
growing
to
a
very
large
number
of
clusters
create
groupings,
and
then
you
can
apply
that
a
lot
of
the
cluster
level
policies
that
we
talked
about
earlier.
B
The
second
step,
then,
is
to
enable
sharing
of
these
clusters
through
basically
groupings
of
namespaces.
So
we
do
this
by
basically
creating
these
flexible
groupings
across
clusters
and
these
groupings
you
can
think
of
as
using
them
for
like
distinct
development
projects,
where
you
want
to
give
a
common
set
of
users
access
to
the
namespaces
across
clusters,
and
you
want
to
set
a
common
set
of
name
space
policies
across
these
namespaces
which
lives
across
clusters,
and
one
way
that
these
groupings
can
be
achieved
is
through
labels.
So
the
truth
is
there's
really
not
one.
B
A
So
implementation,
wise,
though,
like
what
does
scale,
actually
mean
in
terms
of
managing
your
namespaces
in
relation
to
your
organization
and
workloads.
So
what
it
actually
boils
down
to
is
consistency
and
managing
your
kubernetes
policy
objects.
We
already
talked
about
how
to
enforce
individual
policies
with
admission
controllers.
We
also
need
something
that
manages
consistency,
consistency
in
interaction
between
policies,
so,
for
instance,
you
need
to
be
able
to
consistently
make
decisions
like
can
pods
and
cluster
one
namespace
a
have
privilege,
pod
security
policies.
A
You
also
need
to
be
able
to
move
quickly
and
change
quickly
as
well,
and
you
also
need
to
be
able
to
enforce
these
decisions
across
clusters
without
needing
to
manually,
trace
or
edit
some
like
massive
decision
tree,
so
open
policy
agents.
Kubernetes
plugin
is
one
way
to
make
policy
changes
on
a
cluster
without
writing
a
bunch
of
custom
logic
and
its
OPA.
For
short,
so
OPA
is
a
CN
CF
hosted
sandbox
project,
it's
a
general-purpose
policy
engine
and
it
can
be
quickly
used
across
the
stack.
A
So
why
do
we
recommend
using
a
policy
engine
policy,
enabled
services
allow
policies
to
be
specified,
declaratively
and
updated
at
any
time
without
recompiling
or
deploying
your
applications?
Policies
are
also
enforced
automatically,
so
this
is
super
valuable.
When
decisions
need
to
may
be
made
very
quickly,
they
also
make
deployments
more
adaptable
to
changing
business
requirements
and
approve
improve
the
ability
to
discover
violations
and
conflicts.
They
also
increase
the
consensus,
consistency
of
policy
compliant
clients
and
mitigate
the
risk
of
human
error.
A
So,
like
the
point
of
this
entire
talk
is
that
speed
and
software
development
is
on
the
basis
of
competition
organizations,
need
their
developers
to
be
able
to
move
as
quickly
as
possible
by
having
access
to
infrastructure
on
demand.
But,
on
the
other
hand,
operators
are
balancing
this
battle
where
they
need
to
be
able
to
get
keep
the
infrastructure
to
ensure
that
security
and
compiling
client's
needs
are
met.
A
So
what
we
hope
that
you
got
from
this
talk
is
that
you
can
leave
with
the
knowledge
to
start
your
or
to
model
your
organization
against
your
kubernetes
infrastructure
based
on
the
size
stage
and
specific
needs
of
your
organization.
Thank
you.
So
much
for
coming
to
Aaron
and
I's
talk.
Thank
you.
We
hope
you
had
every
time.
Thank
you.