►
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.
Cloud Provider OpenStack Intro & Update - Anusha Ramineni, NEC Corporation India Private Ltd & Lingxian Kong, Catalyst Cloud
In this session we will give overview of provider-openstack subproject. cloud-provider-openstack repository hosts various plugins relevant to OpenStack and Kubernetes Integration which includes OpenStack Cloud Controller Manager, Octavia Ingress Controller, Cinder CSI Plugin, Keystone Webhook Auth, Manila CSI Plugin, Barbican KMS Plugin and Magnum Auto Healer. This session covers the overview of all hosted plugins as well as recent work/enhancements that are being done and future roadmap of the project.
A
A
A
A
Actually,
the
two
can
can
be
both
capable
of
working
in
tandem
in
order
to
bring
greater
values
to
organizations
and
better
service
to
the
users.
So
actually
they
are
friends
and,
most
importantly,
they
are
both
open
source
cloud
provider.
Openstack
was
created
as
a
sub-project
of
seek
cloud
provider.
A
The
responsibility
of
c
cloud
provider
is
to
establish
standards
and
the
requirements
that
should
be
meant
by
other
cloud
providers
to
ensure
their
integration
with
with
kubernetes,
so
basically,
provider
openstack
is
just
like
provider,
aws
provider,
gcp
or
provider
azure.
If
you
are
more
familiar
with
those
public
clouds,
so
they
are
at
the
same
layer.
A
A
The
two
important
ones
are
openstack
cloud
controller
manager
and
the
csi
plugins
other
than
those.
We
also
have
octavia
ingress
controller,
which
is
implementing
the
ingress
resource
in
kubernetes,
and
we
have
magnum
auto
healer
to
achieve
high
availability
of
the
cluster
nodes
in
security
area.
We
have
keystone
house
webhook
for
rbic
and
we
have
barbican
kms
plugin
for
the
secret
data
encryption
and
we
will
go
through
them
one
by
one
shortly.
A
Actually
openstack
has
lots
of
projects,
lots
of
services,
and
you
can
see
here.
Some
service
is
required
by
by
some
particular
provider.
Openstack
component,
for
example,
magnum
the
kubernetes
as
a
service
in
openstack,
is
required
for
the
magnum
autohealer
implementation
and
another
one
is
octavia,
which
is
a
load
balancer
as
a
service
in
openstack
is
required
by
multiple
components
by
the
openstack
cloud,
controller
manager
and
octavia
ingress
controller,
because,
as
you
know,
that
in
kubernetes
the
service
of
load,
balancer
type
and
ingress
both
needs
to
create
the
external
cloud
load
balances.
A
A
A
A
So
if
you
are
familiar
with
openstack,
you
must
know
that
several
years
ago,
in
openstack
networking
service
called
the
neutron.
There
was
a
plug-in
called
neutron-
airbus
that
could
provide
some
simple
load.
Balancer
functions,
however
neutral
airbus
has
been
deprecated,
I
think
two
or
three
years
ago,
as
in
order
to
promote
octavia
in
in
openstack
community.
A
A
A
A
A
Another
improvement
we've
made
in
the
past
releases
is
to
use
one
single
api
call
to
create
the
load
balancer,
which
significantly
decreased
the
service
creation
time
and
the
last,
but
not
the
least.
We
added
the
octavia
version
check
for
some
advanced
features,
because
we
know
that
there
are
some
cloud
providers
are
still
running:
different
versions
of
octavia
and
even
different
versions
of
openstack.
A
So,
move
on
to
octavia
increased
controller.
Well,
the
ingress
controller
is
responsible
for
the
reconciliation
for
the
ingress
resource
in
in
kubernetes
cluster,
similar
to
openstack
cloud
controller
manager.
Octavia
english
controller
is
also
communicating
with
octavia
in
order
to
create
load
balancers
and
the
same.
A
We
also
support
trs
termination
with
barbican,
which
is
a
key
manager
service
in
openstack,
so
it's
very
similar
to
to
the
openstack
cloud
control
manager.
So
basically,
the
job
of
octavia
ingress
controller
is
very
simple.
Just
it's
just
maintaining
the
mapping
relationship
from
the
ingress
definition
to
the
dependency
to
the
resource
dependencies
in
the
cloud
to
make
sure
that
if,
when
there
is
change,
changes
in
the
ingress
definition
and
we
will
update
the
resource
dependencies
in
in
the
cloud.
A
Magnum
auto
healer
magnum
is
kubernetes
as
a
service
in
openstack,
so
it
provides
a
cloud
api
to
create,
update
and
delete
the
kubernetes
cluster
and
additionally,
it
provides
advanced
features
such
as
the
cluster
certificate
rotation
and
cluster
rolling
upgrades
and
the
cluster
node
resize.
So
it's
very
useful.
A
A
A
A
B
B
Before
diving
in
so,
let's
start,
let's
give
a
brief
intro
on
what
is
csi
and
why
is
it
used?
So
csi
is
the
container
storage
interface.
It
is
an
industry
defined
standard
to
expose
storage
systems
to
containerized
workloads
with
the
adoption
of
the
csi
kubernetes
entry
volume
plugins
have
been
moved
to
the
out
of
tree
and
and
also
the
volume
plugins
can
be
containerized.
B
This
is
the
high
level
component
diagram
that
involves
in
the
kubernetes
cluster
with
the
csr,
so
we
have
a
csi
driver
here
at
the
right
hand,
side
it's
a
it
which
implements
the
volume
plug-in,
behavior
and
exposes
grpc
exposes
grpc
of,
as
defined
by
the
csi
spec
implements
the
identity,
service
controller
service
and
the
node
service.
This
csr
driver
in
turn
communicates
to
the
underlying
openstack
cinder
manila
services
to
give
the
volume
volume
management
in
kubernetes
coming
to
the
next
sidecar
containers.
These
are
these
are
helper
containers.
B
B
It
registers
the
csi
driver
with
the
cubelet
and
external
provisional
provisions
and
deletes
the
volumes
and
excel
attacher.
Does
the
attach
and
detach
operations?
External
snap
shorter
is
for
the
volume
level
snapshotting
and
external
resizer
with
the
volume
expansion
functionalities,
so
these
can
be
enabled
as
as
required
by
the
driver.
B
B
The
release
cycle
of
the
plugin
is
in
sync,
with
the
kubernetes
releases
like
a
recent
release,
kubernetes
1.22,
so
we
have
released
the
latest
version
of
1.3.3,
which
is
incompatible
with
the
kubernetes
release
in
the
likewise.
We
also
update
the
sidecars
for
every
release
to
the
latest
to
their
latest
versions
and
we
do
share.
B
We
do
have
the
sidecar
versions
that
are
supported
by
the
driver
in
the
manifest.
Also,
we
do
recommend
use
the
same
versions
to
ensure
that
there
is
no
breakage
with
the
driver
coming
to
the
driver
deployment.
There
are
two
types
of
driver
deployment
that
is
supported,
one
through
health
charge
and
also
we
do
provide
the
sample
manifest
in
the
repo
that
can
be
used
for
the
easier
deployment.
B
A
little
bit
deep
dive
into
the
driver
deployment,
so
here
we
have
csi
driver,
is
commonly
deployed
as
a
two
sets
of
plugins.
One
is
controller,
plugin
and
other
is
a
node
plugin,
so
controller
plugin
is
deployed
as
a
stateful
set
or
a
deployment
inside
this
we
have
to.
We
have
containers
of
the
cinder
plugin
and,
along
with
that,
the
sidecar
containers
of
excellent
provisional
snaps
router
attacher
resizer.
These
can
be
enabled
as
required.
B
B
Then
next
is
the
note
plugin
of
inside
the
daemon
set
this.
This
runs
on
every
node
or
we
have
two
containers.
One
is
the
cinder
csr
plugin,
along
with
the
sidecar
no
driver
register.
This
node
driver
register
registers
the
driver
to
the
cubelet,
so
the
communication
do
happen
over
the
grpc
here
as
well.
B
B
This
for
the
users
who
are
still
using
entry,
cinder
provisioner,
so
starting
from
kubernetes
1.21
the
flag,
the
cinder
csi
migration
flag
is
supported
as
a
beta
feature
and
is
on
by
default.
So
by
default
all
the
plugin
operations
from
the
existing
entry
are
redirected
to
the
cinder
csr.
So
these
are
going
to
fail.
If
you
have,
if
you
don't
have
this
indus
csi
driver
installed
on
your
cluster.
B
So
if
you,
you
need
to
explicitly
disable
offer
it.
If
you
don't
want
to
use
this
in
the
csi,
but
this
all
the
plugin
entry
plugins
are
targeted
for
removal
on
from
1.24.
I
think
maybe
target
a
couple
of
releases,
mostly
by
1.24,
so
it
is
expected
that
everyone
must
migrate
to
the
csi
driver.
Instead,
we
do
provide
the
detailed
guide
on
how
to
migrate
from
the
using
increased
cinder
provisioner
to
the
external
csi
driver.
So
you
can
check
it
out.
B
The
major
updates
that
are
contributed
to
this
plug-in
over
the
past
year,
so
these
we
did
add
generic
ephemeral
volume,
support
and
support
for
the
multiple
config
files
have
been
added
like
cloud
config
can
be
specified
multiple
times
now
they
will
be
merged,
updated.
I
think
latest
site
cards
or
every
release.
We
do
update
to
latest
sidecar
and
there
is
a
we
have
added
support
for
ignore
volume
as
it
were.
B
If
you
have
the
cluster
with
the
no
gazette
and
volume,
is
it
as
different,
so
this
can
be
enabled
to
enable
the
port
to
be
deployed
on
any
of
the
node
availability
zones
and
several
talk
improvements
here
that
have
been
contributed
to
the
repo
planned
for
the
future.
I
think
for
this
cycle,
the
main
focus
would
be
on
the
ci
improvement
stability
and
increasing
test
coverage.
B
B
A
B
B
A
major
updates
of
this
plug-in
over
the
past
year,
the
expand
online
expand
volumes
in
the
online
mode,
have
been
added
and
injecting
metadata
to
the
newly
created
shares,
either
through
cluster
id
or
to
storage
class
parameters
that
has
been
added
influence.
The
selection
of
nfs
share
export
location
by
specifying
desired
subnet
and
the
next,
I
think,
pass
mount
options
specific
to
cfs
sscsi.
B
B
B
We
are
actively
looking
for
developers
who
could
contribute
or
either
in
the
test
area,
documentation
area
or
in
the
plug-in,
enhancements,
etc.
So,
you're
welcome.
So
you
have
a
code.
All
the
all
it
is
host
of
all
the
plugins
is
hosted
in
this
repo
cloud
provider
openstack
and
for
the
users
yeah
do
erase
the
feature
or
bug
if
you
have
come
across
any.
If
you
would
like
to
report
so
and
communicate,
I
think
flag
channel.
We
are
active
or
provider
openstack
channel
on
the
slack
so
feel
free
to.