►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Intro: Azure SIG - Stephen Augustus, VMware & Craig Peters, Microsoft
In the SIG Azure Intro, we’re going to tell you all about why SIG Azure exists and the team behind managing it. From there, we’ll talk about what’s happened over the last few releases, Kubernetes 1.14 and Kubernetes 1.15, as well as some of what’s planned for Kubernetes 1.16. Additionally, we’ll cover some user stories of implementing Kubernetes on Azure. Finally, and most importantly, we’ll talk all about some of the best ways to get involved with SIG Azure and all of the forums that we’re communicating on!
https://sched.co/MPh9
C
Craig
Peters
I
am
a
program
manager
at
Microsoft,
I
joined
Microsoft
in
December,
so
like
six
months
ago
and
from
doing
a
bunch
of
other
kubernetes
related
stuff.
Before
that
I'm
my
p.m.
as
a
piano
roll.
My
responsibility
is
sort
of
all
the
upstream
dependencies
that
ku
Bernays
has
for
running
on.
Azure,
so
say,
geyser
should
be
right
up
my
alley.
C
So
we
wanted
to
get
a
kind
of
a
measure
of
who
actually
comes
to
us.
You
get
as
your
interest
session,
so
I'd
like
to
kind
of
ask
a
couple
of
questions
and
and
just
buy
a
raise
of
hands
or
you
can
call
out
whatever.
Let
us
know
what's
going
on
so
how
many
of
you
have
actually
attended
a
cig
as
your
meeting.
C
C
Doing
it
on
hazard?
Okay,
quite
a
few,
not
everyone!
That's
that's
cool!
How
many
of
you
are
rolling
your
own
with
their
own
mechanisms
for
deploying
your
clusters?
Okay,
how
many
are
using
engine
or
familiar
where
they
can't
say?
Okay
and
how
many
are
using
aks
the
managed
service?
Awesome,
okay
and.
C
C
A
What
is
signature?
Why,
who
are
we?
Why
do
we
exist?
So
it's
a
gasser
is
a
special
interest
group.
The
whole
idea
is
around
obviously
managing
kubernetes
on
Azure,
so
everything
that
is
involved
in
that
ecosystem,
whether
it
be
provisioning,
whether
it
be
application
deployment,
whether
it
be
figuring
out
how
to
do
security
on
Azure
storage,
like
that's
kind
of
all,
the
things
will
be
encompassed
within
missing,
so
the
sick
chairs
are
Dave
Strebel.
A
Architect
at
VMware
Peng
trainee,
who
is
one
of
the
one
of
our
primary
contributors
to
to
the
AKS
engine
to
the
cloud
provider
and
basically
like
he
touches
bunch
of
the
things
in
the
ecosystem
and
he's
also
at
Microsoft
and
then
Cal.
Who
is
one
of
the
principal
engineers
that
Microsoft
is
also
one
of
the
technical
leads.
So
throughout
these
slides
there
are
a
variety
of
github
links
that
you
can.
You
can
pop
on
to
and
get
more
details
on.
C
A
E
A
The
kind
of
genesis
of
these
various
cloud
providers
things
we're
moving
away
from
a
lot
of
what's
been
happening
before
which
is
kind
of
you
know,
cloud
provider
comes
to
the
table
and
they
say
all
right.
Well,
you
know
we
should.
We
should
spin
up
as
a
sake
and
moving
more
towards
a
model
of
how
can
we
build
a
consistent
process
around
all
the
top
providers
that
need
to
run
kubernetes
right
so,
whether
it's
the
whether
it's
the
vSphere
is
the
IBM
clouds,
a
sure
AWS
right?
There
is.
C
A
the
motivation
behind
that
is
really
that
your
experience
as
a
cluster
manager
shouldn't
fundamentally
be
different
if
you're
running
it
on
IBM
or
the
cluster.
Lifecycle
should
really
be
very,
very
common,
but
be
implementation,
differences
that
the
cloud
providers
then
provide.
But
you
should
stop.
Let's
all
have
a
common
management
model
for
your
clusters,
exactly.
A
Right
so
figuring
out
how
to
build
consistent,
Doc's
and
build
consistent.
Api
is
around
these
things.
Make
sure
that
the
the
way
we
meet
and
organize
is
again
consistent
across
all
of
these
cloud
providers
and
making
sure
that,
as
new
cloud
providers
are
interested
in
coming
into
the
pure
Bonetti
space
that
they
have
a
model
to,
they
have
a
model
to
build
around
right.
A
C
B
A
So
you
know
a
lot
of
the
the
active
efforts
right
now
are
again
to
to
move
to
kind
of
more
of
a
consolidation
model.
So
some
of
the
active
some
projects
that
we
have
a
provider
Azure,
which
is
the
entry
kubernetes
provider
for
Azure.
So
it's
basically
you
provide
any
config
and
it
you
know
figures
out
all
right.
Well,
I
have
this
this.
You
know
authentication
or
authorization
to
to
the
the
services
with
an
azure
metadata
services
and
I.
Have
these
permissions
to
spin
up
whether
it
be
new
nodes
or
load
balancers
or
what-have-you.
A
So
all
of
you
are
fairly
familiar
with
it
if
you've
used
if
you've
used
a
KS,
KS
engine,
you
know
and
so
we're
moving
that
effort
into
a
cloud
provider
st.
cloud
provider
which
will
happen
along
the
next,
so
we're
gonna
start
we're
actually
gonna
wait
until
the
cube
columns
are
done.
We've
we've
created
a
proposal
and
submitted
that
to
the
steering
committee.
So
the
steering
committee
is
essentially
like
the
the
top
level
governing
body
for
the
kubernetes,
so
steering
committee
breaks
into
you
know.
A
Then
there
are
six
working
groups
and
sub
projects
within
this
things.
So
if
we're
making
a
sweeping
change,
that's
gonna
affect
a
bunch
of
SIG's.
We
usually
will
draft
a
proposal
right,
so
we
recently
submitted
that,
and
essentially
what
we're
gonna
do
is
wait
until
wait
until
this
cube
con
is
over
and
Shanghai
is
over
to
start
doing
that,
consolidation
ever
because
all
the
people
involved
in
that
will
yep
keep
them
speaking,
so
that
will
be
moving
over
to
state
cloud
provider.
A
A
Trying
to
solve
a
kind
of
a
meta
problem
here
right
like
what,
if
I
can
so
the
same
way
you
you
might
hear
about
the
operator
pattern
where,
like
I,
want
to
be
able
to
encode
human
operational
knowledge
to
a
set
of
kubernetes
primitives.
We
want
to
be
able
to
try
to
do
the
same
thing
with
instantiating
kubernetes,
great,
so
the
ability
to
so
a
cluster
API
provider
Adger
is
one
of
the
implementations
of
that
I.
Am
the
I
am
one
of
the
primary
maintainer
for
that?
A
And
so
that
will
be
moving
into
the
sequestered
life
cycle
and
and
then
finally,
the
CSI
drivers.
So
there
are
various
CSI
drivers
that
we
use
so
continue.
Cirrage
interface
is
that
that
acronym
I
know
you're,
probably
getting
hit
with
acronyms
all
all
week,
but
so
the
CSI
drivers
are
basically
the
drivers
that
figure
out
how
to
do
storage
for
atra
file.
I
for
disc
different
things
like
that.
Those
will
be
moving
into
six
charge
and
that's
mostly
done
actually
yeah.
C
C
Let's
do
just
a
quick
review
and
you
can
ask
questions
so
the
main
thing
is
you
know,
the
big
lift
is
essentially
pulling
the
cloud
providers
that
are
all
implemented
in
kubernetes
kubernetes
into
separate
release
tree
now
from
a
functional
perspective
that
buys
you
zero
right,
like
you,
don't
get
anything
new
for
that.
What
you
do
get
is
the
just.
Why
am
I
think,
freaking
failing
the
word,
the
word
I'm
velocity
I'm
dealing
the
release
velocity
of
kubernetes
from
the
release
of
the
pop
cloud
provider
forever.
C
A
So
yeah,
so
the
idea
is
that
you
know
right
now.
You
know
if
you
know
the
standard
like
building
and
building
a
go
project
right
now,
the
the
the
things
that
we've
created,
the
the
provider-
implementations
that
are
in
tree
kubernetes
they're
a
bunch
of
intertangled
dependencies
within
those
within
those
implementations.
So
what
that
means
is
before
we
can
actually
pull
all
of
these
providers
out
of
street
out
of
tree.
A
We
have
to
track
each
of
the
dependencies
across
all
of
the
providers
that
providers
have
to
work
together
to
essentially
okay,
well
package,
util
amount
that
can't
exist
in
the
providers
anymore
like
if
we're
going
to
stage
the
sporadic
tree,
we
have
to
figure
out
a
way
to
move
this
out
right.
So
you
know
it's
been.
It's
been
kind
of
like
quite
a
bit
of
effort
and
working
together
with
all
the
cloud
providers,
so
to
really
understand
and
take
a
little
bit.
A
A
This
happened
over
the
course
of
the
last
year
or
so
right
to
give
us
the
point
where
we
can
finally
say
so:
I
probably
should
have
put
the
link,
but
you
know
I
did
a
did
a
PR
which
pushes
the
which
pushes
the
out
of
tree
provider
over
to
the
legacy
cloud
provider
implementation
right.
So
there
is
a
staging
repo.
So
basically,
we
have
like
a
bunch
of
go
witchcraft
and
bash
scripts
that
take
things
from
this
staging
directory
within
kubernetes
and
there's
a
publishing
bot
that
runs
nightly.
A
Now
that
will
take
everything
from
the
the
staging
from
that
staging
directory
and
move
it
into
separate,
separate
directories
that
you
can
then
import
right.
So
the
initial
phase
of
moving
things
out
of
tree
is
being
able
to
stage
them
in
the
staging
repo
and
then
pulling
out
those
dependencies
one
by
one,
just
don't
like
riffing
on
it's.
C
A
C
A
E
A
A
point
where
it
was
functional
and
and
then
I
you
know,
I
started
looking
around
was
like
this
cluster
API
thing
is
kicking
off.
I
need
to
make
sure
that
Asscher
is
also
in
the
game
and
as
I
wait,
let's
see
if
there
there's
something
that
already
exists
right
and
there
was
it
was
pretty
great,
so
we
migrated
into
the
kubernetes
repo.
So
it's
an
official
kubernetes
project
now
and
you
know
it's
a
right
now:
it's
a
joint
effort
between
the
VMware
staff
and
and
Microsoft
staff.
A
C
Another
you
know
big
step
in
the
sort
of
maturity
of
all.
The
cloud
providers
is
to
beef
up
the
engine
testing
and
you
know,
essentially,
we
we've
done
that
for
the
is
your
cloud
provider.
In
fact,
one
of
the
core
contributors
is
in
the
room
standing
in
the
back
and
so
now
we're
actually
using
ATS
engine
and
we
have
the
whole
N
test
test
pipeline.
That's
that's!
If
you
have
people,
we've
got
a
lot
of
tests.
There's
a
lot
of
testing
going
on.
C
A
Secure
burnett
is
I,
think
that
I
I,
love,
saying
and
I
think
that
you
know
testing
Docs,
so
important,
they're
often
overlooked
parts
of
the
project,
and
you
know
we
we
can.
We
can
use
all
the
help
we
can
get.
So
if
you're
interested
in
getting
involved
in
some
of
those
efforts
documenting
the
cloud
provider,
building,
building
out
testing
for
it
and
it
doesn't
just
have
to
be
for
a
sure
like
we,
you
know
so.
I
I
also
run
release
in
p.m.
so.
If
you
want
to
talk
about
any
of
that
stuff
feel
for
you.
C
A
For
often
a
jurors
kind
of
like
okay,
well,
I
have
a
service
principal
or
I.
Have
you
know
our
have
managed
service
idea,
identity,
whether
it's
seen
an
external
or
our
note
based
and
we're
kind
of
going
to
this
model,
where
being
able
to
instantiate
a
node
with
no
provider?
Essentially
I
think
Cal
is
working
on
that
right
now,.
E
A
C
And
then,
obviously,
we
kind
of
touched
on
some
of
the
stuff
that's
happening
with
CSI
and
it's
actually,
the
azure
disc
has
turned
the
alpha.
We've
got
the
file
drivers
and
we've
added
support
for
many
more
of
the
SSD
classes.
I
mean,
as
as
your
adds,
more
and
more
SKUs
and
ways
in
which
you
deploy
things
less
and
you
need
to
be
those
need
to
be
supported
then,
and
the
the
cloud
provider
so
we're
just
making
sure
we
keep
up
with
Azure
as
we
go.
D
A
If
you're
familiar
with
like
virtual
machine
scale
sets
you
know
that
the
the
API
for
building
virtual
machines
versus
virtual
machines
scale
sets
are
slightly
different,
so
there
there
was
a
lot
of
work
done
to
essentially
like
well.
One
we've
got
to
build
it
in
Tsukuba
Nettie's
we've
got
to
build
the
the
idea
that
one
you
can.
You
can
instantiate
notes,
but
you
can
also
instantiate
node.
The
idea
from
like
node
pools
right
so
working
on
refactoring
all
the
kubernetes
code
to
be
able
to
support
things
like
that.
C
C
Kind
of
but
there's
also
other
other
considerations
that
really
important,
like
you
may
want
to
have
a
pool
of
machines
that
you
know
you
know
all
of
these
machines
have
a
certain
kind
of
GPU,
for
example
right
and
those
those
kind
of
management
concepts
are
not
being
built
into
Cooper
nodes
itself
and
say:
geyser
is
one
of
the
places
that's
driving
them.
Then.
A
You'll
you'll
see
a
lot
starting
to
happen
around
no
topology
or
not
just
new
topology,
but
resource
topology
in
general
right.
So
the
concept
of
like
I
want
to
you
know.
If
I'm
building
a
standard
datacenter
I
have
to
build,
you
know
after
rack,
I
have
to
have
to
power.
I
have
to
run
storage.
I
have
to
you
know,
do
all
the
networking
right.
A
So
there's
a
lot
of
things
involved
in
that,
and
then
it
gets
more
complex
when
you
start
to
look
at
a
cloud
provider
scenario
and
then,
when
you
start
to
look
at
okay,
well,
I'm
running
multiple
clusters
and
multiple
cloud
providers,
right
I
need
a
concept
of
if
I,
if
I
build
a
node
and
I
build
storage.
I
want
to
make
sure
that
nude
is
close
to
the
storage.
That's
going
to
be
attached
to
it,
okay,
so
that's
all
code
that
has
to
be
written.
A
C
So
what
are
we
doing
next
right?
What
are
the
big
things
we
I
think
we've
alluded
to
a
lot
of
this
already,
so
you
know
we've
already
gotten
pretty
far
with
moving
the
cloud
provider
out
of
the
company's
kubernetes
tree
and
it's
you
know
it's
functional.
It
works.
There's
a
few
last
steps
to
complete
there
that
are
being
tracked
in
this
issue.
The
big
thing
that's
missing
and
it
doesn't
attract
in
that
issue,
yet
is
documentation.
C
C
A
The
perspective
of
a
cluster
API
maintainer
again,
we
need
help
like
I,
think
we
need
help
and
every
portion
of
the
project
right.
So
if
you're,
if
you're
talking
to
a
sig
chair
or
sake
technically
this
week,
ask
them
how
you
can
help
if
you're
interested
in
contributing
to
kubernetes.
So
you
know
from
the
from
the
cluster
API
provider
perspective
I'm
actively
recruiting.
So,
if
you're
interested
working
on
that,
let
me
know
so.
A
We
have
this
idea
of
a
v1
alpha,
one
implementation,
cluster
API
and
the
v1
alpha-1
implementations,
basically
like
the
shift
from
the
shift
into
using
crts
to
manage
some
of
the
stuff
right.
So
what
we're
trying
to
do
is
every
time
we
cut
our
you
know.
Every
time
we
cut
a
version
of
cluster
API
user.
We
want
to
make
sure
that
that
stuff
is
compatible
like
semver
compatible
with
you
to
the
the
upstream
cluster
api,
proper
right,
so
continuing
to
work
on
that
implementation.
A
C
C
We
need
to
get
all
of
the
sort
of
different
pieces
together
and
wait
it's
hard,
because,
no
matter
how
you
cut
the
organization,
there's
always
going
to
be
lots
of
cross
sig
dependencies,
and
we
need
to
find
a
way
to
get
all
of
those
things
together
to
align
them
and
make
sure
that
we've
got
the
right
efforts
and
investments
in
the
right
areas.
So
we're
gonna
have
a
kind
of
a
planning
session
and
sometime
after
the
summer,
we
don't.
C
We
don't
yet
know
when
exactly
and
we're
totally
opens
ideas
and
suggestions
about
when
and
where
and
how
that
would
happen.
My
first
idea
is
that
it
would
be
just
a
virtual
event:
we'd
get
some
pre-planning
done
like
what
are
the
big
questions
that
everybody
wants
to
answer
across
all
of
the
SIG's
and
get
everybody
contributing
to
that.
And
then
we
organize
pre
work
and
preparation
for
that
and
then
we'd
have
a
session
where
we
work
through
all
of
that
and
come
out
with
a
set
of
concrete
roadmaps
for
all
of
the
different
dependencies.
C
A
C
B
A
A
B
C
C
So
we
do
maintain
a
project
board
and
github,
so
this
is
a
great
way
to
kind
of
understand.
At
least
what
the
people
who
are
active
in
the
sig
believe
are
the
things
that
you
that
need
to
be
happening,
and
so
what
one
really
concrete
in
kind
of
easy,
asynchronous
way
to
understand
what
people
are
paying
attention
to
and
have
your
voice
heard,
is
to
go
into
the
project
board
and
add
your
comments
to
issues
like
speak.
I
think.
C
A
C
D
F
A
So
so,
actually
for
the
the
provider
implementations
for
closer
API,
the
bootstrap
phase
of
the
provider
is
actually
can
either
be
done,
via
mini
queue
or
via
kind.
So
if
anyone
has
never
heard
of
kind
go
check
it
out,
what
kind
is
really
cool?
The
bootstrap
process
is
infinitely
faster.
The
one
of
the
issues
that
we
run
into
is
exactly
that
right.
The
way
we
build
cluster
API
implementations
has
to
be
done
in
an
agnostic
way
right
and
there.
A
C
I'll,
take
that
so
cube
atom
is
a
very
sort
of
generic
infrastructure
related
tool
right,
so
it
abstracts
directly
from
the
eye
API
today
what
a
gas
engine
does
is.
It
creates
arm
templates,
which
are
basically
nazzer
specific
implementation
of
that
abstraction,
and
so
we're
at
the
point
where
we're
trying
to
decide
honestly
whether
or
not
you
know
we
need
to
consolidate
those
things
or
they
need
to
remain
on
separate
tracks,
because
they
have
different
use
cases
and
that's
actually
the
analysis
that
I'm
in
the
process
of
doing
actively
over
the
next
several
weeks.
C
A
So
the
funny
story,
the
cluster
API
provider
for
adjure,
actually
started
off
using
arm
templates
as
well
right
so
very
similar
different
provisioning
process.
But
the
you
know,
like
the
end
artifact
that
you
get
out
of
it,
is
the
same
so
right
now
we
act
weird
for
cluster
API,
we're
using
cube,
ATM
and.
D
A
May
see,
as
Craig
mentioned,
we
may
see
a
convergence
of
those
efforts
because
we
I
mean
that's
kind
of
the
reason
we
have
the
AKS
engine
IKS
engine
engineers
working
on
cluster
api
as
well.
There's
gonna,
there's,
possibly
gonna,
be
a
I'm,
not
gonna.
I'm
gonna
speak
for
Microsoft,
but
there's
mostly.
A
A
A
It's
yeah,
it's
exactly
right
there
you
know
so
AWS
doesn't
have
the
concept
of
virtual
machine
skillsets
right,
but
they
do
have
the
concept
of
a
node
or
an
instance
rate.
So,
like
there's
a
there's,
a
mapping
of
what
a
so
the
the
two
main
objects
that
you
kind
of
manipulate
within
cluster
API
are
the
the
cluster
object
and
the
Machine
object
great.
So
how
you
define
a
kubernetes
cluster
is
essentially
the
same
across
all
providers
right,
but
how
you
define
a
machine
within
those
providers
is
slightly
different
right.
A
A
You
know
implementation
of
a
kubernetes
cluster
right
so
on
a
cloud
provider
might
have
a
bastion
host
and
a
load
balancer
and
the
load
balancer,
and
then
a
set
of
security
groups
within
the
cloud
provider
and
then
a
set
of
machines
with
under
the
security
groups-
and
you
know,
on
the
AWS
side,
you've
got
V,
pcs
and
subnets,
and
on
the
other
side
you
know,
you've
got
V
pcs,
but
you
know,
and
then
you
start
to
consider
you
I
mean
you've.
Not
virtual
networks.
A
Excuse
me
so
on
the
you
know,
so
there
are
there
start
to
be
differences
in
those
implementations.
When
you
look
at
the
fact
that,
for
a
virtual
network
in
for
a
virtual
network
in
Azure,
the
way
you
handle
security
groups
is
slightly
different
right
compared
to
AWS
right
AWS.
You
can
attach
you
can
attach
security
groups
and
you
can
stack
security
groups
on
two
on
two
sets
of
machines
right,
whereas
an
azure,
the
security
groups
can
be
NIC
bound
or
they
can
be
subnet
bound
right.
A
So
that's
a
that's
a
that's
a
implementation
detail
that
we
to
handle
within
the
provider,
specific
implementation
and
then
the
same.
When
you
look
at
things
like
load,
balancers
right,
we
handle
load
balancers
entirely
different
between
the
two
providers
and
I'm,
just
using
AWS
as
an
example.
But
the
same
is
true
for
kind
of
like
all
of
these
providers
right,
so
the
line
becomes
like
the
cluster
is
definitely
kind
of
homogeneous
across
providers
and
then
the
implementation,
specific
things
start
to
happen
around
the
Machine
layer.
C
B
C
A
A
The
the
rabbit-hole
goes
a
little
deeper
and
cluster
api.
This
is
kind
of
like
the
broad
strokes,
but
you
know
you
consider
the
vmss
versus
something
like
auto
scaling
groups
in
AWS,
again
different
implementation
right,
so
how
we
have
to
handle
it
within
the
cloud
provider.
Implementations
are
gonna,
be
slightly
tweaked.
What
we
try
to
do
is
right
now
we're
not
looking
too
intently
on
building
out
vmss
only
because
vmss
is
a
little
unethical
to
the
the
whole
like
concept
of
a
single
machine.
C
So
you
know
it's
a
question
of
what
you
want
to
manage
right
like
do
you
do
you
want
to
manage
the
masternodes
in
the
control
plane
and
there
upgrade
path
and
do
you
need
to
have
essentially
intimate
control
over
when
which
features
are
enabled
versus
not
enabled
do
you
need
to
add
in
your
own
capabilities?
Then
they
can't
engine.
This
is
really
your
only
path.
Aks
has
a
managed
service
where
you
know
it's
up
to
us
when
we
add
new
capabilities
into
the
control
plane
and
you
just
don't
have
access
to
the
management
network
right.
C
It's
it's
entirely
protected
from
you
for
good
reasons,
and
it's
really
a
question
of
your
use
case.
So
the
mental
model
that
I
tend
to
use
is
if,
if,
if
you
are
providing
a
major
service
for
your
whoever
your
users
or
your
query,
are
whether
your
service
provider,
yourself
or
you
can
think
of
yourself
as
a
service
provider
within
a
company,
and
you
need
to
do
things
that
are
outside
of
the
scope
of
IKS
the
main
service,
then
a
case
engine
is
a
great
tool
to
help
you
manage.
C
E
C
C
Anybody
know:
okay,
that's
that's
very
interesting!
Oh
you
are,
but
you
came
in
later
to
cool
other
questions.
No
okay,
well,
I
will
be
actually
headed
to
the
Microsoft
booth.
I've
been
asked
by
the
marketing
to
continue
any
conversations
that
want
to
be
happening.
We
can
have
them
there,
but
I'll
also
hang
out
here
for
a
little
while
I'll.