►
Description
Notes: https://github.com/vmware-tanzu/tgik/blob/master/episodes/099/README.md
Come hang out with Duffie Cooley as he does a bit of hands on hacking of Kubernetes and related topics. Some of this will be Duffie talking about the things he knows. Some of this will be Duffie exploring something new with the audience. Come join the fun, ask questions, comment, and participate in the live chat!
This week we will be continuing the Grokking series with: exploring the API Server
A
Hey
good
afternoon,
everybody
and
welcome
to
kay
is
number
99
good
to
see
you
all.
It
seems
with
us
this
MUC
this
afternoon
we
got
Matt
checking
in
oh.
Thank
you
very
much
for
your
word
and
so
encouragement
there
I'm
really
enjoying
that
grokking
stuff
as
well.
We
got
abc123
coming
in.
We
got
suresh
from
hamburg
how
you
doing
suresh
and
we
got
Olaf
from
Copenhagen
and
the
Maddy
good
to
see
you,
oh
as
always,
and
Gustavo
Chavez
from
Chicago.
A
We
got
Ramesh
from
San
Francisco
right
here
in
San
Francisco
and
what
are
my
favorite
memories
from
Keep
Calm?
That's
a
great
question.
Cape
Cod
for
me
was
really
an
interesting
one
this
year,
mainly
because
it
was
part
of
just
a
very
busy
month
so,
like
I
spent
most
of
my
November
traveling
I
spent
the
first
week
in
Barcelona
at
at
vmworld
EU,
which
was
an
amazing
experience.
A
A
The
second
week
I
was
at
an
event
in
Dallas
and
then
obviously
cute
con
in
San
Diego,
which
was
amazing
and
I
participated
in
a
couple
of
a
zero
day
and
pre-show
events,
so
I'm
fluent
on
Sunday
and
did
I
talk
with
my
friend
Nick
Lane,
and
that
was
really
an
incredible
thing
was
really
neat
because
it
was
in
this
museum
that
was,
there
was
really
all
about
kind
of
inclusivity,
and
things
like
that
which
I
thought
were.
It
was
really
a
pretty
neat
kind
of
experience.
A
You
know
like
the
rejects
conference
this
year
in
San,
Diego
was
like
held
in
a
museum
that
was
really
doing
like
a
whole
historical
thing
about
inclusion
and
the
fact
that,
like
you
know,
we
should
all
kind
of
think
that's
super
important.
That's
I
thought
that
was
really
great
and
then,
during
the
show
itself,
I
attended
this
the
security
day
and
I
really
enjoyed
again
speaking
with
in
cold
water,
speaking
of
which
our
talk
from
blackhat
is
up
and
I'll.
A
It
was
really
overwhelming
to
try
and
get
all
of
it
in
I
think
that
everybody
had
their
own
kind
of
unique
experience,
because
there
was
so
much
going
on,
but
I
had
a
great
time
what
else
we
got
a
team
from
Ashburn
in
Virginia
and
we
got
more
Tesla
from
Iran
Suresh
yeah
I'm
wearing
my
my
tons
of
colors.
You
know
I
like
it.
A
We
got
Martin
from
Netherlands
and
got
Elko
Elko
from
the
Netherlands
as
well,
and
we
have
Phillipe
from
Paris
so
good
to
see
you
all
all
right
who
knows
a
little
itchy
still
dealing
with
a
very
last
end
of
a
of
a
head
cold
and
if
I'm,
looking
off
to
my
left.
It's
because
that's
where
my
chat
is
so
you
know
how
it
is
Bogdan
from
Bucharest,
Romania
and
Ishmael
from
Ankara,
so
good
to
see
you
all
I,
hope
you're
getting
ready.
A
I
mean
this
is
another
one
of
those
things
like
I've,
you've
heard
Joe,
say
this
and
I'm
sending
lots
of
times.
I'm,
always
amazed
at
the
fact
that
we
have
audience
members
from
just
all
over
the
world.
I
mean-
and
you
know,
I'm
curious
like
if
you
want
to
put
information
into
the
chat
about,
like
you
know
whether
you
actually
get
time
off
during
this
part
of
the
year
to
celebrate
holidays
or
just
hang
out
with
family
and
friends.
I'm
curious.
A
If
that's
like
a
global
thing
or
if
that's
you
know,
I
know
it's
obviously
here
in
the
US
and
then
I
think
I
think
it's
obviously
in
Europe,
but
I'm.
You
know,
depending
on
where
you're
at
that
may
not
be
quite
as
much
a
thing,
so
I'm
kind
of
curious
how
that
works.
So
anyway,
if
you
do
get
to
take
off
sometime
I
hope
you
enjoy
it
and
this
time
of
year,
I
really
like
to
spend
it
with
family
and
friends
and
that
sort
of
stuff.
A
So
let's
get
started
here
this
week
we
got
some
really
good
news
to
talk
about.
Obviously,
117
is
out,
and
that
is
exciting.
So
this
year's
are
sorry
this
year,
that's
hilarious.
This
release
is
about
stability,
and
so
it
was
really
a
pretty
good,
interesting
thing:
there's
lots
of
there's
lots
of
changes
and
lots
of
things
that
have
come
this
release.
A
If
you're
curious
about
digging
into
some
more
of
the
stuff
that
actually
came
with
it.
There
is
a
link
here
to
the
community
retro.
So
there
was
perspective
with
regard
to
the
the
release
itself,
and
this
is
folks
talking
about
you
know
how
the
release
went
like
how
it
what
it
was.
You
know
what
we
learned
from
it.
What
we
thought
we
could
improve
on
that
sort
of
thing.
A
The
really
release
117
already
has
a
regression.
It's
a
performance
regression
on
web
put
back
end
requests.
So
this
is
your
your.
You
know:
release
release,
lis,
reminder
that
you
know
just
because
we've
released
the
next
version
of
kubernetes.
We
definitely
want
you
to
kick
it
around
and
test
it
out
and
I
mean,
like
the
feedback
that
we
get
from
the
community.
Around
a
new
release
is
actually
incredibly
valuable
to
all
of
the
people
working
on
it,
but
at
the
same
time,
I
wouldn't
necessarily
move
your
production
clusters
to
the
very
freshest
release.
A
I
would
I
would
definitely
say
you
know,
wait
for
a
few
dot
releases
and
let
us
catch
those
things
that
the
brave
souls
kicking
up
brand
new
versions
of
kubernetes
have
discovered
so
really
helpful
stuff,
but
that,
but
that
regression
has
already
been
picked
up.
So
that's
pretty
great
speaking
of
speaking
of
how
can
you
get
your
hands
on
1:17
in
a
safe
way?
You
obviously
I
spend
a
good
amount
of
time
in
in
these
sessions,
exploring
kubernetes
with
kind
and
we're
gonna
do
that
in
this
session
as
well,
and
so
Benjamin
elder
who's.
A
A
Other
things
at
117,
the
Cooper
nudists
podcast,
is
actually
got
a
release
out
on
the
10th
of
December
and
they're
doing
an
exploration
of
kubernetes
1.17
with
Guinevere
singer.
Who
was
our
release
lead
this
year
for
this?
For
this
one,
the
release
manager,
when
is
awesome
like
absolutely
awesome,
so
I'm
sure
that
this
that
this
session
is
just
filled
with
you
know,
laughter
and
awesome
things.
A
A
A
A
Typically,
when
you're
dealing
with
an
application
gateway,
you
have
to
make
that
routing
decision
up
at
the
gateway
level
and
make
sure
that
you
can
terminate
directly
to
the
pods
so
that
you're,
not
so
you're,
not
making
that
decision
twice
and
changing
and
breaking
things
like
you
know,
WebSockets
and
stuff,
like
that.
So
kind
of
interesting
it'll
be
interesting
to
see
how
that
works.
But
it's
out
there
now
so
definitely
go
if
you're,
if
you're
honest
you're
go
check
it
out,
and
you
know.
Let
me
know
how
that
goes.
A
There's
also,
this
actually
made
quite
a
bit
of
an
impact
I
might
I
might
on
my
Twitter,
for
you
I
thought
that
was
pretty
great.
You
know
that
somebody
like
put
up
a
visual
guide
for
troubleshooting
communities
deployments
and
it
just
showed
up
everywhere,
so
I
thought
I
would
put
it
up
here,
and
here
we
have
the
visual
guide
on
troubleshooting
kubernetes
deployments.
I
have
looked
at
this
and
this
is
actually
looking
pretty
good.
If
you,
you
know
some
people
I,
you
know
everybody
learns
and
thinks
about
things
differently.
A
A
Some
people
are
not
linear
thinkers
and
they
want
to
be
able
to
just
like
have
all
the
information
and
figure
out
how
to
throw
it
together
in
their
head
themselves,
and
so
it's
really
great
to
see
stuff
like
this,
because
it
really
I
think
it
means
that
we're
appealing
to
more
audiences
right,
like
we
have
differently
people
who
will
find
this
incredibly
helpful,
just
to
dig
into
it
and
understand
how
to
look
into
it
so
definitely
check
this
out.
I
was
really
impressed
with
how
how
this
was
put
together
and
I
feel
like
it.
A
A
There's
a
new
version
of
cube
state
metrics
out,
which
is
exciting
and
keep
state
metrics
in
this
release,
has
a
number
of
new
features.
Keep
state.
Metrics
is
a
tool
that
allows
you
to
pull
metrics
back
from
all
of
the
cubelets
and
the
control
plane
components
inside
of
kubernetes
is
they're
all
instrumented
with
from
Athiya
scheme
state
metrics
gives
you
a
bill
kind
of
pull
all
those
metrics
back
and
then
exposed
them
inside
of
Prometheus.
A
A
We
have
the
persistent
volume
claim
status,
condition
lots
of
interesting
stuff
being
shown
up
here.
So
this
is
a
very
important
project
and
I
think
it's
actually
pretty
cool,
so
definitely
check
this
one
out
and
if
you're
interested
in
understanding
when
those
things
are
changing,
tarik
is
actually
now
one
of
the
main
contributors
of
one
of
the
release
leads.
A
If
you
go
to
releases
here,
you
can
see
that
there
was
already
another
cut
right
after
this
one
that
fixed
a
bug.
Did
somebody
open
right
so
people
who
are
actually
a
pretty
good
one,
a
pretty
good,
interesting
way
of
evaluating
an
open
source
project
like
this
right,
so
they'll
announce
a
new
release.
I
need
a
new
release
candidate
and
they
asked
people
to
come.
Take
a
look
at
it.
That's
pretty
great,
so
cool
stuff.
A
If
you're
using
cube
state
metrics
in
your
kubernetes
clusters,
throw
a
note
up
into
the
chat,
I'm
curious,
if,
if
you
all
have
seen
this
before
or
if
it's
something
that
you
all
are
exploring,
if
you
have
used
cube
prometheus,
which
is
a
tool
that
is
yet
meant
to
instrument
kubernetes
on
top
of
Prometheus,
you
probably
are
using
it.
You
may
not
be
aware
that
you
are,
but
it's
in
there,
the
folks
that
stack
rocks
actually
did
a
pretty
decent
article
delivered
on
to
the
ninth
digs
into
some
of
the
new
features
of
117.
A
A
What's
here
and
point
slice
is
a
big
one
and
it
happened
kind
of
right
around
the
same
time
as
the
ipv6
stuff,
and
so
there's
a
lot
of
things
that
were
influenced
by
end
point
slice
and
a
really
in
relation
to
ipv6
and
ipv6
do
little
stack
support
so,
but
it's
out
there
now
it's
an
alpha
shout-out
to
my
friend
Cal,
who
has
done
a
ton
of
work
on
this,
and
also
a
number
of
other
people
in
the
community
for
contributing
Valerie
is
one
of
them.
There's
just
a
ton
of
people.
A
Ipv6
is
a
big
change
to
the
way
that
kubernetes
works,
especially
in
the
dual
stack
stuff,
so
I
mean
like,
if
you
think
about
it,
like,
even
if
something
as
as
something
as
intrinsic
as
a
pod,
having
an
IP
address
right
like
it
seems
like
a
built-in
thing.
Well
now
we
have
to
think
about
multiple
IP
addresses
as
they
relate
to
a
pods
right
and
so
there's
a
ton
of
you
can
think
of,
like
all
the
different
places
that
the
codebase
would
have
to
be
touched
to
be
able
to
support.
A
Persistent
vol
snapshot,
backup
and
restore
support
is
in
CSI
and
it's
graduating
to
beta,
which
is
exciting.
So
if
you
haven't
explored
snapshots
as
they
relate
to
CSI,
give
it
a
try
if
you
can
or
if
you're
interested
in
doing
so
and
then
a
topology
aware
service
routing
now
this
is
also
related
to
endpoint
slice
and
this
one's
pretty
interesting,
because
it
gives
us
the
ability
to
think
about,
though,
to
reduce
the
amount
of
work
that
coupe
rocks.
You
might
have
to
do
in
some
cases
right.
So
it's
it's
kind
of
an
interesting.
A
It's
an
interesting
improvement,
and
so
it's
also
the
goal
to
think
about
how
we
said
traffic
back
and
forth
between
nodes,
given
that
they
might
be
part
of
different
availability
zones
right.
So
it
would
give
us
the
ability,
perhaps
to
reduce
the
cost
of
traffic
moving
back
and
forth
is
across
the
cluster.
If
we're
able
to
maintain
if
we're
able
to
enforce
that
that
traffic
keep
within
the
same
topology
or
a
tree
or
availability
zone,
so
interesting,
stuff
happening
there.
A
Api
defaulting
for
custom
resources,
which
is
exciting
lots
of
stuff
happening
for
CR
DS.
Actually
this
year,
this
release
process
namespace
sharing
in
pods,
which
means
that
if
you
had
multiple
containers
in
the
same
pod,
that
means
that
if
you
were
like
to
jump
into
container
one
and
container
to
you
and
type
PS
minus
EF,
you
see
the
same
output
right.
A
The
good
thing
is:
is
that
now
you
can
do
things
like
just
check
out
the
processes
live
as
part
of
a
health
check,
rather
than
rather
than
having
to
interact
with
it.
So
that
might
be.
That
might
be
a
good
thing.
There's
there's
some
other
interesting
stuff
that
happens,
especially
from
a
security
perspective.
Anyway.
A
Do
stock
rocks
did
a
great
job
of
talking
about
this
now
I
have
two
more
things:
I
want
to
talk
about,
newswise,
which
you're
designing
with
falta
means
of
mind
yeah.
This
actually
does
play
into
that
right.
So,
if
you're
designing
with
fault
domains
in
mind,
the
idea
of
what
topology
aware
service
routing
might
might
might
be
a
factor
in
to
consider
there,
we
got
Mohamed
from
Bonn
Germany
and
we
got
a
meeting
from
Algeria.
A
Olaf
is
telling
us
that
in
Denmark
first,
a
second
day
of
Christmas
story,
25th
of
December
and
the
first
day
of
January-
that's
pretty
true.
Here
too
many
people
burn
some
of
their
25th
25
annual
vacation
days.
Yeah
that
makes
sense
like
between
between
Christmas
and
years
or
between
yeah,
and
the
citecar
container
speck
in
pod
speck
is
missed
in
this
release.
What
does
that
mean.
A
Suresh,
do
you
want
to
link
me
to
what
you're
talking
about
I'm
kind
of
curious,
I?
Think
I
know
what
you're
talking
about,
because
we
were
talking
about
a
new
thing
that
was
going
to
be
called
sidecar,
which
I
thought
was
a
little
confusing
at
first,
but
but
yeah
like
a
first
class
citizen
and
what
sidecar
is
also
in
117.
We
have
ephemeral
containers,
they
didn't
cover
in
this
article,
but
that's
also
worth
talking
about.
A
It's
been
a
long
time
coming.
I
think
I
did
this
in
like
gosh
really
early
in
the
year
and
and
now.
Finally,
it's
up
so
go
check
that
out.
Let
me
know
what
your
thoughts
are.
I
hope
that
you
find
it
as
useful
as
I
intended
it
to
be
otherwise
we'll
see
how
it
goes.
Another
project
I've
been
working
on,
and
actually
this
is
a
project
of
VMware
project.
A
There
are
seven
episodes
up
and
these
episodes
are
generally
just
kind
of
exploring
the
area
of
of
communities
and
cloud
native
ecosystem,
not
too
dissimilar
from
TGI
K.
We
try
not
to
in
the
podcast.
We
try
not
to
delve
into
particular
solutions
but
more
to
expand
the
awareness
or
understanding
of
particular
problems
as
they
relate
to
this
whole
ecosystem.
So
if
that's
something
that
you're
interested
in
check
out
the
podcast,
we
were
very,
very
honored
to
have
Kelsey
Hightower
on
it
just
last
week
and
that
was
super.
Exciting.
A
We've
also
recorded
a
session
with
mr.
Joe
betta,
of
course,
and
a
number
of
other
sessions
with
other
members
of
our
team,
like
Josh,
Grasso
and
kaliesha,
and
just
a
ton
of
other
people,
so
go
check
out
that
if
those
are
interesting
to
you
and
now
we're
gonna
get
back
into
the
crazy
part
of
the
show
notes
all
right.
So
this
is
tea
tik.
So
there's
been
a
bunch
of
them.
A
Sorry,
this
is
the
grokking
series.
There's
been
a
bunch,
we
started
with
the
cubelet,
we
went
to
keep
proxy.
We
talked
about
controller
manager.
We
talked
about
the
scheduler
and
this
episode
we're
gonna
talk
about
API
server,
I'm,
not
totally
confident
that
we
can
get
through
the
entire
API
server
in
the
remaining
hour
and
a
half
that
I
want
to
spend
on
this,
but
we're
gonna
give
it
our
best
shot,
so
that'll
be
really
fun.
A
So,
let's
get
started
to
kick
this
off.
What
I'm
gonna
do
is
I'm,
going
to
spin
up
a
kind
cluster
and
create
cluster
and,
while
I'm
glad
to
kick
up
I'm,
actually
gonna
go
ahead
and
and
talk
about
how
some
of
this
stuff
works
and
then
I'll
show
you
like
on
disk,
where
we
could
find
some
of
that
stuff
to
work.
One
of
the
things
I
want
to
talk
about
here
is
this
document
here.
A
This
isn't
a
complete
implementation,
but
if
you
can
see
that,
like
a
user
when
they
create
a
pod,
is
that
pod
spec
gets
where
it
gets
sent
to
the
API
server
and
the
API
server
makes
a
bunch
of
decisions
like
pretty
much
right
away.
Right,
like
is
the
user
authenticated.
How
are
they
authorized
is
the
thing
that
the
user
gave
me
a
valid
spec.
You
know
it's
the
thing
that
they're
asking
me
to
do
valid
and
actually
is
the
thing
that
they're
asking
me
to
do
permissible.
A
But
fundamentally,
we
can
see
like
from
the
top
of
this
diagram,
but
the
API
server
is
responsible
for
being
that
thing
in
the
front
for
everything
right,
what
an
object
gets
persistent
to
the
API
went
gets
headed
to
the
API
server.
It
goes
through
all
the
computer,
all
of
the
the
process
of
determining
its
validate.
A
You
know
what
we're
talking
about
there:
the
authentication
authorization
validating
serializing
of
resources
all
of
that
stuff,
and
then
it
gets
persisted
back
to
SED
as
an
object
upon
admittance
and
then
what's
interesting
is
if
that
that
particular
transaction
is
now
done.
The
API
server
doesn't
spend
any
more
of
its
time.
Thinking
about
that
object
once
it
persists
it,
whether
that
object
is
a
deployment
or
a
stateful
set
or
a
pod
or
any
of
that
stuff.
A
It's
whole
job
is
basically
just
to
persist
that
object
to
NCD
and
get
it
through
that
terrain
of
things
or
or
tooling.
That
has
to
be
that
it
has
to
go
through
before
it
can
be
allowed
admittance,
but
the
API
server
also
acts
as
the
that's.
The
only
way
to
interact
with
that
stored
object
right
so
once
we
actually
have
a
pod
defined
that
metadata.
That
object
is,
of
course,
persistent
to
a
CD,
but
the
API
server
is
the
only
way
to
get
to
it
or
to
modify
it
or
to
interact
with
it.
A
But
fundamentally,
the
API
server
is
meant
to
be
somewhat
somewhat
stateless
in
its
capability
right.
We
want
to
be
able
to
have
multiple
API
servers,
all
talking
the
same
persistent
database
in
the
backend,
and
we
want
to
make
sure
that
we
can
scale
the
number
of
consumers
of
that
API
server
pretty
resilient.
You
know
pretty
pretty
pretty
reliably
right.
A
Thank,
You,
Suresh
I'll
take
a
look
at
that,
but
yeah
there's
like
there's
a
new
thing.
There's
a
new
kept
on
the
sidecar,
which
I
think
is
interesting
and
worth
talking
about.
Presumably
it
didn't
make
it
into
117,
which
is
what
Suresh
is
saying,
but
there
is.
There
is
a
new
first
class
object.
Today
is
the
sidecar
and
I
still
think
that's
a
little
confusing,
but
it's
definitely
worth
checking
out.
A
So
yeah
the
API
server
is
the
is
the
hinge
about
upon
this
whole
thing.
It's.
It
is
the.
It
is
the
way
that
we
interact
with
the
state
of
the
cluster
and
it
is
responsible
for
storing
any
number
of
different
objects,
whether
those
be
the
deployment
objects.
The
state
bill
objects
all
the
different
abstractions
that
we've
created
within
communities.
All
of
that
content
is
stored
in
the
API
server
and
pulled
from
the
API
server
for
those
resources
that
need
it.
A
Now,
let's
dig
in
a
little
bit
into
how
how
this
piece
would
work.
So
some
of
the
benefits
of
this
API
server
model
before
I
go
on
before
I
go
back
to
the
cluster.
We
look
at
like
how
these
things
are.
Interacting
are
the
idea
that
the
API
server
can
also
can
provide
a
number
of
different
ways
to
interact
with
the
objects
in
the
backend
right.
They
can
provide
a
restful
api.
A
The
api
server
provides
a
restful
api
to
interact
with
those
things
and,
of
course,
it
also
provides
an
OPA
open
api
document
to
describe
like
what
all
of
the
different
ways
to
interact
with
any
given
object
within
the
api
server
should
look
like
you
know
what
the
fields
are
necessary
and
like
what
optional
fields
there
are
and
we're.
Gonna
explode.
We're
gonna
explore
those
as
well,
but
there's
also
a
few
different
access
methods
for
four
objects.
A
Right,
like
you,
can
do
a
get
or
you
could
do
a
watch
and
the
watch
is
really
interesting
because
it
lets
us
do
a
thing
where
we
connect
to
an
API
server
and
we
maintain
that
connection,
and
we
tell
the
API
server
over
this
connection.
I
want
you
to
tell
me
when
anything,
changes
with
regard
to
the
resource
that
I
that
I'm
watching
right.
So
if
I
wanted
to
do
cubic
in
I'll,
get
pods
and
I
do
how
you
can
actually
exercise
this
with
keep
you
know
if
you
do
cube,
kettled
get
pods
W.
A
By
bike
or
DNS-
and
so
you
can
see
in
the
output
here-
that
the
because
I'm
doing
a
watch
I'm
only
notified
of
those
things
that
change
right,
and
so
this
is
a
different
model
for
interacting
with,
for
with
this
particular
object
store,
then
we
would
normally
see
in
some
of
the
other
databases
that
are
out
there
right.
So
we
have
different
ways
of
accessing
data
that
are
that
are
that
is
presented
or
that
are
that
the
API
server
is
persisting
all
right.
We
have
this
watch
mechanism.
A
A
So,
let's
go
back
to
our
notes
and
we
have
started
to
kind
of
get
into
theory
of
operation
a
little
bit.
I
want
to
come
back
to
and
just
start
with,
authentication
stuff,
so
we're
gonna.
First
we're
gonna
look
at
kind
of
like
how
the
API
server
itself
authenticates
two
things.
Then
we're
going
to
talk
about
how
the
API
server
handles
authentication
to
it
like
so
like
you
as
a
user.
How
do
you
often
it
kicks
the
API
server?
A
Then
we're
going
to
talk
about
how
authorization
works
right,
our
back
or
no
to
authorization
and
things
like
that.
We're
going
to
come
back
and
we're
going
to
revisit
admission
control
a
little
bit
now.
We've
talked
about
admission
control
a
few
times
in
in
TJ,
okay,
but
we're
gonna
explore
that
stuff
and
then
we're
gonna
get
into
exploring
the
API
as
it
is
presented
by
the
API
server,
like
some
things
that
we
can
look
into
and
see
how
they
work.
A
Like
you
know,
obviously
we
you've
heard
me
talk
about
cubic
it'll,
explain
a
million
times,
but
I'm
also
going
to
show
you
how
to
get
to
that
open
API
document.
If
you
want
to
explore
that
we're
going
to
talk
about
how
deprecation
works
within
the
api
server,
then
validating
meeting
web
hooks,
and
then
we've
already
begun
this
one
we're
obviously
gonna
do
more
there,
but
I
just
wanted
to
kind
of
get
off
to
the
get
off
on
the
right
foot
there.
A
A
In
previous
episodes
of
the
rockin
series,
I've
shown
you
this
as
well
so
I'm
going
to
just
executor
my
kind
control
plane,
which
is
like
jumping
into
the
node,
where
my
API
server
is
run
now
inside
of
the
way
that
cube
ATM
brings
up
a
cluster,
it
brings
up
a
cluster
by
creating
a
folder
called
SE.
Kubernetes
manifests
and
it
specifies
the
some
static
pod
manifests
that
are
gonna,
handle
the
control,
plane,
components
and
the
cube
api
server
is
one
of
them
right.
A
A
Here
are
a
bunch
of
different,
interesting
fields
here,
because
the
API
server
is
so
important
in
the
grandeur
in
the
big
picture
of
how
kubernetes
works,
there's
a
ton
of
like
really
important
things
that
happen
with
the
flags
so
as
usual,
if
you're
curious
about
getting
into
the
flags
and
what
they
mean
and
how
they
work
definitely
go
check
out
the
dock
for
the
API
server
right.
So
we
have
that
here
we
just
do
dock
stockades,
io.
A
Our
reference
documentation
is
pretty
decent
for
this
stuff
and
it
really
describes
a
lot
of
the
different
flags
that
you
can
provide
that
you
could
provide
to
the
api
server
so
including
things
like
how
many
API
servers
there
are.
What
API
audience
is
that
we're
gonna
watch
for
it
I
mean
there's
a
ton
of
stuff
in
here
and
I'm.
Obviously,
not
gonna
spend
the
next
two
hours
going
flag
by
flag
here,
but
you
know
clearly
there
are
a
bunch
of
things
that
the
API
server
does
that
are
configurable
on
the
command
line.
A
Things
like
you
know
whether
you
want
to
turn
on
audit
logs
and
when
you
do
turn
on
audit
logs.
Do
you
want
to
handle
the
automatic
rotation
of
those
logs
and
how?
How
big
do
those
logs
get
before
you
like
change
them,
if
you're
using
a
mechanism
to
actually
send
or
emit
those
events
that
the
audit
log
might
watch
how
you
know?
How
long
do
you
wait
for
it
to
go
so
there's
audit
log
stuff,
there
is
authorization
stuff.
Obviously,
a
lot
of
this
stuff
is
configurable.
A
This
is
one
of
the
defaults
that
I
know
that
makes
Joe
crazy.
It
kind
of
makes
me
crazy
too.
This
is
a
the
authorization
mode
by
default
is
always
allow
I've
got
aware
of
pretty
much
any
kubernetes
cluster
anywhere
that
uses
that,
in
fact,
most
of
them
use
are
back
in
node
together,
but
yeah
like
by
default
its
let
it
all
in.
So
if
you
started
an
API
server,
it's
gonna,
it
has
no
authorization
by
default.
A
This
allows
anybody
to
come
in,
but
fortunately
that's
not
the
that's,
not
typically,
what
people
do
your
bind
address
by
default?
It's
listening
on
all
interfaces,
the
directory
where
you
can
find
certificates.
The
client
see
a
string
all
of
these
things.
You
know
kind
of
makes
sense
when
you
think
about
the
way.
You
know
what
the
response
are,
what
the
API
server
is
responsible
for.
You
have
the
default
wash
cache
size.
So
when
somebody
has
a
cache
or
a
watch
happening,
the
question
becomes
like
how
long
how
about?
A
How
long
does
the
API
server
cache
a
particular
object,
as
it
relates
to
that
watch?
It
is
pretty
cool,
you've
got
admission,
plugins
and
we're
going
to
talk
more
about
these.
This
is
actually
a
really
important
thing
to
understand,
because
there's
not
one
of
the
things
that
is
a
little
frustrating
about
the
API
server
and
I'm,
actually
gonna,
try
and
see
if
I
can
get
this
fixed
myself
in
2020,
there's
not
a
way
for
you
to
enumerate.
A
The
reason
I'm
calling
this
out
is
because
sometimes
it's
difficult
to
determine
whether
these
defaults
have
changed
and
if
they
have
changed
like
how
do
you
determine
like
which
ones
are
enabled
or
not
enabled,
and
the
and
really
right
now.
The
most
concise
way
is
by
looking
at
the
command-line
options
that
were
used
when
spinning
up
the
API
server
to
begin
with.
A
Other
stuff,
the
API
server
does.
Obviously
it
needs
to
talk
to
NCD,
but
there's
some
other
interesting
things
here,
for
example,
this
EDD
prefix
string
right.
You
can't
do
a
thing,
for
example,
where
yeah
I
agree
with
you
and
that's
what
I
think
that
some
of
the
Suresh
I
agree
with
you
and
one
of
the
things
I
want
to
work
on
in
2020
is
actually
extending
the
recall
that
configs
II
endpoint
to
include
oh
yeah.
We're
gonna
talk
to
a
little
bit
more
about
admission,
plugins
here,
just
a
second,
but
it's
not
a
stupid
question.
A
A
Interesting
stuff,
sorry
about
that
bet,
City
uses
em
TLS
right,
so
when
we're
actually
so
part
of
the
configuration
flags
for
sed
is
to
provide
a
client
certificate
that
will
be
used
to
authenticate
to
sed,
and
so
there's
some
of
the
information
that
we
can
do
with
some
of
the
information
that
we
can
pull
for
by
default.
The
API
server
will
compact
NCD
every
five
minutes.
A
If
you
said
to
zero,
it
won't
but
yeah,
there's
tons
of
stuff
configuring
sed,
obviously,
and
then
there's
a
bunch
of
feature
gates
for
things
that
are
relatively
new
or
older
or
things,
and
you
can
see
what
the
defaults
for
all
of
them
are
here
too,
and
especially
as
they
graduate
we
have
and
I
think
this
is
also
interesting.
How
do
you
only.
A
It
is
really
nice
and
there
are
examples
online
for
how
to
do
that.
I'm-
probably
not
going
to
explore
that
in
this
session,
but
if
that's
something
you're
interested
in
having
a
session
on,
go
ahead
and
open
an
issue
with
the
tgia
repo,
and
perhaps
we
could
actually
just
do
a
session
just
on
that
I
think
that
would
be
great.
If
that's
something
you're
interested
in,
we
also
have
the
API
server.
A
It
needs
to
authenticate
to
cubelet
and
I'm
curious
I'm
gonna
pull
the
crowd
here,
because
this
is
an
interesting
one,
especially
if
you
think
about
the
way
that
we'd
normally
talk
about
the
API
side.
Where
we
talk
about
everybody
talking
to
the
API
server,
we
talked
about
the
API
sir
we're
talking
to
sed,
but
we
also
have
a
few
cube
keto
commands
where
the
API
server
has
to
talk
to
the
cubelet
and
I'm
curious.
A
Can
you
all
can
my
awesome
audience
list
the
cube
kettle
commands
where
we
have
to
actually
have
the
API
server
authenticate
to
the
cubelet
to
allow
for
some
communication
back
to
back
to
pots
logs
execu
logs
are
definitely
it
logs.
An
exec
are
both
keep
kettle
proxies
a
tricky
one.
Actually,
Kapila
proxy
doesn't
can
proxy
directly
from
the
API
server.
It
doesn't
necessarily
have
to
go
through
there.
Cp
is
another
one
which
we're
going
to
copy
a
file
in
or
out
of
a
pod
anything
you
have
to
actually
interact
with
the
pod
level
thing.
A
A
A
A
It
would
actually
just
use
like
the
internal
implementation
of
proxy
to
do
that.
So
other
stuff,
you
know
bunch
of
other
commands,
and
this
is
another
big
one.
How
do
you
and
we're
going
to
talk
about
this
here?
Next?
How
do
we
authenticate
to
the
api
server,
some
of
the
more
common
methods
that
I've
seen
involve
oh
I,
DC
and
we'll
talk
about
how
OID
C
works
here
a
little
bit
as
well
yeah,
alright
enough
time
on
the
main
page?
A
Node
I
can
see
that
my
Etsy
Deakin
servers
are
configured
at
one
to
seven:
zero,
zero
one,
two
three,
seven
nine-
and
that
means
that
I
have
to
make
the
assumption
that
the
EDD
cluster
is
local
and
that
there's
only
just
the
one
member
probably,
although,
if
I
do
specify,
only
one
member
there
are
other
members
will
be
learned.
If
there
are
multiple
members
in
NCD,
there
is
vendored
into
the
API
server
of
fully-fledged.
That's
an
e
client
right.
So
this
isn't
necessarily
like
just
curl.
You
know:
RESTful
API
calls
to
NCD.
A
So
we
can
see
that
we're
expecting
the
sed
servers
to
be
signed
by
some
esidisi
a
cert,
and
we
can
see
that
our
certificate,
our
sed
client
certificate,
has
been
given
to
us
at
a
particular
path
and
there's
our
Keef,
our
Keef,
our
s,
any
client
key
all
right,
and
so
this
actually
gives
us
all
the
coordinates
to
interact
with
SED.
And
this
is
how
it's
going
to
authenticate
to
entity.
Now
the
SD,
the
SD
cluster
itself,
doesn't
authenticate
to
the
API
server.
A
All
of
that
in
mind,
because
this
is
running
as
a
pod-
that
we
can
actually
see
the
logs
of
the
API
server
just
by
seeing
the
output
of
those
logs
right
so
because
this
is
running
inside
of
a
container
I
could
see
that
container
running
here
and
if
we're
curious
about
digging
into
the
logs
for
those
things,
we
can
do
CI
catalogs
and
we
can
take
a
look
at
what
the
log
output
looks
like
for
forgiving
before
a
given
cluster
right.
So
this
is
running
116
3.
A
So
looks
like
some
of
the
logs
are
actually
kind
of
scrolled
up
a
bit,
but
we
can
see
kind
of
the
starting
up
here
and
we
can
see
you
know
in
the
log.
We
get
information
about
like
the
mutating
admission
controllers
that
have
been
registered,
mutating
ones
that
have
been
configured
and
these.
This
means
that
these
particular
built-in
admission
controllers
that
have
you
have
the
ability
to
mutate.
A
An
object
have
been
registered
and
then
we
have
validating
admission
web
hooks
that
have
also
been
loaded
in
the
print
in
this
particular
order,
and
then
we
go
through
like
what
else
is
happening
right.
So
we
can
see
that
we've
got
a
connection
error
to
an
city.
Presumably
maybe
it
just
wasn't
up
yet
but
soon,
but
when
it
came
up
after
after
a
time
and
then
we
can
just
walk,
walk
through
the
rest
of
the
log
and
see
what
else
is
happening,
we
could
see
the
caches
are
syncing.
A
We
have
the
namespace
condition:
controller
loading
up,
there's
about
all
of
the
different
controller
logic
that
is
specific
to
the
API
server
is
starting
to
bounce
it's
starting
to
come
up.
We
have
our
open
API
aggregation
controller
starting
up,
and
this
is
where,
if
you're
going
to
register
a
different
C
RDS
and
those
sorts
of
things
like
how
the
API
server
knows
that
those
objects
are
going
to
be
aggregate,
it's
a
is
done
through.
This
object,
be
a
priority
class.
Registering
we
have
the
quota
admission
controller
or
adding
an
evaluator
for
roles.
A
Obviously
one
of
the
things
you
can
do
just
like
we
did
before
in
a
previous
episode.
If
you
were
to
edit
the
SE
kubernetes
manifest
Kubb
api
server,
manifest
itself
and
just
add
the
flag
v
right,
then
you
could
specify
the
verbosity
of
the
logs
provided
by
the
api
server,
and
so,
if
that's
something
you're
interested
in
digging
more
into
or
seeing
more
verbose
logs
with
relation
to
the
API
server
or
may
even
just
one
of
the
API
servers
in
your
cluster.
A
It
does
actually
yes,
so
the
way
that
cube,
API
server
is
going
to
authenticate
2/8
at
CD.
It's
going
to
you
know
it's
it's
like
think
about
like
m
TLS
cuz,
it's
pretty
similar
to
that
right.
I,
have
a
client
certificate,
I'm
going
to
try
and
authenticate
to
ed
CD.
As
he's
going
to
return
to
me,
its
certificate
I'm,
going
to
validate
that
the
certificate
provided
to
me
by
the
sed
server
is
actually
signed
by
that
known
CA.
That's
actually
where
the
CA
file
comes
in
all
right,
so
I
think
this
one
here.
A
If
it
is
all
things
are
good.
If
it
is
not,
then
I
won't
allow
I
won't
connect
to
it
and
the
same
thing
works
on
the
other
side
right.
The
SCE
cluster
is
actually
going
to
take
a
look
at
this
sed
client
that
is
being
provided.
I,
see,
clients,
shirt
provided
by
the
API
server,
and
it's
going
to
say
is
that
signed
by
a
known
CA,
and
if
it
is,
then
it
will
allow
it
access.
But
that's
the
extent
of
permission
right
sed
is
not
typically
configured
with
any
more
granularity
than
that.
A
A
Nope
still
there,
but
it
doesn't
doesn't
seem
to
be
working
terribly
well,
but
keep
going
to
get
component
statuses
actually
gives
us
the
ability
to
kind
of
like
interact
with
whether
other
things
are
working.
I
think
these
are
there's
a
deprecated
down,
it'll
be
removed
soon,
but
there
are
other
ways
to
get
the
API
server
to
tell
you
about
these
things.
A
A
And
so
some
of
the
things
that
we
can
do
are
determine
things
like
object
counts
right,
so
we
can
actually
look
at
the
way.
The
AP
from
the
API
servers
perspective
like
how
many
objects
are
being
stored
in
a
CD.
We
can
look
at
things
like
it's
any
requests
agencies,
there's
a
ton
of
information
that
the
the
API
server
instruments
in
with
relation
to
its
interaction
with
the
sed
cluster
itself,
and
so,
if
you'd
want
to
understand
more
about
the
relationship
between
or
if
you
want
to
instrument
better.
A
The
relationship
between
your
API
servers
and
your
ED
CD
clusters
definitely
take
a
look
at
the
metrics
that
are
exposed
by
the
API
server
and
also
the
metrics
that
are
exposed
by
NCD
directly.
Both
of
them
are
instrumented,
with
Prometheus
and,
and
so
both
of
them
are
available
to
scrape
with
your
Prometheus
instance
and,
to
you
know,
measure
like
latency
responses
and
all
of
the
other
stuff,
as
it
relates
to
just
understanding
the
care
and
feeding
of
the
cluster.
A
What's
neat
about
the
way
this
is
instrument,
it
is
it's
instrumented
in
a
pretty
complete
way
right,
like
you're,
not
you're,
you're
getting
Layton
sees
as
it
relates
to
things
like
config
Maps,
not
just
the
overall
latency
to
the
system,
but
also
latency
by
path.
Right
and
so
we're
able
to
see
things
like
you
know
is
the
is
the
latency
to
the
events
path
creeping
up.
Are
we
starting
to
see
the
number
of
events
overwhelmed?
The
ability
for
the
sed
cluster
to
manage
manage
it
as
it
relates
to
disk
I/o,
for
example
right.
A
A
A
A
The
API
server
is
going
to
get
its
own
client
key
to
authenticate,
to
the
cubelet
directly
and
on
the
cubelet.
Typically,
the
cubelet
will
be
configured
to
validate
that
that
client
key
is
signed
by
some
known
CA,
so
a
very
similar
pattern
to
the
way
that
Exedy
works
right.
So,
for
example,
if
I
look
at
my
my
my
cubelet
here
cat,
it's
the
C
systemctl
cat,
cubelet
I,
look
at
the
Q
a
config.
A
So
the
way
the
API
server,
typically
authenticates,
to
the
eve
to
the
cubelet,
will
be
using
a
certificate
and
with
that
certificate
we're
just
making
on
the
cubelets
ID
we're
just
validating
that
the
certificate
is
signed
by
some
known
CA
right
and
then,
above
that
we
have
this
thing
called
web
hook
where
we
actually
handle
things
like
we're,
where
we
were
able
to
validate
things
like
tokens.
Also
right.
A
So
if
you
had
a,
if
you
had
a
service
account
token
that
had
the
right
are
back
privileges
to
authenticate
to
the
cubelet,
then
you
would
also
be
able
to
use
a
token
to
authenticate
to
the
api
server
to
the
cubelet,
and
we
talked
about
some
of
these
things
back
in
a
cubed
episode,
so
I'm
not
going
to
spend
too
much
more
time.
There.
A
A
A
A
Something
like
iron
or
something
like
that.
I
can
remember
the
company,
but
yeah.
If
you
look
for,
if
you
look
for
articles
on
large
clusters,
there's
definitely
some
really
good
ideas
on
how
to
do
it.
At
the
same
time,
I
personally
I
think
that
we
are
better
off
operating
smaller
clusters,
even
with
the
added
expense
of
being
able
of
having
to
administrate
them
over
time,
for
a
number
of
reasons,
but
probably
not
going
to
dig
into
that
here,
all
right,
so
authentication,
Docs.
A
So
this
is
a
link
to
the
docs
for
here
and
there's
some
other
there's
some
ton
of
interesting
things
that
we
can
do
with
authentication
inside
of
the
API
server
right
so
typically
again,
there's
an
option
for
the
API
server
to
just
take
an
animus
off
vacation
for
things,
and
we
can
see
that
in
the
form
of
things
like.
Oh
sorry,
wrong
button.
A
A
That
isn't
an
anonymous
API
call,
so
I
was
actually
just
me.
I
made
a
call
to
the
API
server
with
no
authentication
and
the
anonymous
API.
The
anonymous
allows
me
to
do
that
because
I
have
my
health,
the
endpoint
turned
on,
but
what,
if
I
did
v1
right,
then
we
can
see
that
what
I'm
getting
back
from
the
the
cluster
is
that
the
user
system
anonymous
since
it
doesn't
know
who
I
am
I'm,
not
providing
it
any
credential
it
needs
to
be
able
to.
A
A
So
this
is
kind
of
exploring
the
authentication
part
of
of
the
API
server.
Now
for
me
to
authenticate
to
the
API
server.
I
have
a
number
of
different
options.
Right
I
can
authenticate
with
a
certificate.
I
cannot
send
a
Kate
with
a
service
account
token.
A
JWT
I
can
now
Sena
Kate
via
Oh
IDC,
which
is
still
using
a
JWT
just
issued
by
some
middleware.
A
But
fundamentally,
these
are
the
the
typical
ways
that
one
authenticates
to
the
api
server
there's
also
a
an
authentication
method
in
the
bootstrap
token.
So
the
way
that
cube
ATM
provides
a
bootstrap
token
that
token
can
be
used
to
authenticate
to
the
API
server
as
well.
Although
it's
generally
locked
down
to
just
those
actions
that
are
required
by
bootstrap.
A
A
A
A
So
in
this
configuration
I
provide
it
bundled
into
this
cube,
config
right,
it's
the
CA
certificate
and
that's
necessary,
because
this
will
allow
me
to
understand
again
whether
when
I'm
authenticating
to
the
API
server
is
the
certificate
it's
presenting
to
me
as
a
serving
certificate
assigned
by
this
CA
right.
So
this
allows
me
to
explicitly
trust
any
certificate
serving
certificate
provides
me
as
long
as
they
are
signed
by
that
certificate
authority.
A
Next
up.
We
have
the
client
certificate,
that's
going
to
be
used
to
authenticate
to
the
API
server
and
there's
a
couple
of
interesting
things
about
it.
That
I
want
to
share
with
you
just
to
understand
the
client
certificate
itself.
The
client
certificate
all
right,
so
I'm
going
to
go
ahead
and
dump
this
to
base64
or
minus
D,
and
then
I'll
pass
the
output
of
that
to
open
SSL
x.509
text.
A
What
I've
done
here
is
I've
grabbed
the
certificate
from
the
client
certificate
data.
Inside
of
my
cube,
config
I've,
decoded
it
using
base64
that
left
me
with
a
certificate
and
then
I
passed
that
certificate
to
open
SSL.
So
we
could
look
at
how
the
certificate
is
actually
configured
and
there's
some
interesting
stuff
that
happens
here
in
the
way
that
that
certificate
is
encoded,
which
includes
things
like
kind
of
providing
hints
around
how
we
tie
this
certificate
into
our
back
in
certificate
authentication
to
the
API
server.
A
We
look
at
these
two
fields:
right,
the
oh,
the
subject
organization
and
the
subject:
client
name.
If
the
organization
is
system
masters,
then
there's
a
group
that's
predefined
within
the
API
server
as
part
of
our
back,
that
provides
system
masters,
an
incredible
amount
of
access
and
we
and
the
custom
and
the
client
name
if
I
wanted
to
actually
just
associate
a
particular
our
back
role,
binding
or
cluster
role.
Binding
I
could
actually
bind
that
to
kubernetes
admin
and
as
long
as
I'm,
using
this
certificate
common
name.
A
Sorry,
yes,
as
long
as
I'm
using
this
certificate
to
authenticate,
then
that
common
name
will
be
the
way
that
I
can
tie
the
authorization
in
as
well.
So
certificates
are
interesting
because
encoded
inside
of
them
in
that
subject,
line
right
is
is
the
way
that
is
enough
information
to
represent
how
we're
going
to
kind
of
provide
hints
or
anchor
the
authorization
aspect
of
this
as
well,
and
that's
true
of
tokens
as
well,
but
we'll
talk
about
that
a
little
bit
now
further
down.
We
can
see
that
this
certificate
is
actually
signed
specifically
for
client
authentication.
A
I
couldn't
use
this
certificate
as
a
server
certificate,
but
this
is
kind
of
getting
into
some
of
the
TLS
stuff,
probably
not
really
worth
digging
into
in
this
particular
episode,
but
interesting
stuff
in
of
us
now
by
default-
and
we
talked
about
this
before
as
well
in
the
all
of
your
search
that
have
expired
episode
that
happened
earlier
this
year
by
default.
We
issue
a
certificate
of
the
cluster
for
for
one
year
for
the
admin
comp,
but
there
is
no
revocation
right.
A
So
there's
no
revocation
list
for
certificates
that
are
issued
by
the
CA,
which
means
that
when
you
issue
a
certificate
leveraging
the
cluster
CA
you're
able
to
provide
a
certificate
that
will
last
a
year
typically
by
default,
and
that
means
that,
if
you
wanted
to,
if
that,
if
that
certificate
becomes
compromised,
if
somebody
gets
ahold
of
that
certificate,
there's
no
way
for
you
to
shut
it
down
other
than
to
change
the
actual
certificate
authority
in
the
cluster.
You
can't
like
just
say
that
certificate
that
was
the
Cooper
dude
is
for
that
particular
group.
A
It's
no
longer
viable,
there's,
no,
there's
no
revocation
list
that
is
being
watched.
So
keep
that
in
mind
when
you're
thinking
about
certificate
authentication
to
kubernetes
certificate,
I.
Think
a
authentication
in
kubernetes
is
somewhat
limited
capability,
because
you
can't
revoke
them.
You
can't
revoke
them.
Now,
let's
look
at
another
one.
There's
a
leave,
I
think
a
little
more
interesting
I'm
going
to
go
ahead
and
create
a
service
account
here
and
I'm
going
to
create
associated
with
that
service,
account
a
row
binding
so
cluster
or
create
cluster
role,
binding
test
admin,
cluster.
A
Service
account:
do
you
fault
test,
so
what
that
does
is
it
creates
I've
created
a
service
account
called
tests
and
I've
created
a
cluster
role,
binding
binding
the
cluster
admin
privilege
to
the
service
account
located
in
the
namespace
default
that
is
name
to
test.
So
the
next
thing
I'm
gonna
do
is
I'll
use
this
create
queue,
config
script,
just
to
generate
a
queue
config
leveraging
that
token.
So
let's
just
do
that
real,
quick.
A
Is
interesting
that
the
token
isn't
expired
and
it's
also
interesting
that
the
token
is
that
some
of
the
other
fields
are
in
here,
including
this
one
here,
where
we
specify
the
key
ID
or
the
thing
that's
signed
it
right,
and
so
this
gives
us
the
ability
to
validate
that
the
signature
of
the
token
is
signed
by
some
known
key.
Does
anybody
know
what
key
is
signing
this
particular
service
account
and
JWT
pop
quiz.
A
A
The
typically
what
that
means
is
that,
when
you're
issuing
a
certificate
when
you're
issuing
a
token
some
of
the
other
fields
that
you
can
specify
are
things
like
expert
so
like
if
you're
going
to
generate
a
token
using
an
OID
C
mechanism
like
I,
don't
know
like
Google
or
any
Ardex
or
any
of
these
other
tools
right,
you
can.
Actually,
you
can
specify
the
the
expert
of
that
token,
and
when
you
do
then,
when
that
token
expires,
the
API
server
will
no
longer
honor
it.
A
Now,
if
I
do
keep
kettle
get
pods
a
cube
config
who
config
tests
I
could
see
that
token
exists
and
that
and
I'm
allowed
to
authenticate
with
it
right.
But
what's
gonna
happen
when
I
do
this,
this
will
be
interesting.
This
is
actually
one
of
the
things
I
like
about
service
account
tokens
delete
secret
tests,
I'm
going
to
delete
the
token
associated
with
the
service
account
and
as
soon
as
I
do
that
and
I
do
cube
head
I'll
get
secrets.
I
can
see
the
token
has
been
regenerated.
A
It's
got
a
different
like
hash,
but
it's
a
brand
new
token.
It's
only
four
seconds
old
now,
but
now
the
token
that
I
had
in
my
cube
config
is
no
longer
viable
because
I
deleted
it
in
the
cluster.
So
what
happens
if
I
do
that?
Get
a
again
right?
It's
still
signed
by
a
known
authority,
but
we
don't
know
it
anymore.
So
this
is
how
you
can
quickly
revoke
access
to
a
cluster.
If
you
have
a
service
account
token
or
an
OID
see
token
some
mechanism,
like
that
and
you're
able
to
actually
revoke
that
token.
A
Then
you
have
the
ability
to
actually
in
an
easier
and
more
real.
You
know
easier
way,
manage
the
access
credential
to
the
API
server
in
a
more
revocable
way,
so
cool,
that's
authentication
for
the
certificate.
For
the
token,
and
actually
also,
let's
just
jump
back
in
here,
real
quick
and
we'll
talk
about
bootstrap,
talking
really
fast,
okay,
Etsy
kubernetes.
A
So
in
the
tokens
that
are
actually
stored
in
bootstrap
tokens
and
if
we
jump
out
here,
we
do
cube
Ketel
get
took
in
a
no
it's.
It's
still
a
secret
and
cubes
system.
A
A
This
token
that
is
actually
put
in
here
and
it's
X
free
and
it's
token
ID
and
all
that
stuff,
it's
actually
just
encoded.
So
if
we
did
describe
I,
think
it'll
decode
it
for
us.
Let's
try
that
described
there.
We
go
well,
not
quite,
but
you
get
the
idea,
so
you
can
actually
pull
these
things
and
decode
them
and
take
a
look
at
them,
but
those
bootstrap
token.
This
can
be
time
bound.
They
can
talk
about
what
their
access
is
and
those
tokens
are
used.
A
Is
this
cube
contain
token
it's
Auto
approved
for
test
user.
Well,
only
because,
as
an
administrator
I
created
it
right,
so
as
an
administrator
I
created
a
new
service
account
when
I
pulled
that
token
associated
with
that
service
account
down,
and
then
I
used
that
as
part
of
my
cue,
fake,
the
s
icky
and
sa
pub
do
not
expire.
In
fact,
if
you
had
all
of
the
other
certificates
expire,
those
tokens
that
took
it
off
an
occasion.
A
Method
mechanism
would
continue
to
work,
even
though
there's,
if
it
gets,
might
have
expired,
the
token
itself
would
still
work
as
long
as
it's
still
defined
within
the
system
and
the
API
server
can
validate
that.
That
token
is
still
there.
So
if
your
sed
client,
if
you're
at
CVS
or
Drake
it
expired,
that
would
hit
you.
But
you
know
the
token
itself
would
not
alright,
let's
get
back
into
our
list
here.
A
We
talked
about
how
authentication
and
authorization
authentication
works,
the
cube
the
components
use
different
things
and
we
I'm
not
going
to
get
into
it
here
in
this
session,
but
like
the
way,
the
controller
manager
authenticate
side
covered
in
the
controller
manager,
episode
and
the
way
the
cubelet
authenticate
we
covered
in
the
cubelet
episode
go
check
those
out
if
you're
curious
more
about
them.
We've
talked
about
the
way
that
people
in
BOTS
my
authenticate
rights,
you
can
use
service
account
tokens,
you
can
use
certificates,
but
I,
don't
recommend
it.
A
A
So
that's
the
authentication
piece
from
the
API
service
perspective,
more
information
in
the
docs,
and
if
you
want
to
explore
more
of
it,
obviously
you
know
one
of
the
things
that
we
can
really
do
dig
into.
It
would
be
to
bump
the
authentically
verbosity
of
the
cubit
API
server
logs
up
and
then
do
things
like
issue
tokens
or
delete
them
or
try
to
authenticate
one
more
thing
before
I
go
on
here,
I'm
going
to
go
ahead
and
re-read
gather
that
took
in
cube
cat
off
yet
odds.
A
So
we
can
see-
let's
see
about
the
v10
thing,
as
you
can
see
this
piece
right
and
so
what's
neat
about.
That
is
that
you
can
see
that
when
I
am
authenticating
with
a
token
I'm,
actually
using
this
off-center
authorization
bearer
mechanism
to
authenticate
I'm,
not
using
just
straight
certificate,
authentication
I'm,
actually
using
the
token
as
a
bearer
token,
when
interacting
with
the
API
server.
A
So
that's
one
of
the
things
that's
one
of
the
other
differences
so
token
is,
is
even
materially
a
different
way
of
authenticating
to
the
API
server,
then
using
a
certificate
using
a
certificate.
We
just
basically
say
we
talked
to
the
API
server.
We
say
here
is
our
client
certificate.
The
API
server
pulls
that
open
and
it
looks
at
the
the
organization
and
common
name
and
then
proceeds
from
there
with
the
token
mechanism.
A
A
A
A
So
yeah,
basically
you
know
today,
once
once
you
have
been
authenticated
to
the
API
server.
We
go
through
a
process
to
determine
whether
the
request
you
made
is
allowed
or
denied
right,
and
so
we
could
do
that.
We,
we
have
a
bunch
of
information
to
to
parse,
to
determine
that
right.
We
pull
apart
the
request
and
then
we
validate
that
against
the
user
or
group
associated
with
that
request
and
the
our
back
rules.
That
are
the
sum
of
permissions
that
that
particular
user
or
group
has
went
authenticating
and
we've
talked
I.
A
A
Auth
can
I,
so
keep
cattle
off
at
can
I
allows
you
to
request.
Weather
weather
allows
you
to
interrogate
the
API
server
with
regard
to
things
that
you
may
or
may
not
be
able
to
do
right.
So
if
I
were
to
do
cube
kettle
off,
can
I
and
I
do
lists
as
an
administrative
user?
I
can
see
exactly
what
permissions
I've
given
right
this
one
up
here
at
the
top,
it's
the
big
one,
because
it
means
that
I
have
full
access
to
do
anything
right.
A
A
A
So
this
is
a
way
of
actually
validating
or
understanding
what
permissions
are.
Scoopa.
Permissions
have
been
granted
to
a
user
based
on
some
identification
of
that
user
right
so
like
in
this
case.
It's
a
service
account,
but
if
you
had
that
user's
name,
you
might
be
able
to
do
as
that
user
name
or
as
group
there's
another
option
there,
but
this
gives
us
the
ability
to
explore
like
exactly
what
that
particular
entity
can
do
what
permissions
have
been
granted,
and
this
is
a
really
good,
clear
way
of
understanding
from
the
rback
perspective.
A
What
permission
you
have
so
we
can
see
that
the
default
service
account
has
things
like
the
ability
to
create
self
subject,
access
reviews
and
the
rules,
reviews
which
is
actually
the
mechanism
that
we
use
to
see
this
output.
They
can
do
things
like
get
api's,
they
can
get
health
checks,
they
can
to
get
lives,
they
can
get
the
open,
API
spec
and
they
can
get
Reddy's
and
they
can
get
version,
but
there's
not
much
more
much.
They
can
do
right.
They
can't
create
pods
or
create
namespaces,
or
do
anything
else
like
that.
A
A
Inside
the
docs
and
I
have
a
link:
I
have
a
link
in
there,
but
it
basically
no
author
Iser
allows
a
cubelet
by
its
identity
to
access
specific,
read
operations
and
write
operations
only
as
they
relate
to
that
node
and
the
good
thing
about
this
is:
it
means
that
were
limiting
the
blast
radius
if
somebody
gets
a
hold
of
a
cubelet
certificate
and
they
won't
be
able
to
use
that
cubelet
certificate
to
exploit
the
cluster
that
can
really
only
use
it
to
interact
with
things
that
are
specific.
To
that
note,.
A
Are
you
talking
about
authorization
and
mission
control?
Then
we
can
get
through
admission
control
in
this
next
piece.
Yeah,
let's
try
it
and
actually
you
know
it's
2:30
I'm
going
to
stop
here.
I'm
gonna
come
back
and
explore
all
the
rest
of
this
stuff
in
the
next
time.
You
know
in
our
next
episode
on
the
API
server,
so
this
is
v1
of
the
API
server
I
had
a
strong
suspicion
that
we
would
not
be
able
to
get
through
it
all
in
in
one
episode,
but
it
is
what
it
is.
A
We
will
revisit
this
in
the
new
year,
probably
after
episode,
100,
so
I
think
I
mentioned
this.
In
the
beginning
of
the
episode
episode
100,
we
really
have
some
cool
stuff
planned,
we're
going
to
be
I'm,
looking
forward
to
seeing
how
it
materializes,
but
our
goal
is
to
have
a
very
special
episode
100.
It
will
happen
on
January
10th.
A
It's
not
going
to
happen
like
next
week.
It's
gonna
be
we're
gonna,
take
a
break
over
the
holiday,
we're
gonna
come
back
on
January
10th
and
do
the
next
episode
of
TGI,
K
and
I.
Hope
that
you
were
all
able
to
attend.
It'll
should
be
really
super
fun.
Thank
you
very
much
for
attending
v1
of
the
or
you
know,
part
one
of
a
two-part
cube,
API
server
exploration.
So
far,
all
we've
really
been
able
to
talk
about
is
how
we
authenticate
to
it
and
how
it
authenticates
to
things.
A
Obviously,
there's
a
bunch
more
to
talk
about.
So
thank
you.
Thank
you.
Thank
you.
I
look
forward
to
doing
a
lot
more
of
a
lot
more
of
the
exploration
of
the
API
server
next
time
you
all
have
a
great
weekend
and
a
great
holiday
break
and
there's
a
ton
of
content
out
there
to
just
you
know,
study
up
on.