►
Description
Kubernetes SIG - Chuck Lane, Salesforce & German Muzquiz, Armory
Join Chuck Lane & German Muzquiz for a look at some of the achievements over the past 12-18 months, and a look forward to what's next. Everyone is welcome to ask questions, share ideas and talk about how the community can work together to push the Kubernetes V2 SIG forward.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
All
right,
I
think
we
can
start
so
welcome
everyone.
This
is
the
kubernetes
system
and
in
this
session,
we're
going
to
discuss
what
has
changed
in
the
past
few
months
in
the
kubernetes
provider.
What
are
the
future
plans
for
the
provider
regarding
the
the
community
and
what's
the
status
of
the
community.
A
A
A
So
again,
these
features
are
implemented
by
the
community.
It's
not
just
the
sick
people
that
we're
implementing
this,
but
since
spinnaker
is
an
open
source
project.
If
you
have
new
features
that
you
would
like
to
see
in
kubernetes,
you
can
submit
put
requests
and
we
can
discuss
it
at
the
sig
meetings.
A
A
in
previous
versions
of
spinnaker,
when
you
were
deploying
a
manifest
spinner
could
use
the
cache
in
order
to
write
some
information
that
was
required
for
the
deployment,
and
this
usually
had
some
performance
problems
because
refreshing
the
cache
is
a
costly
operation,
especially
when
you
have
a
lot
of
kubernetes
accounts
refreshing.
The
cache
may
may
take
a
few
minutes,
so
this
make
that
deployments
or
the
pipelines
were
delaying
and
taking
a
few
minutes
to
complete
just
waiting
for
this
cache
to
be
refreshed.
A
A
A
Now
the
next
performance
improvement
is
using
the
kit
cli.
This
was
a
combined
release
between
february
and
april.
So
before
this
implementation
cloud,
driver
used
the
j,
git
library
for
communicating
with
github
or
for
cloning.
These
repositories,
but
jkit
has
some
drawbacks,
some
performance
penalties
and
it
was
not
the
ideal
solution.
A
A
This
means
that
when
you
are
executing
a
pipeline
that
has
a
bake
manifest
that
that
clones-
the
repository
before
this
change,
this
repo
was
cloned
on
every
execution
of
the
pipeline.
Now
after
this
change,
it's
only
cloned
the
first
time
and
it's
kept
in
cloud
driver
in
the
in
disk
and
every
time
the
pipeline
is
run
again.
It
will
only
do
a
git
pull
to
pull
the
latest
changes
for
that
repository.
A
This
also
greatly
improves,
improves
the
performance
of
running
the
pipelines
with
large
git
ripples
and
finally,
we
have
account
charting,
which
was
released
in
just
in
april,
for
the
sql
back-end
store
of
cloud
driver
account.
Sharding
allows
you
to
specify
or
to
kind
of
load
balance
the
accounts
that
different
cloud
driver
replicas
will
be
caching.
A
A
A
Improvements
now
for
compatibility
in
the
past
few
months,
it
was
end
of
life
for
the
kubernetes
b1
provider.
The
last
supported
version
for
the
b1
provider
was
released
in
august
for
the
ones
that
don't
don't
know
the
big
one
provider.
That
was
the
previous
version
of
the
one
that
we
have
today,
where
you
specify
the
manifest
that
you
want
to
deploy
in
the
big
one
provider.
A
Instead
of
specifying
the
manifest
you
had
a
ui
for
configuring
individual
parts
of
the
manifest.
So
it
was
not.
It
was
not
possible
to
specify,
for
example,
crds.
It
was
really
difficult
and
that's
why
the
b2
provider
give
you
the
full
flexibility
for
providing
any
manifest
that
you
want
to
deploy.
A
A
A
A
A
Today,
clouddriver
uses
cubectl
commands
to
read
the
infrastructure
and
also
to
make
deployments,
and
this
causes
some
sometimes
performance
penalties,
because
you're
running
this
keep
ctl
command
every
time
that
you
run
it
cloud
driver
needs
to
create
a
few,
some
threads
to
run
it.
So
it's
not
very
optimal.
This
implementation.
A
A
A
A
We
need
reviewers
and
approvers,
because
it's
it's
not
just
one
person
or
two
person,
the
one
that
is
able
to
approve
pull
requests
and
merge
them.
There
are
some
requirements
for
so
anyone
can
be
a
reviewer
or
approver
requirements
vary.
For
example,
you
need
to
have
submitted
some
pull
requests
and
you
need
to
have
some
a
review
with
some
pull
request.