►
Description
From the March 28th 2017 OpenShift Commons Gathering in Berlin @KubeCon https://Commons.openshift.org/Gathering
A
A
A
Actually,
as
I
put
this
slide
up
here,
I
thought
I
think
there's
probably
a
lot
of
confused
people
at
tech
conferences
who
work
at
the
tech
conferences
or
see
people
going
in
and
are
these
buildings
because
there's
all
this
container
related
stuff.
They
must
think
that,
like
the
tech
industry
is
suddenly
like
part
of
the
shipping
industry
or
that
were
like
all
like
a
longshoreman
conference
or
something
so
I'm
going
to
think
of
everybody
in
the
audience
as
longshoremen
as
I
talk
to
you
about
this.
A
So
if
you
see
me
giving
you
strange
looks
is
because
you're
big
burly
people
throwing
around
boxes
on
a
dock
somewhere.
So
the
next
slide
please.
So
this
is
a
really
I
said.
Diane
asked
me
to
come
up
and
talk
about
the
features
that
are
in
openshift
3-5,
which
is
based
on
top
of
qu
Bernays
one
five,
and
to
talk
a
little
bit
about
where
we're
going
and
unfortunately,
in
30
minutes,
it's
almost
impossible
to
talk
about
anything
more
than
just
a
few
topics.
A
So,
if
there's
four
things
that
really
matter
from
an
open
shift
perspective,
and
they
also
matter
in
a
kubernetes
perspective
as
well,
but
the
things
I
think
about,
as
what
we're
trying
to
do
community
is
extremely
important
to
red
hot.
It's
extremely
important
to
everyone
who
works
on
the
openshift
team.
It's
extremely
important
to
everyone
who
works
on
the
kubernetes
team
at
Red
Hat
at
Google,
at
core
OS,
and
we
works
at
any
of
the
any
of
the
companies
that
have
come
together
in
the
kubernetes
community
to
build
better
tools
for
running
applications.
A
We
all
kind
of
believe
in
that
shared
mission
been
a
real
privilege
to
work
with
this
community
over
the
last
two
years
and
to
see
it
grow
and
evolve
and
I
really
hope
to
see
it
continue
to
grow
over
the
next
five
six
10
15
years
at
some
point,
I
hope
to
look
back
on
kubernetes.
You
know
seventy
five
point
nine
and
say
wow.
This
is
something
that
really
changed
computing
and
it
changed
how
we
build
and
run
applications
at
scale.
A
Security
is
the
you
know,
one
of
the
most
important
things
when
we
think
about
what
the
difference
between
out-of-the-box,
kubernetes
and
OpenShift
is
it's
incredibly
important
to
us
to
provide
something
to
that
multi-tenant
user
base
for
applications,
because
when
we
think
about
what
openshift
has
been
focused
on
it's
about
bringing
organizations
together
to
build
applications?
Obviously,
to
do
that,
you
need
a
really
fundamental
approach
to
securing
and
managing
how
those
application
users
interact.
So
a
partner
talked
about
our
back
and
that's
based
on
work
that
came
out
of
OpenShift.
A
Many
of
the
same
folks
who
are
involved
in
the
open
shift
side,
along
with
many
others
in
the
community,
helped
bring
it
to
kubernetes
and
I'll
talk
a
little
bit
later
about
why
that's
so
important,
but
there's
many
other
things
in
security
that
still
need
to
be
done,
and
this
is
just
the
beginning
of
a
journey.
We
want
to
build
a
platform
that
as
secure
as
anything
that
has
ever
existed
because
we're
gonna
be
running
all
these
applications
on
top
of
it.
A
So
stateful
sets
are
another
great
feature:
that's
just
now
kind
of
getting
out
there
and
getting
into
a
beta
state
where
people
can
really
try
it,
and
we
expect
to
continue
to
push
these
new
types
of
workloads
and
these
new
opportunities
for
different
types
of
applications,
not
just
your
traditional
three-tier
web
app,
but
really
branching
into
other
areas
of
computing
areas
that
are
kind
underserved
in
terms
of
the
ability
to
rapidly
iterate
and
deploy
applications
next
slide.
So
this
is
the
whole
stack.
I
could
talk
for
a
day
on
any
of
the
topics
up
here.
A
We're
just
gonna
selectively
pick
a
few
things
out
and
then,
if
you
have
any
questions,
please
find
me
later
and
I,
don't
know
if
any
of
our
you
can
find
some
of
our
PM's
and
they
can
talk
to
you
for
six
or
seven
days
about
any
of
these
items.
So
next
slide
please
so
now
I
can
talk
about
what's
happened.
These
are
just
kind
of
the
high-level
bullets.
A
Every
release
it
seems
like
there's
more
and
more
features
of
key
concern
to
us
is
ensuring
that
the
stability
of
each
release
continues
to
increase
and
it's
actually
becoming
somewhat
of
a
challenge.
The
more
features,
the
more
capabilities
that
exist
in
both
kubernetes
and
the
ecosystem
around
kubernetes.
A
It's
actually
really
important
for
us
to
begin
to
look
out
past,
just
the
the
near
horizon
of
the
kubernetes
infrastructure,
but
also
look
at
what
are
the
other
projects
in
the
ecosystem,
like
the
other
projects
that
are
part
of
the
sea
and
CF
that
people
are
using
today
to
build
micro
service
applications,
frameworks,
new
technologies,
new
backends
and
how
we
bring
those
together
in
a
holistic
way.
How
do
we
bring
together
as
Red
Hat
and
as
the
open,
shipped
origin
community,
a
wide
and
diverse
range
of
tools
and
technologies
and
help
them
work?
A
Well,
really
well,
together
in
a
secure
fashion,
next
slide
so
open
ship
35
focused
on
platform,
reliability
and
iterating.
On
the
core
experience,
we
tried
to
expand
application
support.
Stateful
sets
our
tech
preview
and
open
shift
35
and
will
continue
to
we're
trying
to
get
them
as
stable
as
possible
and
have
a
fairly
long
soak
period
so
that
everybody
gets
a
chance
to
really
offer
feedback
on
the
direction
again.
It
makes
no
sense
for
us
to
push
something
out
there
that
doesn't
match
the
needs
of
applications.
A
People
are
building
and
so
that
we
expect
that
to
be
a
dialogue
and
container
security
and
there's
a
number
of
small
items
that
have
taken
place
in
this
release
around
ensuring
that
we
can
articulate
and
communicate
how
you
secure
a
platform
all
the
way
from
the
OS
level
and
the
hardware
level
up
through
the
individual
layers
of
the
stack.
What
are
the
different
parts
of
security?
How
do
you
reason
about
how
secure
your
containerized
environment
is?
A
Because,
if
there's
anything
that
we
hear
it's,
that
this
is
so
new
space
and
there's
so
many
things
going
on
it
up
in
so
many
patterns
of
how
people
run
applications
that
if
we
don't
take
some
time
to
make
sure
that
people
understand
how
things
are
changing,
we
actually
increase
the
risk
of
security.
There's
huge
advantages
to
standardizing
how
you
build
and
run
applications,
but
the
risks
that
comes
with
it.
A
If
you
don't
understand
that
standardization
there's
blind
spots
in
your
security
reasoning
and
we've
done
also
done
a
lot
of
work
in
the
three-five
release
with
other
teams
in
the
community
to
bring
the
container
development
kit,
which
is
a
VM
that
contains
open
shipped
within
it,
we
made
it
easier
to
use
and
some
of
the
great
work
by
folks
on
the
open,
shipped
evangelist
team
and
in
the
community
as
well
to
to
give
power
users
a
way
to
run
open
chef
more
effectively
on
their
local
clusters
or
on
their
local
laptops.
Next
slide.
A
So
in
OpenShift
three
four,
we
were
this
tech
preview
of
integrated
Jenkins
with
the
open
shift
platform,
and
the
idea
was
is
that
everyone
uses
Jenkins
to
some
degree
or
another.
We
wanted
to
make
sure
there
was
just
enough
power
and
ease
of
use
that
you
could
start
consuming
Jenkins
to
run
deployment
pipelines.
Jenkins
is
fairly
fundamental
to
how
many
organizations
build
continuous
integration
and
continuous
deployment.
Today,
we
wanted
to
make
that
bridge
from
openshift
is
a
platform
for
developers
to
be
able
to
easily
consume
Jenkins
pipelines,
which
is
the
exciting
new.
A
The
exciting
new
change
in
how
Jenkins
is
moving
from
kind
of
the
older
jobs
based
approach
to
more
of
a
declarative,
here's,
the
steps
and
stages
and
the
ability
to
reason
about
not
just
individual
parts
of
your
build
chain,
but
how
you
might
start
with
code
and
a
build.
You
then
move
to
a
test
environment.
A
The
flipside
of
having
really
good
web
applications
is
you
want
stateful
apps,
a
part
of
touching
a
lot
of
the
details
of
this.
The
stateful
set
is
really
kind
of
the
translation
of
the
idea
of
you've
got
these
scale
out
web
services
that
don't
have
any
dependencies
and
they
don't
need
any
state.
It's
really
easy
to
create
ten
of
them,
throw
away
two
of
them
bring
back
for
more.
A
A
You
know
the
idea
of
I'm
just
gonna,
take
this
machine
away
and
then
bring
a
new
machine
back
and
the
clusters
gonna
go
create
this
new
instance
of
running
containers
somewhere
and
it's
just
gonna
magically
pick
up
all
the
data
I
had
before
that's
a
big.
That's
a
large
amount
of
trust,
right,
you're,
trusting
that
OpenShift
and
kubernetes
are
gonna.
Take
that
instance
of
the
database
detach
the
storage
correctly,
move
it
to
a
different
machine.
It's
not
gonna
run
two
of
them.
At
the
same
time.
That's
really
critical.
It's
very
easy!
A
We
focused
on
making
sure
that
there's
a
predictable
process
whereby
we
create
only
three
instances
we
bind
them
to
storage
because,
obviously
you
know,
if
you
have
to
use
local
disk,
you
can
definitely
run
into
issues
where
a
machine
dies,
and
you
want
to
avoid
it.
This
ties
into
the
persistent
volume
support,
that's
always
been
in
kubernetes
allows
you
to
detach
volumes,
reattach
them
and
then
in
the
worst
case,
and
this
is
where
the
the
functionality
really
kind
of
stops
today,
where
we
want
to
continue
is
when
something
does
happen.
A
The
cluster
gets
partitioned
and
one
of
these
machines
is
off
there
and
you
can't
actually
talk
to
that
machine
to
figure
out
whether
it's
shut
down
correctly.
You
know
the
dreaded
network
partition.
What
kubernetes
does
today.
Is
it
failsafe?
It
stops,
it
doesn't
try
to
go
and
do
something
special
and
say:
oh
no,
I'm
pretty
sure
this
is
gone.
I'm
gonna,
you
know
and
that's
how
you
end
up
with
four
instances
when
they
were
only
think
there's
three
in
future
releases.
A
What
we
want
to
do
is
take
concepts
that
exist
have
existed
for
a
very
long
time
in
the
system
in
world
fencing
shoot
the
other
node
in
the
head:
storage,
storage,
lock
out
from
products
like
sand,
lock
and
pacemaker.
All
of
these
concepts
that
have
existed
for
very
long
time
to
make
hae
Z
or
make
AJ
even
possible
on
traditional
Linux
systems.
We
actually
wanna
help
integrate
those
with
kubernetes
and
the
stateful
application
frameworks.
A
What
that
allows
us
to
do,
then,
is
to
say,
if
you're
not
running
on
a
cloud
provider-
and
you
don't
have
access
to
world-class
storage
bodies,
but
instead
you're
building
it
yourself.
How
do
you
have
the
confidence
that
you
can
do
what
the
big
cloud
providers
do?
You
can
detach
that
disk
and
ensure
that
the
data
isn't
going
to
get
corrupted,
because
two
pods
are
running
two.
At
the
same
time,
we're
gonna
work
on
ensuring
that
network
fencing
is
something
that
can
exist
at
the
platform
level,
and
these
are
incremental.
A
Steps
will
take
overtime,
but
I'm
very
excited
about
the
possibilities.
We
have
to
really
make
high
availability
for
applications,
something
that's
innate
and
fundamental
to
the
where
you
can
rely
on
it
the
same
way
across
your
entire
application
portfolio,
even
four
classes
of
applications
that
don't
run
well
on
container
platforms,
even
with
these
steps
to
give
people
the
kinds
of
incremental
steps
that
are
necessary
to
run
real
application.
Workloads
next
slide,
please
in
combination
with
that.
The
open
chip
UI
has
begun
to
add
storage
support.
A
Ui
is
has
existed
since
the
very
beginning.
It's
focused
on
developer
use
cases.
What
we're
really
trying
to
do
is
expose
all
of
the
power
of
the
platform
without
necessarily
overwhelming
developers,
and
that
can
be
a
really
tough
balance.
You
know
there's
a
lot
of
people
who
beat
me
up
on
a
day-to-day
basis,
because
we
either
show
too
much.
We
tell
you
about
pods
or
we
don't
show
enough.
A
We
don't
show
you
the
details
of
active
deadlines
seconds
on
a
pod,
and
so
what
we
try
to
do
with
the
developer,
console
and
openshift
is
find
that
balance
between
what
are
the
things
that
developers
need
to
know
to
safely
run
their
applications
to
make
changes
in
data
rate.
We
expect
over
time
to
bring
more
users
more
user
interfaces
together
with
openshift,
to
offer
different
views.
A
If
you're
someone
who's
a
citizen
developer
who's,
you
know
using
a
business
process
engine
on
top
of
openshift
we'd
like
it
to
be
easier
to
fit
those
on
top
of
the
platform
without
necessarily
having
to
integrate
it
and
to
offer
that
you
know
the
difference
of
experience
over
the
full
lifecycle
of
software
development,
not
just
the
particular
kinds
of
web
development.
We're
talking
about
here
next
slide.
A
Some
other
big
changes
open
shifts.
Integrated
registry
is
always
a
point
of
discussion
when
we
talk
about
well,
if
you
have
this
containerized
platform
and
you
don't
have
any
way
to
track
the
images
that
run
on
that
platform
and
if
you
don't
have
any
way
to
easily
new
images
onto
that
platform,
if
you
don't
have
any
way
to
combine
the
secrets
that
you
might
need
to
go,
get
images
from
other
spots,
it's
very
difficult.
A
You
actually
have
to
build
that
on
top
and
so
starting
from
the
very
beginning
and
open
ship,
we
said
images
are
a
fundamental
part
of
the
workflow
for
the
cluster.
We've
continued
to
refine
the
model,
but
I
would
describe
it
as
this.
The
goal
of
the
integrated
registry
and
OpenShift
is
to
help
bridge
the
gap
between
every
other
registry
in
the
world
and,
what's
running
on
your
production
clusters,
it
doesn't
mean
necessarily
that
openshift
has
to
own
that
resource.
A
It
can
still
be
a
downstream
from
an
authoritative
repo
and
that's
very
important
to
us,
integrating
with
external
registries,
but
it
also
means
that
OpenShift
can
provide
things
that
make
your
cluster
safer
and
more
reliable.
So
an
open
shift
three-five
we
actually
added
a
mode.
We
had
previously
supported
the
ability
to
an
open
shift.
When
you
set
up
open
shift
to
point
to
a
remote
registry,
you
could
talk
to
the
integrated
registry.
The
integrated
registry
would
then
go
pull
the
image
and
you
would
proxy
it
through
the
server.
A
Instead,
local
registry,
as
before,
would
talk
to
the
remote
system
with
the
authentication
and
then
once
you'd
begin
pulling
that
image.
It
creates
a
mirror,
and
this
actually
leverages
a
capability.
That's
been
in
the
the
upstream
docker
registry
for
a
long
time,
but
it
does
that
using
all
of
the
security
and
all
of
the
control
of
OpenShift.
It
keeps
that
local
content
in
the
registry-
that's
associated
with
the
particular
open,
shipped
installation
that
remote
registry
goes
down.
A
Image
pools
still
work,
and
so,
as
we
start
to
make
further
steps
down
this
road,
imagine
you
know
federated
clusters
across
the
world.
How
do
you
ensure
that
the
images
that
are
available
if
that
registry
goes
down
that
could
be
downtime
for
any
application?
What
we
really
want
to
ensure
is
that
you
can
have
authoritative
registries
that
are
strongly
and
centrally
controlled
and
then
use
the
OpenShift
clusters
as
the
way
to
distribute
and
manage
locations
next
slide.
Please.
A
This
is
the
big
slide.
There's
ten
things
listed
here
and
there's
a
hundred
things
on
the
back
end.
We
spend
a
lot
of
time
working
on
improving
the
install
experience
for
OpenShift.
From
the
beginning,
we
had
made
a
bet
on
ansible
on
the
redhead.
Even
before
red
had
acquired
ansible,
our
operations
teams
had
decided
that
they
wanted
to
make
a
to
a
newer
model
of
doing
configuration
management.
A
They
took
that
as
an
opportunity
to
pull
in
best
practices
that
we've
leveraged
in
our
open,
shipped
online
hosting
as
part
of
the
3/5
release
and
continuing
work
that
was
done
in
3
4
&
3
3.
We've
continued
to
refine
automate,
streamline
guarantee
via
the
idempotency
of
play
book
updates
and
try
to
ensure
that
the
most
common
operational
patterns
are
easy,
reliable
and
safe.
A
Now
this
doesn't
mean
that
everybody
in
the
world
may
want
to
use
exactly
every
detail
of
these
play
books,
but
our
focus
has
been
a
platform
should
be
easy
to
operate
and
when
you
do
need
to
do
complex
things
like
installing
nuage,
alongside
an
open
shift
cluster
or
if
you
want
to
setup
persistent
storage
like
SEF
and
Gluster,
or
you
need
to
make
sure
that
the
firewall
rules
and
all
of
those
machines
are
consistent.
We
want
to
offer
an
out-of-the-box
default
way
to
install
open
shift.
That
is
a
secure,
kubernetes
distribution
from
top
to
bottom.
A
Each
of
these
things
builds
on
the
other,
we're
able
to
reuse
more
of
the
playbooks
we've
already
put
in
play,
and
it
makes
the
operational
the
day
two
and
day
three
experiences
of
open
shift
even
more
powerful
next
slide.
Please
a
partner
talked
about
network
policy.
Openshift
has
had
the
multi
tenant
Sdn
plug-in
from
the
beginning
through
open,
shipped
Sdn.
We
also
had
the
more
flat
mode
using
OBS,
if
you
think,
of
multi
tenant
Sdn
as
one
extreme,
where
only
two
people
can
only
talk
to
each
other.
A
If
an
administrator
sets
it
and
the
open
mode
is
the
other
extreme,
no
isolation
network
policy,
the
open
engineers
who
worked
on
open
chef,
dia
Sdn,
had
actually
been
involved
in
the
network
policy
design
discussions.
The
goal
was
is
to
add
that
level
of
flexibility,
so
instead
of
just
having
two
options,
one
at
either
end
of
the
security
spectrum,
you
can
give
your
users
a
choice
or
you
can
give
your
administrators
a
choice
to
more
flexibly,
compose
different
applications
in
different
namespaces
and
there's
much
more
that's
going
to
be
done
here
over
time.
A
But
the
goal
is
everything
that
comes
out
of
the
kubernetes
project
in
terms
of
policy.
We
believe
we
work
in
the
kubernetes
project
to
ensure
that
those
things
are
successful,
are
stable,
are
reliable
and
can
be
made
secure,
and
that
security
part
is
something
all
of
touched
on
a
minute
just
a
minute.
Next
slide,
please
and
finally,
I
talked
about
local
dev.
We
made
a
big
switch
from
our
previous
vagrant
based
approach
to
using
mini
shift.
Mini
shift
is
a
downstream
Fork
of
mini
cube
that
does
pretty
much
everything
that
mini
cube.
A
Does
a
few
small
variations
to
start
an
open
chef
cluster
on
a
local
VM?
We're
doing
this
mostly
to
make
it
easier
to
get
access
to
local
development
environments
that
can
mimic
production.
The
VM
the
VM
is
an
important
part
of
that.
Not
everybody
runs
on
Linux,
unfortunately,
including
the
presentation
team
and
as
a
result,
when
they
don't,
they
need
an
environment
that
can
reproduce
production.
The
goal
of
kubernetes
is
to
give
you
in
a
local
environment
or
to
give
you
a
consistent
application
environment.
We
think
it's
fundamental,
that
you
have
a
consistent
development
environment.
A
All
the
way
from
your
laptop
to
the
cloud
skip
come
next
slides,
please,
one
more
there's
been
a
bunch
of
SDL
updates.
This
is
just
you
know:
continued
iteration
on
supported
versions
of
community
ecosystem
images
that
we
we
drive
through
the
Red
Hat
community
and
through
the
open
source
communities
in
Scent,
OS
and
fedora
next
slide.
Please
so
I
think
I
spent
most
of
my
time.
Talking
about
what
has
happened.
A
I
did
touch
on
some
of
the
things
we
want
to
see
our
big
themes
coming
up
in
three
six
and
in
subsequent
releases
the
service
integration
to
the
Service
Catalog,
a
partner
brought
this
up.
This
is
a
critical
effort.
If
you're
running
large
clusters
with
many
applications,
you
need
some
way
to
decouple
developers
from
the
sieze
they
want
to
own,
so
the
dependencies
they
either
shouldn't
own
or
don't
need
to
own.
A
I'll
come
to
that
in
a
minute
cluster
health
and
reliability,
everything
about
kubernetes
that
makes
it
unique,
I
think
from
the
Google
mindset
from
from
Borg.
It's
the
idea
of
feedback
loops.
Your
applications
are
an
environment
that
changes
they're
affected
by
external
conditions.
They
change
over
time.
They
change
during
the
day
and
the
more
feedback
loops.
The
more
ways
that
we
can
take.
The
current
state
feed
it
back
into
how
the
platform
runs
means
that
that's
less
maintenance
that
operators
have
to
do
so.
A
The
basic
ideas
of
a
replica
set
that
if
a
node
goes
away,
you
bring
back
a
new
copy
of
a
pod
or
nodes
getting
evacuated
when
they
stop
checking
in
or
pod
health
and
pod
readiness,
where
the
pods
themselves
are
poured
up,
whether
they're
successful.
We
want
to
take
more
of
that
through
resource
metrics
over
time
and
finally,
multi
cluster
management
is
also
very
important
to
us
if
you
can
skip
ahead.
So
the
sorry
next
slide,
the
Service
Catalog
will
be
an
easy
way
through
the
Service
Catalog
work,
that's
happening
in
kubernetes
if
I,
don't.
A
If
you
have
questions
about
this
afterwards
and
the
person
you
should
speak
to
is
in
the
back
of
the
room,
he's
got
a
pink
mohawk
he's
really
hard
to
miss.
Paul's
help
drive
this
in
the
kerbin
ADEs
community
and
we're
incredibly
excited
about
what
it
means.
You
register
things
in
a
catalog
back-end
brokers,
which
is
part
of
the
open
service
broker.
A
Api
was
donated
by
Cloud
Foundry
to
an
open
foundation
and
we're
working
with
or
it's
sorry,
it's
part
of
an
open
foundation
and
we're
working
with
them
to
bring
that
to
cooper
Nettie's
each
of
those
services
is
provisioned
on
the
backend
can
be
on
cluster
off.
Cluster
can
be
something
in
the
cloud
could
be
an
account
service
could
be
an
accountant
database.
The
goal
is
to
make
it
easy
for
operators
to
do
as
a
service
as
a
service.
A
If
you
think
about
the
kinds
of
challenges
you
have
in
your
organization's,
you
have
two
C's
for
spinning
up
in
provisioning
machines.
We
think
of
service
catalog
and
service
broker
as
a
way
of
standardizing
the
processes
of
how
you
make
things
available
to
your
end,
applications
how
you
separate
control
from
the
administrator
to
the
end
user.
Next
slide.
A
We've
got
a
lot
of
new
UI
work
coming
in
three
six
as
part
of
the
Service
Catalog
there's
just
a
couple
small
sneak
peeks.
You
can
see
this
an
open
shift
master
if
you
downloaded
you're
on
OC
cluster
up
on
the
latest
version.
You'll
be
able
to
see
this
so
I'll.
Leave
that
as
an
exercise
to
the
reader
next
slide,
security
is
really
fundamental.
There's
been
a
lot
of
talk
recently
about
improved
ways
of
managing
secrets
on
the
platform.
Some
of
the
things
that
are
being
discussed,
that'll
be
done
in
kubernetes
in
an
open
shift.
A
There's
a
lot
of
desire
to
encrypt
secrets
at
rest.
When
they're
stored
a
net
CD,
we
want
to
do
more
to
subdivide
who
can
access
secrets,
so
a
secret
can
declare
you
know,
finding
ways
of
ensuring
that
secrets
can
declare
who
they're
used
for
and
then
having
that
be
strongly
authorized
by
the
platform.
A
secret
that
you
want
to
use
to
pull
images
for
import
is
different
than
a
secret.
A
You
want
a
pod
to
be
able
to
access,
which
is
different
than
a
secret
that
you
want
to
expose
to
a
router
to
serve
as
an
end
certificate
for
your
public
website.
We
want
to
make
also
want
to
make
external
secret
integration.
This
will
happen
over
several
releases.
This
is
a
journey,
not
a
destination,
and
what
we
wanted
to
do
is
make
secret
management
as
easy
and
as
part
of
the
platform
as
possible,
because
that
ensures
that
you
can
bring
together
and
standardize
how
you
deal
with
secrets
as
an
organization.
A
Even
if
you
use
external
stores
for
secrets,
we
still
want
to
make
that
flow
from
where
the
secrets
are
stored
to
where
the
secrets
are
is
used
as
comprehensive
as
possible.
Next
slide,
secure
by
default
partner
referenced
are
back,
we're
gonna
start
turning
this
on
we're
going
to
encourage,
integrations
and
things
in
the
community
to
actually
use
and
run
with
security,
because,
obviously,
if
you
develop
an
application
and
you
give
no
thought
to
security,
you
end
up
with
a
problem
later
on
and
so
out
of
the
box
and
the
kubernetes
community.
A
We
think
it's
really
critical
that
people
take
the
security
of
their
containers
into
account
from
day
one,
not
everybody
needs
to
run.
Software
downloaded
off
the
internet
is
route.
It's
just
an
idea.
Next
slide
a
lot
of
work
in
cluster
reliability,
things
that
will
come
over
the
next
couple
of
releases
when
nodes
run
out
of
resources
and
the
resources
that
pods
are
actually
using
surfacing
got
up,
ensuring
that
it
can't
interfere
with
other
applications.
A
A
more
active
management
of
the
containers
on
the
cluster
if
a
set
of
applications
are
overloading
one
particular
node,
we'd
like
to
feed
that
loop
in
we'd
like
to
feed
that
back
up
at
a
loop
where
you
can
take
those
and
move
those
to
other
parts
of
the
cluster
if
necessary.
So
this
is
part
of
the
long-term
evolution
of
kubernetes
we're
getting
closer
and
closer,
and
one
of
these
days
we'll
get
there
next
size,
please
it
didn't
come
out
well.
So
this
was
a
nice
animated
diagram,
but
I
think
it
was
unfortunately
eaten
by
Windows.
A
Our
goal
really
is
we
think
about
Federation,
where
we
want
to
go.
It's
not
about
one
cluster.
It's
not
about
two
clusters:
it's
not
even
about
five
clusters.
At
the
end
of
the
day,
clusters
represent
a
security,
isolation
and
failure
boundary.
We
know
that
there's
different
ways:
people
use
clusters.
You
know
most
of
the
large
openshift
customers
were
aware
of
in
production,
typically
have
two
data
centers.
A
They
don't
have
three
and
have
one
they
have
two,
and
so
what
we
need
to
do
is
build
models
that
enable
Federation,
in
the
kubernetes
sense
to
work
well,
applications
that
are
spread
across
multiple
clusters.
We
also
need
a
good
security
model
because
the
idea
of
a
federated
cluster
that
controls
two
full
clusters
means
you
now
have
a
new
super
root
that
can
control
both
of
those
clusters
and
very
details.
We'd
actually
like
to
invert
that
model
we'd
like
to
say
we
don't
actually
have
to
trust
Federation.
A
A
Federation
is
just
another
client
at
the
platform.
But
ultimately,
when
you
start
talking
about
more
and
more
clusters,
we
believe
that
there
really
does
exist
in
need
for
a
central
pane
of
glass
for
end-users,
who
want
a
self-service
on
the
platform.
If
I
want
to
see
a
list
of
projects,
I
don't
want
to
just
see
a
list
of
projects
that
I
have
in
one
cluster
right.
I,
don't
want
to
go
to
us
east
one
in
u.s..
These
two
and
u.s.
A
sees
three
and
US
East
four
and
APEC
one
and
a
pack,
two
I,
don't
have
to
go
through
a
list
of
things
to
find
where
all
my
applications
are.
The
the
promise
really
of
this
centralized
application
platform
is
a
place
where
you
can
go
to
see
where
all
of
your
applications
live.
You
can
create
security,
boundaries
that
span
geographies
regions
clusters
and
you
can
build
applications
that
when
they
want
to
deliver
to
a
specific
environment,
you
can
do
so
and
get
that
high
availability
and
reliability.
A
So
over
time,
we'll
we'd
like
to
introduce
new
higher-level
concepts
that
take
top
level
users,
projects
policy
and
quota,
push
them
down
into
clusters
and
ensure
you
can
build
and
sustain
models
where
you
have
many
different
ways
of
delivering
application
to
many
different
clusters
and
with
that
I
have
run
out
of
time.
As
I
said,
I
could
only
get
to
a
few
things
if
you
have
other
questions,
please
come
find
me
I'm
happy
to
talk
at
length
about
any
of
this,
and
thank
you
for
coming.