►
From YouTube: Day 2 Operations with Windows Containers - Michael Michael, VMware & Patrick Lang, Microsoft
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
Day 2 Operations with Windows Containers - Michael Michael, VMware & Patrick Lang, Microsoft
The chairs for SIG-Windows will provide an update on the efforts to bring Windows to Kubernetes. This session will concentrate on presenting new features and capabilities as well as focus on day 2 operations and troubleshooting. We will also have a detailed discussion on our future roadmap, key functionality that we want to enable, and open the floor for Q&A with customers and members of the SIG-Windows community. Some familiarity with Windows on Kubernetes is required for the deep dive part since we will have an in-depth discussion on key features that are in the pipeline for Windows, explain their implementation and have a discussion on trade-offs with the community.
https://sched.co/UagU
A
B
B
All
right,
so
we
got
a
nice
long
list
of
topics
and
we're
gonna
have
to
move
pretty
quick
to
get
through
all
of
this,
so
we're
gonna
start
off
talking
about
a
couple
of
the
best
practices
and
deployments.
So
that
way,
you
know
a
couple
of
the
things
you
need
to
plan
for,
as
you
start
to
add,
Windows
nodes
into
your
clusters
and
we'll
talk
a
little
bit
about
how
to
handle
node
maintenance,
how
to
get
more
detailed
application
logs
out
of
your
have
your
Windows
apps
that
are
running
in
containers.
B
B
Kubernetes
already
has
a
concept
of
something
called
a
node
selector
and
what
it
does
is
it
lets
you
match
deployments
to
a
specific
node
based
on
a
set
of
labels.
There's
already
a
label.
That's
there
does
kubernetes
do
/os
were
your
typical
values
that
you're
gonna
see
our
Linux
or
Windows.
Those
are
automatically
added
to
all
the
nodes
and
that's
really
important,
because
you
need
to
make
sure
that
you're
steering
your
windows
work
load
onto
a
Windows
node
in
Linux,
one
Linux
node
and
for
1.17.
B
What's
really
important
is
we're
also
adding
a
new
field,
that's
automatic,
so
that
Windows
nodes
will
automatically
label
themselves
with
the
version
that
they're
running.
You
could
still
do
this
on
older
versions,
but
you'll
just
need
to
go
to
a
manual
step
with
with
cube
control.
It
was
a
label
node
and
then
set
this
up,
so
you
can
put
it
on
there,
but
using
the
combination
of
these
two
things.
B
Now,
if
you
want
to
run
multiple
windows
versions
in
the
same
cluster,
you've
got
a
way
to
do
that
and
match
them
with
a
node
selector,
and
so,
if
you're
doing
all
this
just
on
a
per
deployment
basis,
you're
going
to
end
up
with
around
eight
lines
of
the
amyl
here.
So
that
way
you
can
basically
set
the
right,
node
selector
and
then
also
set
a
toleration,
if
you're
using
taints,
to
make
sure
that
if
someone
doesn't
label
an
application,
it
defaults
to
Linux,
and
so
that's
when
you're,
adding
Windows
nodes
into
a
new
cluster.
B
That's
something
that
we've
generally
seen
to
be
a
good
best
practice
is
to
taint
the
Windows
nodes.
So
that
way,
if
you've
already
got
something
deployed-
and
let's
say
you
haven't
updated
your
helm,
shirts
or
whatever
it's
not
going
to
accidentally
end
up
on
a
Windows
node
where
it's
not
going
to
start,
and
so
you
can
basically
taint
the
nodes
before
you
add
them
to
a
cluster,
to
steer
things
away.
B
You
can
give
it
a
name
like
Windows
2019,
and
then
you
could
take
all
those
scheduling
constraints
that
you
wanted
to
put
in
there
and
encapsulate
those
all
into
one
part.
So
when
you
go
to
actually
update
your
deployment,
all
you're
doing
is
adding
one
line
that
says
run
time
class
named
Windows
2019,
and
so
in
this
case,
if
I
wanted
to,
you
know,
go
and
deploy
a
newer
version
of
Windows
side
by
side.
B
I
could
add
a
second
runtime
class
and
I'm
just
telling
my
developers
to
add
one
line
to
their
deployment,
and
then
their
workload
will
get
steered
to
whichever
version
of
Windows
that
they're
doing,
and
so
this
is
something
that's
in
a
dock.
Pr4
1.17
and
you
know
we're
recommending
that
as
a
way
to
go
forward
and
make
it
easier
to
move.
They
run
multiple
versions
in
the
same
cluster.
B
So
that's
something
to
look
at
from
a
scheduling
standpoint.
Well,
the
next
questions
that
we
commonly
get
when
people
are
starting
out
are
well.
What
do
I
need
to
do
when
it
comes
to
to
resource
consumption
and
the
so
the
two
main
areas
that
you
need
to
look
at
things
are
when
you,
when
you're,
creating
your
your
container
spec
on
there
and
you're
writing
your
resources.
B
You
can
put
CPU
and
memory
on
there,
so
the
initial
implementation
of
CPU
when
we
start
on
Windows
Server
2016,
didn't
have
CPU
percentage
implemented,
but
it
did
have
shares
implemented,
and
so
what
that
meant
was
on
a
fully
loaded
system.
The
amount
of
time
given
each
container
was
proportional,
but
it
didn't
mean
that
you
could
set
a
particular
cap
on
a
container.
B
It
could
always
burst
past
whatever
that
threshold
is,
and
so
there's
actually
a
PR
open
that
we'll
be
reviewing
next
week
to
get
this
updated
because
newer
versions
of
Windows
you
can
do
one
or
the
other,
and
so
we'll
be
updating
our
guidance
soon
on
how
you
could
pick
between
those
two
scheduling
modes
and
do
the
absolute
cap
scheduling
based
on
CPU
percentages,
and
so
the
next
step
is,
is
so
starting.
Windows
server
core
generally
needs
about
two
hundred
Meg's
allocated
to
the
container.
B
It
may
not
necessarily
use
all
of
that
all
at
once,
but
because
you're
bringing
up
all
those
background
services
that
need
you
need
to
have
that
room
for
them
to
expand
in
order
for
it
in
order
for
it
to
be
functional,
and
so
we'd
recommend
that
you
know
you
use
that
as
a
minimum
when
you're
deploying
containers
with
server
core.
If
you
try
to
do
less
than
that,
you
can
get
to
a
state
where
it'll
look
like
a
container
is
starting
and
then
in
the
end
it
just
fails
and
gets
into
a
crash.
A
So
there
so
so
that
was
the
some
of
the
memory
considerations
for
the
for
the
actual
container,
but
the
host
itself
also
has
additional
memory
considerations.
So
when
you
kind
of
look
at
the
hosts
today
in
in
kubernetes
for
Windows,
you
may
be
running
ancillary
processes
where
that's
back-up,
monitoring
other
services,
that
your
organization
needs,
plus
all
the
containers
today
in
Windows,
there's
no
prediction.
A
So
if
a
certain
container
ends
up
taking
more
memory
than
it
was
originally
allocated
or
what
you
were
expecting
for
it
to
use
what's
gonna
happen,
is
we're
going
to
start
paging
to
disk,
so
your
container
now
it's
gonna
run
slower.
On
top
of
that,
it's
gonna
start
eating
resources
out
of
the
host
OS.
A
So
our
recommendation
is
to
basically
until
we
get
predictions
and
the
ability
for
us
to
enforce
a
memory
allocation
on
a
container
in
kubernetes
and
in
Windows
is
to
use
cubelet
reserve,
as
well
as
the
system's
reserve,
to
keep
at
least
two
gigabytes.
That's
the
really
bare
minimum
for
the
node
processes
and
what
can
happen
there
is
kubernetes
and
the
scheduler
is
gonna
help
enforce
that,
along
with
the
ability,
when
you
add
limits
and
reserves
on
your
actual
containers.
B
All
right,
so
a
lot
of
the
topics
we
just
talked
about
are
all
things
that
are
specific
to
the
kubernetes
deployment
and
it's
something
it's
a
place
where
people
can
make
mistakes,
and
so
one
of
the
things
that
we
can
do,
because
this
is
part
of
the
same
kubernetes
ecosystem
is,
if
you
look
at
tools
like
open
policy
agent,
which,
when
you
want
to
implement
a
kubernetes,
is
typically
done
through
gatekeeper.
They
provide
an
admission
controller
and
then
open
policy.
B
Agent
has
a
language
that
you
can
use
to
basically
look
at
the
animal
before
it
gets
deployed,
and
so,
if
you
wanted
to
start
developing
best
practices
for
your
organization
and
taking
some
of
the
things
that
we
just
talked
about,
like
making
note
selectors
mandatory,
you
know
checking
the
minimum
memory
and
making
sure
that
limits
are
applied
on
memory
as
well,
so
that
you're
not
over
provisioning
nodes.
You
can
encode
all
of
that
in
a
language
called
Rago
and
then
gate
keeper
would
actually
be
able
to
block
deployments
that
don't
meet
that
spec.
B
If
you're
not
ready
to
go
into
a
blocking
mode.
There's
also
a
tool
called
comp
test
and
I
think
there
was
a
presentation
on
this
at
cube
con.
If
not,
there
was
definitely
one
at
Barcelona
earlier
this
year
that
you
could
look
at,
but
it
uses
the
same
open
policy
agent
engine,
but
it's
something
that
you
can
run
on
your
developer
laptop
before
you
do
a
deployment.
B
A
A
Microsoft
publishes,
updates
on
a
very
regular,
cadence
and
and
I
really
put
it
in
a
very
predictable
manner.
So
there's
a
couple
of
ways
that
you
can
actually
follow
to
patch
your
windows
nodes.
Let's
start
with
the
one
that
might
be
considered
the
easiest.
So
if
you
have
workloads
running
on
that
node
and
it's
a
production
node
then
the
first
thing
you
need
to
do
is
you
have
to
cordon
the
node
in
kubernetes.
So
what
that
means
is
that
node
will
not
get
any
new
containers
on
it.
So
nothing
new
will
be
scheduled
on
it.
A
Then
you
have
to
wait
because
you
know
studies
have
shown
that
a
lot
of
the
containers
are
fairly
short-lived.
That
may
not
be
as
applicable
on
the
windows
side,
but
it
is
more
on
linux,
so
you
have
an
option
to
wait
for
a
small
period
of
time
and
if
your
container
stone
basically
finish
what
they're
doing
and
exit,
then
you
have
to
drain
the
node.
A
And
then
you
run
your
windows,
update,
reboot,
the
node
update
drivers
or
anything
else
as
necessary,
and
then
you
uncoordinated
and
then
immediately
it's
going
to
be
part
of
the
scheduler
and
new
containers
will
land
on
it.
Now,
if
you're,
swapping
a
node,
that
means
you're
replacing
the
entire
know
to
something
new
again
process
is
very
similar.
You
cordon
the
node.
You
wait
drain
all
the
existing
applications.
A
Now,
if
you
drain
an
existing
application,
that
has
in-flight
requests,
they're
gonna,
basically
the
user
of
the
application,
where
that's
and
another
rabbit
cell
for
an
end
user,
they're,
basically
gonna
get
a
canceled
transaction
or
or
a
or
a
404,
and
you
get
to
replace
lemon
node
very
likely
rejoin
the
node
to
the
cluster.
If
it's
a
replacement
and
then
you
get
one
cord
on
it
and
basically
get
it
to
be
part
of
the
scheduler.
Now,
there's
a
few
things
to
think
about.
A
Now
outside
of
updates,
there's
also
upgrades
where
you're
doing
a
major
always
upgrade
again.
The
process
is
very
similar.
You
cordon
you
wait
the
drain
and
the
new
upgrade,
but
there's
a
caveat
here.
You
cannot
in-place
upgrade
from
a
long
term
servicing
channel.
This
is
the
releases
of
Windows
are
serviced
over
a
long
period
of
time
and
supported
over
a
long
period
of
time
by
Microsoft
to
a
semi-annual
channel.
That's
basically
released
every
six
months.
So
that's
something
to
think
about.
A
If
you
are
going
to
go
from
one
to
the
other,
make
sure
you
did
you
build
out
new
nodes
and
be
careful
so
as
you're
doing
all
of
those
processes
that
your
node
selectors
are
said
correctly,
the
Toleration
are
set
correctly.
So
one
of
the
things
that
patrick
mentioned
earlier
is
this
new
label
that
you
have.
A
Now
one
of
the
things
that
we're
also
working
on
is
clustered
API
that
will
offer
a
declarative,
kubernetes
style
way
to
provision
clusters.
Everything
from
node
management
to
cluster
management
is
gonna
fall
into
cluster
API,
although
Windows
is
not
there
yet
well.
Cluster
API
is
also
not
there
yet
so
we're
we're
in
lockstep
there.
We
are
actually
gonna
make
this
one
of
our
priorities
in
2020
to
make
sure
that
Windows
nodes
are
a
part
one
of
the
specification,
but
a
part
of
the
implementation
are
the
different
cloud
providers.
B
B
A
B
But
the
important
thing
is
that
it's
not
something
that's
sold
in,
like
a
retail
box,
the
same
way
that
the
long-term
servicing
releases
are,
and
so
that's
kind
of
like
the
one
of
the
first
questions
is
like
you
know
like.
Are
you
in
a
position
where
you
can
actually
deploy
this
in
your
org
or
consume
it
from
your
cloud
provider?.
B
B
B
A
Interesting,
alright,
so
so,
let's
talk
a
little
about
the
anatomy
of
a
container
by
the
way
on
the
questions
that
we
asked
you
earlier.
If
you
have
additional
feedback
and
you
want
to
get
a
little
more
context,
you
can
find
out
some
slack
under
sick
windows
and
the
kubernetes
slug.
You
can
ask
your
questions
there,
so
so,
looking
at
the
anatomy
of
a
Windows
container
the
way
of
view
it
is,
you
know,
obviously
in
certain
organizations
this
might
look
a
little
bit
different,
but
at
the
high
level
you
start
with
the
base.
A
A
A
The
goal
here
is
that
you
should
always
try
to
use
derived
images,
so
you
can
share
your
building
blocks.
So
Microsoft
publishes
a
wide
variety
of
derived
images
from
asp.net
who
I
asked,
based
images
to
even
Python,
so
make
sure
you
leverage
that,
because
they've
done
a
great
job
of
basically
building
the
OS
and
wiring
the
necessary
components
for
your
applications
to
work,
and
if
you
actually
utilize
that,
then
that
means
that
you
getting
that
consistency
across
every
time.
You
build
your
images
so
so.
B
So
when
it
comes
to
actually
patching
your
images
that
what
you
want
to
make
sure
that
you're
doing
is
starting
from
one
of
the
official
Microsoft
images,
and
so
if
you
look
at
if
you
go
to
a
docker
hub
to
browse
the
what's
available,
if
you
go
look
at
Windows
server,
core
or
nano
server,
we've
got
a
whole
bunch
of
different
tagged
images,
and
these
are
basically
updated
on
on
a
monthly
basis.
And
so
within
the
tags.
B
B
Because
if
you,
if
you
were
to
go
in
there
and
choose
one
that
was
like
1903
and
try
to
run
it
on
Windows
Server
1809,
it's
not
going
to
start,
and
so
what
you
want
to
do
if
you're,
in
the
case
of
like
1809,
is
look
for
the
new
tag
that
basically
matches.
You
know
that
months,
Patch
Tuesday
and
so
the
most
recent
one
is
down
there
at
the
bottom,
and
you
can
basically
see
it
was
released
on
the
12th
and
the
KB
numbers
behind
behind
that
made
a
nice
little
bar
there
from
from
presentations.
B
But
what
you
can
do
is
that
that
becomes
more
of
the
first
lines
in
your
docker
file,
so
like
the
Windows
Server
core
and
now
serve
Ramage's
are
patched
by
Microsoft
and
released,
and
so
you
can
just
build
on
top
of
them
and
build
up
from
there.
The
derived
images
like
ASP
neck
core
and
the
internet
information
server
are
also
updated
following
the
same
scheme,
and
so
what
you'll
want
to
do
is
basically
go
update,
update
defer
to
the
from
line
in
your
dock.
Your
container
rebuild
it.
B
Hopefully,
you've
got
a
continuous
integration
and
delivery
system
and
then
deploy
it,
and
so,
rather
than
going
in
trying
to
like
graft
a
patch
into
a
container,
you
want
just
follow
the
same
process.
You
do
for
all
your
releases
and
just
update
the
front
line
and
rebuild
and
go
from
there
and
so
I've
seen
this
implemented
in
lots
and
lots
of
different
tools.
B
Yeah
so
yeah
so
I'll
restate
the
question
for
the
recording.
So
the
question
was:
if
you're
following
the
semi-annual
channel
releases
on
the
6
to
18
month
deployment
cycle,
then
you
had
then.
Yes,
you
also
have
to
go
and
update
all
the
containers
that
are
going
to
be
running
on
that
and
then
deploy
them.
So
that
way,
you've
got
matching
major
OS
versions
between
a
node
in
the
container.
A
Reducing
your
availability,
though,
in
that
case
right.
So
if
you
have
like
three
nodes,
one
with
a
different
host
OS,
then
that
means
that
containers
can
only
land
there.
So
your
options
for
high
availability
are
significantly
reduced.
One
of
the
things
that
that's
very
important
here
to
note
this.
If
we
actually
go
back
to
this
diagram,
I
can
very
efficiently
and
with
a
high
degree
of
confidence,
change
the
first
line
with
different
parts
of
Windows
and
I'm,
confident
that
a
lot
of
the
rest
of
the
steps
are
going
to
work.
A
The
same
Windows
is
backwards
compatible
at
the
API
layer
at
the
dotnet
layer.
So
if
you're,
starting
always
from
the
source
of
truth,
which
is
here's
the
base
image
provided
by
Microsoft
and
then
rewiring
your
application
code
and
your
application
components,
if
you
do
it
in
a
in
a
declarative
way
like
this,
it's
very
likely
it's
going
to
work
across
many
patches
of
the
West
as
well
as
upgrades.
A
B
Okay,
so
moving
on
to
the
next
topic,
one
of
the
one
of
the
pieces
of
feedback
that
we've
heard
is
that
since
Windows
has
a
lot
of
background
services
that
are
running
like
the
era,
information
server,
those
basically
log
to
binary
logs-
that
Windows
calls.
You
know
the
event
log
or
event
tracing
for
Windows
and
most
of
the
tools
in
the
container
ecosystem.
B
You
can
basically
build
up
a
list
of
what
logs
you
care
about
for
that
container,
whether
it's
event
tracing
for
Windows
event,
logs
or
custom,
app
logs,
like
your
HTTP
log
from
iis,
and
it
can
basically
stream
all
these
to
the
standard
output
for
you.
So
that
way,
if
you're
going
to
go
and
deploy
something
like
you
know,
fluent
bid
and
elasticsearch
to
grow
to
basically
collect
all
those
logs
for
you.
B
You
now
have
a
way
that
you
can
put
something
in
your
container
that
will
extract
all
that
information
where
those
tools
can
grab
it
and
I've
got
demo
of
this
coming
out.
So
so
this
is
released
on
github,
so
the
urls
there
on
the
slides-
and
let
me
show
you
how
this
actually
works
so
I
took
an
existing
application
that
I
already
had.
That
did
not
have
sufficient
logging
like
before
I
did
this.
B
If
I
want
to
see
the
logs
for
this
container,
I
had
to
do
a
cube,
control
exec
go
in
there
CD
over
to
the
directory
containing
my
logs,
and
then
you
know
you
get
content
or
tail
to
try
to
analyze
those,
and
it
was
a
very
kind
of
a
intensive
process
that
wasn't
very
friendly,
and
so
the
changes
I
made
were
basically
downloading.
This
dis
blog
monitor,
release
and
then
I
added
in
a
config
file,
and
then
the
last
thing
I
did
was
I
set,
my
shell.
B
These
ones
are
based
on
Windows
event,
logs
and
so
like,
if
you
log
in
to
a
Windows
10
machine
and
you
go
to
event
logs
and
you
see
like
system
and
application,
that's
where
people
typically
go
to
look
for
like
failed
services
and
crashes.
I
can
collect
both
of
those
moving
on
to
files
since
I'm
running
under
is
I
want
to
get
my
HTTP
logs.
So
I
can
actually
see
what
you
know.
B
The
result
codes
were
and
what
the
URLs
that
people
were
hitting
and
so
I
basically
told
it
capture
all
the
logs
from
that
directory
for
is,
and
then
the
last
thing
is
because
it
is,
has
some
more
detailed
logging.
That's
done
it's
in
event,
tracing
for
Windows,
which
is
a
structured
data
format.
I've
also
asked
log
monitor
to
go
ahead
and
capture
those
based
on
the
gooood
and
name.
B
That's
there
and
format,
those
in
a
text
for
me,
and
so
that
means
within
one
log
I,
can
see
everything
from
crashes
to
the
addresses
that
the
users
are
hitting
for
this
site
to
to
some
internal
Diagnostics
for
the
iOS
service
itself.
And
so
let
me
get
this
at
this
play
in
there
after
fullscreen,
and
so
this
is
a
demo
that
I've
that
I
set
up
for
cube
con
last
year
and
I
had
I
rebuilt
it
with
log
monitor
in
there,
and
so
what
I
did
was
since
I
had
a
new
image.
B
There
I
just
went
updated
my
values
on
my
helm,
schardt
to
actually
go
and
do
a
deployment,
and
so
after
that-
and
this
is
actually
using
helm,
3
I
didn't
change
my
health
card.
It
just
worked
going
from
helm,
2
down
3,
so
thank
you,
helmet
team,
and
so
after
that
deployed
we
see
that
the
services
is
still
pending
and
then
and
then
the
pods
are
on
their
way
up.
B
B
And
then
so,
while
I'm
waiting
on
the
load
balancer
to
actually
come
up
and
finish
provisioning,
that
external
IP
I
can
already
go
use
cube
control
logs
to
look
at
what's
been
logged
in
that
container,
and
so
it's
really
important
here
actually
done
step
back
just
a
tiny
bit,
so
we
can
actually
read
that
is.
We
could
actually
see
all
the
background
services
that
were
starting
up
on
Windows
and
the
last
line
shows
that
the
worldwide
web
publishing
service
actually
entered
the
running
state.
B
So
if
you,
if
you're,
basically
watching
a
deployment
as
it
happens,
you
can
use
that
same
process
there,
and,
and
so
now,
since
I
had
them
warmed
up
that
site.
It's
basically
warming
up.
All
of
its
caches
and
it's
actually
creating
the
outgoing
database
connection
to
where
it's
gonna
store
its
stuff.
B
So
now,
at
this
point
since
since
the
HTTP
log
is
a
very
well-known
format,
I
can
use
existing
tools
to
go
ahead
and
monitor
how
that
pot
is
actually
going
and
start
looking
for
problems
as
this
stuff
is
running
so
that
so
that's
kind
of
the
first
step.
There
is
providing
an
easy
way
to
get
logs
out
of
the
container
in
a
way,
that's
consistent
with,
with
what
other
frameworks
are
doing,
and
so
the
next
step
from
there
is
now.
B
This
enables
some
tools
like
fluent
bit
seems
to
be
the
one
that
that's
getting
the
most
attention
right
now
I'm
in
this
topic,
but
it
could
go
and
basically
grovel
through
through
those
logs
from
all
these
nodes,
either
through
the
kubernetes
api
or
by
looking
at
them
on
disk,
because
the
cubelet
always
writes
them
out
to
disk,
and
that
gives
you
a
way
to
aggregate
all
of
those
into
one
place.
So
that
way
you
could
look
at
them.
B
Ok,
so
right
now,
there's
a
track,
so
fluent
bid
has
been
available
as
a
beta
on
Windows
since
version
1.1
and
then
there's
actually
a
master
issue.
That's
sort
of
tracking
that
progress,
that's
there,
and
so
this
is
something
that
people
are
actively
working
on
and
and
I'm
sure
there's
room
for
more
people
to
jump
in
and
start
experimenting
with
it
as
well.
I
know
that
one
Ben
and
well
the
folks
from
cig
Windows
has
been
and
started.
Looking
at
this
as
well.
B
B
You
know
specific
log
events
from
containers
there's
also
the
need
to
be
able
to
monitor,
monitor
your
node
metrics.
So
Prometheus
has
already
been
ported
to
Windows
for
some
time
and
it
has
a
scraper
that
can
basically
go
and
get
things
from
the
kubernetes
api,
so
it
can
find
via
pods
and
like
the
memory
usage
and
things
like
that
that
are
being
used.
B
But
if
you
want
to
correlate
that
to
what
the
overall
usage
is
on
a
node,
there's
a
WMI
exporter,
that's
open
source
and
available,
and
that's
what
can
provide
a
node
level
metrics
that
you
would
get
instead
of
using
the
node
exporter,
which
is
like
specific.
You
could
use
the
WMI
exporter
on
Windows
and
configure
that
to
expose
CPU
memory,
disk
network
and
other.
You
know
typical
things
that
you
need.
If
you
want
to
look
at
how
your
nodes
are
running
in
production,.
A
All
right,
then,
I
realize
we're
actually
out
of
time,
so
I'll
go
very
quickly.
So
on
a
compliance
standpoint,
you
know
make
sure
that
you
bake
compliance
into
your
CI
CD
process,
so
host
your
images
in
a
private
registry,
whether
that's
something
like
harbor,
on-prem
or
any
of
the
registries
in
public
cloud
providers,
where
you
have
your
own
private
account,
and
then
you
can
use
tools
and
technologies
like
aqua
security
and
twistlock
to
go
in
and
either
scan
your
images
from
harbor
or
scan
your
images
in
any
of
the
public
cloud
providers
for
vulnerabilities.
A
If
you
want
to,
you,
can
also
use
the
OPA
capabilities
that
the
Patrick
mentioned
earlier
to
do
some
enforcement
as
well.
So
look
at
this
from
a
holistic
viewpoint
and
force
compliance
of
the
CIC
there
at
the
code
layer
and
then
go
back
and
make
sure
that
whatever
gets
deployed,
the
kubernetes
is
really
secure
and
doesn't
have
any
issues
and
critical
vulnerabilities
on
the
disaster
front
recovery
front.
You
know
start
using
some
of
the
same
principles
that
we
using
for
your
containers
today
on
Linux.
A
That
means
backing
up
your
kubernetes
state
backing
up
your
persistent
volumes.
You
can
use
Valero
for
a
lot
of
those
capabilities
and
then
start
thinking
about
you
know
if
you
were
to
do
a
multi
cloud,
dr,
how
would
you
do
that
with
AJ?
Some
of
the
same
principles
that
apply
on
Linux
also
apply
on
Windows,
but
then
you
always
have
to
think
about.
You
know
the
trade-off
between
availability
and
consistency.
That's
the
cap
theorem!
A
So
always
have
that
in
mind,
we're
also
working
with
the
Valero
team
to
make
sure
that
you
have
fully
supported
windows,
bagged
apps
for
your
Windows
applications
on
kubernetes.
So
that's
something!
That's
gonna
come
up
soon.
How
you
can
help
come
to
our
sake.
You
can
help
with
improving
documentation.
Writing
some
blogs,
fixing
bugs
attending
our
meetings
and
just
sharing
your
story.
A
What
you
find
us,
you
know
we'll
publish
this
slide
deck
as
well,
but
you
know
you
can
find
us
on
slag
on
Google
Groups,
find
us
of
github
or
attend
any
of
our
meetings
since
we're
out
of
time.
We
won't
take
questions
now,
but
we'll
be
here
on
the
side,
so
you
guys
can
come
and
ask
us
anything.
You
want.
Thank
you.