►
From YouTube: This Week in Cloud Native
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
well,
we're
hey
everybody!
Welcome
to
this
week
in
cloud
native.
This
is
episode
number
five
good
to
see
you
good
to
see
you,
I'm
saying
hello
to
somebody
who's
coming
to
say
hello,
good,
to
see
you
darkseid
darkside21.
Awesome!
Welcome!
Welcome
all
right!
So,
if
you're
in
the
chat-
and
you
want
to
say
hi-
just
drop
a
note
into
the
chat
over
into
the
chat-
and
I
can
highlight
it,
ask
your
questions
anything
else
like
that.
Just
let
me
know
I'm
happy
to
to
bring
you
to
raise
you
up
in
this
way.
A
If
you
are
here
for
the
first
time,
one
of
the
most
important
things
to
understand
is
that
I
keep
a
weekly
notes
document.
This
is
a
a
carryover
from
something
I
did
in
tgik
this,
which
was
thank
goodness,
it's
kubernetes
and
so
that
I've
created
for
that
I've
created
a
team
account
and
let's
go
just,
go
ahead
and
check
that
out
real
quick.
A
Let
me
set
up
my
environment,
so
you
can
see
it
so
this
is
the
this
week
in
cloud
native.
If
you
go
to
hackmd,
twicn
you're
gonna
see
this
week's
notes,
along
with
along
with
any
previous
notes
that
came
earlier
in
the
session.
These
notes
are
editable
by
you.
If
you
sign
in
then
I
can
see
who's
actually
putting
content
up.
A
A
All
right,
so
so
that's!
This
is
where
I
keep
my
notes
and
everything
else
like
that.
Anybody
else
who
wants
to
say
hello,
go
ahead
and
say
hello
in
the
chat,
and
I
will
raise
you
up
hello
good
to
see
you
welcome
welcome.
So
this
will
be
an
interesting
session,
but
well
yeah,
let's
dig
into
it.
So,
as
you
know,
there's
a
ton
of
really
great
content
on
cloud
native
tv,
I'm
just
one
of
them.
It's
one
of
the
many
shows
there
are
playlists
for
each
of
the
content.
A
So
if
you,
if
you
missed
a
show-
or
you
want
to
make
sure
that
you
catch
a
show,
you
can
actually
go
check
out
the
playlist
and
all
of
the
all
of
our
sessions
are
captured
and
then
upstreamed
into
a
youtube.
Playlist,
so
you'll
be
able
to
see
them
later.
If
you
miss
them.
So
don't
worry
about
that.
There's
lots
of
content
that
happened.
There
was
actually
a
really
great
cncf
face-off
with
matt
stratton.
It
was
actually
I
came.
It
was
like
the
rogues
gallery
versus.
A
I
can't
remember
what
the
other
piece
of
it
was,
but
it
was
a
really
funny
show.
You
should
definitely
check
it
out.
It
was
really
a
kick
search.
Magic
with
siam
lgtm
with
rockcote
is
also
is
doing
opa,
and
I
think
that
spotlive
is
all
spotlight
is
also
doing
opa,
so
lots
of
opa
love
this
week.
If
you're
not
familiar
with
opa,
it
is
the
open
policy
agent.
So
there's
lots
going
on
there.
A
A
Perfect
there
we
go
so
if
you
want
to
go
out
of
our
notes,
you
can
see
here
in
the
bottom
left-hand
corner.
It
says
hackmd
dot
at
twicken.
That's
where
our
notes
are
located.
We
have
the
cloud
native
classroom
with
cat
costco
of
100
days
with
anais
and
fields
tested
with
caslin.
All
of
these
great
shows
definitely
go
check
them
out.
A
One
of
the
things
I
wanted
to
point
out
this
week.
There
was
a
lot
of
hubbub,
of
course,
on
twitter,
because
that's
what
hubbub
that's
what
twitter
is
for.
It
is
a
hubbub
factory,
there's
always
something
going
on
and
this
week
one
of
the
things
that
was
raised
up
was
the
api
removals
in
122
version
122..
A
Now
I
covered
this
in
116
as
well.
In
a
session
very
like
this,
where
we
caught,
we
talked
about
like
basically
how
to
identify
those
manifests
that
have
been
deprecated
and
things
like
that
and
I
figured
I
would
dedicate
this
episode
to
that
same
sort
of
a
a
piece
of
it
and
we're
gonna
get
into
that
here
in
just
a
little
bit.
A
But
if
you
want
to
jump
ahead
or
read
ahead,
you
can
always
jump
over
to
the
kubernetes
blog,
that's
blog.kh
io
and
the
first
one
here
is
a
really
well
written
and
well
thought
out,
post
from
krishna
khilari
at
amazon,
web
services
and
tim
bannister
at
the
scale
factory
writing
a
blog
post
on
kubernetes
api
and
feature
removals.
A
I
don't
know
if
it's
feature
removals
per
se,
but
like
api
api
removals
portions
of
the
api
that
are
being
removed
from
the
generally
available
api
inside
of
your
kubernetes
cluster,
when
you
deploy
version
1.22
and
we're
going
to
kind
of
play
with
that
and
see
what
that
looks
like
and
how
that
feels
during
this
episode.
But
if
you
want
to
read
ahead,
this
is
where
you
can
find
out
information,
so
the
version
122
release
will
stop
serving.
This
is
an
important
distinction.
Stop
serving
the
api
versions
that
we've
listed
below.
A
So
some
of
the
stuff
that's
been
removed
are
things
like
the
custom
resource
definition
in
this
particular
path
right
and
we're
going
to
play
with
this
a
little
bit
we're
going
to
get
hands
on
with
it.
So
if
this
is
confusing
to
you
at
this
point,
don't
worry
we're
going
to
get
more
into
detail.
I'm
going
to
show
you
just
exactly
what
this
means
to
you
in
your
cluster
during
this
episode.
That's
really
my
target
for
this
episode,
the
api
service,
the
token
review.
A
Subject:
access
review
certificate
of
signing
of
the
request
and
lease-
and
this
is
a
going
to
be
a
really
big
one.
This
is
probably
going
to
be
the
one
where
people
really
get
caught
out
is
ingress
is
no
longer
going
to
be
available
at
extension's,
v1,
beta
1
and
is
now
or
at
the
networking
k
I
o
v,
one
beta
one.
A
So
the
kubernetes
documentation
covers
these
api
removals
for
v2122
and
that's
actually
in
the
deprecation
guide,
which
is
a
really
great
one,
and
you
can
actually
see
when
things
are
removed
and
what
things
were
removed
at
what
versions.
So
if
you
want
to
understand
more
about
it,
the
docs
are
a
great
source
of
information,
looks
like
the
next
set
of
removals
are
going
to
happen
in
one
two
five,
but
that
is
some
of
the
content
that
we're
going
to
dig
into
this
week.
A
So
if
you
want
to
look
into
the
change
log
but
difference
between
what
happened
in
120
and
121,
this
is
always
a
good
thing.
I
I
try
to
spend
an
episode
on,
I'm
probably
not
going
to
do
that
in
this
episode,
but
right
now
this
I'm
just
reminding
folks.
This
is
actually
how
you
would
go
about
reading
the
release
notes
for
a
given
upcoming
release,
and
so,
if
you're,
if
you're,
looking
to
adopt
version
1.2.1
or
121.21
1.
A
This
is
where
you
will
actually
look
for
information,
and
it
has
a
lot
of
really
important
information,
some
of
the
major
themes
that
are
happening,
some
versions
of
customized
or
upgraded
from
version
203
to
version
405
people
who
have
used
cube
kettle
customized.
You
can
see
why
that's
an
important
one.
A
A
I
feel
like
this
is
a
repeated
every
every
release
of
kubernetes.
No,
you
really
must
read
this
before
you
upgrade,
so
this
says
information.
This
tells
us
information
that
is
important
to
us
if
we're
going
to
upgrade
from
a
previous
version
of
kubernetes
to
the
current
released
version
of
kubernetes.
So
definitely
read
this
stuff.
A
If
you
have,
if
that,
if
that's
you
or
if
that's
something
that
you're
going
to
be
working
on,
so
this
was
just
a
quick
reminder
of
where
to
go
and
find
information
regarding
upgrade
pads
and
release,
notes
for
kubernetes
clusters,
and
so
the
release
notes
for
122
haven't
been
cut
yet.
But
I
I
imagine
portions
and
pieces,
and
portions
of
them
are
already
in
there
and
we're
kind
of
getting
a
little
bit
of
a
preview
into
what
that
looks
like
here
from
the
deprecated
api
migration
guide,
all
right.
A
What
is
next
up
in
our
notes,
I
did
see
a
new
cbe
being
announced
and
the
way
that
I
track
this
stuff
is
I'm
actually
a
member
of
the
security
announce
group.
If
security
in
kubernetes
is
important
to
you,
I
recommend
that
you
become
a
member
of
the
security,
announce
group
right
and
if
you
click
on
over
here,
it's
a
google
group.
You
can
go
ahead
and
join
that
google
group
and
you'll
be
able
to
get
notified
when
things
when
things
interesting
and
security
wise
have
happened.
A
It
gets
into
the
details
and
I
really
like
how
cj
has
done
this
and
how
I'm
sure
that
many
members
of
the
c
security
are
responsible
on
this
one
as
well.
It
says
if
a
potential
attacker
can
create,
or
edit
endpoints
or
endpoint
slices,
and
that
means
that
you
have
the
ability
to
define
that
object
within
kubernetes.
A
Then
they
can
potentially
direct
a
load,
balancer
or
ingress
implementation
to
expose
back
and
dye
piece.
The
attacker
should
not
have
access
to
importantly.
If
the
target's
network
policy
already
trusts
the
load,
balancer
or
ingress
implementation,
network
policy
cannot
be
used
to
prevent
exposure
from
other
namespaces,
potentially
bypassing
any
security
controls
such
as
load
balancer
source
ranges.
This
issue
is
a
design
flaw
that
can
be
fully
made.
That
cannot
be
fully
mitigated
without
user
facing
changes.
A
With
this
public
announcement,
we
can
begin
the
conversations
about
a
long-term
fix,
so
if
this
I
mean,
if
you're,
making
use
of
load
balancer
ingress,
which
you
probably
are
in
your
production
clusters,
this
is
probably
something
to
be
aware
of,
and
to
and
be
aware
of
that
that
those
things
could
actually
be
changed.
A
A
And
there
was
an
additional
advisory.
A
similar
check
is
possible
using
the
ingress
implementations
to
support
forwarding
to
external
name
services,
which
are
one
of
the
valid
services
within
kubernetes.
This
can
be
used
to
forward
two
services
in
other
name
spaces
or
in
some
cases,
sensitive
endpoints
within
the
ingress
implementation,
so
really
good
update
from
the
from
sig
security
and,
if
you're
interested
in
understanding
more
about
this
vulnerability.
Put
this
here
and
one
of
the
things
they
always
add
here
at
the
kind
of
at
the
bottom.
A
Oh
is
actually
rob
scott
sent
on
behalf
of
the
kubernetes
product
security
committee,
so
awesome
stuff,
so
there's
a
link
to
the
github
issue.
If
you
want
to
know
more
about
it
or
if
you
want
to
follow
along
for
the
resolution
of
this
particular
cbe,
definitely
check
out
that
issue
and
you'll
be
able
to
see
those
things
so
pretty
cool
stuff.
A
So
this
was
the
twitter
thread
I
was
describing
earlier.
It
started
with
cat
cosgrove
putting
out
a
twitter
thread,
saying
you
need
to
pay
attention
to
the
release,
notes
for
kubernetes
version
122..
I
know
not.
I
know
nobody
likes
reading
release
notes,
but
you
gotta
and
in
this
version
multiple
beta
apis
will
be
removed,
not
deprecated
they've
already
been
deprecated
or
we
wouldn't
be
removing
them,
and
this
is
a-
and
this
is
a
removal
of
those
apis
from
serving
and
we're
going
to
play
with
that
during
this
session.
A
He
says
that
apis
go
away
in
1.22,
but
understands
that
existing
objects
created
with
old
apis
are
not,
and
what
that
means
is.
If
you're
in
version
1.21,
you
can
still
create
those
objects
using
those
those
same
versions
and
those
objects
will
then
be
inside
of
your
cluster's
database
inside
of
xcd
stored
as
objects,
and
when
you,
when
you
then
upgrade
that
cluster
to
version
1.22.
A
A
So
there
is
no
object
version
of
v1
beta
1
in
the
cluster
concept.
Objects
are
converted
on
the
fly,
and
that
means
that
there
is
an
abstraction
layer
in
the
api
server
that
is
responsible
for
defining
that
mapping
between
the
api
object
that
you
create
and
the
stored
object.
That
is
stored
inside
of
etcd,
and
this
is
going
to
be
one
of
the
fun
things
that
we
play
with
today.
We're
going
to
look
at
the
difference
there
and
see
how
that
works.
A
But
suffice
to
say
what
that
means
is
that,
as
we
change
api
versions
that
are
made
available
or
unavailable
within
the
kubernetes
api
server,
those
api
versions
are
not
generally
stored
as
an
object
within
etcd.
It's
actually
just
the
core
object
itself.
That's
stored
in
ncd
and
the
abstraction
that
the
kubernetes
api
server
provides
is
how
we
surface
those
objects
either
to
post
commit.
A
I
mean
vote
to
post,
to
posts
when
you're
going
to
be
creating
those
objects
or
whether
they
are
gets
or
reads
when
you're
actually
trying
to
get
or
update
those
objects.
That's
actually
how
that
bit
of
it's
going
to
work
right,
we're
not
in
a
situation,
necessarily
where
we
we
store
the
api
version.
That
was
that
it
was
that
it
was
created
under.
A
A
A
That
is
actually
incorrect.
You
have
to
touch
the
objects
to
convert
them
before
the
upgrade
and
the
kubo
storage
version.
Migrator
can
help,
read
the
release,
notes
and
there's
there's
going
to
be
documentation
on
how
to
do
that,
and
then
the
last
thing
that
stefan
calls
out
is
this
piece
here,
which
is
where
I'm
gonna
spend
the
most
of
the
time
in
playing
with
this
stuff,
because
I
feel
like
this
article
by
evan
cordell
who's
somebody
I
worked
with
at
core
os.
A
A
great
guy
really
gets
into
like
so
one
of
like
really
deserves
more
time
right,
because
I
feel,
like
this,
article
really
gets
into
just
like
some
of
the
internals
about
how
kubernetes
api
server
works
and
how
those
api
versions
actually
are
surfaced
and
manipulated.
A
When
you
do
a
cube
kettle,
get
or
a
cube,
get
all
apply,
or
those
sorts
of
things
when
you're,
when
you're
working
with
the
api
server
directly,
and
so
my
plan
today
is
to
kind
of
get
into
this.
This
is
gonna,
be
the
play
time.
We're
gonna
we're
gonna
walk
through
some
of
these
scenarios.
There's.
A
But
there
was
one
more
thing
I
had,
which
is
something
I
learned
and
I
wanted
to
play
with
you
and
I
wanted
to
share
this
with
you.
It
was
one
of
the
things
on
on
my
side
that
I
thought
was
actually
kind
of
interesting,
so
I'm
working
with
I
surveillant,
which
you
already
are
aware,
I'm
sure
and
I'm
working
as
their
field
cto
there,
and
so
I'm
having
a
great
time
at
I
surveillance
and
my
work.
A
Computer
is
a
linux
laptop,
and
this
is
generally
true
whenever
I'm
not
working
at
a
place
that
doesn't
allow
that.
But
right
now
I
have
a
linux
laptop,
and
one
of
my
goals
was
to
get
to
a
place
where
I
could
do
better
work
with
like
bpf
trace
and
those
sorts
of
things,
and
the
way
that
bpf
does
that
bit
of
tooling
is
that
it
needs
the
it
needs.
Header
information,
not
header
information.
A
It
needs
btf,
symbol
information,
so
they
can
understand
how
to
map
events
that
happen
in
the
linux
kernel
with
context
around.
What's
related
to
that
particular
event,
the
way
that
it
does,
that
is
that
it
actually
holds.
You
could
consider
it
kind
of
like
a
dictionary
of
simple
data.
A
What's
happening
with
that
particular
data,
so
btf
is
very
similar.
It
holds
that
type
data
for
events
so
that
we
can
use
bpf
to
map
what's
happening
at
the
type
you
know
with
at
an
event
layer
with
what's
actually
happening
inside
of
the
kernel
when
a
particular
syscall
or
a
particular
event
happens
at
the
kernel
layer.
A
That
was
a
lot
of
information
and
I
hope
it
made
sense,
but
if
it
didn't
feel
free
to
reach
out
to
me
and
like,
let
me
know
that
the
thing
I
said
doesn't
make
any
sense
like
you
can
hit
me
up
on
twitter.
You
can
hit
me
up
on
the
cooper
news.
Slack,
there's
lots
of
ways
to
get
ahold
of
me,
but
I'm
maui
lyon
everywhere.
A
Suffice
to
say
what
I
was
working
on.
I
wanted
to
get
to
a
place
where
I
could
actually
do
bpf
trace
and
those
sorts
of
things
from
my
own
linux
kernel
that
I
that
I
have
running
on
my
laptop
now.
What
I
noticed
was
that
the
linux
kernel
that
I
was
operating
didn't
have
access
to
btf
information
or
bpf
type
information
and
there's
a
couple
of
different
ways
that
I
can
solve
this
problem.
A
A
A
So
the
way
this
works
is
that
you
can
build
like
a
debug
kernel
and
that
debug
kernel
will
basically
build
a
a
version
of
the
a
kernel
that
that
gives
you
access
to
all
of
that
type
data
and
then
what
I've?
I
found
a
new
config
option
in
the
linux
kernel.
Well
new
to
me
anyway.
I'm
sure
it's
not
like
super
new
that
gives
you
the
ability
to
define
that
you
want
the
kernel
to
make
that
btf
of
that
btf
data
available
inside
of
cisfs,
which
is
really
cool.
A
Again
here
so
we
move
into
so
I've
got
my
my
linux
kernel,
I'm
using
arch
as
a
linux
as
as
my
operating
system
for
my
laptop
and
it
seems
a
little
contentious.
So
I
think
a
lot
of
people
kind
of
kind
of
chuckle
about
the
whole,
like
I
use
arch
kind
of
thing,
but
that's
not
really
where
I'm
coming
from.
A
I
like
that,
it's
actually
very
flexible,
and
I
like
the
packaging
system-
and
I
like
the
aur
stuff,
but
let's
dig
into
how
this
would
work
inside
of
arch,
because
that
was
actually
the
problem
that
I
had
to
solve.
So
this
is
the
actual
build
package
for
the
linux
kernel
that
is
shipped
that
works.
That
is
most
compatible
with
the
version
of
laptop
that
I'm
using
I'm
using
a
t-14s.
A
A
A
A
Btf
symbols
are
also
generated
and
made
available
here
and
when
these
things
are
available
and
when
these
things
are
made
available
inside
of
the
csfs,
that
means
that
bpf
trace
and
other
tools
that
leverage
lid
bpf
can
just
make
use
of
those
symbols
directly
without
having
to
go
look
anywhere
else.
They
can
immediately
find
the
simple
the
symbols
they're
looking
for
and
then
give
you
really
good,
contextual
information
about
what's
happening
at
an
event
level
for
bpf
trace
at
the
kernel
layer,
which
I
thought
was
mind-blowing,
really
really
cool
stuff.
A
So
if
we
do
it
that
way,
then
we
don't.
We
don't
have
to
worry
about
like
actually
making
that
btf
symbol.
Information
available
to
some
other
application
say
I
wanted
to
run
bpf
trace
inside
of
a
container
or,
if
I
wanted
to
like
run
some
other
application
that
would
need
btf
symbol
data
within
a
container
or
something
else
that
was
going
to
share
the
same
linux
kernel
as
my
laptop.
So
if
I
were
to
do,
docker
excuse
me,
run
bash
ls,
cis.
A
Yeah,
we
can
see
that
we
have
that
same
data
available
inside
the
inside
the
internal,
and
so
what
this
means
to
me.
This
is
actually
the
thing
that
I
was
playing
with
on
the
very
beginning
was
I
needed
some
way
I
wanted
to
play
with
some
tracing
information
in
a
kubernetes
cluster,
but
I
wanted
to
be
able
to
leverage
kind
to
be
able
to
do
that,
and
so
to
do
to
be
able
to
get
across
that
finish
line.
A
What
I
needed,
what
I
was
missing
was
making
that
btf
symbol
data
available
to
my
linux
kernel
directly
and
then
any
containers
that
are
also
associated
with
that
same
linux
kernel,
so
anything
running
inside
of
a
a
kind
cluster
or
anything
any
other
docker
container
that
I
run
locally
on.
My
laptop
will
not
have
access
to
that
same
data,
and
I
don't
have
to
make
a
file
available
to
that
to
bpf
trace.
I
could
actually
just
build
it
right
into
the
kernel
cfs
which
is
so
cool
anyway.
A
A
All
I
had
to
do
was
add
these
three
lines,
and
actually
only
two
of
them
are
applying
right
now,
so
it's
config
debug
info
and
config
debug
info
btf,
and
this
makes
my
that
makes
that
cis
fs
piece
work,
and
that
makes
it
so
that
btf
symbols
are
available
to
anything
that
would
actually
try
and
leverage
bpf
inside
of
my
laptop
at
any
layer
as
long
as
it's
not
a
virtualized
layer,
so
really
neat
stuff.
Anyway.
A
A
But
what
this
says
is
not
all
kubernetes
apis
have
controllers.
So
the
thing
that
might
be
modifying
state
for
a
cluster
may
not
be
a
controller
right.
The
thing
that
updates
that
object
may
not
be
an
actual
controller
necessarily
it
could
be.
It
could
be
something
it
could
be
some.
It
could
be
some
shared
context
that
is
updating
status.
So,
let's
read
this
a
little
bit
and
see
what
it
says.
A
An
example
of
that
set
of
controllers
that
happen
at
the
at
the
controller
manager.
For
example,
when
I
create
a
kubernetes
when
I
create
a
deployment,
if
I
do
cubekill
apply
or
keep
it'll
create
deployment,
then
that
creates
a
deployment
object
and
then
there's
a
series
of
controllers
that
are
responsible
that
are
being
managed
by
the
controller
manager
that
that
progress.
A
That
deployment
object
to
a
set
of
running
pods
right
and
so,
for
example,
there
is
a
deployment
controller
that
is
responsible
for
breaking
that
deployment
into
a
replica
set
and
there's
a
replica
controller
that
is
responsible
for
breaking
that
replica
set
into
a
set
of
pods
that
have
been
defined,
and
then
we
pass
the
control
or
life
cycle
of
those
pods
down
to
the
cubelet.
Where
are
actually
no
once
those
pod
objects
are
created,
then
the
cube
scheduler
kicks
in
cube.
A
Scheduler
associates
those
pod
objects
that
have
not
already
been
attributed
to
a
node
with
a
node
and
then
once
you
have
a
complete
pod
object,
the
pod
object
exists.
It's
been
scheduled
to
a
node.
All
of
those
things
are
are
checked
off
the
list.
Then
the
cubelet
sees
that
that
pod
object
has
been
created
and
is
associated
with
itself
and
then
goes
about
managing
the
cl,
the
pod
again
in
a
controller
kind
of
way
right.
There's
a
reconciliation
loop
that
happens
on
the
cubelet
that
we're
that
is
responsible
for
ensuring
a
that.
A
We
know
about
all
of
the
pods
that
are
associated
with
this
node
b,
that
we
understand
the
life
cycle
where
we
are
in
the
life
cycle
of
each
of
those
pods
and
that
we're
reporting
that
life,
where
we
are
in
that
status
to
the
kubernetes
api
server,
so
that
those
objects
can
be
updated,
and
this
is,
I
think,
where
evan
is
going
with
this
right-
is
that
when
you
go
ahead
and
create
those
things,
there
are
different
pieces
that
are
responsible
from
updating.
Perhaps
comparts
of
that
object
over
time
right.
A
So
the
deployment
controller
may
not
be
the
thing
that
marks
itself
as
progressed,
and
that
might
be
the
replica
set
controller
that
pods
are
active
or
unactive.
It's
actually
something
that
is
going
or
active,
or
not
active
or
or
something
that's
going
to
be
kind
of
bubbled
up
from
the
cubelet
to
the
pod
status
object
and
then
to
the
status
object
at
the
controller
right.
A
So
what
information
is
reported
at
at
the
api
server
when
you
do
cubekill
get
deployment,
whether
you
have
the
where
you,
whether
you've
reached
the
current
running
state
of
that
object
or
not,
can
be
updated
by
different
sets
of
controllers,
not
by
one
particular
one?
So,
let's
take
a
look
at
how
this
works.
A
A
A
Here
I'm
going
to
do
a
cube
kettle,
create
cluster
or
create
deployment
dash
and
let's
call
it
quicken
image,
equals
nginx
port
equals
80.
A
A
So
here's
a
deployment
object.
Here's
the
replica
set
replica
set
controller,
basically
creating
two
pods.
Then
we
have
the
pods
themselves
being
pulled
and
created
starting
the
country
starting
the
container
nginx,
and
this
is
being
reported
usually
by
the
node,
that
is,
that
is
reporting
it
pulling
the
image
and
creating
it.
And
so
what
we
see
there
is
that,
like
those
controllers
are
responsible
for
each
of
those
controllers
are
responsible
for
that.
The
command
I
just
ran
was
cube.
Kettle
get
events,
and
I
was
just
targeting
the
the
namespace
in.
A
A
A
So
these
are
the
events.
This
is
the
event
data
happening
at
the
at
the
deployment
object
itself,
and
so
this
is
an
event
data
that
is
actually
represented
inside
of
the
object
itself.
And
then,
if
you
look
at
the
cube
kettle,
events
for
the
namespace
then
you'll
be
able
to
see
even
more
event
data
for
all
of
the
things
associated
with
that
deployment
right,
and
so
what
we
saw
was
a
deployment
be
created
two
minutes
and
30
seconds
ago.
A
A
I'm
only
looking
at
the
deployment
object,
I'm
not
looking
at
pods,
I'm
not
looking
at
replica
sets,
I'm
just
looking
at
the
thing
that
I
created,
which
is
the
deployment
object
and
it's
interesting
stuff,
because
I
have
a
lot
of
information
that
is
made
available
to
me
here
at
the
deployment
object
that
might
have
been
set
or
or
made
available
to
that
deployment
object
through
some
other
controller
right
or
has
been
bubbled
up
by
some
other
controller
replicas.
For
example.
A
Right
I
did
say
when
I
created
the
deployment
that
I
wanted
two
replicas,
but
the
deployment
object
is
not
responsible
for
creating
replicas.
It
doesn't
understand
that
it
doesn't
understand
necessarily
that
those
replicas
that
those
replicas
have
been
created,
but
it
can
surface
the
answer
to
that
question
right.
So
it's
surfacing
that
I
requested
two
replicas
that
two
have
been
updated,
that
there
are
two
total
and
that
there
are
two
available
and
this
information
is
made
available
to
me
via
the
deployment
object.
A
When
I'm
doing
cube
kettle
describe
deployment,
I
can
see
that
data,
but
this
information
was
not.
This
did
not
does
not
come
from
the
deployment
controller.
A
Controller,
which
I
think
is
really
kind
of
the
important
point
that
evan
was
getting
to
in
his
blog
post.
A
So,
let's
move
on
to
the
next
one
here,
so
that
was
the
point
of
it.
I
thought
was
pretty
interesting
and
then
he
has
some
other
examples
right,
so
controller
manager
has
a
deployment
object.
Subject:
access
review
is
one
that
actually
exists,
but
it's
actually
the
abstraction,
for
that
is
entirely
within
the
api
server.
A
So
this
would
actually
just
be
a
function
call
within
the
api
server
when
you
do
a
subject
access
review,
although
we
create
an
object
to
hold
state
for
that
object,
the
thing
that
is
actually
manipulating
that
object
is
actually
going
to
be
the
api
server
itself,
because
the
api
server
handles
the
authorization
piece
of
it.
So
there's
no
controller
necessarily
inside
the
controller
manager
even
or
on
the
cubelet
or
any
of
those
things
that
is
responsible
for
managing
that.
A
Subject:
access
review
object
when
you
do
a
when
you
so
when
you
create
one
you're,
actually
only
seeing
the
we're
only
capturing
the
state
of
that
leveraging
a
function
within
the
api
server
itself
kind
of
interesting
stuff.
A
A
I
think
I
personally
had
internalized,
but
I
had
never
really
thought
about
it
in
these
terms,
and
I
think
evan
does
a
great
job
of
making
this
very
approachable
and
understandable
and
that
if
you've
worked
with
the
kubernetes
api
at
all,
one
of
the
things
that
you
learn
about
is
this
idea
of
gvk
group
version
kind
right
and-
and
this
is
going
to
be
really
relevant
to
those
those
removed
or
deprecated
apis,
because
group
and
version
are
part
of
what
gets
deprecated
or
removed
from
the
api
server
in
these
circumstances.
A
But
the,
but
the
kind
persists
right.
We
still
have
an
ingress
object
that
you
can
define.
In
version
1.22,
but
what's
different,
is
the
group
and
version
the
path
to
that
object.
That
gets
created
is
different
so
and
we're
going
to
dig
into
like
how
this
works
in
this
in
this
article,
and
I
think
he
does
a
great
job
of
describing
it.
A
But
the
other
piece
that
I
think
highlight
the
highlights
is
that
you
also
have
group
version
resource
and
these
things
I
these
three
coordinates
identify
apis
right,
and
so
we
think
about
custom
resource
definitions,
we're
defining
group
version
resource
we're,
defining
whether
that
resource
is
scoped
to
a
namespace
or
to
a
cluster.
But
this
is
a
resource,
it's
an
api
that
is
extended
right
and
then
the
objects,
the
representation
of
objects
that
can
that
are
consumed
by
that
api.
That's
gvk,
group
version
kind.
A
So
if
I
defined
a
new
crd
for
pieces-
and
I
might
say
my
group
and
version-
I
don't
know
trying
to
think
of
you-
know
some
really
famous
new
york
italian
pizzeria
right
as
the
as
the
group
right
so
and
another
another
practical
example-
is
it
might
be
like
isovent.com
or
yourcompany.com,
or
you
know
cluster.com
any
any
of
those
particular
groups
that
you
define
and
then
the
version
is
where
in
the
api
versioning
scheme,
am
I
for
this
particular
api
that
I've
extended
right.
So
is
it
an
alpha?
Is
it
out?
A
A
A
But
when
I
create
a
pizza
like
say,
I
want
a
just
an
amazing
pizza
that
has
like.
A
Basil
and
tomato,
and
just
like
really
just
like
I
want
to
go
for,
like
the
og
pizza
I
want
to
go
for,
like
you
know,
really
good,
like
the
the
the
really
good
just
like
base
upon
which
all
things
are
built
pizza
right
then
I
might
create
that
object,
and
I
have
to
create
an
object
of
kind
pizza,
and
then
I
can
say
what
the
ingredients
would
be:
basil
tomato,
the
really
amazing
dough,
and
that's
going
to
be
my
that's
I
mean
and
some
cheese,
and
that's
going
to
be
my
it's
going
to
be
my
pizza,
and
so
this
is
where
the
gvk
part
comes
in
right.
A
When
I
define
a
pizza
leveraging
that
api
made
available
to
me
by
a
resource,
then
we
can
actually
let
me
create
the
gvk
we
create
that
object
and
that
object
is
represented
by
the
conversion
kind.
All
right.
So,
let's
take
a
look
a
little
bit
more
into
how
they
do
how
he
defines
it
here.
A
A
A
A
A
Roll
pod
reader,
oh
yemo,
we
should
be
able
to
see
the
basically
that
same
output
that
we
saw
on
the
left
and
it
gives
us
the
ability
to
play
with
this
stuff
right,
so
we
can
actually
just
create
that
object
directly.
Now.
This
is
an
object
like
I
said
before,
and
this
is
actually
one
of
the
things
I
thought
was
really
succinct
about
the
blog
post
right.
This
is
the
group.
This
is
the
version,
and
this
is
the
kind
and
this
is
defined
here,
because
this
is
an
object
that
has
been
created.
A
A
Api
there's
nothing
in
the
object
that
tells
you
what
the
resource
is.
The
cube
api
server
maintains
a
mapping
of
resource
types
to
kinds,
as
do
cube,
clients
like
cube
kettler
client
go.
This
is
called
the
rest
mapping
in
these
client
projects
and
related
docs.
Once
you
know
the
resource,
there
are
simple
rules
for
building
urls
apis
group
version,
resource
name,
api's
group
version
name:
space
is
a
name
if
it's
a
namespace
object.
If
it's
a
cluster
scope,
object,
you'd
be
able
to
see
it
here.
A
If
it's
a
namespace
object,
you'd
be
able
to
see
it
there.
Now,
if
you
want
to
like
explore
that
stuff
live
or
if
you
want
to
kind
of
dig
into
like
playing
with
this
pathing
information,
you
can
actually
look
at
this
information
directly.
If
you
just
turn
on
cube
general
cubecattleproxy
right
so,
let's
just
say,
cubekiddle
proxy,
and
now
I'm
serving
the
entire
api
server
in
a
kind
of
a
read-only
mode
at
one,
two:
seven:
zero,
zero
one
call
it
8001.,
it's
not
only
you
could.
A
So
in
the
let
me
make
this
a
little
bit
bigger,
so
in
the
blog
post
you
know
I'm
going
to
clean
up
my
browser
tabs
here.
I
know
people
don't
generally
do
that,
but
I'm
I'm
I'm
a
wild
person
that
way.
A
A
A
A
So
this
gives
us
that
same
path
that
we
talked
about
in
the
blog
post
right.
If
I
wanted
to
understand
for
the
role
what
the
path
would
be,
it
would
be
under
slash
apis
group
version
resource
name.
So
my
group
and
version
are
our
back
authorization
cage
to
I
o
and
my
version
is
v1.
So
let's
go
check
out
that
path
and
see
what
we
see.
So
I'm
going
to
go
ahead
and
grab
this
url.
A
A
The
resources
that
have
been
defined
you
can
define
a
cluster
role
binding
and
the
kind
or
object
that
can
be
defined
for
this
particular
resource
is
a
cluster
role.
Binding
the
resource
for
cluster
roles
and
the
object
or
kind
that
can
be
defined
is
cluster
role,
and
these
are
the
things
that
can
be
done
to
that
particular
object
so
that
for
the
for
this
particular
rest
mapping.
So
when
we
create
this
object,
these
are
the
things
that
can
be
done
with
it.
A
If
we
cruise
down
a
little
bit
further,
I
think
we
can
see
rolls
right,
and
this
is
an
interesting
one,
because
roles
are
defined,
not
a
cluster
scope
but
in
a
namespace
scope.
So
in
this
rest
mapping
we
can
see
that
this
is
a
role.
It
is
represented
by
a
kind
or
an
object
called
a
role,
and
it
is
a
namespace
object,
meaning
that
it
can
only
be
created
at
a
namespace
level.
I
can't
create
a
cluster-wide
role
with
this
object.
A
There's
a
different
object
for
that,
but
since
this
one's
namespaced
it
can
only
be
created
within
a
namespace
and
that's
why,
when
I
did
my
cube
kettle
command
to
create
the
object
which
I
think
I
made
go
away,
but
when
I
used
like
when
I,
when
I
did
the
command
to
create
the
object,
I
had
to
specify
a
namespace
in
which
to
put
it
and
then
the
verbs
associated
with
this
one
it
can
be.
You
can
do
a
create
a
delete.
You
can
delete
a
whole
bunch
of
them.
A
A
A
So
for
the
group
in
the
v1
we
can
see
what
the
preferred
version
is
that
we're
going
to
store
it
as
or
make
it
available.
Let's
go
back
to
our
blog
post
here,
so
this
is
actually
how
we
can
see
it
and
there's
actually
another
great
doc
in
the
docs
that
says
api
concepts
document
that
gives
you
information
about
how
this
stuff
works.
Thank
you
for
coming
by
diane,
see
you
next
time.
A
A
So
we
create
an
ingress
at
this
new
newly
to
be
deprecated
version,
networking
for
networking.k8s
to
io
at
v1
beta1,
and
then
we
do
a
get
or
a
create
of
that.
We'll
see
that
object,
get.
A
A
And
we
can
see
that
instead
of
and
then
it's
made
available
to
us
on
the
get
at
this
new
version,
and
that
means
in
this
particular
case,
it's
calling
out
the
preferred
version.
That's
what
he's
that's
what
he's
referring
to
here
right.
So
when
we
looked
at
the
group
version
right,
we
can
see
that
the
preferred
version
so
anything
that
when
somebody
just
does
a
random
get
of
roles,
then
I'm
going
to
provide
them
the
result
as
mapped
in
this
way.
A
A
A
A
We
can
see
the
version
that
is
being
made
up,
that
is,
preferred
is
v1
just
like
they
were
talking
about
before
right.
A
If
you
submit
an
object
to
the
api
server
and
it
doesn't
match
the
storage
version,
the
api
server
will
convert
it
to
the
storage
version
before
storing
it
in
scd
to
be
more
precise,
it
first
it
converts
it
to
an
internal
version
before
converting
it
back
to
the
storage
version.
But
this
is
an
implementation
detail
now.
A
This
is
where,
like
some
deep
magic
happens
at
the
api
server,
and
I
think
it's
worth
understanding
that
this
happens,
because
it's
actually
pretty
neat
I'm
trying
to
think
we
can
actually
have
an
example
here
to
walk
through
it,
but
maybe
he's
actually
answered
that
for
us.
So,
for
example,
in
cube
120
the
preferred
version
of
aggressors
v1,
but
the
storage
version
is
v1
beta1.
This
can
be
seen
by
looking
at
the
data
the
api
server
stores
in
sed.
A
But
he's
created
the
ingress
object
and
he's
going
ahead
and
grabbing
the
content.
The
data
from
scd
directly
leveraging.
A
A
A
A
That,
if
you
look
at
the
object,
that's
stored
in
std,
there
is
some
content-
that's
stored
about
it
right,
so
we
can
actually
have
a
preferred
storage
version
or
storage
version
that
is
represented
by
that
storage
version,
but
that
storage
version
isn't
necessarily
the
entire
api
that
is
exposed
by
that
by
that
extended
api
itself
right.
It's
just
whatever
is
necessary
to
store
the
object
in
that
cd
and
these
can
differ,
and
this
is,
I
think,
where
evan's
point
is
coming
in
right.
A
So
let's
say
I
created
that
pizza
that
we
talked
about
before
and
before.
I
didn't
particularly
care
about
what
the
contents
of
the
dough
were,
or
you
know
a
particular
topping
like
I
didn't
make.
I
didn't
even
make
it
available
that
you
could
put
pepperoni
on
a
pizza,
and
so
I
didn't
really
have
like
the
topping
section
built
out
and
so
to
make
the
topping
section
to
build
out
the
topping
section
I
needed
to
change
the
api.
A
A
Changing
the
object,
stored
version
requires
writing
a
newer
api
server
or
a
newer
crd,
depending
on
how
you
know
on
what
you're
working
with
here
right.
So
if
we
wanted
to
change
the
object,
storage
version
for
something
that
was
built
into
the
api,
so
we're
like
that
role,
object
that
we
talked
about
before.
We
would
need
to
change
the
we'd
need
to
change
the
api
server,
because
that's
actually,
where
we're
defining
the
api
for
a
particular
version
of.
A
In
this
example,
we
create
an
object
at
v1
in
q120,
which
stores
at
v1
beta1.
We
update
the
api
server
to
version
1.21
and
check
an
sdd
that
it's
still
stored
as
v1
beta1,
and
then
we
overwrite
the
object
with
a
new
api
server
to
see
it
stored
at
v1
so
check
this
out.
This
is
how
you
might
migrate
or
how
you
earlier
we
talked
about
I'm
going
to
pause
this
for
a
moment
earlier.
A
We
talked
about
the
very
salient
point
that
stefan
pointed
out
right,
wherein,
if
you
create
an
object
at
version
that
at
a
version
that
will
be
removed
from
api
serving
how
do
we
actually
convert
that
object
on
the
back
end
to
make
it
available
so
that
we
don't
just
like
abandon
those
objects
that
don't
work
anymore
right,
and
this
is
actually
practically
how
it
works,
and
this
is
a
great
example
right.
So
we
have
a
cluster.
A
A
A
And
we
can
see
now
that
the
store
that
the
version
that
we
do
a
cube,
if
we
do
it
stdget,
we
can
see
that
the
stored
version
gets
updated
and
this
kind
of
happens
somewhat
organically
within
kubernetes,
which
is
actually
pretty
neat.
So
it
means
that
anytime,
you
modify
that
object
and
the
storage
version
has
changed
anytime.
You
modify
that
object.
A
The
object
will
get
stored
as
the
new
preferred
storage
version.
So
if
I
created
a
whole
bunch
of
resources
like
deployments,
for
example
at
v1,
beta
1
and
I
haven't
modified
that
deployment,
but
my
cluster
has
moved
forward
in
versions
right,
so
I'm
no
longer
a
116.
I
moved
to
117
and
moved
to
180
and
move
to
119.
What
have
you?
A
The
those
objects
need
to
be
touched
or
modified
in
the
cluster
before
you
move
to
the
next
version,
so
that
we
can
store
those
in
the
new
storage
version,
and
this
is
where
that
those
release
notes
that
stefan
was
talking
about
before
you
have
a
couple
of
different
options,
so
you
could
actually
run
a
keep
cutting
command
that
just
goes
through
and
does
a
replace
on
every
object.
A
In
the
lcd
data
store-
and
it's
an
intensive
thing,
but
you
can
even
like
you
know
stash
it
right,
you
can,
you
can
go,
buy
api
paths,
let's
do
all
of
our
back.
Let's
do
all
of
ingress.
Let's
do
all
of
networking.
Let's
do
all
of
you
know,
deployments
and
replica
sets
and
all
the
different
crds
that
we
want
to
modify,
and
this
gives
us
the
ability
to
go
through
and
touch
all
of
those
objects
and
get
them
stored
to
the
new
version.
Before
we
move
to
the
next
version
of
kubernetes.
A
Now
you
might
have
heard
like
in
the
upgrade
guide
or
red
in
the
upgrade
guide
inside
of
kubernetes,
that
you
want
that.
You
need
to
ensure
that
you
don't
skip
any
patch
versions
when
upgrading
your
kubernetes
cluster.
So
if
you're
going
to
go
from
116
to
117
or
if
your
target
is
from
116
to
say
like
120,
you
can't
just
go
from
116
to
120.
A
A
Right
so
you
go
116
117,
you
upgrade
all
the
things
to
the
new
storage
version.
118
upgrade
all
the
things
in
the
storage
version,
119
upgrade
to
all
of
things
to
do
storage
version,
because
that's
the
guarantee,
the
api
guarantee
that
we
have
is
that
we'll
get
you
from
old
version
to
new
version,
but
not
necessarily
old
version
to
some
forward
version,
and
now
you
kind
of
understand,
materially,
why
that's
important
the
storage
version?
A
That
so
these
are
the
pieces
of
this
of
this
blog
post
that
I
think,
really
really
apply
to
api
removals
and
deprecations
right.
What
we
talked
about
so
far
is,
if
we're
going
to
remove
an
api
from
serving.
Then
that
means
that
the
objects
that
you
created
with
that
old
api
server
are
still
around
they're,
still
hosted
inside
of
the
lcd
cluster
and
they
may
be
hosted
in
scd
at
some
older
version
of
storage
version
right.
But
the
thing
that's
important
is
that
those
objects
don't
just
get
dropped
on
the
floor.
A
They
don't
stop
existing
inside
of
your
kubernetes
cluster
they're
still
there.
They
just
need
to
be
migrated
to
a
new
storage
version,
because
you've
changed
the
version
that
is
available
via
the
api
server,
and
that
fact-
and
that
may
have
actually
already
taken
place
in
fact
so,
like
the
preferred
version,
is
likely
forward
for
all
of
those
objects
that
we
talked
about
in
the
blog
post
right.
A
I
created
a
bunch
of
objects
against
old
api
against
old
apis
that
were
available
to
me
in
version
120,
and
then
I
upgraded
my
cluster
to
1.21.
Are
those
objects
still
there?
Yes,
they're
still
there
and
they're
still
available,
and
you
can
still
modify
them
and
touch
them
and
make
use
of
them,
but
you
can't
create
new
objects
at
that
api
version
anymore.
A
A
Deployment,
but
even
if
your
crd
hasn't
implemented
the
explained
piece
completely,
this
bit
up
here
will
already
be
made
available
inside
of
cube
cuddle
explain.
A
A
A
A
A
Internal
api
server
ksio.
So
let's
see
I'm
going
to
check
to
see
if
my
cluster
has
this
resource
defined.
So
let's
take
a
look
and
see
if
it
is
right
so
because
I'm
looking
for
a
resource,
the
way
that
I'm
going
to
determine
that
resource
is
available
or
not,
is
I'm
going
to
do?
Cubekittle
get
actually
q
kettle
api.
A
A
A
From
the
kind
config
to
go
ahead
and
enable
this
right,
so
let's
go
ahead
and
do
that
new
kind.
A
A
Okay,
caps,
kinda.
A
A
And
so
I
know
that
this
is
a
kind.yaml
because
of
the
api
version
in
this
right.
So
it
says
kinda
case
I
o
v,
one
alpha
four
and
then
these
are
parameters.
So
I
can
pass
to
my
kind
cluster
that
configure
the
the
cluster
in
a
specific
way
and
these
parameters
get
passed
to
cube
adm
inside
of
the
cluster
on
startup.
So
these
feature
gates.
If
you
want
to
enable
a
feature
gate
inside
of
kind,
you
can
just
use
a
feature,
gate,
stanza
and
then
enable
particular
features
and
then
inside
of
the
runtime
config.
A
A
This
will
create
our
cluster
and,
as
we
saw
before,
we
didn't
see
any
internal
version
when,
when
I
did
a
grep
for
that,
instead
of
api
resources.
But
let's
see
what
happens
after
the
this
new
cluster
starts
up,
we'll
see
if
we
actually
see
it.
There
now
love
to
play
with
this
api
and
see
kind
of
like
what
it
exposes.
That's
actually
pretty
neat.
A
A
Now
I
do
see
that
api
okay,
so
I'm
going
to
go
ahead
and
do
come
back
over
here,
real
quick
break,
my
cue
proxy
start
it
up
again.
A
A
A
A
A
Here
is
the
content
that
is
made
available
on
the
group,
so
we
see
the
group
version.
This
is
kind
of
meta,
so
I
can
get
the
group
version
of
group
version
or
storage
version,
and
we
can
see
that
the
only
version
that
is
available
right
now
is
v
one
alpha
one
and
the
preferred
version
is
also
v
one
alpha
one,
no
shocker
there.
It's
only
the
only
one
available.
A
A
A
It
looks
like
it's,
the
only
object,
that's
been,
that's
been,
oh
there's
a
status
object
and
the
resource
object
itself.
Both
of
them
are
exposed
likely.
These
are
differentiated
by
the
permissions
that
are
associated
or
the
way
that
you
can
update
them
right,
and
so
the
object
itself
can
be
created,
deleted,
delete
collection
list,
patch,
update,
watch
and
then
there's
a
different
permission.
If
you
want
to
apply,
get
patch
or
update
to
storage,
object
to
the
storage
version,
object
status.
A
A
A
A
Then
I
would
understand
that
it
would
be
stored
in
this
particular
version
and
this
particular
group,
and
that
if
I
were
to
do
a
gre
get
for
one
of
these
things,
I
could
get
at
any
one
of
these
other
decodable
versions
right.
So,
for
example,
let's
just
play
with
that
real
quick
and
I
could
show
you
exactly
what
that
means.
A
A
A
A
Deployment
yeah
I
want
to
create,
let's
see,
can
get
all
api.
A
There
we
go
so
ingress
exists
in
both
kind
of
like
the
example
that
evan
pointed
out
before
right.
Ingress
exists
in
extensions,
v1
beta
1
and
exists
in
networking
v1.
So
if
I
do,
this
do
cubekittle
create
ingress.
A
A
A
A
You
can
see
that
right
now,
it's
giving
me
the
result
as
this
new
version
networking.ks.iov1,
but
this
is
the
fun
part,
so
I'm
using
cube
kettle
bash
completion
right.
So,
if
I
do
cube
kettle
get,
I
can
see
the
things
that
I
can
get.
I
want
to
look
at
ingress
the
ingress
object
and
if
I
look
here,
there's
a
few
different
versions
that
are
available
to
me,
which
is
really
pretty
deep.
So
what
this
means
is.
These
are
the
avail.
These
are
the
decodable
versions
available
within
the
ingress
object.
A
I
can
actually
get
the
old
version,
it
says
dot
extensions
dash,
o
yaml,
and
it
will
it
will
on
the
fly,
convert
this
object
according
to
the
api
that
was
presented
when
this
api
was
available
right,
so
I
can
actually
get.
I
can
convert
this
object
in
this
way.
I
can
do
cubekill
get
ingresses
dot
extensions,
which
tells
it
that
I
want
to
see
extensions,
v1,
beta
1,
for
that
particular
group.
This
particular
ingress
object
and
I
can
also
look
at
the
other
one
right.
So
I
had
ingresses
and
I
also
had
I'd.
A
A
If
you
start
interacting
with
an
api
that
has
been
deprecated
even
if
it's
just
a
get
you're
going
to
get
a
warning,
it
tells
you
hey
heads
up.
This
is
the
thing
you
probably
want
to
know
about.
You
created
this
object
using
extensions,
v1
beta1,
that's
a
deprecated
api,
so
we're
doing
as
much
as
you
can
in
the
community
to
make
it
possible
that
you
won't
get
caught
out
by
this
all
right.
A
The
cube
storage
version
migrator
can
handle
migrating
changes,
so
we
can
just
take
a
look
at
how
this
works
so,
like
I
said,
if
you're
going
to
do
like
an
upgrade
from
version
116
and
you're
aiming
for
120,
how
do
you
get
there?
One
way
to
do
it
is
by
leveraging
tools
like
this
right,
where.
A
A
All
right,
crds
define
new
apis.
New
resources
like
we
talked
about
all
apis,
are
cluster
scoped,
even
scope,
namespace
crds,
meaning
that
the
api
itself
is
expressed
as
a
cluster
operation.
Now
this
is
an
interesting
point:
I'm
not
going
to
harp
on
it
too
long,
but
when
we
think
about
multi-tenancy,
this
becomes
a
very
important
point,
because
when
you
define
a
new
api,
you
make
that
available.
You
make
that
api.
A
A
A
A
I
do
recommend
reading
this
blog
post,
there's
some
really
great
stuff
and
it
really
gets
into
the
detail,
and
I
think
it
really
highlights
you
know
some
ways
of
understanding
and
playing
with
how
these
things
could
work
and
how
you
can
kind
of
explore
this
stuff
leveraging
kind
and
explore
this
stuff
in
a
non-prod
environment
where
you
can
learn
all
about
the
way
that
storage
versions
and
all
these
pieces
are
actually
managed
over
time,
and
you
can
take
away
you
can
you
can
work
in
a
really
safe
environment
without
having
to
worry
about
learning
this
stuff
on
the
fly
in
production
environments,
which
I
also
really
highly
recommend?
A
I
hope
you
enjoyed
this
episode.
I
enjoyed
doing
it
I'll
be
back
in
two
weeks
and
I
will
see
you
then,
and
if
you
have
any
questions
or
if
you
ever
want
to
chat
about
anything
or
anything
else
like
that,
you
can
reach
out
to
me
on
twitter
or
on
kubernetes
slack.
I
am
at
maui
lion
everywhere.