►
Description
Guest Speakers: Josh Berkus and Stephen Augustus (Red Hat)
Kubernetes 1.11: In-Cluster Load Balancing and CoreDNS Plugin Graduate to General Availability
This release continues to advance maturity, scalability, and flexibility of Kubernetes, marking significant progress on features that the team has been hard at work on over the last year. This newest version graduates key features in networking, opens up two major features from SIG-API Machinery and SIG-Node for beta testing, and continues to enhance storage features that have been a focal point of the past two releases. The features in this release make it increasingly possible to plug any infrastructure, cloud or on-premise, into the Kubernetes system.
Notable additions in this release include two highly-anticipated features graduating to general availability: IPVS-based In-Cluster Load Balancing and CoreDNS as a cluster DNS add-on option, which means increased scalability and flexibility for production applications.
A
Hello,
everybody
and
welcome
to
yet
another
open
ship
Commons
briefing
this
time
we're
getting
an
update
on
kubernetes
1.1,
one
or
one
point
11,
depending
on
how
you
want
to
talk
about
it
from
Josh
burkas
and
Stephen
augustus,
both
Red
Hatters,
who
have
very
specific
roles
with
a
one
point:
11
release,
so
let
them
introduce
themselves
and
get
us
rocking
and
rolling
here.
We're
gonna
have
questions
in
the
chat
if
they're,
really
good
ones
will
interrupt,
if
otherwise,
we'll
save
them
all
for
the
Q&A
at
the
end,
all
right!
So,
let's
get
going
great.
B
Thanks
a
lot
Dan,
so
I'm
Josh
burkas
I'm,
the
kubernetes
community
manager
for
Red
Hat
first,
which
is
every
one
of
the
companies
that's
heavily
invested
in
kubernetes,
assigns
one
or
more
people
to
be
community
managers
because
as
a
project
with
over
a
thousand
contributors,
we
actually
kind
of
need
our
own
administration,
and
we
have
that.
But
it
takes
people.
The
other.
You
know
relevant
thing
to
111
was
I.
B
Was
the
release
lead
for
kubernetes
1.11
and
the
way
that
works
is
members
of
cig
release
volunteer
on
a
quarterly
basis,
because
we
do
one
release
quarter
to
be
to
fill
various
roles
on
the
release
team
and
that
rotates
every
quarter
to
avoid
having
people
burnout
and
also
because
it's
a
good
way
to
train
people
up
and
so
I
spent
a
couple
releases
as
bug
triage,
lead
and
then
moved
up
to
release
Lee.
Then
now
I'm,
taking
a
quarter
off
the
release
date
Steven.
C
Hey
Steven
I
guess
this
year,
I
am
a
specialist
Solutions
Architect
for
the
openshift
Tiger
team
at
Red
Hat,
my
community
roles,
so
I
was
working
with
Josh
on
the
111
release
team
as
the
features
shadow
I
I
am
actually
the
features
lead
for
uber
Nettie's
112.
In
addition
to
that,
I
I
run
one
of
the
chairs
for
seizure
and
I
am
a
product
management
chair
for
6:00
p.m.
B
And
some
other
what
you're,
seeing
there
on
the
title
slide
is
one
of
the
things
that
we
do
in
the
release
team.
Is
it's
customary
for
the
release
lead
to
pick
a
cute
theme
for
the
release
that
really
gets
used
only
internally
at
the
release
team,
so
for
with
the
110
release,
that
theme
was
left
shark
for
the
111
release.
I
couldn't
pass
up
the
number
and
it
gave
the
theme
a
long
anticipated
release,
as
in
a
reference
to
the
Hobbit
per
the
drawing
on
the
screen.
B
Yeah
the
so
actually
this
is
a
little
bit
out
of
date.
I
prepared
these
slides
earlier,
we
did
actually
release
on
June
27th.
The
release
was
delayed
one
day
by
having
some
indeterminate
test
results
on
our
test
board,
and
we
just
wanted
to
give
it
an
extra
day
to
make
sure
that
the
tests
were
going
to
pass,
because
we
have
a
lot
of
important
in
to
end
in
performance
tests
that
can
take
half
a
day
to
run
one.
B
B
You
know
with
the
in
the
day
the
release,
certainly
we
discovered
the
day
before
the
release,
but
we
decided
not
to
hold
it
up,
and
that
was
the
inability
to
restrict
users
from
prioritizing
their
tasks
as
system
asks,
which
is
kind
of
a
problem.
If
you
have
badly
behaved
users
and
in
one
11.1,
you
have
an
ability
to
do
that.
B
B
What's
this
guy
I
think
it
was
cadenas
great,
though,
for
those
of
you
who
actually
have
not
used
openshift,
actively
or
kubernetes
before
one
of
the
things
that
you
have
to
provide
inside
a
container
cluster
is
directory
services
right?
You
have
to
know
where
your
various
services
are,
and
you
have
to
be
able
to
redefine
that
dynamically
as
you
move
containers
around
the
cluster,
so
DNS
is
kind
of
a
critical
part.
B
Now
this
has
always
been
pluggable
via
in
API
within
kubernetes,
but
for
that
matter,
we've
always
had
a
default
one
that
we
recommend
and
that
a
lot
of
the
kubernetes
installers
installed
by
default.
Now,
for
the
last
three
or
four
releases,
that
default
has
been
coop,
DNS
particular
you
know
open
source
DNS
thing
built
for
kubernetes.
B
We
are
now
I
we're
not
switching
the
default
yet,
but
as
part
of
the
plan
of
switching
the
default
core
DNS,
which
is
a
smaller,
lighter,
simpler
but
still
completely
dynamically
configurable
DNS
server
written
and
go
I
has
now
graduated
the
thing
to
wear.
It's
installable
as
your
dns,
just
by
a
small
configuration
change
in
most
of
the
installers
and
one
of
the
installers
that
is
qu
bad
men
bought
installs
it
by
default
at
any
new
cluster,
although
not
on
an
upgraded
cluster.
C
B
By
the
way
for
anybody
hasn't
played
with
it,
one
of
the
things
that
happened
after
we,
this
became
a
feature
of
the
features
board,
was
I,
checked
out.
Core
DNS
I
actually
run
a
DNS.
You
know
server
on
my
laptop
know
that
I
can
fake
out
things
for
demos,
etc.
I
and
control.
Other
hardware
in
my
office
and
I
actually
switched
that
to
core
DNS
because
it
it
really
is
very
nice
and
you
can
get
a
working
DNS
server
in
a
little
tiny
configuration
file
with
like
five
lines
of
JSON,
so
check
it
out.
B
Yeah
you
like
monkeying
with
network
stuff,
the
second
one.
This
is
actually
honestly
the
feature
that
I
personally
am
the
most
excited
about
from
111
everybody
has
their
favorite
feature
or
whatever
I
so
I
do
a
lot
of
bare
metal
stuff,
because
I
have
a
long
history
of
you
know
in
in
the
pretty
cloud
days,
and
then
for
that
matter,
one
of
my
things
is
databases
on
top
of
kubernetes
and
openshift,
and
that
often
means
bare
metal
environments.
B
Or
the
the
you
know,
memory
allocation
for
machine,
or
things
like
that.
If
you
wanted
to
change
one
of
those,
the
only
way
to
do
it
was
to
actually
restart
the
couplet
on
the
server
with
separate
configuration
flag
with
different
flags
start
up
flags,
and
this
had
to
had
two
really
annoying
issues
with
it
number
one
is,
or
even
a
fairly
minor
configuration.
It's
like
like,
for
example,
you
want
to
increase
the
maximum
number
of
pods
per
machine
because
you
realize
you're
not
actually
using
all
your
system
resources.
B
That
means
that
you're
having
a
rolling
you're
having
a
rolling
blackout
on
your
cluster
in
order
to
do
that,
and
when
you
do
that
Cooper
days
is
gonna
shift
a
whole
bunch
of
the
pods
run,
it's
going
to
shift
them
back,
and
so
you
have
a
lot
of
service
degradation.
Well,
that's
happening.
Second
issue
is
that
on
a
lot
of
Linux
systems?
That
means
that
you
are
then
modifying
the
system.
B
One
is
some
configuration
things
like
maximum
pods
per
server
can
be
changed
dynamically
on
the
fly
well
with
the
cubelet
running
and
the
way
that
you
actually
do,
that
is,
there's
actually
a
config
map
for
the
nodes
and
for
each
node
and
you
can
actually
modify
settings
and
that
config
map
and
it's
a
strolling
delay.
The
couplet
will
pick
this
up,
which
means
that
you
can
make
some
setting
changes
without
ever
leaving
the
kubernetes
system
or
openshift
system
once
openshift
raps.
B
This
feature
the
and-
and
the
second
thing
is:
we've
moved
the
kuba
configuration
to
an
actual
configuration
file
instead
of
using
startup
Flags
and
so
for
people
who
are
managing
their
couplets
via
puppet
or
ansible,
or
something
else
I'm.
Having
that
separate
configuration
file
actually
makes
it
easier
to
manage.
C
B
Yes,
yeah
I
mean
I
played
with
it.
I
mean
the
truth
is
that
my
bare
metal
clusters
are
all
for
testing
purposes.
So
I
haven't
had
that
many
reasons
to
tinker
with
that.
Although,
if
I
get
serious
about
the
performance
testing
that
I'm
doing
I
will
have
reasons
to
use
that
feature
a
lot
more
and
that
says,
I've
wanted
to
complete
a
set
of
performances,
I've
started
where
I'm
testing
running
a
database
benchmark
on
top
of
kubernetes
with
various
configurations
of
storage
and
that's
the
answer.
B
The
question
people
like
cuz,
like
I,
talked
to
a
lot
of
database
people
because
of
my
history,
yeah
and
one
of
the
questions
they
say
is
they
say
look
we
can
accept
that
running
our
database
and
kubernetes
will
result
in
an
increased
latency
and
maybe
some
limitations
on
throughput,
that's
okay.
We
need
to
know
exactly
how
much,
though,
when
you
know
how
much
does
it
increase
latency
right
we're?
B
What
is
the
throughput
limit
if
any,
and
so
I
want
to
put
some
numbers
behind
that,
and
so
I've
actually
started
doing
some
testing
on
the
ideas
to
test
just
database
on
bare
metal
which
I
already
have
for
that
those
numbers
and
then
to
test
kubernetes
with
local
storage
and
then
kubernetes
with
various
forms
of
clustered
storage,
so
Gloucester
something
rook
based,
etc.
So
that
I
can
actually
get
an
idea
of
what
those
numbers
look
like
and
then.
B
C
B
C
Sure
why
don't
have
two
guys
fun
so,
with
kubernetes
111,
we
see
improvements
to
see
our
DS,
which
you
know
for
for,
for
those
of
you
who
are
aware,
it's
a
customer
resource
definitions
which
used
to
be
third-party
resources
or
TP
RS.
So
extending
what
we've
done
here
is
a
we've
extended
the
functionality
of
of
the
CRD
api,
one
to
include
versioning
and
and
secondarily
to
be
able
to
actually
track
sub
resources
right.
C
C
What
happens?
What
happens
there
is,
as
we
move
through
different
versions
of
kubernetes,
the
api's
may
change.
What
you'd
like
to
be
able
to
do
is
have
a
Cooper,
Nettie's
native
way
of
of
expressing
what
your
app
does
right,
though
versioning
the
same
way,
the
you
know,
v
1,
v,
1,
alpha
1,
V,
1,
beta
beta.
So
following
that
data,
you
know
that
ability
to
version
the
same
way
kubernetes
does
allows
us
some
some
niceties
and
in
planning
around
planning
around
building
or
you're
out
your
API,
so
on
on
the
on
the
sub
resource
side.
C
The
reason
that
having
the
functionality
to
manipulate
some
resources
as
opposed
to
top-level
CR
DS,
is
several
several
applica.
We'll
take
things
like
we'll
watch
things
like
status,
so
there's
a
there's
a
status
endpoint
as
well
as
a
scaling
endpoint.
So
when
you're
building
out
your
application,
you
want
to
be
able
to
you
know
certain
applications,
don't
need
the
the
same
level
of
access
to
a
CRD
right.
If
you
provide
access
to
the
top-level
CRD
you
you
start
to
introduce
these
security
implications
right.
C
So,
if
I,
you
know,
if
my
application
is
able
to
manipulate
a
CRT
in
a
certain
way,
is
that
is
that
dangerous
to
cluster
overall?
Is
that
dangerous
to
the
namespace
right
so
being
able
to
to
watch
watch
these
SEP
resources
instead?
So
you
know
just
maybe
I
have
an
application
that
just
needs
to
query
the
status
of
the
CRT
as
opposed
to
manipulate
the
entire
CRT
right,
so
so
bringing
that
functionality
and
is
really
really
crucial.
C
The
reason
that
I'm
pretty
excited
about
CRT
is
is
being
a
you
know,
being
a
former
core
OS
field
engineer,
you
know
the
all
of
the
work
around
building
operators,
as
well
as
the
operator
framework.
We
start
to
see.
We
start
to
see
more
and
more
of
that
ability
for
people
to
really
manipulate
manipulate
clusters
and
and
build
applications
for
kubernetes,
and
you
know,
and
and
building
around
that
operator
pattern
we
need
more
and
more
functionality
and
and
and
providing
you
know,
being
able
to
provide
means
to
build
applications
in
a
safe
manner.
C
B
Yes,
I
mean
to
be
clear
because
I'm
sure
if
people
have
been
following
the
open
ship
briefings,
you've
heard
a
lot
about
operators
and
so
most
operators
rap
EC
Rd
as
part
of
their
functionality.
So
you
know
if
your
is
talking
about
series
it's.
This
is
in
a
critical
piece
of
what
makes
operators
work.
Thank.
A
B
So
one
of
the
other
ones-
and
this
one
has
been
very
important-
I
know
to
the
open
fifteen
because
of
the
need
for
Enterprise
production
workloads
to
have
this
functionality
is
priority
and
preemption,
and
so
priority
is
the
ability
to
give
odds
in
jobs
in
the
case
of
like
cron
jobs,
different
priorities
in
terms
of
how
important
it
is
to
run
them,
and
then
preemption
is
the
ability
to
say
hey.
This
is
a
really
high
priority.
B
But
you
want
to
get
bumped
off
of
the
cluster
whenever
there's
not
spare
capacity,
you
may
need
to
run
a
debug
or
a
diagnostic
tool
when
the
cluster
is
overloaded,
specifically
to
find
out
why
the
cluster
is
overloaded,
and
if
the
cluster
is
overloaded,
because
one
of
your
micro
service
pods
is
performing
very
badly,
you
want
to
be
able
to
prioritize
the
new
replacement
pod
so
that
it
will
bump
the
old
ones.
Even
though
the
cluster
does
not
have
any.
You
know
spare
resource
capacity,
then
there's
a
number
of
other
things.
C
B
C
B
B
C
C
So
the
classically
kerbin
at
ease,
so
the
the
service,
the
service
resource
and
kubernetes
by
default,
uses
uses
a
set
of
IP
tables
rules
and
netfilter.
So
what
you
see
in
in
clusters,
with
a
large
amount
of
services,
a
large
amount
of
pods
across
multiple
nodes,
essentially
what's
happening
every
time
you
you
build
a
service
is
I'm.
I'm.
Writing.
C
You
know
that
service
is,
is
a
proxy
to
a
set
of
pods
right,
so
I'm
writing
a
set
of
IP
tables
rules
that
says
hey
if
you're
looking
for
service
food,
these
pods
are
the
ones
that
hold
service
right.
So,
as
we
start
to
see
more
services
into
the
cluster
as
well
as
as
well
as
more
nodes,
those
iptables
rules
get
longer
and
longer
and
longer
and
they're.
There
hasn't
really
been
an
efficient
way
to
scale
that
right,
so
the
secondary
option
for
for
using
services
and
kubernetes
is
to
implement
via
IP
PS.
C
So
as
Josh
was
saying,
IPPs
is
in
kernel
in
kernel
networking
it's
built
essentially
using
essentially
using
a
hash
map
instead
of
a
table.
So
what
that
allows
for
is
quicker
lookups
of
these
rules
right.
So
you
have
one
it's
happening
in
kernel:
we
have
faster
lookups
and
it's
and
it's
much
more
lightweight
than
building
a
set
of
IP
tables
rules.
So
what
we'll
start
to
see
is
people
switching
over
to
this
rather
quickly
I
believe
we're.
We
were
planning
to
do
this
and
I
want
to
say
311.
B
Yes,
it's
nice
I
mean
that's
definitely
nice
again
for
bare-metal
eeks
like
me,
because
you
know
mostly
for
bare
mental
setups.
I've
been
kind
of
subsisting
on
just
using
round-robin
E
and
for
all
the
services
and
everything
and
with
IP
vs
I
have
the
option
of
doing
more
sophisticated
load
balancing.
B
When
you
look
at
like
having
OpenShift
host
a
database
where
you
may
have,
you
may
want
to
do
more
sophisticated
things
with
your
load,
balancing
like,
for
example,
you
might
have
a
right
connection
that
goes
only
to
the
master
and
a
reconnection
that
gets
load
balanced
among
replicas
and
ideally
only
replicas
and
with
the
service
round-robin.
You
don't
have
the
ability
to
be
that
specific.
C
And
around
around
stateful
applications,
so
one
of
the
options
for
for
IP,
vs
I.
Believe
it
is
you
don't
you
you
have.
The
ability
to
like,
like
Josh,
was
saying:
I
have
more
sophisticated
routing
techniques
right,
so,
in
addition
to
round
round-robin
you've
got
things
like
these
connection.
You
know
something
for
a
saiful
app
that
might
be
super
important.
Is
you
know
being
able
to
have
a
sticky
connection
to
the
database
right,
so
both
will
start
to
see
that
that
come
into
play?
C
B
B
C
Just
a
call
out
to
stick
a
sure
I'll
do
what
what
we've
seen
is
a
lots
of
improvements
around
the
azure
support,
one
in
in
cluster,
auto
scaling
as
well
as
VM
scale
sets
right.
So
one
of
the
big
features
of
you
know
having
a
kubernetes
cluster
is
that
you
get
to
consider
these.
You
know
these
commodity
nodes
is
homogenous.
You
know
homogeneous
that
of
of
nodes,
so
classically
in
environments
like
AWS,
let's
say
right,
you
might
spin
up
in
an
auto
scaling
group,
and
that
would
be
you
know.
C
So
what
we
had
before
on
the
Azure
support
side
in
kubernetes
was
support
for
availability
sets,
which
means
you
have
to
essentially
configure
each
of
your
nodes
in
a
certain
way,
so
that
you
know
it's
able
to
it's
able
to
pick
up
the
couplet
and
and
and
join
the
cluster
as
opposed
to
being
able
to
declaratively
define
what
your
nodes
should.
Look
like
in
a
template
and
and
being
able
to
spin
up
notes
based
on
that
and
and
obviously
having
the
niceties
of
being
able
to
scale
up
and
scale
down.
A
B
C
C
C
B
C
B
C
Yeah
coming
back
the
the
AWS
network
load
balancing
this
is
it's
pretty
cool
but
yeah,
jealous
bootstrapping
that
that
was
a
problem
that
we
were.
You
know
we
were
pounding
at
at
at
core
OS.
Definitely
at
Red
Hat,
so
to
see
some
of
that
start
to
coalesce.
So
around
gala
food
shopping
as
well.
As
you
know,
certificate
rotation,
I.
Believe
that's
going
to
be
a
separate
feature.
That's
already
in
progress.
Yeah.
B
And
node
level
user
namespace
remapping
is
part
of
our
path
to
that.
One
of
the
things
that
open
TIFF
requires
is
that
you
can't
run
in
your
container
as
the
root
user
in
the
container,
because
right
there's,
a
number
of
security
exploits
that
are
possible
if
you
are,
and
but
the
drawback
about
this
is
that
you
end
up
having
to
redefine.
B
If
you
pick
up
a
container
that
was
designed
for
a
different
environment
like
docker,
you
end
up
having
to
read
to
find
it
for
OpenShift,
and
if
the
container
contents
need
to
run
is
a
specific
non-root
users
opposed
to
a
random
non
root
user.
You
have
to
take
even
more
extra
steps
and
so
user
name.
Space
remapping
is
actually
the
fix
for
that.
C
So
yeah
so
around
feature
wise,
we're
gonna,
see
more
improvements
in
storage,
so
the
CSI
container
storage
interface
will
will
kind
of
get
buffed
up.
There
are
a
few
I
mean
this
is
this
has
been
happening
across
the
I
say
the
last
three
releases
or
so,
and
it'll
continue
forward,
probably
to
I,
want
to
say
114,
so
improvements
around
around
CSI
being
able
to
do
things
like
having
topology
is
support,
so
you
know,
building
in
the
constructs
of
you
know,
am
I
in
a
certain
region
am
I
in
a
certain
zone.
C
So
there
are
their
tandem
proposals
for
essentially
figuring
out
Paula,
G
and
and
how
to
approach
that
we
on
the
outer
side,
we
recently
merged
a
cap
which
is
a
curvy
Nettie's
enhancement
proposal
for
building
support
for
aperture
availability
zones
right
so
again
same
constructs
in
AWS,
you've
got
regions,
you've
got
zones
across
the
zones.
The
zones
are
essentially
different
data
centers
within
the
same
region,
right
so
having
the
ability
dates.
C
You
understand
where
your,
where
nodes
in
your
cluster
actually
live
across
a
you
know,
say
you
don't
want
a
node
in
you
know
in
zone
one
trying
to
trying
to
claim
storage.
You
know
that
lives
in
zone
2,
right,
he's,
got,
you've
got
latency
concerns
there
and
you
it's
it's
an
overall
application
performance
issue
right.
C
Interesting,
so
we
were
talking
about
core
DNS
will
seek
or
DNS
moved
to
G,
not
rather
sorry
Raj,
but
will
see
it
move
to
the
default
in
in
kubernetes
112.
Hopefully,
fingers
crossed
I
think
everything
should
be
fine.
The
new
beta,
you
know,
the
cube
ATM
guys
are
gonna,
be
doing
a
lot
of
work
around
testing
that
out
by
switching
it
to
default.
So
you
know
thank
thank
you
for
for
jumping
ahead
and
you
know
and
making
sure
that's
good
for
the
community.
I.
C
B
C
To
get
just
a
little
bit
more
feedback
from
the
people
who
own
the
future,
it's
an
ensure
that
it's
actually
going
to
be
part
of
the
milestones.
So
you
know
features
is,
as
a
you
know,
part
part.
Data
entry,
part
cat
herding,
part
a
part
pinging
on
features,
so
yeah
we're
just
waiting
to
get
feedback
around
around.
What's
going
to
happen
before
we
actually
mark
that,
as
tracked
and
kind
of
maintains
a
sheet
across
the
release,
yeah.
B
And
and
I
you
know
for
realism,
historically,
for
what
we've
had
in
tracked
features
for
an
individual
release.
By
the
time
we
here,
beta,
usually
30
to
40%
of
these,
have
been
postponed
to
the
following
willies
because
of
whatever
issue
they
ran
into
that
they
didn't
expect,
and
we
tend
to
get
three
to
four
additional
features.
C
C
Yes,
yes,
so
just
a
note
around
for
the
viewers
at
home
a
note
around
features
that
kind
of
meet
meet
that
mark.
That
Josh
was
mentioning.
We
actually
have
a
features
exception
process,
that's
where
the
where
the
owner
of
a
future
will
have
to
file
an
exception.
Let
us
know
the
amount
of
time.
You
know
that
it's
going
to
take
to
include
that
feature
in
the
release
and
and
why
we
think
that
and
why
they
think
it
should
be
included
in
the
release
all
right.
A
C
B
B
B
C
Yeah,
the
25th
yeah,
so
I
mean
the
first
month
or
so,
which
is
which
is
what's
happening
right
now,
we'll
see,
essentially
it's
the
features,
collection
process
right
so
that
I
I
tend
to
be
a
lot
busier
during
the
first,
the
first
third
or
so
of
the
of
the
cycle
and
my
my
role
tapers
off
a
little
bit
a
little
bit.
Maintenance
note,
following
up
on
following
up
on
things
that
have
slipped
towards
the
end
of
the
release
cycle.
So
what
we're
doing
right
now
is
its
features
collection.
C
B
C
Yeah
yeah,
so
what
that
will
allow
you
to
see
if,
for
anyone,
who's
curious
is
all
of
the
features
that
are
tracked
for
essentially
slated
for
for
112.
Are
you
know
in
insert
milestone
here
so
yeah?
Well,
everyone
who
submits
a
feature
to
this
repo
expected
to
have
a
requisite
amount
of
data
included,
including
you
know
whether
or
not
there
are
Doc's
or
tests
where
the
proposal
lives.
What's
the
expected
timeline,
moving
through
different
stages,
and
also
you
can
see
these?
Are
these
brown
labels
for
the
the
SIG's
that
own
each
of
the
features?
Oh.
B
A
That's
really
a
lot
of
the
information
is
really
very,
very
accessible.
You
just
need
to
know
where
to
find
it
and
I
think
that's
what's
really
helpful
about
the
conversation
you
guys
are
guiding
us
through
today
and
it'll
help
us
with
some
of
the
future
releases
too,
and
when
we
watch
and
try
and
see
when
they're
going
to
show
up
in
kubernetes
how
they
get
therapists
and
and
released
into
vanadis
and
then
watching
them
in
an
open
ship
or
the
open
ship
release
cycles
too.
A
A
So
this
has
been
really
very
interesting,
I
think
to
see
how
this,
how
this
all
works,
and
hopefully
we
can
get
you
guys
back
in
write,
each
each
ensuing,
release
and
work
it
out
and
I
think
this
would
be
a
really
great
reoccurring
topic
to
have
neutrality.
So,
thank
you
very
much
for
bearing
with
us
if
you've
been
listening
since
the
beginning
and
I
will
make
a
few
edits
to
the
video
for
continuity.
A
Shall
we
say
and
make
it
available
on
on
our
YouTube
channel
as
usual
and
as
a
blog
post,
with
an
embedded
video
on
blog
that
open
ship
comm
later
today,
or
maybe
Mauri.
But
I
this
is
an
invitation
to
Josh
and
and
that
one
of
the
things
that
I've
really
wanted
to
do
is
is
to
ask
the
different,
not
just
red,
hat
or
kubernetes.
Big
leads
just
to
have
maybe
a
reoccurring
and
different
sig.
The
top.
Do
that
open
ship
Commons
on
some
sort
of
reoccurring
basis
on
Fridays.
You
know.
A
That
Red
Hat
is
doing
this
because
red
asked
putting
a
ton
of
the
engineers
who
used
to
plus
more
work
on
open
shift
are
now
actually
working
directly
on
kubernetes
such
as
yourselves
and
a
myriad
of
other
people
and
and
and
then
really.
This
is
an
open
ship
is
a
district
distribution
of
kubernetes
and
it
is
a
huge
collaborative
effort.
So
I'd
love
to
showcase
some
of
the
people
and
some
of
the
work
that's
going
on
in
the
SIG's
and
some
sort
of
regular
format.