머리말
이 기사는 주로 비즈니스 부서가 인그레스 액세스 비즈니스 보고서의 404 문제를 해결하는 데 도움이 되는 특정 시간을 검토합니다.
사례 시뮬레이션 반복
사업부 인그레스를 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
수신 규칙 구성은 다음과 같습니다.
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 암호문 구성과 인그레스 구성의 네임스페이스가 다르기 때문에 한눈에 단서를 볼 수 있을 것입니다. 그래서 우리는 tls의 네임스페이스를 lybgeek로 변경했습니다. 문제가 해결되어야 한다고 생각했습니다. 방문 후 여전히 404이고 빨간색 삼각형 아이콘이 여전히 서 있음을 알았습니다.
그래서 도메인 이름에 바인딩된 ip가 우리가 구성한 인그레스 노드 ip가 아닐 가능성이 있는지 추측이 있었고 비즈니스 측에 물었습니다. 그는 도메인 이름 바인딩이 구성된 인그레스 노드 ip라고 확실하게 말했습니다. 아주 이상한. 나중에 인그레스 컨테이너에서 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는 인그레스 노드 ip가 아닐 확률이 높습니다. 그러나 우리는 여전히 사실에 의존해야 합니다. 나중에 도메인 이름을 ping하면 도메인 이름에 바인딩된 포트가 실제로 수신 노드 ip가 아님을 알 수 있습니다.
해결책
도메인 이름 매핑의 IP를 수신 노드 IP로 변경한 다음 방문하십시오.
요약하다
이 기사는 절제된 표현이지만 실제로 문제를 해결하는 데 많은 시간이 걸렸습니다. 이 기사는 향후 유사한 문제를 쉽게 해결할 수 있도록 기록을 남길 것입니다.