►
From YouTube: KCSNA22 - Technical Values of the Kubernetes Community
Description
Speaker: Sergey Kanzhelev
Every Community is defined by its values. It attracts people thinking alike and people evolve these values. In this session we will try to formulate Kubernetes Technical values. When making a technical tradeoff do we care about performance or consistency, opinionated API or generalization, taking dependencies or pushing dependencies. The session will have an intro that will put some structure to the discussion and will be an open discussions forum from there.
A
A
I
will
try
to
be
like
short
and
then
have
opportunity
to
discuss
something.
I
also
wanted
to
say
in
advance.
I
will
exaggerate,
sometimes
don't
take
any
offense.
Please
just
tell
me
if
I
did
something
I
mean
exaggerated
too
much,
but
yeah
I
didn't
mean
any
anything.
Bad
and
I
I,
don't
like
the
slides
about
myself
and
this
photo,
but
I
wanted
to
highlight
couple
of
things.
A
So
I
put
the
side
in
so
first
of
all,
I
wanted
to
highlight
that
I'm
only
with
kubernetes
with
for
two
years,
so
in
kubernetes
years
and
seeing
contributors
who've
been
here
from
the
beginning,
I
can
say
that
I,
don't
know
everything
and
I
know
very
small
portion
of
everything.
So
me
talking
about
technical
values
of
kubernetes
is
like
yeah.
I
I
saw
something,
but
I
haven't
seen
everything.
A
So,
if
I'm
making
mistake
I'm
going
wrong
direction,
you
you
let
me
know-
and
this
is
specifically
my
view
on
that-
and
I
also
wanted
to
highlight
that
I
have
some
standing
in
open
source.
I
was
with
open,
telemetry
and
I
was
a
co-founder
of
open
Telemetry.
The
second
largest
project
in
cncf,
so
I
know
a
little
bit
about
values
and
I
know
how
to
how
communities
works
so
a
little
bit
of
standing
so
and
my
other
contact
information.
A
If
you
want
to
discuss
further
and
again
with
working
with
open
source
working
with
different
platforms
and
communities,
I
started,
seeing
more
and
more
of
the
fact
that
everybody
is
a
great
engineer
like
after
a
few
years
into
engineering,
you
become
good
in
design.
You
become
good
in
coding,
so
you
don't
have
problems
of
expressing
yourself
what
people
typically
struggle
with
to
become
great,
is
when
their
values
don't
don't
match
the
values
of
the
project.
They
apply.
A
This
values
in
apply
their
contributions
into
so
value
is
a
small
traits
of
a
project
or
software
a
bit
like
performance
or
robustness
like
this
kind
of
traits
that
you
always
struggle
to
await
and
make
a
I
can
brace
one
trace
and
pay
less
attention
to
other
trades.
This
is
where
you
all
the
struggles
coming
from.
You
can
design
everything,
but
your
design
may
not
satisfy
the
project
that
you
contributing
into
and
if
you're
thinking
about
the
values
we
already
have,
some
selection
happened
even
before
we
started
contributing
to
kubernetes.
A
So
first
we
all
software
Engineers
like
most
of
us
and
when
you
become
software
Engineers.
You
already
express
your
value
that
you,
like
things
more
than
people,
I
mean
you
like
people,
but
you
like
things
more
and
if
you
like
people
more,
you
probably
will
become
doctor
or
something
like
of
this
nature,
and
it's
not
bad
that
you,
like
things
more,
it's
just
in
this
community
where
we
operate,
we
tend
to
Value
the
things
more
than
others
and
then
in
open
source.
A
Typically,
people
in
open
source
have
left
their
craft
and
not
every
software
engineer
have
lost
their
cross.
So,
like
you,
you
don't
work
in
public
unless
you
want
to
demonstrate
it,
or
you
have
like
I
mean
again,
it's
a
little
bit
exaggeration,
a
little
bit
oversimplification,
but
typically,
this
is
what
happening
in
an
open
source.
I
also
noticed
that
people
who
stay
in
open
source
typically
have
less
desire
for
immediate
gratification,
so
instant
gratification
is
can
be
achieved
on
internal
projects
way
easier
than
on
the
open
source
in
open
source.
You
need
to
build
consensus.
A
Finally,
cncf
has
their
own
Shadow
on
top
of
Open
Source,
like
people
who
may
like
opens
the
cncf
May
create
a
CNC,
but
it's
different
beasts.
They
it
imposes
values
and
then
kubernetes
is
I.
Think
it's
found
in
project
of
cncf.
We
have
very
all
this
values
reflected
in
it.
I
know
cncr
project
that
doesn't
reflect
all
the
cncf
values.
I
think
it
doesn't,
but
kubernetes
is
very
close
to
what
cncs
stands
for
and
finally
into
kubernetes.
We
have
different
six,
but
I
will
not
go
to
sixth
level.
A
I
will
try
to
stay
on
the
kubernetes
level
and
then
once
you
go
through
this
cycle,
you
became
a
software
engineer.
All
the
way
to
you
contribute
to
kubernetes.
You
already
passes
where
you're
like
expressing
what
you
value
more
or
at
least
what
you
value
more
when
you
contribute
to
this
to
kubernetes
project.
A
So
if
you
come
to
kubernetes
project
and
start
making
contributions
that
are
not
aligned
with
everybody
else,
values
you
probably
will
lose
out
and
you
will
be
stressed
and
confused
most
of
the
time
and
since
you
came
here
and
you
have
these
values
and
you
keep
working
on
kubernetes,
you
reinforce
this
value.
So
it's
like
infinite
cycle
of
like
people,
new
people
coming
to
kubernetes
with
the
same
values
and
reinforcing
these
values
even
further.
A
So
this
is
what
builds
us
and
again
you
can
be
working
on
kubernetes,
second,
first
half
of
the
day
and
working
on
other
projects,
the
second
half
of
the
day
and
it's
fine
you'll
express
different
values
and
so
to
your
identity.
It's
a
framework
you
operate
in
when
you
work
in
kubernetes,
so
don't
take
it
too
close
I'm,
not
call
like
saying
that
when,
when
we're
saying
that
kubernetes
value
this
trade
more
than
other
trade,
it
it's
not
like,
you
value
one
trade
more
than
other
trade.
A
It's
like
when
you
work
in
kubernetes.
You
will
Express
this
trade
more
often
than
this
trade
and
yeah.
So
it's
not
their
identity
and
I
joined
the
kubernetes
I
intentionally
moved
from
open
Telemetry
to
kubernetes.
It
was
my
desire
to
go
into
this
community
I
I
learned
a
lot
being
here
and
I
wanted
to
find
out
what
the
values
of
kubernetes
and
I
wanted
to
find
out.
Some
written
documents
saying
like
this
is
our
values.
A
This
is
how
we
develop
code
and
I
didn't
find
any
what
I,
maybe
it's
a
good
I
didn't
find
any
because
I
needed
to
develop
it
for
myself.
I
need
to
look
at
reality
versus
what
is
declared
and,
as
you
can
see
like
people
may
declare
some
values
but
Express
different
values
and
when,
when
asked
about
it
or
when
they
actually
looking
at
things
and
working
on
things,.
A
So,
what's
written
I
I
kept
my
I
kept
searching?
What's
written
about
the
values
and
I
found
Charter
of
cncf?
That
has
technical
values
like
I,
don't
think
I
think
it's
just
called
values
and
again
kubernetes
founding
project
of
cncf
so
likely
this
values
was
written
based
on
community
was
formed
about
kubernetes,
and
you
know
some
of
them.
Reincarnated
with
me.
Very
much
like
let's
say
fast,
is
better
than
slow.
It's
a
very
first
technical
principle
of
cncf
and
I.
A
I
have
slides
for
every
one
of
them,
but
I
don't
want
to
go
deep
into
details
so
faster
better
than
slow
is
I
want
to
highlight
this
again,
so
I
think
it
resonated
with
me
a
lot
when
I
joined
kubernetes,
because
I
tend
to
I
used
to
work
in
projects
that
doesn't
have
that
much
of
aggressive
pursuing
users
to
switch
to
something
new.
So
we
duplicate
things
very
actively.
We
pursue
customers
to
adopt
features
very
aggressively
and
it's
it's
good
and
bad
I.
A
A
What
you
want
to
express
and
I
spoke
with
many
people
saying
that
kubernetes
used
to
be
the
startup
feeling
project
and
now
it's
moving
into
this
enterprise
system,
and
when
you
look
at
values
that
projects
supposed
to
have
when
it's
moved
from
startup
to
Enterprise
level,
you
think
that
culture
needs
to
change.
You
think
the
values
needs
to
change
and
I.
Think
what
we're
doing
in
our
community
right
now
is
a
good
good
example.
How
values
can
be
changed
by
placing
some
process
around
it
and
again,
change
in
values
is
hard.
A
Once
you
change
the
values,
you
may
attract
different
type
of
people
and
some
people
who
used
to
contribute
a
lot.
There
will
be
decency
distance
in
devised
like
they.
They
wouldn't
want
to
contribute
any
longer,
but
this
is
what
it
is.
I
mean
project
changes
and
we
need
to
embrace
this
change
and
two
examples
that
I
wanted
to
release.
Here
is
permability
elimination
or
we
don't
want
to
keep
features
in
beta,
for
that
long
is
great
for
velocity.
A
Now
we're
moving
a
little
bit
away
from
velocity
by
forcing
people
to
get
into
GA
stage.
Like
good
example
is
I
mean
a
signal
device
manager
is
still
in
beta
and
we
were
just
thinking
about
next
generation
of
device
manager.
We
didn't
even
want
to
put
it
in
GA
yet,
but
Enterprise
needs
different
values.
We
need
to
get
it
to
J
and
I.
Think
what
that's?
What
we
will
do
in
127.
A
and
second
example-
is
products
interview
our
care
process
getting
more
and
more
elaborate
and
Broad
Readiness
review
is
one
of
the
examples
when
we
try
to
import
this
value.
Like
you
need
to
think
about
maintainability,
you
need
to
think
about
specific
metrics.
You
want
to
collect
out
of
this
feature,
and
so
another
example
of
change
attempt
to
change
the
culture
by
imposing
process.
A
A
There
is
no,
like
you
haven't
thought
about
this
scenario
so
like
they
never
sometimes
people
don't
say
that
they
care
about
this
scenario.
Specifically,
they
were
just
saying:
can
you
put
unit
tests
in
this
specific
location
and
like
okay?
Like
are
you
caring
about
reliability
because
you
want
unit
tests
or
you
care
about
the
specific
scenario
because,
like
so
sometimes
intent
is
not
clear,
we
also
have
a
lack
of
time
from
contributors
and
it's
really
challenging
to
understand
what
people
want
from
care
preview.
A
For
instance,
when
a
person
who
can
approve
this
cap
review
doesn't
have
time
to
discuss
it
with
you
so
like.
If
you
have
design
proposal-
and
you
try
to
understand
this
trade-off
between
one
value
and
another
value,
you
may
not
get
a
clear
answer
just
because
there
is
lack
of
time.
So
you
need
to
go
through
that
and
that's
why
Finding
values
through
absolving
is
always
sometimes
hard.
That's
why?
Probably?
We
need
to
write
it
down
at
some
some
point
next
and
now.
I
wanted
to
go
into
actual
discussion
and
brainstorming,
I.
A
A
Doesn't
golang
doesn't
give
you
things
in
specific
order
when
you
do
use
some
hash
map
or
something
and
the
fix
for
this
problem
was
not
to
fix
tests
to
like
understand
any
order
ever,
but
the
fix
was
to
sort
values
before
you
returning
them
in
the
API.
So
for
me
it
wasn't.
Mind-Blowing
like
I
came
from
monitoring.
Space
like
performance
was
like
on
top
of
everything,
and
here
you
sort
of
things
just
to
make
them.
Predictably
out
from
API
surface.
A
A
I
I
was
really
impressed.
How
kubernetes
is
bold
and
changing
things.
One
example
is
grpc
probes
that
we
introduced
in
Signal
recently.
What
happened
is
we
have
an
API
for
probs
and
this
API
support
named
ports
and
name
ports?
Arguably
was
not
the
best
decision
ever
when
designing
an
API,
so
decision
was
to
just
don't
follow
the
same
pattern.
We
have
three
types
of
probes
that
support
name
named
ports
and
force
probes,
that
doesn't
support,
name
probes,
and
it
was
fine
because
it's
like
we
need
to
do
things
better.
A
We
need
to
improve
engineering
and,
like
again,
I
understand
this
value
now
I
understand
where,
where
it's
coming
from,
but
it
was
a
mind-blowing
for
me
that
we
don't
like
we
would
care
about.
You
is
new
and
better
engineering,
more
than
consistency
with
all
things
and
another
example
like
you,
you
all
know
how
often
we
change
how
we
build
stuff
and
like
we
already
have
like.
We
have
Coop
test
one,
and
we
have
Coop
test
two
and
like
it's
like
we're.
Constantly
trying
to
change
something
adapt
new
golang
version
adapt
new
Frameworks.
A
A
No
okay,
I
was
prepared,
so
I,
don't
know
if
you
saw
this
talk
by
Brian.
Cantel
I
really
enjoy
all
his
talks,
and
this
was
one
of
the
inspirational
one.
I.
Don't
care
about
rust
that
much
he
just
like
in
in
the
bottom
there,
but
he's
way
explaining
things
about
values.
The
different
languages
and
Frameworks
expressed
was
very
inspirational
for
me
and
he
put
the
slides
like
I,
just
copied
bluntly
out
of
his
slides.
What
values
may
exist?
B
Looking
at
the
docker
shim
deprecation
is
a
lesson
I
think
minimizing
user.
Surprise
I
think
is,
is
probably
you
know
an
evolving
value
here,
the
deprecation
policy
kepts
in
general
as
a
way
to
make
sure
that,
instead
of
just
checking
stuff
in
willy-nilly,
we
have
a
chance
for
people
to
get
ready
and
see
it
and
be
prepared
for
it
and
integrate
it.
So
I
don't
know
where
that
fits
with
Brian's
list
here,
but
that
that
does
seem
to
be
sort
of
an
evolving
value
of
the
of
the
community.
A
B
Well,
I
mean
compatibility,
is,
is
one
thing,
I
think
the
project
is
not
afraid
of
making
breaking
changes,
like
you
said,
and
also
we
want
to
minimize
the
price
for
users.
So
there's
a
balance
between
those
things
that
I,
don't
think
is
is
expressed
here.
Like
you
know,
predictability
may
be
a
good
way
to
talk
about
it
right.
We,
you
know,
we
want
people
to
you
know
again.
Just
that
minimize
of
surprise
is
is
the
way
that
I
would
say
it.
A
You
any
other
opinions.
Okay,
let's
talk
about
this
way.
So
I,
don't
know
if
you
saw
this
meme
this
person
who's
a
cop,
saying
changed
my
mind
so
I
think
kubernetes,
really
one
of
the
kubernetes
value
is
opinionated
apis
and
scenarios
over
expressiveness.
So
we
don't
care
of
expressing
this.
That
much
kubernetes
has
opportunities
to
support
many
many
scenarios,
but
we
picked
few
and
we
support
them.
Well.
D
I
agree
what
we
are
having
a
lot
of
opinionated
apis
I,
don't
agree
what
we
are
working
well
so
like
there
are
several
scenarios.
What
was
implemented
to
to
accommodate
with
use
case,
what
we
see
right
now,
but
in
a
few
years
something
is
get
changed
like
either
have
a
pattern
of
application
get
used?
Let's
change
it
like
new
hardware,
accounts,
complexity
of
Hardware
increases
and
so
on,
and
with
practically
like
constrain
us
to
to
evolve
in
some
areas.
C
A
E
One
one
example,
I
can
think
of.
Actually
here
is
K
native
or
native,
depending
how
you
say:
connective
yeah,
and
so,
if
you
look
at
kubernetes,
it's
got
a
ton
of
tweaks
and
knobs
on
that
pod
resource
and
things
like
that.
But
quite
a
lot
of
users
just
want
to
run
an
application
and
they
want
to
say
here's
my
image
and
so
I
I,
I,
I,
agree.
B
I
mean
the
original.
You
know.
One
of
the
ideas
was
unit
philosophy,
a
set
of
small
sharp
tools
that
compose
well
together,
which
I
think
you
know
is
on
the
expressiveness
end,
as
opposed
to
you
know,
essentially
I
think
there's
places
where
we
screwed
that
up
like
this
service
object,
you
know,
is
everything
in
a
kitchen
sink,
it's
very
opinionated,
but
it's
also
been
limited
and
I.
Think
we've
seen
that
with
the
shift
to
the
Gateway
API,
we've
actually
aired
on
something
that's
more
flexible
and
more
expressive
versus
something
that's
more
opinionated.
A
Okay,
so
I
think
we
had
this
less
expressive
before,
but
we
moving
into
more
expressive.
Direction
and
I
hear
it
from
that
from
you
as
well
that
we
want
to
be
more
expressive.
Okay,
I
think
we
almost
out
of
time,
but
I
have
a
couple
more
I
already
talked
about
performance,
maintainability
yeah.
This
is
one
of
the
maintainability
and
operability
is
always
afterthought
on
most
of
the
work
we're
doing.
E
Like
I
think
yeah
Joe
just
said,
like
I
think
we
we
kind
of
want
to
focus
on
maintainability
and
it's
you
know
when
you
see
in
a
pull
request
review
like
how
are
we
going
to
actually
iterate
or
evolve
this
feature
and
think
about
the
next
things?
Not
boxing
ourselves
into
certain
API
decisions
is
something
quite
key,
so
I
think
high
class
that
is
maintainability
being
able
to
like,
extend
it
and
continue
to
develop
it.
E
A
And
I
put
this
after
a
few
PRS
I
reviewed
one
PRS
specifically,
something
was
too
long
to
initialize
and
message
like
log
message
was
too
often
viewed
in
a
log
file,
so
people
just
wanted
to
hide
this
message
saying
like
Okay,
it's
too
often
shows
up
like.
Let's
not
show
this
message
at
all,
and
this
is
some
some
kind
of
pattern.
I
see
observe,
but
I
agree
with
it.
B
B
A
difference
between
maintainability
and
operability
and
and
I
think
you
know,
James
was
I,
think
referring
to
maintainability
as
in
like
how
do
the
project
maintainers
evolve
things
over
time,
but
then
I
think
there's
operability
of
like
how
easy
is
it
for
users
to
operate
and
debug
and
you
know
and
maintain
a
running
kubernetes
system,
and
so
you
know
two
sides
to
that.
I
think
and
so
it's
worth
teasing
those
apart,
yeah
yeah,
okay,.
F
I
think
this
is
something
that
you
find
anywhere,
not
just
in
the
kubernetes
project.
Of
course,
if
you
bring
this
up
in
any
technical
community-
and
you
say,
maintainability
is
always
an
afterthought
everyone's
going
to
nod,
but
I
think
the
real
answer
is
the
true
answer
of
all
of
Tech.
It
depends
on
where
you
are
different
groups
put
maintainability
in
different
places
in
their
Cycles.
Some
groups
value
it
more
highly
and
put
it
earlier
in
their
their
work.
A
Okay-
and
we
find
out
a
time,
I
wanted
to
highlight
that
again
coming
to
one
of
my
previous
slides,
something
we
express
as
a
value,
not
always
something
we
want
to
be
as
a
value
for
community,
and
we
try
to
put
some
process
in
place.
I'd
like
to
have
some
values
written
down,
so
we
will
declare
what
we
want
and
maybe
side
list
what
we
actually
have
and
I
was
trying
to
put
it
some
way
here.
But
I
may
be
wrong,
and
this
is
something
I
want
to
keep
discussion.