Document per namespace sysctl and how to set them in pods

[bprashanth]

Source of major confusion in webserver tuning, but I'm sure that's just one victim.

• lack of documentation (best i could find was https://github.com/docker/docker/blob/master/opts/opts.go#L257)
• how do i set it on the host? (daemon set, probably)
• how do i set it in container? (privileged sidecar for network sysctls)

@kubernetes/sig-node

[ncdc]

@bprashanth see #26057

[bprashanth]

So that says:

network namespace: net.*

which is pretty much what I could figure out from the link to docker source above. But experimentation shows that /proc/sys/net/netfilter/nf_conntrack_max is not per ns, and I think i found a couple more. What am i missing?

Without reading through the proposal, setting it on a contaienr pipes through to the host, or does someone still need the daemon set?

[vishh]

The sysctl proposal mentions maintaining a file that will list sysctl that
are namespace aware.
The general strategy is to let kubelet configure sysctls and not have pods
update sysctls themselves.

One of the open questions on that proposal is that of knowing which sysctls
can be safely set to a higher value by default globally... Any inputs in
that regard will help!

On Mon, Jul 25, 2016 at 2:08 PM, Prashanth B notifications@github.com
wrote:

So that says:

network namespace: net.*

which is pretty much what I could figure out from the link to docker
source above. But experimentation shows that
/proc/sys/net/netfilter/nf_conntrack_max is not per ns, and I think i found
a couple more. What am i missing?

Without reading through the proposal, setting it on a contaienr pipes
through to the host, or does someone still need the daemon set?

—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
#29572 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGvIKGnH5hlK_SOyfXxGyfvtseqKSmfwks5qZSXegaJpZM4JUicg
.

[bprashanth]

I can write down the common ones for webserver tuning, when i have some time. Maybe @aledbf or @PiotrSikora know off the top of their head the ones we use in https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx or commonly with nginx

[aledbf]

net.core.somaxconn and net.ipv4.ip_local_port_range are the ones used in the sysctl example. I've been unable to find a list of the values is possible to change in a network namespace.

[vishh]

A list with safe defaults will be helpful.

On Mon, Jul 25, 2016 at 3:01 PM, Manuel Alejandro de Brito Fontes <
notifications@github.com> wrote:

net.core.somaxconn and net.ipv4.ip_local_port_range are the ones used in
the sysctl
https://github.com/kubernetes/contrib/blob/master/ingress/controllers/nginx/examples/sysctl/change-proc-values-rc.yaml#L80
example. I've been unable to find a list of the values is possible to
change in a network namespace.

—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
#29572 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGvIKLz9j-uUYwmR1qMkCUdCDrNEoqFSks5qZTIdgaJpZM4JUicg
.

[sttts]

Here is a good starting point in the kernel source to see which namespaced (per netns) sysctls exist under net.*:

https://github.com/torvalds/linux/search?utf8=%E2%9C%93&q=register_net_sysctl

If I understand it correctly, a number of sysctls only exist in init_net, the initial network namespace. And network namespaces are not nested, but flat. So we have a good chance that we really only get those sysctls which are safe.

It's not that hard to double check: lines like

table[0].data = &net->xfrm.sysctl_aevent_etime;

set a sysctl value destination in the given network namespace object net.

For example here are the netns specific tables for ipv4 and core:

https://github.com/torvalds/linux/blob/a7fd20d1c476af4563e66865213474a2f9f473a4/net/ipv4/sysctl_net_ipv4.c#L668
https://github.com/torvalds/linux/blob/a7fd20d1c476af4563e66865213474a2f9f473a4/net/core/sysctl_net_core.c#L417

[sttts]

Of course, the philosophical question remains: do we want to offer all technically possible sysctls (i.e. all those that are namespaced) or only the most common ones like the two above.

[fejta-bot]

Issues go stale after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle rotten
/remove-lifecycle stale

[yujuhong]

I think we can close this issue now that there is documentation on sysctl and how to use it: https://kubernetes.io/docs/concepts/cluster-administration/sysctl-cluster/