如何为外部系统创建内部代理

59次阅读

问题描述

在Kubernetes的一个Deployment中有一个Web服务器，它使用ElasticCloud上的ElasticSearch实例。用户通过环境变量从Secret中参数化了容器，使用了以下格式的URL：https://elastic:***@xxx.yyy.eu-west-3.aws.elastic-cloud.com:9243。用户对以下问题感到不满意：
– 容器可以访问凭据
– 每次更改密码时都会有停机时间
用户想知道是否有一种方式可以代理ElasticCloud（添加凭据），并且如果可能的话，希望有一种机制来更新凭据。

解决方案

请注意以下操作注意版本差异及修改前做好备份。

方案1

我建议您创建一个caddy:2的Pods Deployment，并从一个Secret中挂载Caddyfile，类似于以下示例：

http://elastic-proxy.default.svc.cluster.local:9243 {
    reverse_proxy https://xxx.yyy.eu-west-3.aws.elastic-cloud.com:9243 {
        header_up Authorization "Basic Zm9vOmJhcgo="
        header_up Host {upstream_hostport}
        header_up X-Forwarded-Host {host}
    }
}

然后，在命名空间（在此示例中为default）中创建一个名为elastic-proxy的Service。将应用Pods指向此服务而不是Elastic Cloud。

解释：
这将创建一个Caddy 2服务器，将来自端口9243的所有请求反向代理到虚拟主机elastic-proxy.default.svc.cluster.local，并添加一个带有基本身份验证凭据（这里是foo:bar）的Authorization头。您可以使用base64命令创建密码，如下所示：

$ echo 'elastic:password' | base64

每次更改密码时（为什么要更改密码？），只需修改Secret中的Caddyfile即可。

方案2

使用脚本或工具来管理代理可能会增加复杂性，并且需要确保代理的安全性。
另一种方法是编写脚本或使用工具来控制代理的行为。您可以使用nginx或HAProxy等工具来创建一个代理服务器，然后在代理服务器上配置身份验证和其他必要的设置。这样，您可以将所有对Elastic Cloud的请求都发送到代理服务器，而不是直接发送到Elastic Cloud。这样，您可以在代理服务器上轻松地更新凭据。

请注意，使用脚本或工具来管理代理可能会增加复杂性，并且需要确保代理的安全性。您还需要确保代理服务器的可用性和性能。

以上是两种解决方案，您可以根据自己的需求选择适合您的方式。希望对您有所帮助！

正文完