当前位置: 首页 > 知识库问答 >
问题:

nginx代理不能传递给kubernetes中的kibana吗

孙永嘉
2023-03-14

我正在尝试使用nginx代理传递到使用基本身份验证的Kibanapod。

用于测试(这是另一个k8s集群,但非常相似,使用相同的命名空间,kube dns,POD内的env匹配,并且它们彼此看到)上下文:我通过AWS中k8s的helm部署了这个,nginx有一个Kubernetes LB服务类型(基本上是AWS的ELB,其cname位于route53)。

如果我将nginx pod指向kibana-app.kube-system.svc.cluster。本地:5601我在kibana pod上看到来自nginx的请求,但在尝试转到服务器时返回404。基本路径:/api/v1/proxy/namespaces/kube system/services/kibana app/

我可以通过从“kubectl colum-info”获取url然后检查日志来访问kibana-app pod,请求如下所示:

"method":"get","statusCode":200,"req":{"url":"/app/kibana"
"x-forwarded-uri":"/api/v1/proxy/namespaces/kube-system/services/kibana-logging/app/kibana

在尝试从nginx访问Kibana路径时找不到问题所在(在完成基本身份验证后)

    server {
    listen       80;
    server_name  localhost;

    access_log  /var/log/nginx/host.access.log;

    location / {
        auth_basic "simple auth";
        auth_basic_user_file /var/kibana_config/htpasswd;
        try_files KIBANA @kibana-app;
    }

    location @kibanaapp {
        return 301 http://kiban-app-url-from-route53/server.basePath;
    }

    location /api {
            proxy_pass https://api.awszone.mydomain/api;
        proxy_set_header Authorization "Basic ";
    }
}

还尝试移动proxy\u pass语句,删除返回值,只从kibana的pod正在侦听的位置执行proxy\u pass,但要么不起作用,请求从未到达pod,要么当请求到达kibana app pod时,返回404。

有什么想法吗?

谢谢

更新:

我就快到了,现在我可以看到“kibana正在加载屏幕”,但从来没有完成加载捆绑包、json和其他东西,nginx pod log:

GET /api/v1/proxy/namespaces/库贝-system/服务/kibana-日志记录/捆绑包/commons.style.css

在kibana pod返回404时的相同请求:

“statusCode”:404,“req”:{“url”:/app/kibana/v1/proxy/namespace/kube system/services/kibana logging/bundles/commons.bundle.js?v=10146,“method”:“get”,“headers”:{“host”:“kibana.app.env.com”,“referer”:”http://kibana.app.env.com/api“referer”:http://kibana.app.env.com/api“},“res”:{“statusCode”:404,“responseTime”:2,“contentLength”:9},“message”:“GET/app/kibana/v1/proxy/namespace/kube system/services/kibana logging/bundles/commons.bundle.js?v=10146

我的nginx配置

server {
    listen 80;
    server_name localhost;
    access_log  /var/log/nginx/host.access.log;

    location / {
        auth_basic "simple auth";
        auth_basic_user_file /var/kibana_config/htpasswd;
        try_files KIBANA @kibana-app;
    }

    location @kibana-app {
        return 301 kibana.app.env.com/server.basePath;
    }

    location /api {
        proxy_pass http://kibana-logging.kube-system.svc.cluster.local:5601;
        proxy_set_header HOST $host;
        proxy_set_header Referer $http_referer;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Authorization "simple auth ";
    }

}

“kibana.app.env.com”这只是kubernetes在route53上创建的FQDN,作为到达nginx/kibana pod所在节点的ELB的CNAME。这是我在浏览器上使用的url,它应该到达nginx,询问我基本授权,然后带我去kibana pod和服务器。basePath:/api/v1/proxy/namespace/kube system/services/kibana logging如果我不清楚,请问我一些问题,很抱歉我不能复制/粘贴所有内容。

共有2个答案

华俊贤
2023-03-14

最后,它起作用了:

    server {
        listen 80;
        server_name localhost;
        access_log  /var/log/nginx/host.access.log;

        location / {
            auth_basic "simple auth";
            auth_basic_user_file /var/kibana_config/htpasswd;
            try_files KIBANA @kibana-app;
        }

        location @kibana-app {
            return 301 /api/v1/proxy/namespaces/kube-system/services/kibana-logging/;
        }

        location /api/v1/proxy/namespaces/kube-system/services/kibana-logging/ {
            proxy_set_header Authorization "simple auth ";
            proxy_pass http://kibana-logging.kube-system.svc.cluster.local:5601/;
            proxy_set_header HOST $host;
            proxy_set_header Referer $http_referer;
            proxy_set_header X-Forwarded-For $remote_addr;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection 'upgrade';
            proxy_cache_bypass $http_upgrade;
        }
}

转到K8s在AWS上创建的URL作为ELB(kibana-app.env.com)重定向到 /api/v1/proxy/namespaces/库贝-system/service/kibana日志记录/proxy_passkibana pod:http://kibana-logging.kube-system.svc.cluster.local:5601

陈业
2023-03-14

不确定这在另一个集群上是如何工作的。因此,您提到的基本路径:/api/v1/proxy/namespace/kube system/services/kibana app/看起来像kube-apiserver基本路径,这是使用kubectl-proxy的代理设置与集群中的应用程序和服务对话的路径。

如果你真的想在集群内从nginx到Kibana对话,你必须添加Kibana-app.kube-system.svc.cluster。本地:5601。

 类似资料:
  • 问题内容: 我的nginx服务器实际上是使用以下简单的代理来代理节点后端(侦听端口3000): 其中上游_1是我在nginx.conf中定义的节点群集(在端口3000上)。 我将不得不通过http连接添加SSL,所以我有以下问题:我是否只需要配置nginx来启用ssl?并且它将自动“解密”请求并将未解密的请求传递给能够正常处理的Node?还是我需要将Nodejs配置为也支持ssl? 问题答案: 如

  • 我有一个通过uwsgi运行的小型python应用程序,其中的请求由nginx提供。 我正在打印环境变量。。。看起来在两个ok请求之后,nginx正在为不相关的请求发送相同的HTTP_COOKIE参数: 例如: {'UWSGI_CHDIR':'/ebs/py','HTTP_COOKIE':'ge_t_c=4fcee8450c3bee709800920c','UWSGI_SCRIPT':'服务器','

  • 我要做的是,当用户访问时,应该将他们代理到运行在端口80上的apache。 当我访问时,我会得到正确的结果(index.php)。当我访问时,我会得到正确的结果(404来自apache)。当我访问时,我会得到正确的结果(404来自nginx)。当我访问时,我会得到正确的结果(404来自apache)。 问题是当我访问时。我得到一个301响应,并被重定向到(注意后面的斜杠,当然还有'localhos

  • 我的a域是在CloudFlare的免费工具后面管理的。我想添加一个名为“test”的子域,但我希望它指向在我的服务器端口8183上运行的第二个webserver。在Cloudflare DNS portal中,我有一个“test.example.com”的A记录,它指向我的WebServer的IP地址,该地址也被代理以隐藏我的WebServer的实际IP地址。所有流量都通过HTTPS路由,证书也由

  • 当我尝试在注册期间保存用户对象时,我得到以下错误 用户服务 用户控制器: JSP: 错误,然后添加用户:

  • 我正在尝试运行一个带有env变量的docker映像。 但是它对我来说不管是使用env.list文件还是命令行都不起作用。