►
Description
(i) What are the key trends in 2022 that are driving Kubernetes adoption? (ii) What kinds of challenges are enterprises facing? (iii) What’s the current state of the Kubernetes project? (iv) What’s new in Kubernetes 1.24 and what new features are in progress for future releases? We’ll answer all these questions and more. We will also celebrate the work done by Indian contributors in Kubernetes! This talk is geared towards everyone from Kubernetes newbies to advanced users.
A
A
So,
let's
get
started
a
little
bit
about
me.
My
name
is
nikita
and
I'm
a
staff
engineer
at
vmware
my
day.
Job,
luckily,
is
to
work
on
the
kubernetes
project
itself
and
I've
been
working
on
it
for
over
four
years
now
I
was
also
a
former
member
of
the
kubernetes
steering
committee.
It
is
a
committee
which
oversees
the
governance
of
the
whole
project,
so
we
have
different
levels
and
committees
and
groups
in
the
community,
and
the
steering
committee
is
the
topmost
body
which,
like
is
the
leadership,
takes
the
leadership
role
for
the
whole
project.
A
I
also
hold
a
few
other
roles
in
the
community,
like
being
a
technical
lead
for
a
sig,
related
automation,
policy,
contributor
experience,
I'm
also
a
cncf
ambassador.
You
can
find
me
on
github,
the
user
name
nikita
and
twitter
nikita
okay
enough
about
me.
Let's
get
back
to
kubernetes.
A
In
the
cncf
annual
survey,
we
notice
that
there's
96
percentage
of
organizations
are
either
using
kubernetes
or
they're
evaluating
kubernetes,
which
honestly
is
at
an
all
time
record
high
ever
since
these
surveys
started
so
before,
kubernetes
was
something
like
okay.
This
is
a
very
niche
technology
that
only
some
companies
can
use.
Only
one
of
the
bigger
companies
or
medium-sized
companies
use
the
smaller
companies.
They
don't
need
to
use
it,
but
now
it
definitely
shows
that
kubernetes
has
crossed
that
adoption
chasm
to
become
a
mainstream
global
technology.
A
A
A
So
it
goes
on
to
show
that
developers
may
not
even
realize
that
many
of
the
popular
services
they
use
use
kubernetes
under
the
hood.
It's
become
somewhat
like
linux
right
now,
so
somewhat
like
the
ubiquity
of
linux.
Right
now,
this
shows
that
kubernetes
is
finally
becoming
boring
and,
honestly
that's
good
for
the
project
and
also
for
the
ecosystem,
because
that's
what
exactly
kubernetes
should
have
to
do.
Surely
there's
more
to
do,
but
we
are
getting
there
along
the
same
thoughts.
A
A
A
Another
very
interesting
thing
to
notice
is
that,
since
kubernetes
is
maturing
to
a
mainstream
technology,
more
organizations
are
slowly
moving
up.
The
cloud
native
stack,
leveraging
kubernetes
apis
and
interfaces
so,
like
I
said,
kubernetes
has
become
boring,
so
they
are
looking
to
go
to
something
that's
more
fun
and
interesting
to
work
on
now.
A
This
is
particularly
apparent
with
runtime
containers
like
container
d
and
cryo,
like
I
think
all
of
you
must
have
heard
of
the
container
d
project
right
now:
service
mesh,
like
envoy
and
linkedin,
and
monitoring
tool
spectrometers,
given
that
there
is
a
43
increase
in
prometheus
adoption
and
53
for
fluency
adoption.
It
shows
that
organizations
are
looking
to
tap
into
open
source
technologies
since
prometheus
and
fluently
they're
all
open
source
technologies
to
advance
their
observability
practices
and
capabilities.
A
So
since
a
lot
of
the
cncf
projects
are
open,
so
almost
all
of
them,
we
can
see
that
organizations
are
looking
to
adopt
those
and
eventually
moving
to
open
source
technologies.
A
This
underlying
growth
of
iot
will
also
continue
to
propel
the
total
usage
of
kubernetes.
There
are
also
a
lot
of
exciting
challenges
in
the
edge
computing
space,
because
you
have
a
lot
of
other
constraints
like
memory,
cpu
and
so
on.
So
if
this
concept
of
iot
and
engines
excites,
you
I'd
highly
recommend
to
looking
into
kubernetes
and
the
edge
computing
space.
A
Okay,
now
that
we've
talked
about
how
kubernetes
adoption
is
increasing,
it's
also
touch
based
on
some
challenges
that
folks
might
face,
while
doing
so.
One
big
business
challenge
that
organization
face
is
the
lack
of
expertise.
It
honestly
still
takes
a
steep
learning
curve
to
build,
deploy
and
manage
kubernetes
effectively.
A
This
is
mainly
due
to
the
lack
of
operational
precedent
with
it.
Even
though
we've
seen
that
kubernetes
is
being
adopted
across
almost
96
of
our
organizations,
it
is
still
new.
It
is
still
a
new
technology
compared
to
others.
So
there
is
a
lack
of
operational
precedent
with
it
to
break
through
these
barriers.
Organizations
can
take
training
programs,
including
cnc
and
certifications,
and
work
with
partner
organizations
that
have
specific
expertise
and
solutions
along
the
same
lines.
It's
also
becoming
harder
for
organizations
to
hire
skilled
kubernetes
engineers,
but
hey.
A
This
also
means
that
if
you
are
a
kubernetes
engineer,
it
is
a
very
good
time
to
be
slow,
because
your
skills
would
be
in
high
demand
with
more
organizations.
Moving
to
cloud,
there
seems
to
be
an
emerging
trend
of
lack
of
internal
alignment,
so
with
multiple
stakeholders
involved
decision
making
around
how
to
integrate
and
manage
kubernetes
can
become
difficult.
So
it
is
important
to
set
a
cloud
strategy
around
various
aspects
like
cloud
financial
management
operations,
security
and
compliance
now
scalability,
it's
kind
of
ironic
that
kubernetes
improves
scalability.
A
Yet
I'm
saying
that
one
of
the
common
challenges
faced
organizations
is
in
fact
scalability.
This
is
mainly
due
to
the
complexity
of
kubernetes,
so
most
organizations
have
a
hard
time
with
complex
installation
and
configuration
honestly
if
you've
tried
it
doing
from
scratch
yourself.
You
know
how
hard
it
is,
but
this
problem
aggravates
when
there
are
multiple
clouds,
multiple
policies
and
designated
users
involved.
A
A
So
let's
live
dive
a
little
deeper
into
the
security
aspects
which,
according
to
me,
is
the
most
fun
part.
Let
me
start
by
saying
that
kubernetes
itself
is
not
some
inherently
vulnerability
written
technology,
the
security
that's
affecting
it
are
similar
to
those
that
affect
most
other
technologies
that
are
relatively
new
to
users.
Now
here
are
some
top
security
concerns.
A
First,
one
is
a
possible
configuration
issues
involving
container
images,
name,
spaces,
runtime
privileges
or
even
unnecessary
exposure
of
secrets,
as
they
are
baked
into
images,
because
all
of
this
can
lead
to
risk
exposures,
so
misconfiguring
handling
misconfigurations
is
very
important.
A
Now
security
vulnerabilities.
I
think
a
lot
of
you
might
know
that.
Obviously,
this
is
a
huge
cause
for
risks
around
security,
so
security
vulnerabilities.
What
does
that
include?
So?
It
includes
exploit
some
containers
like
malware
installation
and
privilege
escalation
to
name
a
few
now
these
can
exist
in
production,
production,
accessible
container
registries
and
even
third
party
admission
controllers
in
kubernetes
clusters.
A
A
A
Okay,
now
that
we've
seen
how
the
ecosystem
looks
like
today,
let's
dive
deeper
into
the
kubernetes
project
itself.
What
are
some
of
the
achievements
that
we've
done
on
the
last
year?
I'd
say
one
of
the
biggest
one
is
feature
maturity
and
stability
like
I've
been
saying
like
kubernetes,
is
becoming
more
boring.
It's
been
able
to
get
more
boring
only
due
to
maturity
and
stability.
A
A
Anyway,
coming
back
to
the
point,
a
lot
of
kubernetes
are
continuing
to
drive,
long-standing
beta
features
to
graduate
to
stable,
so
some
examples
that
you
might
have
heard
of
as
the
ipv4
ipv
v6,
dual
stack,
which
graduated
to
stable
in
1.23
or
even
the
generic
fm
middle
inline
volumes
also
graduated
to
stable
in
123.
A
now
showing
up
and
sticking
around.
This
sounds
like
a
very
simple
phrase,
but
let
me
explain
more
on
how
important
it
is.
Climbing
the
contributor
ladder
the
contributor
ladder
is
basically
when
you
start
out
as
a
new
contributor
like
okay,
I
want
to
contribute.
Then
you
start
contributing
a
little
more.
We
call
you
a
member
once
you
become
a
member
and
you're
contributing
even
more
than
participating
in
reviews
and
other
reviews
also
trust
you
as
a
reviewer,
you
become
a
reviewer
and
so
on.
A
So
you
basically
move
up
a
ladder
and
that's
called
the
contributor
ladder.
One
of
the
biggest
challenges
that
we've
been
facing
right
now
is
that,
even
though
we
say
that
okay,
the
kubernetes
project
has
a
lot
of
contributors,
we
don't
have
folks
who
can
who
are
consistently
moving
up
the
contributor
ladder.
A
Now,
let's
talk
more
on
how
we
solve
this
challenge.
In
some
sense,
it's
still
not
perfect,
though.
Okay,
now
coming
back
to
the
contributor
ladder,
so
climbing
this
contributor
ladder
is
a
trust
building
exercise
as
much
as
it
is
a
skills
one
so
sticking
around,
and
we
use
a
phrase
called
chopping
wood
and
carrying
water.
It
is
the
main
formula
for
growing
leaders
in
the
project
you
need
to
stick
around.
You
need
to
do
the
actual
work
and
you
need
to
show
up
now.
How
did
we
kind
of
solve
this
problem
in
a
sec?
A
Let
me
take
the
example
of
sick
dogs,
so
it's
an
amazing
example
of
an
intentional
contributor
ladder,
growth
effort
because
they
grew
their
contributor
base
and
their
reviewer
base
in
2021.
How
did
they
do
that?
They
introduced
a
shadow
program
for
pull
requests
handling.
A
So
there
was
a
lot
of
pull
requests
coming
in,
but
no
one
was
taking
a
look
at
it,
and
new
contributors
would
get
rejected
because
their
pull
requests
were
not
getting
reviewed
and
it
was
just
like
leading
on
to
a
youth
cycle,
so
they
designated
a
shadow
program
and
basically
a
designated
person
would
be
there.
Who
would
be
wrangling
these
fears
and
looking
at
these
pr's
at
a
regular
basis.
A
They
also
showed
up
a
shadow
program,
so
there
would
be
a
lead
who
would
be
doing
this
and
there
would
be
a
mentee
or
you
can
think
of
it
as
a
mentor
mentee
system,
where
a
lead
is
doing,
they
are
responsible
for
the
actual
work
and
there
is
a
shadow
who
is
who
is
learning
from
this
lead
and
how
things
need
to
be
done.
So
they
introduced
a
shadow
program
for
pr
wrangling
and
dedicated
more
time
to
be
active
in
the
sickbox
slack
channel
and
answering
questions
from
new
contributors.
A
This
eventually
helped
grow
the
community,
not
only
this.
They
also
worked
on
the
leadership
transition
strategy
to
bring
community
members
into
leadership
roles
by
a
specialized
six
month.
It's
a
six
month
group
mentorship
program
from
this.
They
were
able
to
cultivate
leaders
for
the
sake
and
some
of
its
subgroups
adding
new
coaches
and
tech
leads.
In
fact,
one
of
them
is
also
from
india
and
we'll
see
a
lot
more.
Who
who
are
these
people
in
a
minute?
A
Now,
every
group
in
kubernetes
has
a
responsibility
to
make
sure
that
we
are
putting
our
best
foot
forward
with
supply
chain.
Security.
Security
is
very
important
for
us
in
particular,
though,
sid
release,
sick,
oath
and
sick
security
worked
hand
in
glove
to
drive
sustained
efforts
in
this
area,
including
artifact,
signing
compliance
with
slsa3
standards
and
improving
the
end
user
security
documentation.
A
Now
there
are
plenty
of
processes,
tools
and
policies
that
are
put
together
in
a
project
life
cycle
that
sometimes
eventually
need
to
be
phased
out,
for
whatever
reason,
we've
seen
that
in
all
organizations-
and
it
is
same-
it
is
also
true
for
the
kubernetes
project,
now
contributor
pain-
point
that
we've
had
in
the
cold
base
by
lush
is
basil.
If
you've
not
used.
If
you've
not
used
basil
in
the
past,
be
happy
for
yourself,
it
is
very
complicated
to
use
you
can.
A
Essentially
it's
like
a
build
system,
so
the
crews
in
six
testing
and
sig
release
they
put
in
a
lot
of
time
and
attention
on
removing
basil
from
coal
kubernetes.
It
still
exists
in
a
few
parts
of
the
code
base
in
other,
like
not
cold
kubernetes
but
in
other
parts,
but
we're
also
planning
on
removing
it
there
and
finally
stick
windows.
It's
had
it
has
had
amazing
progress
and
growing
windows
supporting
the
ecosystem
with
their
efforts
like
majorly,
defining
operational
readiness
standards
for
windows.
A
Now
these
are
all
the
achievements
that
the
project
has
done
over
the
last
year.
Now,
looking
at
all
of
these,
there
are
a
few
themes
or
trends.
Let's
see
what
that
what
they
are
now
one
is
that
we
are
trying
to
prioritize
on
quality.
Why
so,
there's
been
actually
an
increase
in
regression
related
backwards
in
the
last
few
releases?
A
Many
of
these
regressions
why
they're
occurring
is
basically
related
actually
to
two
types
of
changes,
so
one
change
is
to
add
features
or
fix
unrelated
bugs
in
areas
that
are
too
complex
and
under
tested.
Kubernetes,
like
I
said,
it's
a
huge
code
base
and
there
are
some
areas
that
are
too
complex
and
understaffed
and
under
tested.
So
there
are
only
few
people
who
know
what
is
actually
going
on
there,
and
sometimes
when
another
contributor
comes
and
changes
things
it
breaks
and
leads
to
regressions.
A
The
other
type
of
change
is
changes
that
were
intended
to
be
mechanical
refactors,
but
then
they
accidentally
ended
up
modifying
behavior.
Now
to
fix
these
problems,
we
are
tracking
the
health
of
existing
components
and
we're
developing
more
specific
test
plans.
Also,
when
we're
adding
new
reviewers,
we
are
being
very
cautious
that
okay,
these
reviewers
have
the
necessary
experience
and
they
can
actually
review
code
properly,
so
we're
prioritizing
quality
of
the
world.
A
The
other
thing
for
us
is
growing
independent
contributors.
Now,
what
does
independent
really
mean?
So
we
have
a
lot
different
scenario
of
contributors,
so
there
are
folks
who
work
on
kubernetes
on
like
the
deja.
That's
people
like
me,
but
then
there's
also
the
independent
contributor
base,
who
are
not
paid
to
work
on
kubernetes,
but
they
do
so
on
their
own
time
because
they
like
it
now
we're
trying
to
grow
the
independent
contributor
based
by
connecting
folks
to
jobs.
So
if
you
go
to
the
cncf
jobs
website,
there
is
cncf.jobs.I
o
lb
cncf.jobs.io.
A
The
job
listings
also
indicate
a
percentage
of
time
that
the
employers
would
support
for
upstream
activities.
For
example,
if
I
am
an
employer
and
I'm
listing
a
job
site
there.
I
would
say:
okay
like
if
you
apply
to
this
job,
50
of
your
time
is
20
of
your
time.
You
can
work
on
upstream
kubernetes,
so
that
way
you
can
filter
out
which
jobs
you
want
to
apply
for
as
well,
and
this
will
eventually
help
grow
the
contributor
base
and
that's
something
that
we
really
really
want
right
now.
A
Another
thing
is
niche
contributor
documentation.
So,
like
I
said,
kubernetes
is
very
huge.
There
are
a
lot
of
complex
areas
and
with
that
its
contribution,
documentation
also
needs
to
be
big,
and
it
is
pretty
big.
We
are
starting
to
take
better
measures
to
document
more
complex
areas
and
keep
things
up
to
date.
We
sorry
like
we
really
need
to
do
more.
I
think,
but
we're
still
getting
there
honestly
if
you're
looking
to
contribute
to
kubernetes
writing
documentation
is
an
excellent
way
to
get
started
and
finally
gone
out.
A
So
it's
become
an
industry-wide
problem
now
with
the
pandemic
and
there's
so
many
things
happening
all
over
the
world.
It's
like
I'm
sure
most
of
you
might
have
been
through
burnout
at
one
point
or
the
other.
Unfortunately,
but
we
need
to
solve
it
together
and
there
are
a
mix
of
reasons
why
contributors
are
burning
out.
A
We
are
still
unsure
of
the
exact
solution
to
this
problem,
though,
but
at
least
we're
constantly
talking
about
it.
In
fact,
we
also
reduce
the
release
scales
to
make
it
easier
and
more
sustainable
for
contributors
and
users,
and
we
are
keeping
our
doors
open
for
contributors
to
have
these
discussions
with
us.
A
So
if
you
are
feeling
the
symptoms
of
burnout
or
if
you
feel
burnt
out
already
feel
free
to
reach
out
to
sick,
leads
or
leaders
and
the
kubernetes
community
and
we'll
be
more
than
more
than
happy
to
talk
to
you
about
this
now,
we've
also
identified
some
areas
of
growth
opportunities
or
needs.
So
some
six.
A
Let
me
actually
take
a
step
back,
so
we're
talking
about
project
health
right.
So
how
do
you
define
project
health
so
some
things
they
have
industry
by
open
source
veterans
and
like
these
are
veterans?
They've
worked
in
open
source
for
a
long
time.
They
can
quickly
identify
areas
of
the
components
that
need
help,
they're
able
to
tell
stories
about
what's
flourishing
and
they're,
pretty
quick
in
doing
things.
A
So
all
of
those
things
they
have
better
health
compared
to
some
others,
but
they're
slightly
newer,
open
source
work.
So
that's
totally
fine,
but
since
different
people
have
different
levels
of
experience,
there
needs
to
be
a
standard
way
to
establish
universal
indicators
of
project
health
in
a
project,
especially
as
large
and
diverse
as
communities.
So
that
is
some
one
area
where
we
are
still
working
on
like
what
and
trying
to
define
what
is
project
health
anyway,
we
do
run
annual
reports,
obviously
annually
yearly.
A
So
we
ask
all
six
to
list
down
some
statistics
like
how
many
contributors
do
you
have?
Did
you
help
grow
these
contributors,
and
so
on?
What
features
did
you
work
on?
How
many
do
you
graduate
to
stable
things
like
that,
so
we're
using
all
of
this
data
to
eventually
create
or
we've
to
create
a
report
called
the
summary
of
the
annual
report?
Basically
and
it
we
are
trying
to
get
the
overall
project
health
from
it,
but
still
more
to
do
so.
A
Now,
if
you've
been
watching
open
source
news
over
the
last
year,
supply
chain,
security
has
made
headlines
according
to
open
ssf
and
other
security
groups.
Code
reviews
are
an
important
piece
to
putting
prioritization
on
security.
If
you
don't
do
code,
reviews
right
bugs
can
sneak
in
and
vulnerabilities
can
sneak
in
so
doing
code
reviews
right
is
very
important,
but
with
burnout
and
other
factors,
people
aren't
having
enough
time
to
work
on
it.
A
It's
been
hard
for
us
to
grow
the
number
of
reviewers,
so
that's
another
growth
area
that
we've
identified
that
we
definitely
need
more
reviewers.
We
are
trying
out
some
strategies
right
now,
but
if
you
have
more
ideas,
feel
free
to
reach
out
to
us
and
seek
contributor
experience
now
only
a
handful
of
the
most
active
contributors.
A
Now
we're
working
with
the
cncf
governing
board
to
see
if
we
can
develop
some
incentives
and
long-term
strategies
to
fix
this,
but
having
less
full-time
folks
and
less
senior
folks
is
turning
out
to
be
a
huge
problem
to
the
project.
A
Okay.
Now.
Finally,
let's
look
in
brief
about
the
kubernetes
one
or
24
days
1.24.
It
had
a
strong
focus
on
beta
and
stable
features,
and
it
involves
some
pretty
major
changes.
Let's
see
what
those
are,
so
one
of
the
biggest
change
is
that
docker
has
been
removed
from
cubelet,
so
from
1
or
24
onwards.
It
is
recommended
that
you
move
to
a
container
runtime
like
container
deox,
but
this
change
made
a
lot
of
noise
when
it
was
announced,
like
kubernetes,
no
longer
supports
using
docker
as
a
container
on
time,
but
don't
panic.
A
This
change
has
no
impact
at
all
for
most
users
of
kubernetes.
If
you
use
a
managed
kubernetes
service,
this
change
should
not
impact
you
in
any
way.
If
you
manage
your
own
cluster
and
still
use
docker
as
a
container
run
time,
like
I
said,
moving
to
container
d
is
important,
but
it's
fairly
simple
to
do
so,
so
you
don't
need
to
worry
too
much
about
it.
A
A
Another
interesting
things
cubelet
offers
a
new
prometheus
metric
to
allow
cluster
operators
to
count
out
of
memory.
Events
that
happen
in
each
container
running
in
the
kubernetes
cluster
best
practice
is
to
set
memory
limits
for
each
container,
but
when
software
does
not
run
as
expected,
it
can
reach
this
limit,
and
when
that
happens,
the
kernel
kills.
The
faulty
process
so
find
out
exactly
what
happened
is
not
easy,
but
this
new
metric
will
definitely
help
them
now,
no
secret
by
default
for
service
account
tokens.
This
chair
sounds
scary,
but
it
only
impacts.
A
Kubernetes
users
who
use
a
long
lived
service
account
tokens
that
kubernetes
stores
inside
secrets
so
to
kubernetes
1.23,
creating
a
service
account
in
a
cluster
results
in
kubernetes
automatically
creating
a
secret
with
a
token
for
that
service
account
and
this
token
never
expires,
which
can
be
useful,
but
it
is
also
a
security
issue,
so
starting
with
kubernetes
1.24,
these
secrets
will
no
longer
be
created
automatically
now
being
able
to
load
a
sidecar.
That
checks
for
the
health
of
persistent
volumes
is
a
welcome
addition.
A
A
I'd
also
like
to
take
a
minute
to
celebrate
some
kubernetes
contributors
from
india.
Dems
is
another
prolific.
Kubernetes
contributor
also
did
a
version
of
this
in
kcb
bengaluru
2020.
I
wanted
to
do
a
follow-up
on
it.
So,
while
working
on
this,
I
realized
that
we
have
a
lot
of
new
contributors
who
joined
us
in
the
last
year,
so
this
is
in
absolutely
no
particular
order,
but
let
us
see
who
they
were
so.
First
I'd
like
to
start
with
karupiya,
who
is
also
from
chennai.
A
He
has
contributed
to
the
e2e
framework
and
a
few
cluster
api
libraries
anubha.
I
could
not
find
a
picture
of
them
when
they
have
been
instrumental
in
sick
contributor
experience
and
sick
dogs.
Nikhil
has
a
lot
of
pr's
to
his
name
in
cube
builder
scientific
who's.
Also,
one
of
my
favorite
contributors
she's
wondering
cluster
api
providers.
A
Mija
works
on
the
gateway
api,
karthik
sharma
has
contributed
to
storage
and
csi
related
projects.
Devi
brada
is
also
one
of
my
favorite
contributors
and
he's
been
taking
leadership
roles
in
sick
contributor
experience.
A
Have
worked
on
cluster
api
and
its
providers,
priyanka
sagu
has
taken
leadership
roles
and
release
teams
she's
also
with
the
enhancement
lead.
So
she
is
the
lead
for
making
sure
what
all
features
get
into
1
25.
She
is
also
mentoring.
A
few
other
folks
to
take
this
leadership
role
in
the
next
few
releases.
A
Azithi
is
a
very,
very
pro
respects,
ignored
contributors
from
india.
Okay,
I
will
go
through
all
of
these
names
here,
because
they
were
also
talked
about.
In
previous
case
series,
I
would
like
to
give
a
shout
out
to
divya
who
is
leading
sick
dogs
as
well,
but
yeah,
it's
very
nice
to
see
so
many
people
contributing
from
india-
and
I
hope
you
all
also
consider
joining
in
as
well
I'd
love
to
see
your
faces
on
your
name
included
in
the
slides
next
year,
so
yeah.
A
If
you
want
to
get
involved
in
any
specific
area,
so
I
talked
about
q
builder.
I
talked
about
csiro's
cluster
api,
so
there's
a
variety
of
projects.
Please
feel
free
to
reach
out
to
these
folks.
If
also
happy
like
to
answer
any
questions
myself,
so
please
feel
free
to
reach
out
to
me
as
well.