K8s 生产环境问题汇总及解决方案(持续更新 ing)

这篇具有很好参考价值的文章主要介绍了K8s 生产环境问题汇总及解决方案(持续更新 ing)。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

目录

一、前端页面显示 503 Service Temporarily Unavailable

问题背景

解决方案

原理

二、Dockfile 构建镜像失败:When using COPY with more than one source file, the destination must be a directory and end with a / 

问题背景

解决方案

原理

三、前端页面显示 502 Bad Gateway

问题背景 

解决方案

原理


一、前端页面显示 503 Service Temporarily Unavailable

时间:2023-04-19        k8s 版本:v1.18.4

问题背景

        Kubernetes 中的前端项目 Pod 运行正常,但访问通过 Ingress 代理的域名时页面出现“503 Service Temporarily Unavailable”的错误,查看 log 日志也无报错信息。

解决方案

        我最初是 service.yaml 和 ingress.yaml 里的 name 名称为 gtp,然后我又修改为 gpt,在修改前没 kubectl delete 原来的资源,当我删除原来的为 gtp 名称的 ingress 和 service 资源后,前端页面就可以正常访问了。

原理

        问题出在修改资源名称时未删除旧资源。当我将名称从 gtp 修改为 gpt 时,应该首先使用 kubectl delete 删除旧的资源(即原先的 Ingress 和 Service),然后再应用新的资源配置。如果没有删除旧资源,可能会导致以下问题:

  1. Ingress 混淆:如果旧的 Ingress 和新的 Ingress 都存在,它们可能会争夺同一个域名和路径。这可能导致 Ingress 控制器在处理请求时混淆,从而选择错误的后端服务。当你删除了旧的 Ingress 资源后,Ingress 控制器开始将流量正确路由到新的后端服务。

  2. 后端服务冲突:类似地,如果旧的 Service 和新的 Service 都存在且监听相同的端口,可能会导致端口冲突或 Kubernetes 无法正确将流量路由到预期的后端服务。删除旧的 Service 资源后,Ingress 控制器可以将流量路由到正确的后端服务。

        总之,当你修改资源名称时,务必确保先删除旧资源,以避免出现混淆和冲突。在应用新的资源配置之前,使用 kubectl delete 删除旧资源,然后再使用 kubectl apply 应用新资源配置。这样可以确保 Ingress 控制器将流量正确路由到新的后端服务。

二、Dockfile 构建镜像失败:When using COPY with more than one source file, the destination must be a directory and end with a / 

K8s 生产环境问题汇总及解决方案(持续更新 ing)

问题背景

        COPY 根据通配符 * 匹配到多个多个文件,所以语法错误,镜像构建不成功,push 到镜像仓库失败。 

解决方案

在 COPY 最后面加个 / 即可。

原理

   COPY 指令的语法是 COPY <src> <dest>,其中 <src> 是要复制的源文件或目录,<dest> 是目标路径。在这个例子中,. 表示当前目录,所以 COPY . . 的含义是将构建上下文的当前目录中的所有文件和目录复制到容器的工作目录(由 WORKDIR 指令设置)。

与 COPY target/*.jar . 有以下几点区别:

  1. COPY . . 是将整个构建上下文的当前目录的内容复制到容器的工作目录。而 COPY target/*.jar . 仅复制 target 目录下所有的 .jar 文件到容器的工作目录。

  2. COPY . . 不需要指定目标路径以 / 结尾,因为它是在将整个目录复制到另一个目录。而 COPY target/*.jar . 复制多个文件时需要以 / 结尾,表示目标是一个目录。

        使用哪种 COPY 取决于您的需求。如果您需要将整个构建上下文的所有文件复制到容器中,可以使用 COPY . .。如果您只需要复制特定的文件或目录,可以使用类似 COPY target/*.jar . 的语法。

三、前端页面显示 502 Bad Gateway

时间:2023-08-3        k8s 版本:v1.25.4

问题背景 

        新建了个 service 资源类型为 nodePort 后端指定一组 pod 标签,service 创建成功;使用 Nginx 代理了这个 nodePort 端口使外部可以访问,结果访问前端页面显示  502 Bad Gateway。

解决方案

1. 查看 Nginx 错误日志:

2023/08/03 15:01:52 [error] 29229#29229: *1116307 connect() failed (111: Connection refused) while connecting to upstream, client: 10.22.11.237, server: valetorder.xxx.com, request: "GET / HTTP/1.1", upstream: "http://10.0.4.173:31193/", host: "valetorder.uat.dusto-yc.com"
2023/08/03 15:01:52 [error] 29229#29229: *1116307 connect() failed (111: Connection refused) while connecting to upstream, client: 10.22.11.237, server: valetorder.xxx.com, request: "GET / HTTP/1.1", upstream: "http://10.0.4.172:31193/", host: "valetorder.uat.dusto-yc.com"

        初步排查是否后端服务器(upstream)正常运行,并且监听了配置文件中指定的端口(例如:31193)

2. 查看后端 pod 的运行状态

是 running 状态,无异常

3. 判断 service 与指定的 pod 是否关联了

[root@idc-master-01 yaml]# kubectl describe svc -n uat valet-order-uat-out
Name:                     valet-order-uat-out
Namespace:                uat
Labels:                   app.kubernetes.io/name=valet-order-uat
                          io.cattle.field/appId=valet-order-uat
Annotations:              <none>
Selector:                 app=valet-order-uat
Type:                     NodePort
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.102.177.78
IPs:                      10.102.177.78
Port:                     http  80/TCP
TargetPort:               80/TCP
NodePort:                 http  31193/TCP
Endpoints:                <none>
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

[root@idc-master-01 yaml]# kubectl get pods --selector app=valet-order-uat -n uat
No resources found in uat namespace.

Endpoints 为空且查找不到有 app=valet-order-uat 标签的 pod,那就是 service 资源有问题。

4. 修改 service 资源中的 selector 字段的值

指定 pod 资源文件如下:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: valet-order-uat
    vvv: 1.0.1
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app.kubernetes.io/name: valet-order-uat

        我在 service 中的 selector 选择了 app: valet-order-uat 标签,导致没有匹配到,改为 app.kubernetes.io/name: valet-order-uat 即可。

最终页面成功访问。

原理

        上面 Pod 资源中的 spec.selector.matchLabels 使用的是一个复合标签,即 app.kubernetes.io/name: valet-order-uat。而在 Service 资源中的 selector 使用的是简单的单个标签 app: valet-order-uat

        由于标签的匹配规则是精确匹配,所以 Service 的 selector 并不会与 Pod 资源的 spec.selector.matchLabels 完全匹配。因此,Service 将不会与该 Pod 直接关联,且不会将流量导向该 Pod。

        当 Pod 资源中的 metadata.labelsspec.selector.matchLabels 同时打了不同的标签,Service 将只会根据 spec.selector.matchLabels 来选择与之关联的 Pod。

        在 Kubernetes 中,Service 的 selector 字段用于选择与之关联的 Pod。selector 字段包含一个标签键值对的 map,其中定义了 Service 要选择哪些标签的 Pod 与之关联。而 Pod 的 metadata.labels 字段是用来标识 Pod 的特性和属性的标签。

        当 Service 创建或更新时,它会根据 spec.selector.matchLabels 字段的标签键值对来选择与之匹配的 Pod。Pod 的 metadata.labels 字段中的标签不会影响这个选择过程。文章来源地址https://www.toymoban.com/news/detail-433538.html

到了这里,关于K8s 生产环境问题汇总及解决方案(持续更新 ing)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • k8s问题汇总

    本文章为记录使用k8s遇到的问题和解决方法, 文章持续更新中... curl: (7) Failed connect to test.com:8080; Connection refused error execution phase kubelet-start: error uploading crisocket: Unauthorized To see the stack trace 网页提示信息Client sent an HTTP request to an HTTPS server. 原因: 因为直接使用ip:端口的方式是

    2024年02月12日
    浏览(92)
  • Spring Cloud 使用 k8s 作为注册中心 开发环境 和 生产环境

    因为 k8s 本身就有拥有注册中心,和配置中心的功能。如果还是用 Nacos、Eureka、Consul 之类的注册中心组件,就有点冗余了。当然这些组件还是可以继续用的。 所以,本教程,教授 Spring Cloud 使用 k8s 的注册中心。在开发环境和生产环境 的教程! 下面以一个最简单的 服务消费

    2024年02月15日
    浏览(61)
  • k8s 集群 搭建过程问题汇总

    1. 为k8s集群添加内网域名 修改core-dns 的configmap ,添加hosts 2. 修改apiserver server端口号,支持NodePort 指向80 修改master 节点 vim /etc/kubernetes/manifests/kube-apiserver.yaml - --service-node-port-range=1-65535 然后记得重启  (此处我是kubeadmin 安装的k8s 集群) 删除pod 完后,会自动重启

    2024年02月14日
    浏览(46)
  • 记一次Redisson连接k8s环境Redis报UnknownHostException-域名解析错误问题解决

    一直听说Redisson分布式锁好用,终于在项目上使用了!在本地测试完毕,一上测试环境,运维就反馈服务没起来,拉日志一看,是以下报错 主要报错信息是 于是乎,上github看了一下,发现这还是一个比较热门dns解析失败的问题,好多人都遇到了同样的问题。想着开源项目,这

    2024年02月04日
    浏览(48)
  • 使用kubeadm搭建生产环境的多master节点k8s高可用集群

    环境centos 7.9 目录  1.对安装 k8s 的节点进行初始化配置 2 通过 keepalived+nginx 实现 k8s apiserver 节点高可用 3、kubeadm 初始化 k8s 集群 4.扩容 k8s 控制节点,把 xuegod62 加入到 k8s 集群 5、扩容 k8s 控制节点,把 xuegod64 加入到 k8s 集群 6、扩容 k8s 集群-添加第一个工作节点  7、安装 ku

    2024年02月16日
    浏览(49)
  • T1级,生产环境事故—Shell脚本一键备份K8s的YAML文件

    大家好,我叫 秋意零 。 最近对公司进行日常运维工作时,出现了一个 T1 级别事故 。导致公司的“酒云网”APP的无法使用。我和我领导一起搞了一个多小时, 业务也停了一个多小时 。 起因是:我的部门直系领导,叫我**删除一个 Deployemnt 资源(node-api-gateway)**说该资源不用

    2024年04月27日
    浏览(42)
  • 生产问题(十四)K8S抢占CPU导致数据库链接池打爆

            线上一天出现了两次数据库连接失败的大量报错,一开始以为是数据库的问题,但是想了想如果是数据库的问题,应该会有大量的应用问题         具体分析之后,发现其实是容器cpu出现了Throttled,导致大量线程阻塞         既然出现了报错,又没有发布,先

    2024年01月25日
    浏览(97)
  • K8S常见异常事件与解决方案

    Coredns容器或local-dns容器重启 集群中的coredns组件发生重启(重新创建),一般是由于coredns组件压力较大导致oom,请检查业务是否异常,是否存在应用容器无法解析域名的异常。 如果是local-dns重启,说明local-dns的性能也不够了,需要优化 Pod was OOM killed 云应用容器实例发生OOM,请

    2024年02月07日
    浏览(39)
  • 第12关 精通K8s下的Ingress-Nginx控制器:生产环境实战配置指南

    ------ 课程视频同步分享在今日头条和B站 大家好,我是博哥爱运维,这节课带来k8s的流量入口ingress,作为业务对外服务的公网入口,它的重要性不言而喻,大家一定要仔细阅读,跟着博哥的教程一步步实操去理解。 Ingress基本概念 在Kubernetes集群中,Ingress作为集群内服务对外

    2024年02月03日
    浏览(48)
  • K8s Token 过期解决方案(Kubeadm)

    Token 是 Node 节点用来连接 Master 节点的令牌字串,它和 CA 证书的 Hash 值是把一台 Node 节点加入到 K8s 集群时使用的凭证。如下图所示: 在 K8s 1.8 之后,默认生成的 Token 有效期只有 24 小时,过期后 Token 将不可用,如果想新的 Node 节点加入 K8s 集群,则需重新生成新的 Token。生

    2024年02月13日
    浏览(37)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包