►
From YouTube: kOps: Recent Advances and the J... Peter Rifel, Ciprian Hacman, John Gardiner Myers, Ole Markus With
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
kOps: Recent Advances and the Journey to an OSS Kubernetes Distribution - Peter Rifel, DataDog; Ciprian Hacman, eyeo; John Gardiner Myers, Proofpoint; Ole Markus With, Sportradar
kOps is a kubernetes subproject to manage and operate kubernetes clusters, delivering the full end-to-end user experience. We’ll give a quick introduction to kOps, and cover recent advances. Learn about better security, certificate rotation; support for containerd, arm64, azure; dedicated apiserver nodes; binding cloud roles to kubernetes service accounts; initial ipv6 support; much deeper testing and more! We’ll then deep-dive into how we are continuing to deliver the end-to-end experience, even as the core kubernetes repository extracts out networking, storage and cloud support … are we building a distro? What are the implications for how we can continue to develop and build kOps, and what can we learn from traditional Linux distros?
A
A
The
typical
installed
instructions
for
the
split
components
is
I
apply
this
this
large
amount
of
yaml
or
or
use
this
home
chart
these
new
split
components.
They
have
their
own
life
cycle
and
you
have
to
track
your
as
an
operator.
You
have
to
track
yourself,
the
compatibility
between
the
control
plane
and
the
split
components,
and
that's
pretty
big
additional
burden
on
cluster
operators.
A
So
what
kops
aim
to
do
is
to
take
on
these
components
and
manage
them
transparently,
just
as
if
they
were
a
part
of
the
old
control
plane
and
that's
what
we
mean
by
becoming
an
open
source
software
distribution.
So
you
have
the
the
kernel.
The
control
plane
and,
in
addition
you
have
all
of
these
smaller
components
around
it.
A
And,
of
course,
for
those
who
have
an
existing
production
cluster,
we
want
to
make
the
transition
from
the
larger
control
plane
into
this
by
using
the
split
components.
So,
for
example,
when
we
had
a
support
for
eds
csr
driver,
the
migration
is
completely
transparent
and
user
doesn't
have
to
do
anything.
It
just
happens
in
the
background
and
we
will
track
the
ensure
that
the
right
version
of
the
driver
is
being
used
based
on
what
kubernetes
version
you're
running.
A
They
might,
for
example,
require
additional
permissions
to
the
cloud
vendor
and
I
think
kops
will
just
handle
all
that
that
for
you,
our
goal
here
is
not
to
support
like
an
immense
large
number
of
add-ons,
but
rather
a
few
really
essential
ones.
At
the
same
time,
we
also
don't
want
to
support
every
feature
of
these
components,
but
the
ones
that
most
people
typically
will
need
just
to
reduce
the
burden
of
for
operators.
A
So
one
of
the
things
worth
mentioning
on
around
this
is
that
we
are
now
start
to
support
external
permissions
for
these
add-ons.
So,
instead
of
the
add-ons
inheriting
the
instances,
privileges
to
the
cloud,
they
will
get
their
own
roles
and
and
can
interact
directly
with
the
with
the
vendor
and
authenticate
directly.
So
this
is
what
is
known
as
im
roles
for
service
accounts
on
aws
or
workload,
identity
on
google
cloud.
A
B
B
B
We
have
improved
the
way
we
provision
several
certificates.
Previously,
all
certificates
and
private
keys
for
a
cluster
were
created
and
placed
in
the
secret
store
by
the
chaops
command
line.
When
the
cluster
was
first
created,
all
certificates
were
given
a
10-year
lifetime
nodes
would
use
their
instance
role
or
other
ambient
credential
to
read
the
certificates
and
keys
from
the
secret
store.
B
B
B
K
ops
also
has
a
new
mechanism
for
provisioning
certs
on
worker
notes,
notep,
which
runs
on
the
worker
node.
While
it's
bootstrapping
generates
the
private
keys
for
the
certificates
that
the
node
is
going
to
need,
depending
on
the
configuration
it
sends,
the
corresponding
public
keys
to
chaos,
controller
which
runs
on
the
control
plane
and
has
access
to
the
ca
private
keys.
B
This
mechanism
is
currently
only
implemented
for
aws.
Other
cloud
providers
still
have
worker
nodes,
retrieve
shared
10-year
certs
and
corresponding
keys
from
the
secret
store.
Implementing
the
cloud.
Provider-Specific
authentication
for
other
cloud
providers
is
an
area
where
we
would
appreciate
contributions
as
the
version
122
chaops
supports
graceful
rotation
of
the
ca
and
surface
account
scanning
keys,
all
of
the
necessary
components
have
been
extended
to
support.
Trusting
multiple
cas.
B
There
are
new
commands
for
performing
the
steps
of
rotation,
creating
and
staging
trust
in
new
keys,
promoting
the
new
keys
into
active
use
and
removing
trust
in
the
old
keys
by
default.
All
of
the
cas
and
the
service
accounts.
Training
key
are
rotated.
At
the
same
time,
there
is
a
documented
procedure
for
performing
a
rotation
complete
with
rollback
instructions
for
each
step.
B
B
B
The
problem
then
becomes
how
to
get
the
assets
into
the
local
repositories.
The
previous
mechanism
was
particularly
obscure
and
hard
to
use.
Chaops
122
adds
a
much
simpler,
get
assets
command
for
either
copying
assets
to
the
local
repositories
or
getting
the
list
of
assets.
One
needs
to
feed
into
an
external
process
with
fees
and
other
changes.
Chaops
continues
to
improve
the
security
of
its
default
configuration
and
the
ease
of
securing
it
further.
C
C
C
C
C
C
This
includes
add-on,
manifests
static,
pod
manifests
and
nodeup
config.
This
is
primarily
to
resolve
a
race
condition
during
upgrades
where
chaop's
update
cluster.
Yes,
was
updating
objects
too
soon
they
will
now
be
updated
during
a
terraform
apply,
which
is
closer
to
when
launch
templates
are
updated,
which
reference
these
objects
a
nice
side.
Effect
of
this
change
is
that
it
improves
discoverability
of
changes
to
these
resources.
C
D
D
They
were
wrong
and
feels
like
a
lifetime
ago,
but
things
are
finally
starting
to
happen.
Ipv4
addresses
are
harder
and
harder
to
obtain
each
year
and
much
more
expensive
for
iot
telecom
and
large
enterprises
using
ipv6
is
no
longer
a
preference,
but
a
hard
requirement
is
kubernetes.
Ready
for
this
is
k.
Ops.
D
D
D
D
With
the
release
of
kubernetes
121
and
dual
stack
support,
we
decided
to
give
it
another
try.
A
few
weeks
later,
the
cloud
provider
part
was
ready
and
we
moved
to
the
networking
setup
we
used
in
parallel,
both
calico
and
cilium,
with
unique
local
addresses,
which
means
not
quickly.
It
became
obvious
that
something
was
missing.
D
We
tried
to
create
a
patch
we
submitted
it
upstream
and
with
a
custom
built
based
on
that.
We
move
forward
to
testing
and
it
was
successful.
Finally,
we
could
say
that
k-ops
can
work
with
ipv6
conformance
tests
were
passing
and
everything
looked
great,
so
coming
with
k,
ops,
122
ipv6
will
be
available
as
an
option.
D
What's
next
global
address
is
using
prefixes
instead
of
unique
local
addresses
is
a
much
better
solution.
This
would
allow
clusters
to
communicate
with
the
outside
world
without
any
need
for
that
simple
setup
when
aws
will
allow
using
launch
templates
for
prefixes
is
also
preferred.
The
lat64
appliance
will
also
be
a
much
needed
addition.