►
From YouTube: Introduction to Windows Containers in Kubernetes - Michael Michael, VMware & Deep Debroy, Docker
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
Introduction to Windows Containers in Kubernetes - Michael Michael, VMware & Deep Debroy, Docker
The chairs for SIG-Windows will provide an update on the efforts to bring Windows to Kubernetes. This will concentrate on presenting an introduction of Windows Containers in Kubernetes and new features that are being delivered.
https://sched.co/UaiZ
A
B
I'm
deep
now
so
I'm
deep
Dubrow
I
work
at
docker,
the
part
of
docker
that
still
docker
and
let's
see
I've,
been
involved
with
sig
Windows
pretty
actively
over
the
last
year,
working
on
a
couple
of
features
around
GM,
SA
and
right
now
around
enabling
CSI
support
for
Windows.
It's
been
a
great
community
and
working
with
a
lot
of
the
folks
here
on
different
stuff
yeah.
A
All
right,
good,
good
blend
of
the
crowd,
so
how
many
of
you
have
windows
containers
in
production
today,
the
least
got
much
smaller
and
how
many
of
you
guys
are
evaluating
windows
containers
or
you
have
like
workloads
that
you're
basically
trying
to
pour
legacy,
don't
add
into
that?
Okay,
how
many
of
you
guys
are
doing
that
in
public
clouds
and
how
about
on
pram
like
PKS,
rancher,
open
shaved,
docker
enterprise
or
Mir
entire
enterprise,
all
right
cool
and
I
say
it's
a
good
blend.
You
know
as
part
of
cig
windows.
A
Give
you
an
overview
of
cig
windows,
kind
of
walk
you
through
the
journey
of
where
we
are
today,
we'll
leave
some
time
for
Q&A
later
on,
and
then
we
have
another
session
tomorrow.
That's
gonna
go
deep
dive
into
into
Windows,
more
specifically
around
day
2
operations,
management,
logging,
monitoring,
etc.
So
if
any
of
you
guys
are
interested
look
for
that
session
as
well,
so
you
know
why
windows
containers
and
why,
on
kubernetes?
A
More
importantly,
so
some
of
the
biggest
benefits
that
windows
containers
bring
to
the
ecosystem
is
the
fact
that
you
get
a
single
set
of
the
tools,
a
single
set
of
management
that
you
can
actually
use
across
your
entire
infrastructure.
So
if
you're
using
kubernetes
for
Linux
containers,
now
you
can
enjoy
the
same
set
of
capabilities
for
Windows.
That
means
that
you
don't
have
to
train
your
personnel
on
a
different
platform.
You
don't
have
to
kind
of
look
at
different
solutions
to
basically
establishes
get
the
same
goals.
A
When
we
started
back
in
December
of
2016
with
our
first
release,
which
was
the
alpha
release,
we
basically
hacked
around
the
cube
proxy
and
the
couplet
to
basically
show
the
art
of
the
possible
and
kind
of
energize
the
community
to
come
and
help
us
basically
build
Windows
containers
in
kubernetes
alessandra.
That's
here
was
part
of
that
journey
right
from
the
beginning,
and
so
was
Patrick.
They
saw
the
vision
and
they
said.
Ok,
let's
go
start
building
capabilities.
A
On
top
of
that,
then
we
started
building
CN
eyes
on
Windows,
and
then
beta
came
along
a
year
later
in
December
of
17,
with
kubernetes
1.9,
where
we
had
significant
investments
into
functionality
and
to
the
CNI
support,
and
then
this
this
March
of
this
year
with
1.14.
We
release
stable
support
for
Windows
containers
in
kubernetes
that
included
Windows
Server
2000
nine
support.
Now
our
journey
is
not
done.
Obviously,
there's
more
things
that
we
need
to
build
on
top
of
that
and
we're
continuing
to
do
that.
A
So
with
115
and
116,
we
added
CSI
support
for
storage.
We
added
cube,
ATM
support
for
bootstrapping
and
starting
up
a
cluster
with
Windows
nodes
as
part
of
it.
We
added
advancements
in
identity
with
Ranas
username
and
the
GMs
a
work
that
we're
going
to
drill
into
later
on,
and
then
we
added
things
like
cube
city
or
port
forward
support
for
AWS
volumes,
etc
with
117
that's
coming
out
in
a
few
weeks
who
are
adding
CSI
providers
so
now
we're
going
to
enable
you
to
to
basically
take
advantage
of
CSI
on
DCP
and
Azure.
A
What
adding
support
from
1903
the
latest
release
of
the
Windows
operating
system
and
then
in
the
future,
we're
gonna
enable
CRI
container
D
as
well
as
cluster
API
capabilities.
So
if
you're
we've
seen
here
at
cubic
on
cluster
API
is
becoming
a
bigger
and
a
bigger
thing
in
terms
of
giving
you
the
declarative
model
of
creating
and
provisioning
a
cluster
and
treating
clusters
as
cuddle
rather
than
pets.
And
we
want
to
be
part
of
that
as
Windows.
You
want
to
make
sure
that,
as
the
different
cluster
cluster
API
providers
build
their
capabilities
for
Linux.
A
A
So
a
couple
of
things
to
consider
and
we're
gonna
spend
a
lot
more
time
on
this
in
the
in
the
deep
dive.
But
the
first
and
most
important
thing
is
read
the
documentation.
A
lot
of
you
guys
did
not
say
that
you're
running
Windows
containers
in
production.
The
reason
why
we
say
that
is
because
there's
different
capabilities
and
different
things
on
Windows
as
compared
to
Linux.
You
cannot
compare
them
up
force
to
up
cause
when
you're,
creating
your
pod
specs.
A
When
you
configuring,
kubernetes
and
your
policies,
you
need
to
take
into
account
some
special
considerations
around
windows
and
our
documentation
causes
those
out
specifically
just
so
you're
made
aware
of
what
works
and
what
doesn't
work
on
windows.
Then,
when
these
are
most
a
very
important
one,
Windows
nodes
can
only
run
windows.
Containers
and
Linux
nodes
currently
run
Linux
containers.
So
so
that's
a
very
specific
thing
that
you
guys
need
to
be
aware
of
and
the
way
that
we
solve
this
is
you
can
use
node
selectors
in
your
path,
specs.
A
You
can
use
stains
and
toleration,
which
is
something
that
we
recommend
as
a
seed,
so
that
you
can
protect
your
existing
nodes
that
are
running
Linux
from
getting
a
Windows
workload
scheduled
on
them
and
vice
versa.
You
know,
if
you
have
an
already
existing
infrastructure
of
applications
and
kubernetes
clusters,
you
likely
have
Linux
applications
have
pod
specification
that
doesn't
have
node
selectors.
It
doesn't
have
taint
in
it.
It
doesn't
have
toleration.
So,
by
using
this
method,
you
can
protect
your
windows
nodes,
so
they
can
only
windows.
A
Containers
can
run
on
them,
be
careful
of
resource
consumption
as
a
Windows
node
you
and
in
a
Windows
container,
there's
specific
sort
of
processes
that
are
running
that
have
a
little
bit
higher
resource
consumption
requirements
as
compared
to
to
their
Linux
equivalents.
So
take
that
into
account
when
you're
building
your
applications.
But
then,
on
top
of
that,
when
you
think
about
memory
limits
and
prediction,
we
haven't
completely
implemented
the
set
of
functionality
in
kubernetes,
yet
we're
working
on
it.
A
So
when
you're
monitoring
your
applications
or
windows,
take
that
into
account
and
make
sure
that
you
put
certain
alarms
and
events
that
will
come
back
to
you
as
you
have
those
applications
running
in
production
and
the
last
is
the
kernel
compatibility
today.
The
way
that
Windows
is
being
structured
is
you
have
to
match
the
major
version
of
the
OS
across
the
container
host,
as
well
as
a
container
image.
So,
if
you're
running
several
2019,
for
example,
as
your
host
OS,
all
your
containers
need
to
also
run
the
same.
A
A
So
some
of
our
recent
features
that
we
want
to
kind
of
highlight
and
deep
dive
on
that
is,
we've
been
focused
a
lot
around
Windows
identity
and
the
reason
behind
it
is
a
lot
of
the
traditional
existing
legacy.
Even
if
you
may
say
that
Windows
applications
really
do
a
lot
of
things
with
Windows
identity,
where
that's
an
application
pooling
is
that
tied
to
Active
Directory
or
an
application?
That's
talking
to
an
external
database
server
or
an
external
file
share,
and
it's
using
the
Windows
identity
to
basically
be
authorized
with
that
external
entity.
A
A
Well,
that
alpha
support
for
cube
ADM
join
so
we'll
make
it
easier
for
you
to
provision
and
boost
up
a
cluster.
So
how
does
that
look
like
so
today?
All
your
master
components
need
to
run
in
Linux.
You
can
use
whatever
method
you.
You
want
to
basically
create
your
master
components
and
all
those
nodes
in
kubernetes
and
then,
when
the
time
comes
to
add
windows.
Nodes
to
your
container
will
give
you
a
set
of
scripts
that
we
maintain
as
a
sig.
A
That
will
allow
you
to
download
all
the
necessary
binaries
cubelet
proxy
flannel
as
your
CNI,
and
then
our
script
will
go
through
provision,
all
of
them
as
Windows
services
and
get
them
started
and
immediately
once
that's
done,
you
can
join
that
node
to
the
kubernetes
cluster.
So
we
try
to
make
it
fairly
simple
to
do
provision
and
boost
elaborate
cluster
next,
actually
we're
working
on.
How
do
you
help
you
upgrade
those
clusters
from
one
version
of
kubernetes
to
the
next?
A
So
that's
the
next
step,
that's
coming
from
that
area,
and
then
the
last
thing
here
is
alpha
support
for
for
CSI.
So
we
added
that
starting
with
1.16
and
we're
making
more
advancements
into
our
next
release.
So
how
can
we
make
it
easy
for
you
to
use
persistent
storage
in
your
kubernetes
applications
running
on
windows
containers?
So
let
me
pass
it
to
deep
to
talk
a
little
bit
more
about
this.
B
All
right,
so,
let's
take
a
look
at
how
we
implemented
some
of
the
things
around
identity
for
Windows
containers.
So,
as
you
might
be,
a
very
active
directory
is
a
pretty
important
part
of
all
Windows
enterprise
shops
and
in
order
to
ensure
that,
as
you
migrate,
your
apps
to
containers
they,
they
are
able
to
maintain
the
same
same
level
of
identity
guarantees
that
were
there
in
the
non
containerized
world.
And
what
helps
in
that
regards
is
this
concept
called
group
managed
service
accounts?
B
Now
the
challenge
and
the
kubernetes
ID
was:
how
do
we
maintain
these
identities
in
an
orchestrated
fashion
across
the
cluster,
so
that
as
a
pod
moves
from
one
host
to
another,
probably
due
to
the
node
failing
or
for
any
other
reason,
the
identity
goes
along
with
the
workload
from
one
node
to
another
throughout
the
cluster.
So
we
mapped
this
concept
of
a
GMS,
a
credential
spec
to
something
called
custom
resources
in
cuban
aires,
and
we
came
up
with
CRD
definition
that
we
released
called
JMS
a
credential
spec,
and
we
also
give
you
a
command.
B
Let
that's
referred
to
in
the
kubernetes
talks
on
Windows
threw
that
allows
you
to
generate
the
yeah
Malan,
the
left
or
I
guess
write
that
encapsulate
s--,
exactly
the
identity
that
you
want
to
associate
with
a
particular
container.
So
once
you
have
the
custom
resource
ready,
that
represents
your
dmsa
identity.
You
need
to
make
sure
that
all
the
hosts
that
are
all
the
windows
hosts
that
are
part
of
the
cluster
where
the
pod
my
clan
is
domain,
joined
and
one
and
once
it
is
domain
joined
and
you
have
the
CRD
applied
to
your
cluster.
B
You
need
to
make
sure
that
the
pods,
the
service
account
that's
used
to
run.
The
pod,
for
example,
it
could
be
just
default
default.
Has
the
use
permissions
on
the
custom
resource?
So
basically,
this
slide
describes
the
three
important
things
that
needs
to
be
applied
on
the
cluster,
the
credential
spec
llamo,
which
is
basically
a
custom
resource,
cluster
role
and
role,
binding
time,
allowing
the
usage
of
the
custom
resource
by
containers
by
specific
pods
and
then
finally,
the
way
this
ties
back
into
Ana
into
actual
pod.
B
Is
we
introduced
a
couple
of
security
options
under
the
windows
option
stanza
in
the
pod
spec,
so
initially
at
around
114
around
alpha?
We
used
to
use
annotations
for
this,
but
gradually
around
115
there's
a
graduated
into
like
full-fledged
pod
spec
fields
and
we
release
as
part
of
the
seg
a
couple
of
one
admission:
Webber
controller
and
one
mutating
waiver
controller.
What
the
mutating
Webber
controller
does
is.
It
looks
at
the
specification
called
the
GMs.
B
A
credential,
spec
name
looks
up
the
custom
resource
that
maps
to
it
and
mutates
the
pod
spec
with
the
actual
contents
that
you
specified
in
the
credential
spec
into
the
pod
spec
itself,
before
it's
sent
out
to
the
API
server.
Another
interesting
feature
that
we
added
is
the
ability
to
specify
the
username
that's
running
the
workload
itself,
so
that's
encapsulated
in
the
run
as
username
field
that
is
I,
believe
going
to
beta
in
117
and
oh
yeah,
so
and
as
you're
going
through
this,
it's
important
to
realize
that
a
pod
itself
can
have
multiple
containers.
B
So
basically
you
can
have
GMs
a
that
applies
to
the
entire
port
to
all
the
containers
in
the
pod,
or
you
can
specifically
override
the
GMs
sacred
spec
that
you
want
to
apply
to
specific
containers
within
the
pod.
This
is
a
pretty
useful
concept
because,
you
might
have
say
a
main
workload
container,
along
with
logging,
sidecar
and
some
other
sidecar,
which
requires
their
own
set
identities,
which
you
can
specify
individually
per
container
as
part
of
the
overall
pods
back.
B
One
of
the
things
we
noticed,
especially
Jeremy,
noticed
when
he
was
trying
it
out
in
his
own
test
beds,
was
that
oftentimes,
as
the
containers
come
up,
they
do
have
a
little
bit
of
a
lag
before
which
the
during
during
which
they
are
not
able
to
actually
authenticate
with
the
ad
server.
It's
mainly
a
lag
with
how
the
networking
gets
set
up.
Whether
DNS
is
responding
and
things
like
that.
B
So
as
part
of
our
documentation,
we
also
call
out
post
start
lifecycle
hook
that
easily
allows
you
to
make
sure
that
the
NL
test
commands
are
actually
passing
for
the
container.
That's
that
actually
indicates
that
the
Active
Directory
connection
is
enabled
and
altercation
can
go
through,
after
which
the
kind
the
main
payload
of
the
container
is
allowed
to
execute,
using
something
like
a
lifecycle
hook
makes
it
pretty
easy,
because
then
you
don't
have
to
go
back
and
change.
A
Actually,
one
more
thing
to
add
to
that
is:
if
you're
looking
at
you
know
your
your
container
itself
and
the
services
are
running
inside
of
it.
If
you
want
the
container
to
carry
that
identity
in
the
networking
is
to
run
either
as
local
service
or
network
service,
and
those
are
the
two
services
in
Windows
that
will
carry
the
identity
on
the
network.
So
if
you
run
something,
as
you
know,
account
name
foo
that
that's
not
going
to
carry
that
until
in
the
network.
So
if
you
have
iis
make
sure
your
application
pools
carry
the
identity.
A
B
B
Typically,
your
tublat,
as
well
as
on
the
provisioning
side
in
the
controllers,
but
through
through
an
initiative
called
CSI
migration.
The
overall
idea
is:
the
community
wants
to
get
away
from
entry
plugins
in
2
out
of
3
plugins
delivered,
ideally
through
CSI.
Now
in
the
CSI
model,
the
idea
is,
there
are
controller
plugins
that
allow
you
to
provision
storage,
attach
it
to
certain
nodes
and
things
like
that,
and
then
there's
this
other
critical
piece
called
a
CSI
node
plugin,
which
needs
to
be
deployed
on
each
node.
B
B
6
storage
does
not
like
them,
so
CSI
is
a
way
forward
and
the
way
we
are
enabling
CSI
support
in
Windows
is
using
a
privileged
proxy
binary
that
sits
in
your
host
and
allows
arbitrary,
CSI
node
pods,
geared
towards
Windows
to
communicate
with
the
privileged
proxy
and
get
their
privileged
operations
accomplished.
We
have
a
talk
right
after
this
in
I
think
meeting
room
7,
a
and
B,
where
we
dive
a
lot
more
into
this.
But
this
is
the
general
idea.
B
The
CSI
proxy
is
going
to
expose
a
whole
bunch
of
API,
so
it
allows
you
to
anywhere
a
disk
volumes.
Mount
SMB
shares,
login
to
I
scuzzy
targets
and
so
on.
Some
of
a
broad
array
of
common
storage
related
operations
that
a
container
that
is
published
by
a
storage
vendor
can
make
use
of
pretty
easily
so.
B
Yeah,
it's
the
the
bulk
of
this
component
is
in
the
CSI
proxy
repo
that
we
are
working
on
it's
completely
out
of
tree.
It's
going
to
be
launched
as
a
separate
binary,
there's
a
lot
of
support
for
different
API
versions.
That
may
be
enabled
to
support
multiple
different
CSI
plugins.
At
the
same
time,
on
the
same
host.
This
model
follows
very
closely
the
kubernetes
api
model
and
uses
a
lot
of
the
same
tooling
that
allows
screw
binaries
to
support
multiple
different
API
versions.
B
At
the
same
time,
some
of
the
enhancements
that
were
needed
in
the
cubelet
and
the
CSI
no
driver
register
side
was
already
completed
in
116.
So
all
that
is
entry.
The
bulk
of
the
work
remaining
is
pretty
much
in
the
CSI
proxy,
just
finishing
up
all
the
api's
and
servicing
it
up
to
the
CSI
plugins.
So
right
now
we
have
been
doing
some
prototyping
work
with
GCPD
CSI
driver
and
Azure
dis
CSI
drivers,
folks
from
both
of
these
projects,
are
involved
in
the
CSI
proxy
effort.
A
Stay
away
deep,
so
the
you-know-what
just
mentioned,
and
the
last
one
is
super
important
right.
So
if
any
of
you
guys
have
requirements
into
a
separate
type
of
storage
device
or
or
another
infrastructure
in
storage
coming
to
our
cig,
let
us
know
we'll
capture
your
requirements.
Hopefully
some
of
you
are
willing
to
come
and
help
us
develop
that
and
you
know
make
that
the
reality.
So
so
what
are
we
going
next,
so
CRI
container
D,
that's
super
super
important
to
us.
A
Patrick
has
been
driving
that
eating
sleeping
CRI
container
D
pretty
much
every
day
for
the
last
few
months
and
we're
gonna
get
it
in
alpha
very
soon.
We're
collaborating
very
closely
with
sig
node.
That's
gonna
enable
a
few
things.
You
know
the
doc
regime
and
in
the
current
existing
runtime
layer
that
we
have
is
you
know
it's
necessarily
deprecated,
but
you
know
not.
A
lot
of
investment
is
going
into
it.
A
Cri
container
these
where
the
community
is
going,
is
going
to
Nabal
us
to
take
advantage
of
the
layer
and
also
make
investments
into
how
the
cni
work
really
well
in
the
lair.
How
do
you
make
storage
possible
in
a
layer
how
bring
hyper-v
isolation
with
CRI
continuity?
All
of
those
are
things
that
you
can
enable
as
part
of
that
work
as
well.
We're
gonna
obviously
continue
our
cube.
A
Atm
investments
we're
going
to
bring
you
cluster
lifecycle
and
cluster
API
into
Windows
containers,
and
our
goal
is
to
do
that
within
the
next
six
to
eight
months
at
the
most,
and
you
know,
obviously,
of
the
work
that
Deb
has
been
spearheading
around
GM
Si
and
si
si
we're
gonna
keep
promoting
that
we're
gonna
get
GM
si
to
stable,
we're
gonna,
get
si
si
to
beta
and
beyond,
so
we're
not
stopping
in
any
of
those
investments.
Now
we
have
weekly
meetings
every
week
at
12:30
Eastern.
A
So
if
any
of
you
guys
want
to
learn
more
about
sig
windows,
come
to
our
meetings,
bring
your
scenarios
tell
us
about
issues
that
you're,
having
or
obviously
also
on
slack,
we
have
a
recording
of
all
our
community
meanings.
If
you
wanna
hop
its
Tobuscus
started,
coming
fix
some
bugs
how
about
fix
documentation.
Those
are
usually
the
easiest
barriers
to
entry
into
our
sig.
A
So
if
you
want
to
get
started,
find
a
couple
of
bugs
from
our
project
board,
try
to
fix
them
and
that
should
get
your
feet
wet
in
the
sig,
and
this
is
how
you
can
find
us.
We
have
all
of
Google
groups.
We
have.
We
are
on
YouTube,
there's
a
playlist
with
all
our
community
meetings
who
have
our
documentation
on
the
bottom
right.
A
If
you
want
to
get
your
feet
wet
on
Windows
and
I,
don't
want
to
take
a
moment
here
to
recognize
a
couple
of
folks,
so
so
sick
windows
me
and
Patrick
have
been
the
the
chairs
for
for
a
while
now
and
dip
deploy
and
Ben
moss
from
pivotal
and
deep
from
from
docker
have
been
recognized
for
their
valuable
contributions
to
the
sig
and
they're.
Both
technical
leads
in
our
signals.
So
let's
give
them
a
round
of
applause.
C
C
Right
so
I
guess
kind
of
effort.
The
first
step
in
moving
to
the
hyper-v
stuff
for
isolation
is
actually
moving
to
container
D.
One
of
the
problems
we
had
with
what
the
previous
implementation
is.
We
could
only
run
one
container
per
pod
with
the
earlier
hyper-v
alpha,
but
we
can
fix
that
with
a
cry
container
D,
and
so
that's
something
that's
a
in
the
works
right
now
and
should
be
usable
in
the
18
time
frame,
probably
I
mean
before
18
release,
but
you
know
over.
C
A
A
Initially,
just
from
the
point
where
it
goes
alpha,
they
should
be
able
to
use
it
and
start
providing
us
feedback,
and
you
know
this
is
just
us
following
the
kubernetes
required
basically
cycle,
it
doesn't
mean
that
you
know
it
doesn't
work
or
you
can't
really.
You
know
play
around
with
it
or
start
putting
your
your
windows
continues
into
hyper-v.
So.
C
Yeah,
okay,
to
restate
the
question,
so
the
question
was
around
how
file
Ackles
work
and
those
are
basically
interpreted
inside
the
container
today
and
that's
because
each
windows
container
carries
its
own
security
database
in
there,
and
so
those
names
are
resolved
in
within
inside
there.
That's
also,
why
run
as
user
name
needed
to
be
added,
so
we
could
pass
that
in
as
a
string.
A
C
C
A
What
you've
seen
is
a
lot
of
customers
like
you,
look
at
it
from
an
application
standpoint
that
stance
patty
gave
you.
If
you
look
at
it
from
a
hardening
standpoint
as
part
of
the
process
of
building
your
container
and
using
your
docker
build,
you
can
declaratively
indicate
what
occurs
you
want
throughout
the
entire
file
system
of
the
container,
so
you
can
use
things
like
I,
see,
ALS
or
other
tools
to
reduce
or
amplify
the
permissions
of
the
of
the
file
system,
and
then,
once
that's
declaratively.
A
A
C
A
C
A
Yes,
essentially
today,
with
Windows
server
containers,
were
the
containers
shared
the
kernel
with
each
other
container
on
the
same
host
as
well
as
with
the
hosts
itself.
The
requirement
is
that
the
major
version
of
the
wesen
is
too
much
because
the
kernel
is
shared
if
you're,
using
hyper-v
isolation.
That
Patrick
mentioned
earlier
that
coming
with
CRI
container
D
you're
going
to
be
able
to
escape
that
the
much
more
than
you
can
any
container
inside
of
it,
because
it's
going
to
be
wrapped
up
into
a
very
lightweight
virtual
machine.
A
A
C
You're
gonna
have
a
step
to
get
a
bunch
of
that
stuff
loaded
in
and
then,
after
that
it
becomes
incremental
again
and
so,
like
I'm,
my
laptop
I
was
able
to
run.
You
know,
like
I,
don't
know
20
IAS
instances
in
a
matter
of
a
couple
gigs,
so
it's
still
much
denser
than
your
you're
gonna
get
with
the
VM
and
in
the
startup
time,
for
that
first,
one
is
a
little
bit
higher
because
more
that
stuff
needs
to
be
paged
in
off
a
disk.
C
Basically,
I'm
a
part
of
the
Azure
team,
I'm
working
on
kubernetes
there,
but
I
work
closely
with
the
team.
That's
doing
the
CRI
implementation
on
the
window
side
and
one
of
the
balances
that
were
always
having
to
be
very
careful
too,
is
making
sure
that
we're
meeting
both
the
needs
of
window
of
what
is
actually
needed
for
windows
application,
because
the
goal
is
not
to
make
Windows
work
like
Linux.
C
The
goal
is
to
run
Windows
Windows
Windows
apps,
in
a
way
that
the
windows
administrator
can
understand
it,
and
that
does
mean
that
some
of
the
concepts
that
were
there
that
weren't
in
Linux
there
is
a
bit
of
an
impedance
mismatch
there.
And
so
you
know
things
like
the
user
name
versus
UID.
It
was
a
common
one.
The
file
Ackles
are
different,
and
but
we've
I
feel
like
we've,
had
a
really
good
collaboration,
particularly
it
was
sick,
node
and
being
able
to
work
through
those
things.
C
Because
if
you
go
and
look
at
things
like
the
open
container,
they
should
have
spec.
They
did
account
for
multiple
OS
differences
in
there
and
so,
wherever
possible.
We're
trying
to
make
sure
that
that's
something
that
can
be
mirrored
between
you
know
the
OCI
spec
that
was
used
to
actually
build
the
containers.
All
the
way
up
to
the
kubernetes
api
and
there's
still
gonna,
be
a
few
more
gaps
here
and
there
that
we
need
to
fill
along
the
way.