►
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
Kubernetes Policy WG Intro – Zhipeng Huang, Huawei (Any Skill Level)
This session will be divided into two sections, the first section will be the introduction of Kubernetes Policy WG (motivation, current work status, etc...), and second section we will invite folks from the current-forming CNCF SAFE WG to give an overview talk about their WG and future collaboration areas with k8s policy wg.
About Zhipeng
Zhipeng Huang currently serve as open source operation manager for Huawei. Zhipeng have been involved with various major open source communities and is now the PTL of OpenStack Cyborg project, co-chair of OpenStack Public Cloud WG, and co-lead of the Kubernetes Policy WG.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
A
Motivation,
so
why
are
we
doing
this
right?
I?
Think
if
you
have
like
participate
in
communities,
you
can
find
many
places
that
are
policy
related,
so
the
most
mentioned
examples
are
our
backs
right.
You
need
policies
for
admission,
control
and
all
this
stuff,
but
we
find
that
the
policy
features
in
communities
is
actually
like.
Scatter
around
the
place
you
have
like
Network
policy,
networking
site.
You
have
our
back
on
the
authentication
side
and
many
other
features
it's.
A
A
So
that's
actually
one
of
the
the
main
motivation
for
us
to
do
this
working
group
and
also
other
things,
for
example,
like
item
number
three
here
so
do
we
have
a
or
do
we
need
a
unified
policy
language
or
we
could
offer
like
different
language
for
different
purposes
and
you
know
and
for
different
role
and
what
are
the
like?
The
impact
and
what
are
the
functionalities
that
a
policy-related
functionalities
are
needed.
So
these
are
the
questions
that
we
ask
ourselves
before
we
like
establish
the
working
group
so
warning
there.
B
A
From
the
very
beginning
of
the
discussion
around
the
working
group,
we
want
to
be
absolutely
clear
that
we
want
to
avoid
you
know,
reinvent
the
wheel
or
redefining
many
things
that
the
community
has
agreed
upon
and
developed.
You
know
great
features,
we
don't
want
to
do
that.
You
know
chunking
and
saying
hey.
We
have
a
better
solution
and.
A
So
a
little
bit
history,
so
we
actually
kicked
off
the
discussion,
offline
discussion
between
David
here
and
Turin
from
OPI
and
Clayton
and
those
people
last
year,
and
so
around
the
time
of
cube,
Kong
North
America
that
held
frozen
Austin
last
year.
We
decide
to
you,
know,
to
go
into
public
and
make
this
a
absolutely
community
effort.
A
So
I
think
we
officially
formed
in
early
January
and
officially
like
approved
on
February,
and
we
have
been
having
the
weekly
meeting
ever
since
so
I
have
to
try
to
now
to
you
know,
miss
any
meetings
and
keep
a
tight
pace
so
that
everyone
participated
in
the
working
group
have
a
sense
of
I
project
development.
You
know
not
just
some
place,
you
come
over
and
talk
and
yeah.
So
now
we
have
a
wide
variety
of
companies
participating
like
Google,
Huawei,
IBM
rahat.
A
You
know
all
these
great
companies
and
some
interesting
facts,
so
we
have
been
very
actively
collaborate
with
other
with
all
the
possible
related
SIG's
working
group
or
projects
for
them
ho
with
C
gothic
architecture
and
hopefully
in
the
future.
You
know
seek
network
and
many
other
working
group
and
projects,
and
we
have
a
community
driven
approach,
meaning
everything
should
be
done
through
open
discussion
and
everything
is
open
design.
A
We
don't
like
biased
certain
solutions
from
certain
company,
so
we
want
this
to
be
a
totally
community
driven
and
also
just
as
I
mentioned,
I'm
personally
biased
action,
so
I
want
the
like
many
of
the
ideas
that
we
have
in
the
working
group
could
eventually
be
coded
out.
So
we
you
know,
help
of
our
colleagues
here
we
have
been
having
this
tight
development
style
of
working
group
discussions.
A
B
Howard
so,
as
Howard
indicated,
we'll
talk
through
sort
of
three
use
cases,
so
this
is
the
challenge
cat
gif
right.
This
is
the
battle
that
we
have
to
overcome.
How
do
you
take
such
a
broad
problem
of
policy
across
kubernetes
and
come
up
with
a
solution
that
yea
that's
manageable,
where
we
can
contribute
value
back,
so
we
wanted
it
to
be
very
use
case
driven
and,
as
we
talked
among
our
working
group,
what
were
some
of
the
use
cases
to
prioritize?
B
There
were
three
that
we
identified
the
first
being
around
compliance
and
data
management,
given
how
prevalent
things
like
GTR
are
becoming
now
things
like
PCI
and
other
data
standards
that
have
been
enforced
for
many
years.
If
you're
running
a
true
enterprise
workload
in
a
kubernetes
environment,
how
can
you
understand
and
curate
that
data
and
manage
it
understand
which
pieces
are
subject
to
compliance
laws
which
pieces
may
be
restricted
into
certain
geographies,
etc?
So
compliance
being
one
of
the
the
key
first
scenarios
to
tackle
the
second
one
was
around
capacity.
B
One
of
the
use
cases
that
we
thought
was
interesting
out
of
the
coop
con
event
in
Austin
was
the
HBO
team
who
presented
how
they
run
kubernetes
as
part
of
their
organization
in
order
to
provide
services
and
capabilities
for
things
like
Game
of
Thrones
and
Game
of
Thrones,
obviously
being
a
very
popular
show
that
occurs
in
a
particular
periodic
schedule.
When
it's
actually
released
into
the
HBO
streaming
services
and
their
challenge
was
they
had
to
rapidly
scale
up
an
account
for
that
periodic
scaling
of
workload
on
an
ongoing
basis.
B
So,
in
terms
of
capacity
management,
how
could
we
define
more
flexible
policies
that
allowed
you
to
maybe
trade
off
capacity
to
prioritize
certain
lines
of
businesses
or
certain
teams
within
certain
windows?
How
could
they
actually
sort
of
trade
or
share
capacity
among
themselves?
How
would
you
then
recover
that
quota
if
it
was
granted
out
right?
B
Could
we
actually
establish
a
common
notion
of
a
security
profile,
for
example,
to
manage
all
those
aspects,
and
so
in
that
one
we'll
talk
through
how
we
might
do
that
with
a
specific
proposal
that
Eric
will
take
us
through
at
the
end,
you'll
notice,
some
bit
ly
links
that
are
down
here
at
the
bottom
in
some
of
the
charts,
that's
actually
where
these
topics
are
being
discussed.
So
if
you
drop
them
down
or
download
the
actual
slides
there'll
be
a
link
at
the
end
as
well,
then
you
can
actually
come
and
join
the
conversation
directly.
B
So
we
welcome
that
contribution
and
that
interaction
so
compliance.
How
do
you
groom
your
data?
How
do
you
manage
that
for
for
understanding
which
pieces
are
subject
to
regulation
and
which
pieces
are
subject
to
audit
controls
and
things
of
that
nature?
If
you
look
at
gdpr
as
a
foundation,
it
defines
some
primary
roles
as
part
of
the
legislation
that
is
optimizing
around.
So
you've
got
your
data
compliance
officer,
you've
got
your
data
controller
and
then
there's
also
a
data
processor
who's.
B
Actually,
the
function
which
is
in
carrying
out
the
instructions
right,
the
compliance
officer
basically
is
responsible
for
defining
policy,
defining
ways
to
audit
and
alert
when
policies
violated.
The
controller
is
responsible
for
actually
implementing
the
policy
specification
through
either
manual
or
automated
means,
and
then
the
data
processor
is
responsible
for
carrying
out
the
instructions.
So
the
processor
is
generally
something
that
we
considered
more
an
automated
function
or
a
piece
of
software
rather
than
a
human
being
or
a
persona.
B
So
if
you
look
at
the
two
primary
human
being
personas
we're
looking
at
the
data
compliance
officer
and
the
data
processor
or
excuse
me,
the
data
controller,
and
in
this
case
you'll
see,
we've
highlighted
a
couple
of
use
cases.
I
won't
read
them
all
verbatim,
but
a
couple
that
I'll
highlight
is
really
around
this
capture
metrics
and
ensure
that
policies
are
being
followed
and
understand
when
violations
occur.
B
The
data
controller
is
responsible
for
creating
the
policies
so
defining
the
artifacts
that
describe
how
that
policy
should
be
enforced
and
then
taking
measuring
the
organizational
and
technical
measures
for
ensuring
the
security
of
that
data
processing.
So
this
scenario
we
expect
to
ultimately
result
in
a
set
of
proposals
to
improve,
perhaps
how
we
tag
or
annotate
the
utilization
of
persistent
volumes
and
pods,
etc.
That
may
interact
with
sensitive
personal
information
personally
identifiable
information,
other
forms
of
health
data,
etc.
B
The
next
scenario
here
is
about
capacity
or
how
to
manage
demands
on
your
resources,
so
there's
a
puppy
gif
in
case
you
don't
like
cats,
no
all
right.
In
any
case,
the
capacity
management
is
really
again
about
this
dynamic
quota
management.
Beyond
simply
setting
a
hard
limit
on
how
much
quota
a
particular
team
could
consume,
how
do
you
balance
and
trade
that
off
amongst
various
teams?
B
And
so
the
idea
here
is
to
define
a
set
of
use
cases
that
allow
you
to
say,
for
instance,
within
this
window
right,
my
Game
of
Thrones
example
for
the
HBO
team
they're
presented
on
stage
within
this
window,
Sunday
9:00
p.m.
Eastern.
We
actually
need
to
make
sure
that
this
particular
function
or
a
set
of
services
related
to
Game
of
Thrones
or
other
video
streaming
needs
to
be
prioritized
for
their
various
requests
versus
other
teams,
which
might
be
doing
more
batch
processing.
That
is
less
time
dependent.
B
That's
in
the
document
again
the
document
that
was
linked
a
moment
ago
and
the
first
slide
about
the
the
different
scenarios,
but
here
we're
looking
at
things
like
how
to
set
policies
that
lines
of
business
to
lend
out
unused
capacity,
how
to
set
capacity
allocation
that
varies
by
time
of
day
week
or
month,
and
then
how
to
enable
lines
of
business
to
be
able
to
set
hierarchical
policy
that
divides
quota
allocation
amongst
a
larger
org.
So
perhaps
I
have
a
retail
banking
org.
B
I
allocate
a
set
of
quota
against
my
shared
services
and
they
then
subdivide
it
amongst
their
various
teams
and
business
functions.
So
really
this
again
is
about
how
do
you
really
get
the
best
utilization
of
your
cluster,
whether
that's
in
public
or
private,
and
in
fact
one
of
these?
Yes,
this
one?
The
other
aspect
here
is
how
do
I
specify
which
teams
are
aunt
entitled
to
use
capacity
of,
and
maybe
a
federated
use
case
on
the
public
resources
or
private
resources?
B
Finally,
the
keeping
intruders
out
right
how
to
prevent
them
from
scaling
the
walls
and
getting
in
here
there
are
great
individual
components
of
policy
around
our
back
network
security
policy,
pod
security
policy,
etc,
but
managing
the
lifecycle
of
when
to
apply
those
say
as
you
create
new
namespaces
is
not
something
that
the
platform
handles
out
of
the
box
today.
So
again,
in
line
with
the
theme,
this
is
not
about
raising
and
rebuilding
everything.
B
That's
been
established
by
consensus,
it's
about
incrementally
improving
how
I
use
it
from
end
to
end
so
there's
a
policy
that
Eric
will
talk
about
just
a
moment,
but
ultimately
defines
a
notion
of
security
profile
that
then
groups
together,
a
collection
of
policy
and
the
lifecycle
events
around
it.
So
these
scenarios
reflect
some
pieces
that
already
exist
right.
The
ability
to
set
our
back
rules
across
different
namespaces
is
there
today.
B
That's
not
necessarily
new,
isolating
Network
and
blocking
traffic
can
be
supported
today,
but
then
standardizing
these
policies
that
account
for
the
life
cycle
required
to
apply
or
modify
them.
That's
something
that
we
think
is
sort
of
a
net
new
that
would
build
on
top
of
what's
already
there
so
now,
we'll
get
into
more
of
the
depth
of
some
of
the
proposals
and
Eric
will
take
us
through
that.
C
So
the
first
one
here
is
scheduling
policy.
The
kind
of
problem
is,
we
have
a
lot
of
very
fine-grained
ways.
You
can
control
your
scheduling,
you
can
add
the
taints
and
toleration
x'
or
node
affinity
or
anti
affinity.
You
have
priority
classes
so
that
you
can
say
that
certain
pods
have
more
higher
priority
over
others.
C
You
know
make
sure
you
don't
kick
one
of
your,
like
logging
demons
off
of
a
node
just
because
some
new
workload
comes
up,
for
instance,
or
you
want
to
make
sure
that
your
master
nodes
only
run
your
master,
the
right
pods
and
don't
have
some
user
workload
schedule
bomb
to
them.
So,
while
you
have
all
those
controls,
the
problem
right
now
is
that
it's
kind
of
up
to
the
pod
to
make
sure
it
has
all
of
the
right
kind
of
parts
on
there
rather
than
having
someone
control.
C
So
if
you'd
like
change
your
label,
you
might
be
able
to
kind
of
sneak
on
to
another
onto
the
master
node
when
we
do
not
want
that
to
happen.
So
the
scheduling
policy
is
a
way
to
with
some
amount
of
fine-grained
control,
say
what
can
and
can't
be
done
with
these
scheduling
controls
so,
for
instance,
which
schedulers
can
pods
in
a
namespace
use
or
which
priority
classes.
Perhaps
you
know
set
aside
a
set
of
namespaces
that
are
allowed
to
have
the
highest
priorities.
C
C
We'll
try
this
out.
Okay,
this
is
another
one
that
I
think
comes
to
when
I
think
about
policy.
It's
kind
of
like
the
policy
are
when
you
have
a
place
that
you
need
to
make
a
decision
about
something
it's
the
guidelines
for
making
that
decision,
so
you
can
kind
of
come.
You
can
see
that
there
are
some
main
points
where
decisions
need
to
be
made
in
our
systems.
Scheduling
is
a
very
obvious
one.
C
C
B
So,
just
to
build
on
a
little
bit
of
what
Erika
said
here,
as
we've
thought
about
most
of
the
policies
today,
we're
restricting
behavior
pods
we're
restricting
Network,
firewalls,
etc.
There's
not
necessarily
a
lot
of
policies
that
indicate
describing
behavior
about
how
you
want
the
network
flow
for
a
particular
service
call
to
be
enforced
unless
you're
bringing
a
specific
service
mesh
at
the
application
tier,
but
at
the
at
the
actual
structure
tear
this
proposal
is
meant
to
help
improve
more
of
the
routing
behavior.
B
So
if
I
have
a
particular
service,
that's
exposed,
this
policy
would
allow
me
to
specify
I
want
to
have
it
serviced
by
a
pod
which
is
closer
in
locality.
A
service
pond
is
providing
that
API
I
wanted
to
be
closer
to
the
client.
So
if
a
client
makes
the
call,
they
would
actually
have
the
response
from
a
pod,
that's
running
on
the
same
host
or
the
same
rack
or
the
same
data
center.
If
you
get
into
the
application
layer,
you
can
actually
do
some
of
this
with
things
like
console.
B
This
particular
proposal
was
brought
forward,
though,
to
really
be
able
to
optimize
the
per
packet
routes
that
are
travelling
beneath
the
coop
service
proxy
and
that's
really
kind
of
the
difference.
This
is
one
that
we
welcome
a
lot
of
feedback
on
exactly
whether
or
not
welcome
feedback
on
whether
you
think
it's
viable
or
whether
the
community
believes
that
the
service
management
layer,
that's
already
there
with
saying
Sto
or
a
console
or
other
server
or
Eureka
style
service
discovery
frameworks.
B
They
already
account
to
a
large
extent
for
that
kind
of
locality,
but
they
don't
have
control
or
visibility
on
the
packet
routes
that
are
actually
taken,
so
you
might
actually
send
a
packet
to
a
service
that
is
much
further
away
versus
being
able
to
identify,
know
when
it
always
to
kind
of
default,
is
at
the
closest
spot
possible.
So
I
can
improve
latency,
that's
really
what
this
one's
about
a
little
bit
more
low
level
perhaps,
but,
as
you
can
see
again
the
pull
request
or
reference
we're
looking
for
feedback
from
you
guys.
C
B
C
And
then
we
have
our
last
one,
which
is
security,
profile
policy.
This
is
sort
of
a
big
proposal
that
encompasses
a
lot
of
different
ideas.
One
of
them
is
kind
I.
Think
there's
a
common
idea
of
how
can
you
have
define
a
configuration
that
you
can
or
maybe
not
configuration
but
describe
your
cluster
when
it
comes
to
the
policy
and
its
security
in
a
way
that
it's
portable
across
clusters,
so
that
you
can
boot
a
cluster
with
the
same
policy?
C
So
please
there's
it's
an
active
discussion.
I
think
there's
a
lot
of
different
ideas
that
we
would
like
some
opinion
on,
and
you
can
see
here-
is
an
example
of
one
aspect
which
is
the
namespace
template.
This
would
be
when
you
create
new
namespaces,
want
an
area
to
ensure
that
certain
it's
kind
of
Auto
populated
with
the
right
controls
on
it.
Things
such
as
our
back,
that's
I,
think
probably
the
biggest
one
people
always
think
about,
or
pod
security
policies,
Network
policies,
etc.
C
A
So
those
three
proposals
are
the
most
mature
ones
that
comes
to
the
working
group,
and
we
think
those
three
could
be
the
priorities
for
us.
Looking
towards
one
point
of
release,
and
here
are
actually
other
possibilities.
So
one
thing
we
haven't
explained
is
like
why
we
design
the
way
that
the
discussion
carrying
why
we
discuss
use
cases
and
why
you
know
later
on,
we
discuss
proposals.
A
For
example,
Mike,
Michael
and
Khalid
has
some
of
the
prototype
for
the
combines
use
case
by
defining
a
data
control
policy
which,
which
I
think
is
a
pretty
awesome
idea
that
you
can
actually
automate
the
auditing
process
rather
than
you
know,
having
people
manually,
checking
out
and
also
resource
policy
like
we
have
like
in
the
resource
management
working
group,
we
have
many
discussions
around
the
non-native
resource
management.
You
know
how
do
we
do
that
and
there
will
be
also
policy
related
to
that
and
also
the
multi-tenant
quota.
A
The
multi-tenancy
working
group
is
currently
as
far
as
I
understand,
working
on
a
multi-tenant
controller,
so
how
the
quota
policy
feed
into
that
architecture
and
help
the
quota
control
is
the
topic.
We
will
be
interesting
and
there
possibly
be
more
to
add.
So,
as
you
can
see
the
holistic
architecture
we
have
been
talking
about,
we
don't
want
to
like
draw
that
up
on
the
on
the
slide
using
squares
circles.
A
So
all
the
use
cases
you
have
been
seen
is
documented
on
the
design
dock.
So
we
will
continue
discussion
for
the
design
document
on
the
architecture
picture.
You
know
all
this
stuff
alongside
the
discussion
of
the
twelve
and
thirteen
release
top
priority
PRS.
So
those
three
you
just
saw-
and
maybe
others
if
people
are
interested
to
bring
to
the
working
group-
and
we
are
also
looking
at
further
collaboration
within
the
scene-
safe
community.
So
maybe
some
of
you
already
attend
since
F
safe
working
group
session.
A
For
example.
How?
If
you
have
something
like
OPA
policy
engine,
you
know
how
the
policy
engine
talking
to
the
policy
enforcement
point,
so
there'll
be
a
lot
of
interesting
ideas
to
be
discussed
so
and
if
you
are
interested,
please
talk
to
us
and
let's
see
if
we
can
movie
on
this
subject
and
again,
I'm
biased
toward
action
so
I.
A
If
we're
gonna
have
this,
since
you
have
policy
working
group,
I
also
won
in
this
working
group
to
to
be
able
to
implement
any
ideas
that
we
would
discuss
so
tomorrow,
I
think
have
assigned
a
all-star
team
that,
beyond
my
expectation,
so
tomorrow
same
room
non
same
time
later,
we'll
have
the
deep
dive
session,
which
I
invited
six
experts
to
come
over
and
do
lightning
talks.
Well,
it's
five
minutes,
lightning
talk,
but
that's
all
like
technical,
interesting
policy
implementations.
A
B
Actually
not
so
much
about
the
cat,
but
the
link
underneath
it,
which
hopefully
you
saw
the
link,
as
you
were,
looking
at
the
cat
right
drawing
your
eye
over
anyway.
If
you
are
interested
in
a
copy
of
the
slides,
that
link
will
give
you
a
copy
there.
So
on
Google
presentation
you
can
have
comments,
etc.
Questions.
D
D
B
So
it's
this
example.
This
is
simply
a
snippet
of
the
broader
proposal.
This
is
really
just
describing
how
they
define
the
matching,
but
again,
if
you've
got
feedback
on
an
alternative,
there's
a
pull
request
that
describes
it
and
then
there's
links
as
well.
This
actually
I
think
is
the
Google
Doc.
That
kind
of
highlights
everything
so
whether
the
PR
are
there
and
actually
provide
that
feedback.
E
A
B
B
B
So
I
think
this
is
probably
this
is
broader
than
something
I
could
just
answer
and
give
you
a
definitive
answer.
I
think
my
opinion
I
think
we
haven't
really
seen
how
OPA
integrates
into
this.
Yet
we
have
Turin
and
others
that
are
helping
guide
that
discussion
and
we'll
do
a
lightning
talk
on
that
tomorrow.
So
that
may
be
a
question
that
he
will
be
in
a
better
position
to
answer
specifically
I.
Think
in
general
the
architectural
approaches
that
we
see
most
policy
engines
follow
typically,
but
there's
a
declaration
point.
A
D
B
So
if
I
can
summarize
the
question
I
believe
it
would
be
something
along
the
lines
of,
as
we
have
many
different
descriptions
of
policy
having
a
common
intermediate
language
that
allows
us
to
represent
those
intentions
that
then
can
be
enforced
in
a
consistent
engine.
Is
there
a
thought
process
around
what
that
consistent
language
might
be
so
I
I
would
tend
to
suggest
right
now,
I
think
if
there
were
such
a
common,
descriptive
language,
oppa's,
probably
the
starting
point,
because
there's
already
the
community
effort
around
it.
C
B
C
I
mean
I
think
that's
kind
of
the
questions
that
haven't
been
as
discussed
in
kubernetes.
What
is
the
right,
how
low
level
or
high
level
or
expressive
should
these
policies
be?
And
if
you
notice
I'm
not
answering
giving
you
a
question
just
saying
that
I'd,
like
totally
with
you,
that
there
these
are
the
type
of
things
that
we're
trying
to
discuss
and
most
immediately
in
the
scheduling
policy,
where
we
want
to
get
a
new
policy
object
out
within
the
next
couple
releases.
So
please
comment
on
that.
Pr.