k8s解除NodePort端口限制

发表于2023-09-20|更新于2025-11-01|容器

|浏览量:

我自己写了一个 svc 的 yaml 文件，部署的时候报错，不在默认的范围内，默认范围是: 30000-32767

kubectl apply -f nginx-src.yaml

报错:

1	The Service "nginx" is invalid: spec.ports[0].nodePort: Invalid value: 80: provided port is not in the valid range. The range of valid ports is 30000-32767

如果是 kubeadm 部署
修改配置文件 vim /etc/kubernetes/manifests/kube-apiserver.yaml

在启动参数里面添加如下一行

1	- --service-node-port-range=1-65535

重启 kube-apiserver

1	kubectl delete pod -n kube-system kube-apiserver-xxx

文章作者: 张理坤

文章链接: https://zahui.fan/posts/lmri345s/

版权声明: 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源杂烩饭！

相关推荐

单节点Kubernetes更换ip地址

如果是个多节点的集群，更换一台 master 节点的 ip 有个更简单的办法，那就是先扩容一台新的 master，再把旧的 master 节点下线，安全无副作用，如果是单节点更换 ip 地址（如果旧 ip 不用回收，那么可以直接在网卡上再绑定一个 ip 地址，不用对 k8s 进行修改）和 kubeadm之单节点master升级高可用master 有点类似首先更换操作系统 ip 地址略准备123456789# 备份配置文件cp -r /etc/kubernetes{,-bak}# 查看证书绑定的ip或域名for i in $(find /etc/kubernetes/pki -type f -name "*.crt");do echo ${i} && openssl x509 -in ${i} -text | grep 'DNS:';done# 删除需要重新生成的证书rm -rf /etc/kubernetes/pki/{apiserver*,fron...

找出占用Kubernetes节点磁盘的Pod

有部分开发不规范导致日志写入容器, 在 k8s 环境下导致节点磁盘空间占用过高, 解决方案有: 通过监控告警来提前预防挂载磁盘, 容器日志写入磁盘使用自动清理脚本 kubectl 查询每个 pod 占用磁盘空间使用 python 处理所有节点123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160...

开源分布式存储工具longhorn部署

k8s 如果需要用到存储，对于云产品一般都是采用云厂商提供的存储驱动，自建机房简单一点的会采用 nfs，nfs 有以下问题：高可用性问题，一般都是单台机器在跑，高可用完全依靠物理机器的 RAID，非常不云原生性能问题，NFS 本身性能不算好，外加一个集群都在使用，网卡速度是个瓶颈longhorn 是个开源的存储引擎，简单来说就是它把 k8s 每个节点的磁盘空间搜集起来，组成一个大池子，然后分配个各个 pod 使用。并通过多副本的方式做高可用。longhorn 好像是 openSUSE 家的吧，和 rancher 一个公司。官方文档官方安装说明：https://longhorn.io/docs/1.6.1/deploy/install/install-with-kubectl/ 官方安装要求：https://longhorn.io/docs/1.6.1/deploy/install/#installation-requirements 官方的检查依赖项脚本： 1curl -fsSL https://raw.githubusercontent.com/longhorn/l...

在Kubernetes中部署nacos 2.1.0

本次在 Kubernetes 上部署 nacos 2.1.0 版本，部署 3 节点集群，不做数据持久化（nacos 的配置管理是存储 MySQL 数据库的，服务发现是需要本地存储的）新版本 nacos 部署参考：在Kubernetes中部署nacos 2.3.2 MySQL 数据库准备创建数据库，配置好账号权限，执行如下 SQL 建表： 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101111121131141151161171181191201211221231241251261271281291301311321331341351361371381391401411421431441...

Java程序被停止前自动dump内存快照

线上业务偶尔会出现重启现象，为了排查这个问题，决定在 OOM 的时候自动进行 dump 内存快照用于分析针对 JVM OOM 的情况OOM 全称 “Out Of Memory”，表示内存耗尽。当 JVM 因为没有足够的内存来为对象分配空间，并且垃圾回收器也已经没有空间可回收时，就会抛出这个错误，解决 OOM 问题的一个思路: 假设发生 OOM 了，必然说明系统中某个区域的对象太多了，塞满了那个区域，而且一定是无法回收掉那些对象，最终才会导致内存溢出的，首先就得知道到底是什么对象太多了导致 OOM ，就必须得有一份 JVM 发生 OOM 时的 dump 内存快照有了 dump 内存快照，就可以用 MAT 之类的工具，或者在线工具来分析：https://memory.console.heapdump.cn/JVM 在发生 OOM 的时候并不是直接挂掉的，而是在 OOM 之前会尽量去 GC 腾出来一些内存空间，如果 GC 后还是没有空间，放不下对象，才会触发内存溢出的。JVM 给我们提供了一些参数可以在发生 OOM 的时候进行自动 dump 内存快照。： -XX:+HeapDu...

Kubernetes之master高可用方案

之前一直用使用的负载方案是搭建一台负载均衡器，可以是 haproxy 或 nginx 或 lvs，来将多个 master 节点的 6443 端口做个负载均衡，但是考虑到负载均衡也需要高可用，所以会引入类似 keepalived 的方案来解决问题。偶然看到了 kubeasz 这个开源项目，宣称解决了 master 高可用问题，部署了一遍发现并没有额外搭建负载均衡器，研究了一下，发现了另一种思路。使用额外的负载均衡来做高可用这种就是比较容易想到的一种方案，比如 3 个 master 节点，前面有一台负载均衡（nginx、haproxy、lvs）等，但是负载均衡本身就是一个单点故障，所以一般来说还需要另一台负载均衡，通过 keepalived 来实现 VIP 的切换使用Keepalived来实现Nginx高可用使用Nginx做负载均衡使用HAproxy做负载均衡使用LVS做负载均衡vim nginx.conf 在文件最后添加 123stream { include stream.conf;} 然后 vim /etc/nginx/stream.conf ...

评论

数据加载中