问题描述
在使用Rancher v2.6.3中的Kubernetes集群,并且部署了一个基于AWS的Django工作负载。他在集群中设置了一个集群IP端口,并创建了一个带有前缀规则的Ingress,指向他的Deployment。他还使用了nginx-ingress的Helm Chart,并在服务上添加了一些Annotations。尽管HTTP可以正常工作,但当尝试使用SSL访问站点时,出现了”The plain HTTP request was sent to HTTPS port”的400 Bad Request错误。
解决方案
请注意以下操作可能存在版本差异,以及可能需要在解决问题前备份相关配置。
解决方案1
根据用户投票评选为最佳答案的回复,他通过重新安装nginx-ingress应用程序(chart)并编辑配置来解决了问题。以下是解决方案的详细步骤:
- 首先,删除已安装的nginx-ingress应用程序(chart)。
- 返回到应用市场并重新安装nginx-ingress。
- 当出现编辑配置的机会时,使用以下值编辑service块(其他保持不变):
service:
annotations:
service.beta.kubernetes.io/aws-load-balancer-ssl-cert: my-cert-arn
service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "http"
service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "https"
service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: '3600'
httpPort:
targetPort: http
httpsPort:
targetPort: http
- 保存配置,验证问题是否解决。
用户提供的链接https://github.com/kubernetes/ingress-nginx/tree/main/charts/ingress-nginx#aws-l7-elb-with-ssl-termination提供了详细的修改细节。尽管这个链接是针对ingress-nginx仓库的,但在Rancher v2.6.3中,nginx-ingress的Helm Chart使用了kubernetes-ingress,并且在目前的版本中似乎遵循了相似的结构。
解决方案2(备选方案)
这个备选方案使用了自定义的脚本来控制容器的启动顺序。如果之前的解决方案无法满足需求,可以考虑使用这个备选方案。
如果上述方案未能解决问题,你可以尝试使用自定义脚本来控制容器的启动顺序。以下是一个简单的bash脚本示例,可以在容器A启动后启动容器B:
#!/bin/bash
# 启动容器A
docker run -d --name container_a your_image_a
# 等待容器A完全启动
while ! docker exec container_a echo "Container A is ready"; do
sleep 1
done
# 启动容器B
docker run -d --name container_b your_image_b
在这个示例中,我们首先使用docker run
命令启动容器A,并将其命名为container_a
。然后,使用一个循环来等待容器A完全启动(这里是通过在容器内运行echo
命令来测试)。一旦容器A就绪,我们再使用docker run
命令启动容器B,并将其命名为container_b
。
这个方案的优势在于它可以手动控制容器的启动顺序,但也增加了一定的复杂性。确保你的容器A和容器B之间的依赖关系设置正确。