记一次通过K8S ingress访问业务服务出现404问题
前言
本文主要复盘某次协助业务部门排查ingress访问业务报404问题
案例模拟复现
业务部门ingress配置了https，访问出现
因为业务部门的CA证书是买的，理论是不应该出现红色三角形图标。于是查看证书
发现证书不是业务部门配置的那个。他们的配置tls密文形如下
apiVersion: v1
data:
tls.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUdEakNDQkhhZ0F3SUJBZ0lSQU13Y省略。。。。
tls.key: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBcG15Y
省略。。。。
kind: Secret
metadata:
annotations:
field.cattle.io/description: '*.lybgeek.com 泛域名证书'
name: tls.lybgeek.com
namespace: test
type: kubernetes.io/tls
ingress rule配置形如下
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: demo-ingress
namespace: lybgeek
spec:
rules:
- host: demo.lybgeek.com
http:
paths:
- backend:
service:
name: demo-service
port:
number: 80
path: /
pathType: Prefix
tls:
- hosts:
- demo.lybgeek.com
secretName: tls.lybgeek.com
眼尖的朋友估计一眼就可以看出端倪，tls密文配置和ingress配置的namespace不一样。于是我们这边就将tls的namespace也改成lybgeek。本以为问题应该可以解决。访问发后，发现仍然是404，仍然是红色三角形图标屹立不倒。
于是产生了一个猜测，有没有可能域名绑定的 ip不是我们配置的ingress node ip，问业务方，他说很肯定说，域名绑定就是配置的ingress node ip，那就非常诡异了。后面通过查看ingress容器中的nginx.conf,发现那个配置并没写入形如下内容
server {
server_name demo.lybgeek.com ;
listen 80 ;
listen 443 ssl http2 ;
set $proxy_upstream_name "-";
ssl_certificate_by_lua_block {
certificate.call()
}
location / {
set $namespace "lybgeek";
set $ingress_name "demo-ingress";
set $service_name "demo-service";
set $service_port "80";
set $location_path "/";
set $global_rate_limit_exceeding n;
rewrite_by_lua_block {
lua_ingress.rewrite({
force_ssl_redirect = false,
ssl_redirect = false,
force_no_ssl_redirect = false,
preserve_trailing_slash = false,
use_port_in_redirects = false,
global_throttle = { namespace = "", limit = 0, window_size = 0, key = { }, ignored_cidrs = { } },
})
balancer.rewrite()
plugins.run()
}
header_filter_by_lua_block {
lua_ingress.header()
plugins.run()
}
body_filter_by_lua_block {
plugins.run()
}
port_in_redirect off;
set $balancer_ewma_score -1;
set $proxy_upstream_name "demo-service-80";
set $proxy_host $proxy_upstream_name;
set $pass_access_scheme $scheme;
set $pass_server_port $server_port;
set $best_http_host $http_host;
set $pass_port $pass_server_port;
set $proxy_alternative_upstream_name "";
}
从这基本上有大概率可以说明，域名绑定的ip并不是ingress node ip。但我们还是要以事实作为依据。后面通过ping域名，发现域名绑定的端口确实不是ingress node ip。
解决方案
将域名映射的ip改为ingress node ip，再访问
总结
虽然文中轻描淡写，但实际上排查花费了不少时间，本文就做个记录，方便以后出现类似问题排查