►
From YouTube: Webinar: Get Your Windows Apps Ready for Kubernetes
Description
Running Windows Containers on Kubernetes is now fully supported! But running Windows applications in production on Kubernetes is more than just containerizing the app – especially in enterprise environments. Join us for a presentation and demo to learn about critical design elements for making sure your Windows app is production-ready, including:
*How to implement Active Directory with container-based applications requiring Integrated Windows Authentication
*Options for workloads requiring persistent storage
*Techniques for retrieving logging data from Windows apps, which do not default to using standard out
*When to utilize each available container base image from Microsoft
Presenter:
Steven Follis
Manager, Solutions Engineering @Mirantis
A
All
right
we're
gonna
go
ahead
and
start
up
I'd
like
to
thank
everybody
joining
us.
Today.
We've
got
a
nice
group
of
attendees
out
there.
Welcome
today's
CN
CF
webinar,
get
your
Windows
apps
ready
for
kubernetes
I'm
Randi
Abernathy,
with
rxm
on
the
cloud
native
ambassador
and
I'll.
Be
your
host
we're
going
to
also
welcome
today's
presenters,
even
foulest
manager
of
solutions,
engineering
at
Moran,
just
a
couple
of
housekeeping
items
before
we
get
started
during
the
webinar
you're,
not
able
to
talk
as
an
attendee.
A
So
this
is
an
official
webinar
of
the
CNC
F
and,
as
such,
its
subject
to
the
scenes,
the
F
Code
of
Conduct.
So
please
don't
put
anything
in
the
chat
or
in
the
questions
area
that
would
violate
that
code
of
conduct.
You
know
just
be
respectful
as
the
bottom
line,
and
so
really
with
that
I'll
I'll
hand
it
over
to
Steven
to
kick
off
today's
presentation,
Steven
excellent.
B
Thank
you
so
much
Randy
and
welcome
everyone
to
this
webinar
today.
I.
Thank
you
for
trusting
us
with
your
time.
This
morning
afternoon
or
evening,
wherever
you
might
be,
my
name
is
Steven
Follis.
As
Randy
said,
I
run
a
team
of
solution
engineers
amaranthus
prior
to
that
spent
almost
three
years
at
docker,
working
with
container
customers
of
all
shapes
and
sizes.
I'm
excited
today
to
talk
about
the
intersection
point
between
the
kubernetes
container,
orcish
trader
and
Windows
workloads,
and
so
today
we're
gonna
be
talking
a
little
bit
about.
B
B
I
do
have
some
time
for
a
demo
today
and
and,
as
Randy
said,
we'll
leave
some
time
for
Q&A,
okay
here
at
the
end.
So
with
that,
let's,
let's
jump
right
on
in
so
as
far
as
why
Windows
containers.
This
is
a
question
we
get
all
the
time.
You
know.
Containers
are
a
Linux
thing.
They
came
from
the
Linux
world,
cgroups
namespaces
baked
in
the
Linux
kernel.
Why
are
we
talking
about
Windows?
B
Well,
as
many
of
you
may
be
aware,
beginning
with
Windows
Server
2016
Microsoft
introduced
support
for
Windows
containers,
which
are
analogous
and
very
similar
to
their
Linux
container
cousins.
This
then
allowed
us
to
take
legacy
net
based
workloads,
running
on
Windows,
Server,
containerized
them
and
then
get
the
benefits
of
containers
with
those
windows
based
workloads,
and
so
one
of
the
things
that
we've
seen
over
the
last
several
years
is
that
there
are
still
a
lot
of
Windows
applications
out
there
in
the
world
today.
B
So,
while
we
oftentimes
in
the
industry
really
enjoy
talking
about
the
new
shiny
micro
service
framework
or
things
like
nodejs,
go,
laying
rust
python
in
reality,
there's
a
significant
amount
of
applications
that
are
out
there
in
the
world
today
that
can
use
the
benefits
of
containers
to
breathe
normal
life
into
them,
and
so
this
is
by
targeting
these
on
from
workloads.
It
allows
folks
that
are
operating
on
prim
environments
to
shrink
that
footprint
and
make
them
more
efficient
with
how
they're
able
to
operate
those
workloads
today.
B
Secondly,
from
a
people
perspective,
we
still
see
a
lot
of
developers
out
there
that
are
utilizing
the
c-sharp
programming
language,
and
so
nearly
a
third
of
respondents
to
the
stack
overflow
developer
survey
are
stating
that
they're
still
writing
a
lot
of
c-sharp,
which
predominantly
and
historically
is
associated
with
Windows
Server
based
workloads.
There
are
certainly
with
dotnet
core
that's
starting
to
change,
but
a
lot
of
the
c-sharp
out.
There
is
still
in
the
dotnet
framework
family
speaking
of
frameworks.
B
We
still
see
asp.net
and
dotnet
s--
near
the
top
of
lists
from
stack
overflow
rounds,
the
top
framework
choices
that
are
being
used
today
out
in
the
industry,
and
so
hopefully
all
these
numbers
are
painting
a
picture.
There's
still
a
lot
of
applications
out
there
that
we
can
go
after
and
that
we
can
focus
on
container
izing
and
getting
the
benefits
around
portability
or
on
scalability,
and
then
all
the
capabilities
of
kubernetes
alongside
them
as
well.
So
from
a
use
case
perspective,
we
see
a
variety
of
values
that
folks
find
it's
with
containers
and
kubernetes.
B
The
first
is
around
consistent
operations.
Historically,
we
have
had
different
siloed
stacks
of
how
we
built
and
ran
applications,
so
over
here,
I
may
have
my
Linux
team
that
are
running
kind
of
engine
X
based
applications,
and
they
do
things
one
way
and
then
over
on
another
side
of
the
organization,
we
have
the
windows,
team,
building
and
running
windows
apps
differently.
There's,
oh
there's
large
discrepancies
between
the
two
there.
B
What
kubernetes
allows
us
to
do
nowadays
is
to
take
one
standard,
cluster,
the
kubernetes
technology
and
then
be
able
to
run
a
Linux
based
application
that
we
built
last
quarter
and
a
Windows
app
that
we
built
last
decade
and
ran
them
side-by-side
on
the
exact
same
infrastructure.
This
greatly
decreases
operational
complexity
like
breaking
down
those
silos
and
having
consistency
between
how
we
run
applications
allows
us
to
set
up
one
set
of
firewall
rules
instead
of
em
fro.
Instead
of
our
back.
We
do
everything
once
rather
than
every
single
time
for
each
different
kind
of
application.
B
So
consistency
is
a
big
benefit
that
we
get
with
a
myriad
of
different
applications.
Running
on
kubernetes
next
is
around
legacy
Network
loads.
We
stated
a
second
ago
that
there's
a
lot
of
that
out
there
and
those
applications
are
typically
an
in
need
of
some
tender,
love
and
care
right
now,
while
you
may
have
developers
that
are
building
greenfield
kind
of
new
applications
and
gonna
take
advantage
of
very
seamless
deployment
and
build
experiences,
whereas
the
teams
that
are
supporting
legacy
top
net
apps
are
oftentimes
still
running
in
your
manual
build
scripts.
B
You
know,
there's
oftentimes
a
lot
of
manual
work,
that's
being
done
because,
back
when
those
applications
were
created
there,
there
weren't
a
whole
lot
of
better
options
there
and
so
containers
allow
us
to
bring
characteristics
of
more
modern
frameworks
and
be
able
to
use
that
with
this
more
legacy
code.
So
we
get
a
smoother
deployment
experience,
a
smoother
scalability
experience
and
just
a
better
operational
context,
and
what
we've
had
historically
third
is
cost
savings.
This
is
really
one
of
the
biggest
oftentimes,
especially
on
print.
We
have
VM
sprawl.
B
B
So
we
can
run
them
side
by
side
and
get
much
higher
utilization
in
a
kubernetes
cluster
than
we
can
on
mini
stand-alone
VMs,
and
so
it's
it's
cheaper
from
an
infrastructure
perspective,
it's
cheaper
from
a
management
perspective
and
then
for
those
users
that
are
looking
at
at
public
cloud
as
an
option.
What
we
find
is
that
that
VM
that's
running
right
now
on
prim
at
20
percent
utilization.
You
know
we
already
expense
that
whole
that
whole
blade
server.
B
That's
not
a
big
deal,
but
as
we
go
to
the
public
cloud
and
we
start
being
charged
on
an
OP
X
model,
where
every
single
second
we're
being
charged.
You
know,
eighty
percent
of
an
unused
VM
starts
to
get
pricey
right.
So
by
utilizing
less
resources
either
on
prim
or
in
the
cloud.
We
can
save
substantial
money
when
it
comes
to
operations.
B
Speaking
of
the
cloud
cloud,
migration
is
often
front
and
center.
Many
organizations
today
container
izing
creates
a
very
elegant
way
to
be
able
to
shift
applications
from
running
on
an
on-premises
context
up
to
a
public
cloud
or
even
multi.
Multiple
public
clouds
or
hybrid
containers
are
intrinsically
portable,
it's
one
of
the
best
benefits
of
them
and
so
by
container,
raising
of
windows
that
we're
able
to
more
easily
move
that
to
the
cloud.
B
So
we
can
containerize
today
and
then
in
six,
six
or
twelve
months
down
the
road
choose
to
move
that
to
the
public
cloud
or
we
can
container
eyes
and
move
to
the
public
cloud
all
at
once.
So
we
have
some
options
there
on
where
we
run
the
application
and
it
enhances
the
flexibility
of
when
and
how
we
moved
to
that
public
cloud
or
back
on
prim.
B
If,
if
me
be
and
then
finally
DevOps
applications
that
have
been
built
over
the
last
four
to
five
years
have
been
able
to
benefit
from
the
DevOps
pipelines,
you
know
continuous
integration,
continuous
deployment,
some
automation
of
all
the
things.
However,
on
the
windows
side
of
the
house,
we
haven't
always
had
the
ability
to
use
those
types
of
practices
with
our
legacy
applications.
So
we
run
DevOps
perspective.
B
We
can
now
have
very
consistent
pipelines
of
how
we
build
Linux
containers
and
then
how
we
build
Windows
containers
with
those
different
kinds
of
applications,
thus
simplifying
our
our
processes
and
taking
advantage
of
a
lot
of
the
automation
that
DevOps
in
kubernetes
afford
for
us.
So
these
are
five
of
the
main
buckets
that
we
see
interest
around
as
far
as
why
to
containerize
and
run
apps
on
kubernetes.
B
But
the
number
one
reason
that
we've
seen
over
the
last
three
years
is
all
around
Windows
Server
2008,
so
you
may
have
seen
on
Twitter
or
blogs
yesterday,
but
as
of
yesterday,
Windows
Server
2008
is
now
officially
end-of-life,
and
so
this
means
there
are
no
more
security,
patches
or
hot
fixes
coming
from
Microsoft.
We
are,
we
are
past
the
extended
support,
dates,
standard
and
extend
and
support.
There's
nothing
else
coming
there,
and
so
there
are.
B
That
said,
there
are
still
a
large
number
of
Windows
Server
2008
servers
that
are
out
in
the
world
today,
and
so
those
now,
as
of
yesterday,
are
starting
to
represent
severe
vulnerabilities
from
a
security
perspective
from
an
audit
perspective
from
a
governance
perspective
and
there's
a
bit
of
a
gold
rush
now
to
try
to
move
workloads
off
of
Server,
o
8
and
on
to
more
modern
and
supported
operating
systems
such
as
Windows,
Server,
2016,
2019,
etc.
And
so
this
has
been
a
big
driving
force
over
the
past
year.
Is
everyone
looking
at
well?
B
What
are
we
going
to
do
with
all
these
workloads
that
we
have
running
right
now?
108-
and
there
are
several
options-
the
main
ones
we
see
or
hey
we're
going
to
refactor
and
upgrade
this
application.
So
we
can
take
this
dotnet
framework,
app,
tear
it
apart.
So
let's
go
recode
it
and
the
brand-new
shiny
net
core
moving
on
to
Windows
Server
2019
and
we're
good
to
go.
That's
a
great
pathway,
but
it
typically
doesn't
scale
very
well.
B
So
if
you
have
one
or
two
applique
Asians
that
that
may
be
an
option,
but
when
we're
talking
at
a
portfolio
of
a
hundred
or
five
hundred
or
thousand
applications,
there's
simply
not
enough
manpower
and
time
to
be
able
to
go
in
and
under
undertake
such
a
massive
shift
in
application.
There's
a
lot
of
rework
many
line
of
business.
Apps
may
not
have
a
real,
visible
ROI
for
going
through
and
investing
that
much
time
and
resources.
So
this
this
refactor
and
redevelop
the
application
can
be
challenging.
B
Next
is
a
custom
support
agreement
from
Microsoft.
They
typically
come
with
a
lot
of
zeros
on
them.
So
now
that
we're
after
that
dates,
it's
simply
not
practical.
For
many
organizations
based
on
the
price
tag
of
having
very
custom
bespoke
support
from
Microsoft
for
those
workloads
that
are
running
best
case
scenario,
is
that
it's
a
it's.
It's
a
temporary
band-aid
that
you're
still
going
to
have
to
address
those
applications
sooner
rather,
you
know
at
some
point
down
the
road.
It's
really
kicking
the
can
down
the
road.
B
So
those
three
are
options,
but
the
one
that
we
found
to
be
the
most
compelling
is
around
containerization.
So
we
can
take
an
application.
That's
running
dotnet
framework
on
a
VM.
Today
we
containerize
the
application
itself
with
its
configuration.
Thus,
decoupling
that
app
from
the
underlying
operating
system
once
containerized,
we
can
throw
away
that
server,
o8
environment
and
move
the
container
forward
to
Windows
Server
2019
with
that
and
oftentimes
without
code
change,
usually
its
configuration
change
adjustment
to
web
config
files
based
on
environment,
those
types
of
things,
and
so
from
once
containerized.
B
We
then
deploy
onto
kubernetes,
and
then
we
get
I'm
a
lot
of
those
benefits
of
the
deployment
model
without
having
to
undergo
substantial
and
costly
redevelopment
efforts.
Furthermore,
if
we
fast
forward
to
two
or
three
years
down
the
road,
if
we
need
to
go
through
this
exercise
again,
we
simply
in
our
docker
file
change
the
from
statement
to
a
different
version
of
Windows
recompile,
the
container
and
now
we're
able
to
cope
with
additional
upgrades
down
the
road.
So
it's
a
more
future-proof
path
than
investing
all
that
manual
effort
today.
B
So
this
containerization
path
is
a
really
compelling
way
to
be
able
mitigates
the
windows
2008
that
are
still
within
environments
and
provide
a
more
future
looking
way
of
running
that
that
application
code,
okay.
So
now,
as
far
as
kind
of
why
we're
going
to
go
and
run
this,
let's
talk
about
kind
of
how
and
some
of
the
things
to
think
about
as
you're
beginning
this
journey
down
the
path
towards
Windows
applications
on
kubernetes,
so
the
first
place
I'd
like
to
start,
is
around
the
server
operating
system.
So
what
are
you
gonna
run?
B
These
containers
on
I
mentioned:
that's
Windows,
Server
2016
and
reduce
support
for
containers,
but
there
are
actually
a
couple
of
different
main
branches
of
how
we
can
go
out
and
get
Windows
Server.
This
may
be
review
from
any
of
you,
but
I
liked
about
Johnny,
because
it's
not
as
universally
known
as
as
I
would
expect,
but
Windows
does
come
in
two
different
flavors.
The
first
is
what
they
call
the
long
term
servicing
channel
or
LTS
C.
B
This
is
when
we,
when
you
see
Windows,
Server,
2019,
2016
2012,
those
are
all
on
the
long
term,
servicing
Channel
and
and
really
is
what
I
think
about
when
I
think
about
Windows
Server
right.
So
we
get
a
new
version,
every
2
or
3
years.
We
have
the
5
plus
5
of
support,
5
mainstream
than
5
of
extended,
and
this
is
really
focused
on
stability
and
predictability.
So
Microsoft
isn't
typically
not
shipping
bleeding-edge
features
into
the
LTS,
see
good
they
is
they
don't
want
to
rock
the
boat.
B
This
is
where
historically,
we've
built,
you
know,
mission
critical
workloads
on
top
of
the
very
stable
LT
SC,
starting
starting
with
Windows
Server
2016.
There
was
also
a
second
channel
that
has
been
opened
up
and
they
call
it
the
semi-annual
channel
or
si
si.
So
if
you've
seen
Windows
Server,
comma
version,
1909
version
1903,
1809
1709
any
of
those
types
of
numbering
scheme,
that's
related
to
the
semi-annual
channel,
and
this
isn't
a
very
different
release
channel.
So
there
you
can't
kind
of
bounce
back
and
forth
between
the
two.
B
When
you
install
a
server
you
select
kind
of
one
path
or
the
other
and
the
semi-annual
channel.
This
is
different
and
that's
we.
They
ship
at
Microsoft
ships,
new
version
every
six
months,
typically
in
the
spring
and
in
the
fall
1909,
was
just
released
a
few
months
ago.
These
come
with
with
all
the
latest
features,
so
these
are
much
more
bleeding-edge
and
so
for
technologies
that
are
emerging,
such
as
containers
and
kubernetes.
B
The
downside
to
this
that
we
often
see
here,
is
that
the
s
AC
comes
with
18
months
of
support
and
that
is
oftentimes
too
short
of
a
window
for
some
organizations,
especially
those
that
may
be
on-premises
that
have
very
stringent
qualifications
and
processes
for
approving
operating
systems.
So
you
may
be
saying:
look
hey
we
just
we
just
got
Server
2016
approved
six
months
ago.
You
know
there's
no
way
we
can
move
to
something
this
quickly
and
that's
understandable.
B
So,
typically,
if
you're
in
the
cloud
Microsoft
and
our
instance,
we
would
recommend
looking
at
the
semi-annual
channel,
that's
where
all
the
bugs
are
being
fixed.
First,
where
new
features
are
being
released,
you're
going
to
have
a
better
kubernetes
experience
on
the
semi-annual
channel,
but
you
can
still
use
kubernetes
with
Windows
Server
2019
on
the
LTS
C
as
well,
so
that
host
operating
system
matters
on
what
also
matter
is
the
base
image
that
you're
building
off
of
so
in
the
container
world.
B
You
may
be
aware
that
everything
is
built
up
off
a
concept
of
layers:
it's
not
one
large
blob
or
one
big
binary,
but
instead
several
distinct
layers
that
make
up
and
container
image
in
the
Linux
world.
You
may
be
used
to
building
on
Alpine
based
images
or
busybox
or
scratch
they're,
one
of
thousands
that
are
available
in
the
docker
hub
in
the
windows
world.
We
everything
derives
from
three
base
images,
the
first
being
nano
server.
This
is
the
smallest
image.
That's
available
on
the
latest
semi-annual
channel
of
1909.
B
This
clocks,
in
around
100
Meg's
I,
mean
it'll,
be
larger
on
different
versions
of
Windows.
The
size
has
changed
quite
drastically.
To
be
honest,
nano
server
is
great
for
greenfield
and
cloud
native
apps.
So
if
you
were
building
a
a.net
core
applica
or
no
js'-
and
you
wanted
to
run
that
with
Windows,
you
would
typically
choose
nano
server
to
do
that.
B
So
it's
also,
if
you
had
any
kind
of
PowerShell,
scripts
or
kind
of
automation
or
ETL
type
jobs,
you'll
be
able
to
put
that
into
a
nano
server
to
keep
the
container
size
small,
and
it's
definitely
when
you
don't
need
full
net
framework.
If
you
do
need
the
full
net
framework
that
gets
us
into
the
second
base
image
which
is
server
core
server
core
is
really
is
our
our
bread-and-butter.
B
When
we
talk
about
legacy
net
applications
because
we
have
full
dotnet
framework,
so
it's
really
targeting
those
legacy
based
applications
that
have
been
around
for
five
ten
plus
years,
and
so
we
can
go
in
and
install
those
types
of
applications
into
server
core
and
have
all
of
the
components
that
they
need
to
operate.
If
you,
if
there's
an
application,
that
your
container
izing
and
you
hit
a
roadblock
because
it's
missing
some
component
of
Windows,
we
also
now
have
a
third
option
that
was
introduced
with
Windows
Server
2019
and
that's
this
window
space
image.
B
This
is
this,
carries
the
most
Windows
components
that
are
available
and
goes
really
above
and
beyond
what
we
have
in
server
core.
So
if
your
application
makes
heavy
use
of
win32
api
s
or
other
pieces
of
Windows,
this
would
be
kind
of
a
last
stop
of
something
to
try
to
be
able
to
containerize
that
app.
It's
much
it's
more
expensive
than
super
core.
What
I've
personally
seen
windows
more
and
this
Windows
based
image
utilized,
is
for
customers
that
are
looking
to
do
things
like
headless
browser
testing.
B
So
we
something
like
a
selenium
grid
where
we're
going
to
spin
up
servers,
we
check
in
some
code
spin
up
some
servers
and
then
do
browser
testing,
and
we
want
to
test
on
windows
that
the
selenium
driver
pieces
historically
had
not
worked
with
server
core,
but
they
did
work
with
this
windows-based
image.
So
that
provides
us
more
capabilities.
We
typically
recommend
start
sticking
to
whichever
base
image
is
going
to
result
in
the
smallest
container
available.
B
So
while
something
may
work
in
Windows
as
a
base
image
server
core,
if
it'll
work
in
server
core,
we
all
always
recommend
server
core
and
likewise
down
to
nano
server.
If
it
would
run
there,
keep
things
nice,
small
and
efficient
from
an
image
perspective.
So,
while
we're
talking
so
much
around
OS
versions
and
base
images
is
that
in
the
linux
worlds,
you're
likely
familiar
with
the
fact
that
we
don't
really
have
to.
B
You
know
care
that
much
about
the
host
as
long
as
it's
got
a
container
runtime,
where
typically
good
to
go
in
linux
on
windows
that
we
have
to
care
about
version
compatibility
and
so
I've
got
a
small
chart
here.
It's
a
simplified
version
of
what's
in
the
Microsoft
Doc's
here
on
this
link
at
the
bottom,
but
you
can
see
here
from
a
host
OS
version.
If
we're
running
Windows
Server
2019
as
our
host,
then
we
need
to
make
sure
we
match
and
align
the
base
image
that's
running
inside
of
that
container.
B
So
we
would
need
to
have
a
Windows
Server
2019
image,
that's
inside
of
that
container.
If
we
were,
if
we
had
a
base
image
of
2019
and
tried
to
then
run
a
container
image
based
on
1903,
it's
going
to
stop
us
not
allow
us
to
run
that
workload.
That's
because
the
windows,
api
and
kernel
has
been
undergoing
such
change
in
something
in
the
last
several
years.
B
We
want
to
ensure
that
the
hosts
in
the
container
match
up,
so
we
don't
have
any
errors
or
weird
issues
with
a
mismatch
between
those
two,
and
so
this
is
based
on
what
we
call
process,
isolation,
which
is
the
default
mode
of
running
containers,
both
in
Linux
and
in
Windows,
and
so
in
a
process.
Isolation
if
I
have
five
containers
on
the
same
host,
they're
all
sharing
the
hosts
kernel,
and
that
meant
in
that
host
operating
system.
Alternatively,
in
Windows,
we
do
have
a
second
option
that
we
call
hyper-v
isolation.
B
Hyper-V
isolation
is
specific
to
Windows
containers,
but
it
allows
us
to
wrap
a
running
container
in
a
very
thin
virtual
machine
where
that
container
gets
a
dedicated
version
of
the
kernel.
Just
for
that
one
container,
and
so
historically
for
standalone,
Windows,
Server
containers
that
are
running
without
orchestration
or
for
other
orchestrators
we've
been
able
to
utilize
this
hyper-v
isolation,
but
we
are
in
the
process
of
bringing
that
in
the
kubernetes.
So
it's
currently
at
an
alpha
feature,
so
not
quite
ready
for
primetime
today,
but
over
the
year
over
this
next
year
in
2020.
B
We
expect
that
to
mature
greatly
and
it's
under
active
development
here
to
bring
this
option
here.
What
hyper-v
isolation
allows
us
to
do
is
a
little
bit
more
flexibility
around
version
compat.
So
in
here,
if
I
had
a
host
operating
system
of
1903
that's
running
on
in
my
cluster,
and
someone
gave
me
an
image
that
was
based
on
2019.
B
I
could
then
run
that
container
image
on
top
of
that
host,
utilizing
hyper-v
isolation
rather
than
process
isolation,
so
again
coming
soon,
but
wanted
to
kind
of
mention
it
now,
so
that
you
can
be
thinking
about
that
in
the
future,
and
insurance
you're
matching
up
these
versions
here
when
it
comes
to
the
cluster,
make
up
with
Windows
Server.
This
should
look
very
similar
to
you.
B
So
in
kubernetes
we
have
this
notion
of
master
nodes
that
are
the
brains
of
the
operation,
I,
think
of
them
as
air
traffic
controllers,
that
are
doing
all
the
kind
of
organization
and
operations
of
the
cluster.
And
then
we
have
the
worker
nodes
that
are
running
our
actual
container
workloads
that
we
specify
that
we
give
kubernetes
to
run
historically,
we've
had
all
Linux,
so
the
Masters
were
Linux.
The
workers
were
Linux,
as
we've
introduced
support
for
Windows
server
into
the
environment.
They
are
available
as
Windows
worker
nodes.
B
Only
so
one
of
the
questions
we
get
all
the
time
is:
hey
we're
a
window
shop.
We
don't
really
like
running
Linux
VMs.
If
we
don't
have
to,
can
we
do
a
full?
You
know
pure
100%,
Windows,
Server
cluster
and
still
run
kubernetes,
and
so
that
the
short
answer
right
now
is
no.
We
do
require
that
master
nodes
are
running
the
Linux
operating
system
and
then
we
can
add
one
or
more
windows,
server
worker
nodes
that
are
there
today
and
so
right
now
we
do
need
a
mix
of
Linux
and
Windows
in
the
environment.
B
So
at
this
point,
if
I
had
a
cluster
with
a
mixture
of
worker
nodes
and
I
wanted
to
go,
deploy
and
a
Windows
container
say
running
iis
and
I
gave
the
pods
back
on
and
all
my
yeah
mol
gave
it
to.
You
did
a
cube,
cuddle
apply
and
the
Masters
went
to
schedule
it
onto
a
node.
That
windows
container
could
potentially
wind
up
on
any
of
these
for
worker
nodes,
Linux
or
Windows.
B
But
what
we'd
like
to
do
is
I'm
is
have
a
more
elegant
approach
to
ensuring
that
Linux
pods
run
on
Linux
nodes
and
Windows
pods
run
on
Windows
nodes
to
do
that.
We
utilize
features
inside
of
kubernetes,
specifically
taints
and
toleration
x'.
So
what
I
could
do
here
is
I
could
use
cube,
cuddle
to
go
and
entertain
those
notes
with
an
OS
of
Windows
equals
no
scheduled,
and
then
that
would
block
Windows
nodes
from
running
on
those
Windows
pods
from
running
on
those
nodes.
B
When
I
go
to
deploy
an
actual
Windows
pod,
though
I
could
then
specify
a
toleration
that
would
allow
me
to
go
on
top
of
that
taint
into
schedule,
and
then
I
could
even
use
something
like
a
node
selector
to
ensure
that
the
pod
is
being
landed
on
a
on
a
Windows
node.
So
over
here
on
the
right,
I
have
three
worker
nodes.
B
We
have
a
Linux
and
Windows
and
Linux,
and
so,
if
I'm
deploying
with
this
node
selector
of
Windows
that
pods
going
to
land
on
a
node
that
has
that
label
where
we
have
that
match
I'm
sorry,
we've
assertively
done
this
in
various
ways
with
labels
we're
simply
applying
those
same
that
same
technique
to
Windows.
Instead,
so
we
didn't
go
reinvent
the
wheel
here,
we're
utilizing
currently
available
techniques
inside
of
kubernetes,
starting
with
cube
1.17.
B
We
also
have
the
ability
to
have
a
node
selector
based
on
this
Windows
build
command,
so
you
can
see
on
here
on
the
bottom.
We
have
ten
0.177
63,
that
is
the
build
number
of
Windows
Server
2019,
that
LT
SC
branch.
So
if
I
had
a
kubernetes
cluster
that
was
mixing
for
some
reason
of
LTS
C
nodes
and
si
si
nodes,
I
can
further
specify
my
node
selector,
which,
which
Nova
that
tool
and
on
based
on
that
notes,
select
your
command
there.
B
So
we're
getting
even
more
granular,
not
just
Windows,
but
that
LTS
CR
that
particular
build
number
of
Windows.
Is
there
available
as
well,
so
something
to
think
about
I'm.
The
very
first
Windows
pods
that
I've
scheduled
I
was
trying
to
figure
out
hey.
Why
are
these
not
coming
up
and
working?
Well,
it's
because
they
were
trying.
The
kubernetes
was
trying
to
assign
those
pods
onto
a
Linux
node.
It's
not
gonna
work.
B
B
There's
a
concept
in
the
Linux
world
called
privileged
containers,
which
is
where
a
container
has
I,
don't
want,
say,
carte
blanche
to
the
host
but
significant
access
to
the
host.
What
it's
able
to
do
there
they're
special
and
they
run
in
a
much
higher
privileged
mode,
and
so
these
are
good
for
some
Damons
and
agents
and
other
use
cases
and
are
a
common
in
the
linux
world.
But
are
we
are
unable
to
do
that
in
the
windows
world?
The
way
that
Windows
containers
are
put
together?
B
We
don't
have
the
ability
for
a
privileged
container
and
so
that
limitation,
pops
up
in
various
times.
I
wanted
to
kind
of
mention:
that's
if
you're
wanting
to
have
a
Windows
container,
that
is
somehow
manipulating
the
Windows
registry
of
the
host.
That's
going
to
be
blocked,
there's
not
a
way
to
be
able
to
do
that.
You
could
be
able
to
edit
the
registry
inside
of
the
container,
but
we
we
have
more
of
a
separation
and
more
of
a
security
boundary
there
than
what
we
have
in
Linux.
B
We
touched
on
the
Linux
masterpieces
and
then,
finally,
when
you're,
creating
pods
and
you're
setting
resource
constraints
or
allocating
resources,
rather,
you
really
need
to
bump
up
the
minimums
in
which
you
may
be
used
to
in
the
Linux
world.
I'm
an
eye
is
image
running
on
Windows
server
core,
which
is
a
large.
You
know,
5
gigabytes.
Sized
image
is
going
to
require
much
more
resources
than
an
engine
X
container
running
in
Linux.
That
may
be
10
Meg's,
for
example.
B
So
you
will
need
more
resources
when
we
go
to
deploy
windows,
containers
they're,
simply
heavier
based
on
the
other
components
of
Windows
that
are
running
inside
of
that
container.
They
need
more
resources,
they're,
something
to
keep
in
mind.
It's
very
easy
to
accidentally
starve
pods
by
not
allocating
up
resources
when
you're
running
those
those
pods
for
a
little
bit
of
history.
B
We
mentioned
starting
way
back
in
2016,
with
the
initial
container
support
and
2017
that
container
network
interface
work
began
around
CNI
to
get
the
networking
going
with
kubernetes
and
then
work
continued
throughout
2017
and
2018,
culminating
in
a
release
back
in
March
of
2019.
This
was
the
stable
release
that
initially
brought
support
for
Windows
Server
and
did
the
kubernetes
project
so
starting
last
March.
We
got
the
thumbs
up
kind
of
the
ga
release.
There
says
we're
stable
and
we're
good
to
go.
B
Each
subsequent
release
after
1.14
the
the
groups
that
cig
windows,
microsoft,
docker
at
vmware
at
a
variety
of
companies
that
are
involved
in
the
I,
have
worked
to
add
feature
after
feature
into
window
server
and
so
I
went
out
in
15.
We
got
outlet.
Support
for
GM.
Sas
will
talk
about
why
those
are
important
in
a
moment
I'm
into
in
1.16.
B
It's
not
completed
so
there'll
be
new
features
in
each
release
to
look
forward
to
and
to
expand
the
capabilities
of
the
platform
for
for.net
based
applications
so
to
get
into
different
considerations.
The
the
very
first
thing
that
we
often
run
across
right
is
identity,
so
we've
containerized
an
app.
We
go
to
run
it
and
boom
we've
got
a
problem,
it's
we're
having
issues
with
identity,
and
so
we
always
suggest
that
folks
take
a
take.
Take
a
good
look
at
how
applications
work
beforehand
to
understand
how
they
work.
B
B
We
need
to
know
that
ahead
of
time,
if
we're
utilizing
integrated
windows
off
we're
going
to
need
some
additional
considerations
as
well,
and
so
what
we
find
is
that
the
vast
majority
of
apps
over
the
past
10
years
have
been
written
with
integrated
windows
off
IWA
has
been
very
simple
from
a
developer's
perspective,
I
clicked
a
little
box
and
voila
I
have
authentication
in
my
app
very
convenient
and
the
way
that
that
magic
worked
was
because
I
was
typically
running
on
a
web
server.
That
was
in
close
coordination
with
an
Active
Directory
domain
controller.
B
So
that
servers
what
we
call
domain
joint
and
so
then,
when
that
application
ran,
I,
could
have
the
web
server
and
the
host
itself
talked
to
Active
Directory
and
handle
that
user
authentication.
For
me,
outside
of
my
app
code,
very
convenient
and
very
easy
to
operate
in
the
container
world,
we
do
not
domain
join
every
single
container
or
every
single
pod
to
a
domain
controller.
Instead,
the
pattern
is
that
we
domain
join
each
of
the
host
nodes
that
were
running
on.
B
So,
if
I
have
ten
Windows,
Server,
1909
worker
notes,
I
would
domain
join
each
of
those
to
a
domain
controller
and
then
I
would
then
I
would
then
utilize
an
Active
Directory
component,
so
we've
got
an
Active
Directory
group
managed
service
account.
This
is
a
this
is
an
ad
thing.
It's
not
a
container
thing.
It's
a
component,
that's
been
an
ad
for
several
releases
and
it's
essentially
a
password
list
service
account
that
I
can
load
into
a
container
and
then
assign
permissions
for
that
across
my
network.
B
So
the
way
this
works
is
that
if
I'm
running
a
cube,
cuddle
apply
to
go,
create
a
pod
I
pass
in
a
credential
spec,
which
is
simply
a
JSON
representation
of
of
that
service
account
and
then
on
the
server
that
it
lands
on
and
that
that
the
pot
is
being
scheduled.
The
hosts
compute
service
of
Windows
picks
that
up
and
says
hey.
This
is
this
is
a
special
pot.
It's
not
kind
of
a
regular
identity.
B
I
actually
need
to
go
and
send
a
credential
spec
to
the
container
credential
guard,
another
component
of
Windows,
so
that
it
can
talk
to
Active
Directory
to
generate
and
maintain
Kerberos
tickets,
then
I'll
create
the
container
and
I'll
set
the
identity
to
that
specific
service
account
so
that
anytime,
that
container
calls
out
of
the
container
to
it.
Database
or
a
file
share.
It'll
then
utilize
that
service
credential,
not
the
default
identity,
that's
there.
B
So
this
is
something
that's
I
like
to
talk
about
first,
because
it's
it's
almost
always
the
first
thing
we
run
into
and
in
many
organizations
that
means
coordination
with
your
Active
Directory
team.
Talking
with
that
identity
team
around
hey,
we're
gonna
need
these
service
accounts.
We
need
to
add
these
permissions
and
grant
these
permissions
to
those
service
accounts.
Typically,
some
legwork.
That
needs
to
be
done
to
be
able
to
enable
kubernetes
to
work
with
integrated
windows
off
based
applications
inside
of
kubernetes.
Now
we
have
a
custom
resource
definition:
a
CRD
around
GMS,
a
credential
spec.
B
Where
were
able
to
pass
in
information
and
around
our
domain
around
the
agenda,
the
sit
for
the
account
the
domain
name,
NetBIOS
standard,
ad
information
that
we
can
pass
in
to
kubernetes,
and
so
when
we
create
a
pod
this
will
be
loaded
in
and
that
identity
will
be
then
utilized
as
part
of
kubernetes.
So
this
feature
is
gone
from
alpha
to
beta
over
the
past
six
months
and
excited
to
see
this
reach
stability
here
shortly,
but
a
very
key
foundational
tech
when
were
working
with
windows
containers.
The
next
piece
that
comes
up
is
oftentimes.
B
We
may
hit
a
problem
or
we
want
to
keep
tabs
on
what's
happening
inside
of
the
container
for
Linux
naps,
these
typically
log
to
standard
out.
So
if
I'm
meeting
to
go
in
and
see
what's
happening
in
the
container,
I
can
go,
do
run
a
you
know.
Docker
logs
commands
I
can
run
an
interactive
session
with
my
container
in
time.
Some
like
docker,
run
or
cube
cuddle
logs.
Any
of
these
commands
are
really
built
to
take
the
standard
out
of
the
container
and
pass
it
through
back
to
me
as
the
user.
So
I
can
see.
B
What's
going
on,
alternatively,
in
the
windows
world,
we
windows
apps,
don't
log
to
a
standard
outs.
They
typically
go
to
the
event
tracing
for
Windows
CTW.
They
go
to
event
logs,
they
go
to
custom
files,
they
go
to
different
spots,
and
so,
if
you've
ever
run
docker
logs
on
an
on
a
Windows
container,
it's
pretty
anti-climatic,
there's
not
a
whole
lot.
That's
there,
because
there's
nothing
being
sent
out
to
the
standardout
it's
being
sent
to
different
areas
inside
of
that
container.
So
to
address
this
Microsoft
spent
some
time
of
the
past
year.
B
Doing
some
great
work
around
a
tool
called
this
log
monitor
tool.
So
this
is
a
small
binary.
That's
going
to
help
us
get
the
same
experience
that
we
have
on
Linux,
where
we
go
application
to
standard
out
and
then
have
our
container
runtime
pick
those
up
with
docker
logs
or
cube
cuddle
logs.
We
can
bring
a
similar
experience
to
Windows.
So
in
this
example
on
the
right,
we
have
a
Windows
container.
Our
app
and
services
are
writing
in
these
metrics
locations.
B
We
have
a
lot
of
monitor,
binary,
that's
reading
those
passing
them
to
standard
outs
and
then
the
runtime
is
then
able
to
run
docker
logs
and
cube
coda
logs
to
be
able
to
get
that
information,
so
very
handy
and
very
useful
and
and
good
to
put
in
to
adopt
this
earlier.
Rather
than
later,
it's
when
you're
trying
to
debug
an
application.
B
That's
not
working
in
that
container
having
this
log
monitor
tool
can
make
a
big
difference,
because
otherwise
you're
typically
doing
a
docker
exec
or
a
cube
cuddle
exec
session
inside
of
the
container
and
trying
to
parse
through
xml
or
error
codes
and
an
exec
session,
and
it's
quite
painful.
This
makes
life
a
little
bit
easier
easier
and
allows
you
to
integrate
into
third-party
logging
tools
that
are
built
to
on
that
standard
out
of
the
container
to
get
their
information
there
so
very
useful.
It's
available
on
github,
it's
open
source.
B
But
with
that,
thank
you
for
sitting
through
all
those
slides
want
to
jump
into
some
demos
in
and
make
this
a
little
bill
for
folks
as
well.
So
what
I've
got
here
is
that
I
have
a
Windows,
Server,
2008
virtual
machine
I
went
ahead
and
just
pre-recorded
this,
so
I
didn't
break
anything.
It's
running
here
is
Windows
Server
2008
in
a
virtual
machine.
This
is
a
web
server
running
is,
is
7
to
be
specific,
and
also
running
on
this
site
is
something
called
the
jobsite
starter
kit.
B
This
is
about
the
oldest
set
I
could
find
on
the
internet.
It's
a
dotnet
2.0
app
that
came
off
the
CodePlex
site,
which
is
long
long
gone
kind
of
a
pre
github
thing.
It's
a
two-tier
application
talking
to
a
server
to
sequel,
server,
2008
database
I
can
log
in
with
a
username
and
password
and
from
there
I
can
I
can
post
resumes.
I
can
look
at
jobs,
I
can
set
a
company
profile.
B
Think
of
this
is
a
an
incredibly
low
fidelity
LinkedIn,
but
a
very
old
LDAP,
10
plus
years
old,
but
it's
simulating
a
line
of
business
app
that
may
be
running
in
your
organization
today,
so
to
get
more
information
about
the
app
and
how
it's
running
I,
often
like
going
to
see
the
is
manager
to
get
information
about
the
app
you
know.
How
are
these
app
pools
configured?
How
many
apples
are
there?
B
I
can
see
I've
got
a
jobs
at
pool,
so
that's
running
there
with
one
app
it's
running
net
to
oh
and
we've
got
a
service
account
and
that
pull
identity
there,
a
job
stash
SVC.
So
that's
good
information
to
know.
When
we
go
to
sites
we
see,
we've
got
our
little
job
site
here
we
can
go
in
and
see
different
configuration,
different
user
authentication
can
be
looked
at
here.
It's
any
kind
of
SSL.
You
know
bindings.
B
B
So
we
can
see
there
creation
codes
here,
we'll
go
and
open
up
on
that
dockerfile
and
kind
of
talk
through
the
pieces
of
how
it
was
fit
together.
So
up
at
the
top
we
escape,
we
have.
We
set
a
new
escape
character,
makes
it
easier
for
windows,
because
the
slash
is
a
newline
character
in
Linux.
It
gets
kind
of
wonky
this
little
line.
One
isn't
a
really
nice
piece
there
to
allow
it
for
Windows.
B
We
then
use
a
base
image
running
on
an
LTS
C
2019
based
image
of
Windows
server
core,
and
this
is
actually
an
asp
net
image.
So
Microsoft
hasn't
not
only
the
raw
base
images,
but
they
build
some
derivative
images
on
top.
That
includes
a
default
website,
so
we
remove
that.
We
come
in
and
configure
any
OS
level
operating
system
features
that
we
need
so
in
the
web
world.
This
would
be
things
like
directory
browsing.
You
know,
HTTP
errors.
B
I
sappy
is
the
common
one
static
content
very
common
pieces
that
we
would
need
for
our
application
to
run
from
an
OS
level.
So
we
run
that
with
the
standard
powershell
commandlets.
Now
containers
come
in
with
all
the
ports
shut
down,
so
we
have
to
expose
the
ports
that
we're
going
to
use
for
that
web
application.
B
If
we
needed,
if
we
wanted
to
handle
SSL
in
the
container,
we
can
copy
certificates,
we
can
set
ackles,
so
that
is,
can
access
all
those
files.
And
then
we
go
when
we
initialize
that
website.
So
we
set
up
an
ISO
sites
who
set
up
bindings
any
certs
and
do
any
of
the
other
configuration
that
we
need
for
iis
they're.
B
Typically,
we
could
stop
there,
but
what
I
like
to
do
and
a
lot
of
images,
especially
if
you're
debugging
is
to
enable
remote
administration
for
is
these
are
a
few
extra
lines
that
are
going
to
allow
us
to
use
that
is
manager
GUI
against
a
container
makes
it
a
heck
of
a
lot
easier
to
figure
out.
What's
going
wrong
or
what's
functioning
there.
Finally,
we'll
add
support
that
log
monitor.
We
just
talked
about
where
we
download
a
binary.
We
add
it
into
the
container.
B
We
set
a
config
object
to
say
which
areas
of
the
container
we
want
to,
and
then
we
set
a
shell
in
an
entry
point.
I
said
the
blood
monitor
started
as
part
of
that
IAS
process
there,
so
that
that's
a
standard
kind
of
rundown
of
what
we
do
with
a
docker
file
to
then
be
able
to
build
and
run
on
that
container.
B
So
to
start
off
with
here,
I
want
to
run
a
couple
of
containers
before
we
get
to
our
custom,
one
to
show
kind
of
what
that
experience
looks
like
for
Windows,
so
we're
gonna
set
a
couple
of
variables
really
just
for
some
naming
conventions
there
and
then
we're
gonna
go
and
we're
gonna
make
sure
we
don't
have
anything
running
here,
but
then
we'll
go
and
run
a
standard.
Just
is
basic
image.
This
is
oftentimes
a
base
image
that
we
may
use.
B
If
we
have
a
small
website,
we
want
to
add
in,
we
can
start
and
build
right
on
top
of
that,
so
we're
going
to
run
the
container
with
is
with
an
open,
Chrome
and
we'll
go
ahead
and
tail
out
the
container
logs.
So
we
can
see
what's
coming
out
of
that
default
experience
there
we
select
those
run
them
and
in
here
locally
on
this
machine
we
went
an
is
container.
B
We
pop
open,
Chrome
and
we
see,
is
not
running
locally
but
running
in
a
container
I
can
refresh
this
a
couple
times
generate
some
traffic
on
the
command.
We
see
nothing
coming
through
log
wise,
you
know,
there's
nothing
there,
nothing
to
be
used.
That's
very
typical
for
windows
containers
based
on
kind
of
how
that
logging
experience
works
very
typical,
and
what
we
expect
to
see
anytime.
We
would
be
running
so
like
docker,
container,
logs
or
cube
cuddle
logs,
nothing
really
to
see
there.
B
So
that's
one
of
those
kind
of
gaps
that
the
log
monitor
tool
is
going
to
help
us
with
when
we
get
into
operating
our
own
container.
So
I'm,
just
gonna
drop
a
note
here,
removing
this
container
in
the
future
and
then
it's
on
to
building
the
docker
file
that
we
showed
a
second
ago
so
same
command
as
we
would
in
Linux
docker
image
build.
We
give
it
a
tag
with
a
name
and
we
say
where's
the
docker
file
so
go
out
and
build
and
boom
it's
been
cached.
B
But
usually
this
takes
a
few
minutes,
typically
longer
than
a
Linux
container
that
we've
built
that
image
and
now
we're
ready
to
run
that
image.
So
we're
going
to
do
a
very
similar
process
here,
where
we
run
a
container
and
we
pop
it
open
in
chrome.
So
we
can
see
that
running
locally
and
immediately.
We
see
a
problem
here
log
in
failed
for
user
anti-authority,
so
the
container
is
trying
to
go
out
and
talk
to
the
database.
You
know
we
didn't
change
the
connection.
B
It
was
set
to
utilize
integrated
windows,
often
an
Apple
identity,
but
the
database
said
no,
who
this
anonymous
user?
Is
it's
not
going
to
give
them
any
results
back,
and
so
we
have
this
user
authentication
issue.
That's
popping
up
a
very
common
in
any
kind
of
application
that
may
be
calling
out
to
Active
Directory
secured
resources.
So
what
we
do
is
inside
of
Active
Directory
we'd
come
in
and
generate
a
new
GMs
a
we
do
that
with
a
simple
power
or
shell
command,
let
where
we
give
it
a
Adina's,
hostname,
some
service,
principal
names,
etc.
B
Then
we
run
in
an
install
command
on
those
servers
and
now
that
account
would
be
created
an
ad
I
pre
created
it
for
time.
We
then
create
a
credential
spec
file,
which
is
a
command
lit
that
essentially
talks
to
Active,
Directory
and
then
formats
a
JSON
file
with
some
information
for
us
to
really
the
only
operation
not
considered
super
secure,
it's
just
simply
reading
against
Active
Directory.
B
So
we
see
information
around
the
domain,
a
lot
of
those
same
information
that
we
would
then
take
and
plug
into
that
see,
Rd
for
a
GMS,
a
credential
spec
that
we
saw
a
second
ago
in
the
presentation.
This
point
we
have
a
GMS,
a
in
Active
Directory.
We
have
a
credential
spec
file
and
now
we
can
go
and
run
a
container
with
that
credential
specs
we're
going
to
bring
the
two
together
so
we're
going
to
delete
the
exist
in
that
pre-running
container.
B
We're
gonna
run
the
new
one,
but
this
time
passing
in
that
GMs
a
I
mean
at
that
point.
The
container
when
it
calls
out
of
the
container,
is
not
going
to
use
that
anonymous
ID,
but
instead
it's
gonna
focus
on
that.
Active
Directory
service
account
for
use
there
and
you'll
see
here
in
a
moment
we'll
see
the
exact
same
website
we
saw
earlier
should
look
and
feel.
Similarly,
it's
the
exact
same
source
code
simply
running
in
a
container
this
time,
rather
than
a
VM,
so
I
go
and
I
can
even
login
to
that
database.
B
Where
my
user
credential
pieces
are,
then
the
application
itself
is
talking
to
the
database
and
then
enforcing
kind
of
what
I'm
allowed
to
do
there.
So
I
can
go
and
post
jobs
I
can
search
resumes
all
that
same
experience
there.
The
last
piece
to
to
kind
of
mention
here
and
show
I'm
is
around
how
we
can
kind
of
work
from
a
debugging
perspective
to
identify,
if
or
when
we
had
issues
from
the
containerization
perspective.
So
the
first
piece
we
do
is,
as
we
can
look
at
the
logs
and
so
immediately.
B
You
see
that
it's
not
on
that
is
based
image.
Earlier
there
was
just
crickets
there
was,
and
there
was
nothing
coming
through
there
and
but
on
this
image,
because
we're
using
that
log
monitor
tool.
We
see
the
worldwide
publishing
service
entered
the
running
States
and
we're
seeing
information
coming
back
from
is
directly
here
in
that
docker
logs
command,
so
cube
catalogs
to
be
able
to
pick
this
up
and
be
able
to.
Let
us
know
what's
happening
inside
of
that
container.
B
B
I
can
go
in
and
connect
to
a
server
I'll
give
it
the
IP
address
for
that
container,
then
I
give
it
the
username
and
password
of
the
account
I
want
to
connect
with
and
now
I
able
to
use
this
full
rich
GUI
experience
to
introspect
how
the
is
is
configured
inside.
Of
that
container.
This
is
can
be
incredibly
valuable,
especially
if
you
have
dozens
of
app
pools
dozens
of
sites,
lots
of
things
going
on
inside
of
the
container
a
lot
easier
and
utilizing
this
than
digging
through
kind
of
alternative
options
there.
B
So
we
look
at
bindings,
different
settings,
authentication
everything
you
would
expect
to
be
able
to
do
inside
of
is.
We
can
do
here
as
well.
So
at
this
point
we've
looked
at
the
application.
The
last
thing
to
do
is
we'll
go
and
we
can
log
into
a
registry.
A
container
registry
push
this
image
into
the
registry
and
then
we're
ready
to
go
from
a
kubernetes
perspective.
We
can
add
that
image
into
our
gamal,
a
cube
cut'
will
apply
that
to
a
cluster
and
then
this
image
will
go
and
be
scheduled
on
to
a
node.
B
So
just
to
recap,
we
started
in
a
virtual
machine.
Running
Windows
Server
2008
took
that
application
code
out
on
the
Windows
Server
2019
built
an
image
added
is
from
management,
log
monitoring
and
it
was
able
to
push
that
into
you
know
another
a
into
a
registry
there.
So,
hopefully,
that's,
hopefully
that's
a
kind
of
showing
kind
of
the
workflow
that
we
often
go
through
when
we're
looking
at
container
izing.
B
Those
kinds
of
applications
to
mention
to
close
up
on
on
when
other
considerations,
persistent
storage
is,
is
the
other
big
one
in
the
room
that
we
often
see
with
legacy
apps
so
identifying
what
kind
of
app
you
have
for
that
application?
Is
it
persistent?
Is
it
okay
if
it
goes
away
such
as
a
cache
I'm?
How
large
we
talking
10
Maggie's?
Are
we
talking
10
gigs?
B
Are
we
talk
about
databases,
file
shares
local
disk,
knowing
what
the
application
interacts
with
is
critical,
and
this
can
often
be
hard
for
app
4
or
a
line
of
business
app
that
was
built
eight
years
ago.
The
dev
team
is
gone.
It's
used
by
only
five
people
internally,
but
you
can't
get
rid
of
it.
Yet
it
may
take
a
little
bit
of
time
to
introspect
and
figure
out
how
that's
working.
Databases
can
often
be
easier
because
we
can
use
the
same
connections
sharing
information.
We
can
typically
leave
databases
where
they
are
with
DBS.
B
We
can
containerize
them,
but
I
often
prefer
to
leave
them
on
the
VM.
That
they're
at
today
container
is
the
app
and
then
just
call
call
out
to
the
DB
/
connection
strings,
it's
typically
easier
than
moving
the
app
and
the
database
all
at
the
same
time.
You
can
kind
of
phase
it
out,
since
are
the
values
for
like
passwords
connection
string
certificates,
use
cube
secrets
for
that.
B
Another
kind
of
standard
best
practice
for
kubernetes
gives
nice
are
back,
enabled
separation,
so
that
the
right
user
can
see
the
rights,
sensitive
information
and
it
doesn't
get
mocked
up
down
in
your
container
there.
So
a
very
mature
way
of
handling
those
secrets
in
the
kubernetes
world.
When
we're
talking
about
storage
for
Windows,
it's
a
little
bit
different
than
Linux.
So
in
the
in
the
Linux
world
CSI,
the
container
storage
interface
is
much
further
along.
B
That's
really
becoming
the
best
practice
of
how
to
do
things
in
the
Linux
world,
on
Windows
flex,
volume,
typically
with
SMB
and
I
scuzzy
are
the
ways
to
go
today:
I'm
where
those
are
entry,
plugins
and
so
we're
hoping
over
the
next
year
that
this
story
will
improve.
We've
got
a
lot
of
great
work
happening
with
cig
windows,
around
external
provisioner
there's
around
kind
of
initial
support
for
CSI
it's
coming
soon,
but
again
we
needed
those
we
needed
privileged
containers
for
CSI
and
so
we're
looking
at
alternative
since
Windows.
B
Don't
have
that
available
there
today,
so,
if
you're
working
today,
SMB
and
I
scuzzy
or
your
best
bet
with
Flex
volume
or
utilizing
one
of
the
cloud
based
providers,
if
you're
running
in
a
public
cloud
already,
those
are
also
good
options.
So
to
summarize
container
izing
legacy.
Apps
is
a
great
way
to
gain
agility
and
flexibility
and
be
able
to
run
older
applications.
Just
like
you
would
a
brand-new
micro
servers
up
your
building
from
scratch.
I
definitely
recommend
that
you
start
small
and
develop
muscles
around
kubernetes.
B
B
You
know
last
week
the
week
before
additional
resources
check
out
cig
windows.
This
is
the
special
interest
group
and
the
kubernetes
community.
Where
a
lot
of
this
work
happens,
they
have
a
full
Kanban
board
available.
We
can
go
in
and
see
the
features
that
are
coming
down
down
the
pipe,
including
some
documentation
here
on
Microsoft
and
kubernetes
as
well.
Finally,
that
we
have
a
full
white
paper
available
that
was
put
together
from
the
team
at
docker
when
we're
there
around
delivering
safer
amps
with
with
docker
Enterprise
in
Windows
Server.
B
So
it
really
targets
this
kind
of
scenario
of
legacy,
windows-based
applications
there
and
with
that
I
just
want
to.
Thank
you
all
for
joining
us
today.
I
know
it's
been
a
whirlwind
tour
through
Windows,
Server
and
kubernetes,
but
we
do
have
a
few
more
minutes,
and
so
Randy
would
love
to
see.
If
there
were
some
questions
that
we
can
speak
towards
for
the
remaining
time,
hey.
A
A
Four
minutes,
or
three
or
four
minutes
to
run
through
some
I
think
we've
got
a
good
12
questions
at
the
moment.
So
let
me
start
off
with
a
couple
of
softballs,
though
people
you
know,
what's
the
best
way
for
people
interested
in
you
know,
windows
and
I'm
kubernetes
to
kind
of
keep
up
with.
What's
going
on
in
kubernetes
with
them,
you
know
what
features
are
showing
off
that
sort
of
thing.
Yeah.
B
Great
question
of
some
thing
that
I
near
dear
to
my
heart,
because
I
I'm
always
trying
to
keep
up
to
date
at
the
best
I
can
as
well
I
sent
a
link
to
that
that
Kanban
board
here.
This
is
Patrick
laying
at
Microsoft
and
the
rest
of
the
sig
windows
team.
Do
a
really
great
job
of
keeping
an
entire
print
planning
board
of
what's
being
worked
on
win,
so
you
can
see
the
whole
backlog
of
here's
all
the
features
we'd
love
to
get
into
Windows
and
kubernetes,
but
then
they
divide
those
out
based
on
release.
B
B
So
those
are
those
are
two
of
the
ways
that
I
try
to
keep
sharp
they're
sig
windows
also
has
a
weekly
or
bi-weekly
meeting
them
that
they
that
they
host
for
the
community
and
so
they're
there's
notes.
There's
discussion,
notes
of
every
one
of
those
meetings.
There's
YouTube
recordings
of
each
of
those
community
meetings
feel
free
to
jump
on
those
calls
in
those
communities
and
to
use
those
notes
as
ways
to
keep
up
on
what
are
folks
talking
about.
B
A
I
can
I
can
definitely
echo
the
conference
side
of
things.
I
actually
hosted
a
talk
by
a
gentleman
from
docker
and
from
Miranda
at
KU,
con
San
Diego,
and
it
was
just
really
fantastic
and
I
know.
This
is
a
lot
you
know
in
the
hopper,
for
you
know
for
the
European
Convention
coming
up
another
thing
too
they
like
for
me
I,
don't
know
how
you
feel
about
this,
but
I
always
like
to
look
at
the
release.
Notes
if
I
need
a
low-bandwidth
kind
of
yeah.
B
B
A
B
Of
course,
monitoring
is
a
it's
very
important
so
and
the
prom
stack
typically
we're
talking
about
utilizing
the
the
node
exporter
project
on
our
linux
nodes,
and
so
there
is
not
a
cheer
vert
windows
version
of
node
exporter,
mainly
cuz
windows
is
built
differently
and
it's
a
very
different
architecture.
And
so
there
is
a
project
on
on
github
called
WMI
exporter,
that's
being
maintained,
and
so
WMI
exporter
operates
in
much
the
same
way.
B
So
it
goes
and
it's
scraping
metrics
out
of
the
the
windows,
management,
interface,
WMI
and
then
providing
those
on
to
a
in
endpoints.
That's
sitting
there
on
the
server
that
allows
Prometheus
to
go
and
scrape
that
endpoint
and
bring
those
right
in
alongside
all
the
things
that
it's
collecting
off
of
linux
nodes.
B
There,
with
the
rest
of
your
cluster
information-
that's
there
so
WMI
exporter,
I'm
it's
the
main
tool
that
we
would
use
to
be
able
to
integrate
nicely
with
a
prom
stack,
deploys
very
similarly
to
node
exporter,
so
nothing's
nothing's
too
different
than
what
we're
what
we've
been
doing
in
linux.
Super.
A
B
It's
something
to
people
it's
a
challenge,
especially
for
long-lived
clusters,
where
your
update,
if
you're
on
some
annual
Channel
and
trying
to
update
your
lips'
clusters
every
every
six
months,
it
can
be
a
challenge,
and
so
automation
is
the
key
is,
is
is
key.
So
what
we
can
do
in
in
docker
follows
themselves
on
that.
When
we
have
the
from
statement,
we
have
an
image
and
then
we
have
a
colon
and
a
tag,
and
so
that
tag
we
don't
have
to
hard
code
into
there.
B
B
Those
are
all
some
options
to
be
able
to
make
sure
you're
keeping
up
up
to
date
on
the
latest
and
greatest
one
of
the
other
easy
from
those
perspective
as
well.
You
may
just
choose
to
just
simply
in
the
notion
of
cattle.
Just
if
you've
got
five
existing
nodes,
you
can
just
add
five
new
ones,
cordon
off
all
the
old
ones,
drain
them
and
then
kind
of
remove
those
and
have
everything
flow
onto
them.
B
A
Indeed,
cool
well,
you
know,
unfortunately,
I
think
that's
about
all.
We've
got
time
for,
but
I'd
like
to
think
that
ready
for
for
joining
us
here,
the
recording
and
slides
will
be
online
later,
there's
a
link
in
the
chat,
but
you
should
just
get
an
email.
If
you
signed
up
giving
you
all
the
information
you
need
to
follow
up
after
and
I
hope,
everybody
has
a
fantastic
day
thanks.