问题描述
在使用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之间的依赖关系设置正确。