代码之家 › 专栏 › 技术社区 › Necevil

Kubernetes nginx通过301而不是308进入HTTP到HTTPS重定向?

nginx-ingress kubernetes-ingress kubernetes

1

Necevil · 技术社区 · 7 年前

我们在Azure AKS上运行几个K8S集群。服务(ghost blog)位于nginx入口的后面,并通过letsencrypt的证书进行保护。所有这些都可以正常工作,但重定向行为正是我遇到的问题。

< Buff行情>

入口正确地从 http://whatever.com to重新定向 https://whatever.com _;问题是它使用308 重定向用户在任何时候共享的所有文章/页面元从网站上翻页。

< /块引用>

该问题导致在大多数社会财产上共享网站任何页面的用户收到“预览链接”,其中页面标题和页面元预览不起作用,取而代之的是“308永久重定向”文本,如下所示:

从 ingress nginx docs over here 我可以看到这是预期的行为(即308 redirect),我认为不是预期的是与社会共享的交互。服务当这些服务尝试创建页面预览时。

虽然问题将通过默认情况下直接指向https站点的Facebook(或Twitter等)解决,但我目前没有办法强制这些站点查找将用于创建预览的内容的https。

设置永久重新定向代码

我还可以看到,看起来我应该能够将重定向代码设置为我想要的任何东西(我相信301重定向将允许Facebook等。要正确地提取post/page snippet meta), docs on that found here 。

问题是,当我按指定方式添加重定向代码注释时:

nginx.ingress.kubernetes.io/permanent-redirect-code:“301”
< /代码> 

尽管我能够(从我的kubectl代理服务器)看到重定向代码注释正确应用,但我仍然可以在我的资源上获得308个重定向。作为参考,我的入口注释的完整列表如下:

apiVersion:extensions/v1beta1
种类:入口
元数据:
姓名:幽灵入口
注释:
kubernetes.io/tls-acme:“真”
nginx.ingress.kubernetes.io/permanent-redirect-code:“301”
< /代码> 

< Buff行情>
重申一下,我的问题是:通过自定义错误代码强制重定向到HTTPS的正确方法是什么(在我的案例301中)?
< /块引用这很好,但是重定向行为是我遇到的问题。


入口正确地从http://whatever.com到
https://whatever.com__问题是使用308
重定向用户在任何时候共享的所有文章/页面元
网站的网页。


该问题导致在大多数社会财产上共享网站任何页面的用户收到“预览链接”,页面标题和页面元预览不起作用,取而代之的是“308永久重定向”文本,如下所示:



从ingress-nginx docs over here我可以看到,这是预期的行为(即308重定向),我认为这不是预期的,当这些服务试图创建页面预览时,与社会共享服务的交互。

虽然这个问题可以通过默认情况下直接指向https站点的facebook(或twitter等)来解决,但我目前没有办法强制那些站点查找用于创建预览的内容的https。

设置永久重新定向代码

我还可以看到,看起来我应该能够将重定向代码设置为我想要的任何东西(我相信301重定向将允许Facebook等。要正确地提取文章/页面片段meta),请执行以下操作:docs on that found here.

问题是,当我按规定添加重定向代码注释时:

nginx.ingress.kubernetes.io/permanent-redirect-code: "301"


尽管我能够(从我的kubectl代理服务器)看到重定向代码注释正确应用,但我仍然可以在我的资源上获得308个重定向。作为参考,我的入口注释的完整列表如下:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ghost-ingress
  annotations:
    kubernetes.io/tls-acme: "true"
    nginx.ingress.kubernetes.io/permanent-redirect-code: "301"



重申一下,我的问题是:通过自定义错误代码强制重定向到HTTPS的正确方法是什么(在我的案例301中)?

2 回复 | 直到 7 年前

1

3

Rico 7 年前

我猜是tls重定向隐藏了 nginx.ingress.kubernetes.io/permanent-redirect-code 注释。

你可以改变 ConfigMap 为了你 nginx-configuration 所以默认的重定向是301。这是您的nginx入口控制器用于nginx本身的配置。这个 组态图 如下所示:

apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
  name: nginx-configuration
  namespace: ingress-nginx
data:
  use-proxy-protocol: "true"
  http-redirect-code: "301"

你可以找到更多关于 组态图 选项 here . 请注意,如果您更改 组态图 您必须重新启动 nginx-ingress-controller 豆荚。

你也可以把壳装进 nginx入口控制器 弹出并查看控制器创建的实际nginx配置:

kubectl -n ingress-nginx exec -it nginx-ingress-controller-xxxxxxxxxx-xxxxx bash
www-data@nginx-ingress-controller-xxxxxxxxx-xxxxx:/etc/nginx$ cat /etc/nginx/nginx.conf

2

0

Necevil 7 年前

这些说明适用于Azure AKS用户,但对于Facebook/社交财产预览链接(显示为308永久重定向)的解决方案可能适用于任何云提供商(尽管尚未测试),您只需更改登录/获取凭据的方式等。

感谢Rico的解决方案!因为这只在Facebook上测试过,所以你可能会或者可能不想使用configmap应用程序路径(上面提到过),这将通过手动编辑configmap而不是使用 kubectl apply -f 应用本地保存的一个。

为您的cluser获取az证书( az login )
承担集群的角色: az aks get-credentials --resource-group yourGroup --name your-cluster
浏览群集: az aks browse --resource-group yourGroup --name your-cluster
导航到包含入口nginx容器的名称空间(不是后端服务),尽管它们可能在同一个ns中。
在左侧导航菜单(设置上方)上找到“configmaps”选项卡并单击它。
编辑yaml的“data”元素并添加以下行(注意键/值中名称和数字的引号): "data": { "some-other-setting-here": "false", "http-redirect-code": "301" } 除了最后一行之外,每个键/值行后面都需要一个逗号。
删除后重新启动nginx控制器盒确保您不会像我一样删除部署。
如果您想提高生产效率,可以升级nginx安装(从helm),该安装将通过以下方式在流程中重新启动/重新创建容器: helm upgrade ngx-ingress stable/nginx-ingress 其中,ngx entress是您的头盔安装的名称。还要注意,使用“--reuse values”标志将导致升级失败(请重新: https://github.com/helm/helm/issues/4337 )
如果您不知道您在安装时使用的Nginx名称,您可以使用 helm list 找到它。
最后,为了测试并确保您的重定向使用了正确的configmap代码,请将您的HTTP站点卷曲为: curl myhttpdomain.com 您应该收到这样的信息:

` `

<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.15.3</center>
</body>
</html>

` `

这里要注意的一件重要的事情是,如果你正在修改301,请重新直接尝试修复Facebook或其他社交媒体属性(Twitter等)的预览链接,那么很可能这不会修复任何链接到你已经链接到的任何页面/帖子,至少不会立即修复。

社交属性都使用强缓存来限制其资源使用,但您可以通过链接到以前未引用的新页面/文章来查看上面的内容是否修复了预览链接问题。

注意“post”的含义

因此,nginx entress使用代码308的主要原因是,在您发送POST请求的情况下,它会保持“body”(正文)/有效载荷不变(与使用浏览器进行的普通GET请求链接相反)。

对我来说,这不是一个问题,但是如果你出于任何原因将邮件发送到HTTP地址,并希望能够无缝地重新定向,那么在你切换到邮件中讨论的301重定向之后,这可能不起作用。

但是,如果你在发送帖子请求时没有期望一个无缝的重定向(我认为大多数人可能没有,我知道我没有),那么我认为这是修复Facebook 308永久重定向行为的最佳方法。