k8s解除service端口限制
发表于|更新于|容器
|浏览量:
我自己写了一个 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 |
文章作者: 张理坤
版权声明: 本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 杂烩饭!
相关推荐

2025-06-20
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 内存快照。:...
2025-06-20
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...
2025-06-20
Kubernetes同一个namespace共用镜像secret
配置一个全局的镜像拉取密钥, 后续拉镜像就不用每个 deployment 单独配置了。 在每个 namespace 下都有一个默认的 service account, 假设命名空间是 test 使用 kubectl get sa -n test 查看 查看 serviceaccount 信息 1kubectl describe sa -n test Image pull secrets 是此 namespace 下拉取镜像的秘钥 1.创建 secret 1kubectl create secret -p docker-registry registrykey --namespace=test --docker-username=<harbor_user> --docker-password=<harbor_password> --docker-server=<harbor_url> 2.配置进 service account 1kubectl patch serviceaccount default -p...
2025-06-20
Kubernetes的3中探针readinessProbe、livenessProbe和startupProbe
探针K8S 提供了 3 种探针 startupProbe 启动检查(1.16 版本新增)livenessProbe 存活检查readinessProbe 就绪检查 startupProbekubernetes 1.16 版本新增功能,用于判断容器内应用程序是否已经启动,如果配置了 startuprobe,就会先禁用其他的探测,直到它成功为止,成功后将不再进行探测。 1234567891011startupProbe: # 健康检查方式:[readinessProbe,livenessProbe,StartupProbe] failureThreshold: 3 # 检测失败3次表示未就绪 httpGet: # 请求方式 path: /health # 请求路径 port: 8080 # 请求端口 scheme: HTTP # 请求协议 ...
2025-02-14
Kubernetes回滚应用之kubectl rollout
kubernetes 每次更新资源会记录资源的历史版本, 方便我们进行回滚操作。真的 k8s 解决了很多运维的痛点问题, 想起来以前没有用 k8s 的时候,用 jenkins 和 ansible 来做的发布和回滚… 查看历史版本12345678kubectl rollout history deployment nfs-client-provisionerdeployment.apps/nfs-client-provisionerREVISION CHANGE-CAUSE1 <none>2 <none>4 <none>5 <none> 这里列出的就是版本, 为什么没有 3, 因为从版本 4 回滚到了版本 3, 则版本 3 就变成了版本 5 查看指定版本详情1kubectl rollout history deployment nfs-client-provisioner --revision=4 回滚到指定版本1kubectl rollout undo...
2025-06-20
kubernetes节点维护流程
节点设置为 SchedulingDisabled 其实就是打上污点 node.kubernetes.io/unschedulable:NoSchedule 命令 说明 kubectl cordon 将 node 设置为 SchedulingDisabled, 不允许新的 pod 调度上来, 旧的 pod 不受影响 kubectl drain 先驱逐 node 上的 pod, k8s 会在其他节点重新创建, 然后将节点设置为 SchedulingDisabled kubectl uncordon 恢复调度, 删除 SchedulingDisabled 污点 操作流程常规操作将节点上现有的 pod 驱逐, 不追求优雅 1kubectl drain <node> --delete-local-data=true --ignore-daemonsets=true --force 操作完毕后, 将节点恢复调度 1kubectl uncordon <node> 对集群无影响的操作先针对节点执行 1kubectl cordon...
评论
公告
此博客为我记录运维工作总结所用,供网友阅读参考,如有侵权,请通知我,我会核实后进行处理。
欢迎加入技术交流群: