前言
本文主要覆盤某次協助業務部門排查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,再訪問
總結
雖然文中輕描淡寫,但實際上排查花費了不少時間,本文就做個記錄,方便以後出現類似問題排查