ingress-nginx 如何用 Init 容器调整 somaxconn 与 ip_local_port_range 内核参数【免费下载链接】ingress-nginxIngress NGINX Controller for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/in/ingress-nginx如果你的 ingress-nginx 控制器已经部署在集群里现在需要调整内核网络参数——把连接监听队列长度net.core.somaxconn从128提到32768把临时端口范围net.ipv4.ip_local_port_range从32768 60999调整为1024 65000——仓库中的官方示例 docs/examples/customization/sysctl/README.md 给出的做法是不改 Deployment 清单文件而是用一条kubectl patch命令通过一个特权 Init 容器在控制器 Pod 启动时执行sysctl -w写入这两个参数。适用前提是 ingress-nginx 已安装且控制器的 Deployment 名为ingress-nginx-controller、位于ingress-nginx命名空间示例命令即按此名称编写。为什么是这两个参数README 的Changes一节明确列出本示例要做的事Backlog Queue settingnet.core.somaxconnfrom128to32768Ephemeral Ports settingnet.ipv4.ip_local_port_rangefrom32768 60999to1024 65000README 还说明变更依据来自 NGINX 官方博客中一篇关于调优的文章文中对这两处改动作了解释外部链接此处不复述可查阅仓库文档原文。这两个参数与 ingress-nginx 的关系不只是建议调优。控制器代码在生成 nginx 配置时会读取当前节点的net/core/somaxconn值并把它用作监听 socket 的 backlog 大小见 internal/ingress/controller/util.gosysctlSomaxconn()通过/proc/sys读取该值和 internal/ingress/controller/nginx.goBacklogSize: sysctlSomaxconn()。也就是说somaxconn的实际值会直接体现在生成的 nginx 配置里而临时端口范围则影响控制器向外发起连接时可用的源端口数量。补丁内容patch.json 里有什么示例使用的补丁文件是 docs/examples/customization/sysctl/patch.json完整内容如下{ spec: { template: { spec: { initContainers: [{ name: sysctl, image: alpine:3.23.3, securityContext: { privileged: true }, command: [sh, -c, sysctl -w net.core.somaxconn32768; sysctl -w net.ipv4.ip_local_port_range1024 65000] }] } } } }逐点说明均按文件原样补丁作用在 Deployment 的 Pod 模板spec.template.spec上追加一个名为sysctl的 Init 容器镜像为alpine:3.23.3securityContext.privileged为true。执行sysctl -w需要写内核参数特权容器是其运行前提这一点在应用前应当明确知晓该容器的权限高于普通业务容器command依次执行两条sysctl -wnet.core.somaxconn32768和net.ipv4.ip_local_port_range1024 65000。第二条的值包含空格所以用单引号包裹。执行步骤把上面这份 JSON 保存为本地文件仓库中该文件的完整路径是docs/examples/customization/sysctl/patch.jsonREADME 原始命令是通过curl从仓库 raw 地址拉取同一内容本地已有文件时可直接引用本地文件。执行 patch把 Init 容器注入控制器 Deploymentkubectl patch deployment -n ingress-nginx ingress-nginx-controller \ --patch$(cat patch.json)命令与 README 一致仅把--patch的来源改为本地文件内容。注意 patch 修改的是 Pod 模板新的 Init 容器会在控制器产生新 Pod 时随 Pod 启动而运行不会 retroactively 作用于正在运行的旧 Pod。如果你的控制器 Deployment 名称或命名空间与示例不同自行部署时可能不同需相应替换命令中的-n ingress-nginx与ingress-nginx-controller。验证参数已生效文档给出的目标值就是验证基准net.core.somaxconn应为32768net.ipv4.ip_local_port_range应为1024 65000。在 Init 容器所修改的环境即控制器 Pod 所处的网络环境中执行只读查询sysctl net.core.somaxconn sysctl net.ipv4.ip_local_port_range返回值与上面两个目标值一致说明sysctl -w已生效。另外可以通过常规的kubectl -n ingress-nginx get pods观察控制器 PodPod 模板变更后重建的 Pod 会带有sysctlInit 容器并显示其运行完成状态这是 patch 已应用且容器已执行的最直接观察方式。可选替代路径Helm 的 controller.sysctls如果控制器是通过官方 Helm chart 部署的chart 本身提供了一类不同机制的选项controller.sysctls见 charts/ingress-nginx/values.yaml# -- sysctls for controller pods ## Ref: https://kubernetes.io/docs/tasks/administer-cluster/sysctl-cluster/ sysctls: {} # sysctls: # net.core.somaxconn: 8192该值会渲染为控制器 Pod 的securityContext.sysctls模板逻辑在 charts/ingress-nginx/templates/controller-deployment.yamlDaemonSet 模板中同样支持。两个使用细节数值需要以字符串形式给出这正是 values 示例中8192带引号的原因见 helm-chart-2.9.1 变更记录Add quoting to sysctls because numeric values need to be presented as stringsvalues 文件给出的示例值是8192与 Init 容器示例的32768不同——两处是独立示例本文不替你统一取值以你自己核对过的目标为准。chart 的sysctls走的是 PodsecurityContext路径与本文主路径的特权 Init 容器 sysctl -w是两种不同的注入机制按你的部署方式二选一即可。限制说明该文档只演示如何把这两个参数写入并给出变更前后值没有提供性能对比数据也没有给出调优后应达到多少吞吐的成功指标不要把它当成带量化收益的调优方案。特权 Init 容器privileged: true是本示例生效的前提在安全策略较严的集群中是否允许取决于集群自身的准入配置文档未对此作承诺。参数值32768、1024 65000、8192均为文档示例值修改时请保留单引号等书写格式并重新核对目标值与你的节点实际情况。【免费下载链接】ingress-nginxIngress NGINX Controller for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/in/ingress-nginx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考