gitlab runner 无法使用S3缓存
gitlab runner 的pod info 的环境变量如下
Environment:
CI_SERVER_URL: ****
CLONE_URL:
RUNNER_EXECUTOR: kubernetes
REGISTER_LOCKED: false
RUNNER_TAG_LIST: k8s-runner
RUNNER_OUTPUT_LIMIT: 4096
KUBERNETES_IMAGE: *****
KUBERNETES_PRIVILEGED: true
KUBERNETES_POLL_TIMEOUT: 180
KUBERNETES_HELPER_IMAGE: ****
KUBERNETES_PULL_POLICY: always
CACHE_TYPE: s3
CACHE_PATH: runner
CACHE_SHARED: true
CACHE_S3_SERVER_ADDRESS: 192.168.30.25:20004
CACHE_S3_BUCKET_NAME: gitlab-runner
CACHE_S3_BUCKET_LOCATION:
CACHE_S3_INSECURE: true
但是在实际运行过程中报错：
ERROR: error while generating S3 pre-signed URL error=Get "http://169.254.169.254/latest/meta-data/iam/security-credentials/%22: dial tcp 169.254.169.254:80: i/o timeout
为什么这里会去请求http://169.254.169.254/ 而不是 http://192.168.30.25:20004/.
如何配置缓存才能够生效
“Devil组”引证GPT后的撰写：
为了配置 S3 缓存，请按照以下步骤进行操作：
首先，请确保在 Kubernetes 集群中正确配置了 kubectl 工具，并使用它来检查当前正在运行的 GitLab Runner pod 的详细信息：
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
gitlab-runner-5f59f4c4-h4z4f 1/1 Running 0 1d
然后，请获取 GitLab Runner pod 的详细信息，以查看其环境变量和配置文件：
$ kubectl describe pod gitlab-runner-5f59f4c4-h4z4f
确保在环境变量中设置了正确的 S3 缓存配置，例如 CACHE_S3_SERVER_ADDRESS、CACHE_S3_BUCKET_NAME 等。
检查网络策略是否正确，以确保可以访问 S3。您可以使用以下命令检查当前网络策略：
$ kubectl get networkpolicy
如果没有正确配置网络策略，请使用 kubectl 工具创建一个新的网络策略。
例如，以下是一个允许从 GitLab Runner pod 访问指定的 S3 存储桶的网络策略示例：
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: s3-access
spec:
podSelector:
matchLabels:
app: gitlab-runner
ingress:
- from:
- podSelector:
matchLabels:
app: s3
ports:
- protocol: TCP
port: 80
允许来自标记为 app: s3 的 pod 的 TCP 流量访问端口 80。
可以将此示例网络策略保存到名为 s3-access.yaml 的文件中，并使用以下命令在 Kubernetes 集群中创建它：
$ kubectl apply -f s3-access.yaml
确保在这个示例中，app: gitlab-runner 标签与 GitLab Runner pod 的 metadata.labels 属性匹配。
通过以上步骤检查和更新配置，应该可以成功使用 S3 缓存来加速 GitLab Runner 的构建和部署过程。
参考GPT和自己的思路，根据你提供的信息，可能是因为 runner 在 Kubernetes 集群中运行，但是在 pod 中获取不到 S3 的地址，从而导致了这个错误。
解决这个问题的方法有两种：
1 将 CACHE_S3_SERVER_ADDRESS 改为 S3 的公网地址，例如 s3.amazonaws.com，这样可以让 runner 直接访问公网上的 S3 存储，而不需要访问集群内部的网络。
2 配置 pod 的 dnsPolicy 为 ClusterFirst，这样可以让 pod 优先使用 Kubernetes 集群内部的 DNS 服务器，从而正确解析 S3 的地址。
你可以尝试按照下面的方式修改 runner 的配置文件：
1 编辑 config.toml 文件，找到 [runners.cache] 部分，修改为以下内容：
[runners.cache]
Type = "s3"
Path = "runner"
Shared = true
[runners.cache.s3]
ServerAddress = "s3.amazonaws.com"
BucketName = "gitlab-runner"
BucketLocation = ""
Insecure = true
2 修改 Kubernetes 的 YAML 文件，找到 spec.containers.env 部分，添加 dnsPolicy: ClusterFirst：
spec:
containers:
- name: gitlab-runner
image: gitlab/gitlab-runner
env:
- name: CACHE_TYPE
value: s3
- name: CACHE_PATH
value: runner
- name: CACHE_SHARED
value: "true"
- name: CACHE_S3_SERVER_ADDRESS
value: s3.amazonaws.com
- name: CACHE_S3_BUCKET_NAME
value: gitlab-runner
- name: CACHE_S3_BUCKET_LOCATION
value: ""
- name: CACHE_S3_INSECURE
value: "true"
dnsPolicy: ClusterFirst
注意，如果你选择了第一种方法，可能需要修改 S3 存储的访问控制策略，以允许 GitLab Runner 访问该存储。
参考GPT的回答内容，这个错误看起来像是 S3 缓存插件在获取 S3 凭证（credentials）时出现了问题，它似乎正在尝试从 EC2 实例元数据服务（metadata service）中获取凭证，而不是从你提供的 S3 服务器地址中获取。
可能的原因是缓存插件没有正确配置 S3 凭证，或者缓存插件与 Kubernetes 集群中的 Pod 相互作用时发生了问题。
以下是一些可能的解决方案：
1.确认缓存插件的 S3 凭证是否正确
您可以通过检查 cache.s3.accesskey 和 cache.s3.secretkey 配置项，确保您正确地配置了 S3 凭证。如果缓存插件正在使用 AWS S3，请确保您提供的凭证拥有足够的权限来执行 S3 操作。
2.检查缓存插件是否与 Kubernetes 集群中的 Pod 相互作用
如果缓存插件无法访问 Kubernetes 集群中的其他 Pod，那么它将无法获取正确的 S3 凭证。您可以使用 kubectl exec 命令进入 Pod 中，然后尝试使用 curl 命令访问您的 S3 服务器地址，以确保 Pod 能够访问该地址。
3.检查 Kubernetes 服务配置是否正确
如果您的 S3 服务器位于 Kubernetes 集群之外，则需要使用 Kubernetes 服务来公开 S3 服务器。您可以使用 kubectl get svc 命令检查服务是否正确配置。
如果您的 S3 服务器位于 Kubernetes 集群之内，则需要检查服务是否正确配置，并确保缓存插件使用正确的服务名称和端口。
4.联系 GitLab Runner 社区
如果以上步骤都没有解决问题，则可能需要联系 GitLab Runner 社区，以获取更多支持。
希望这些提示对您有帮助！
以下答案由GPT-3.5大模型与博主波罗歌共同编写：
根据错误日志信息推测，可能是因为 runner 在获取 S3 pre-signed URL 时，发现自己没有 IAM 角色，导致去尝试从 AWS metadata endpoint 获取临时 IAM 凭证（详见 AWS EC2 IAM Roles 文档 https://d/
如果您在使用GitLab Runner时无法使用S3缓存，可能是由于以下原因引起的：
配置文件错误：在配置Runner时，您需要在.gitlab-ci.yml文件中配置S3缓存相关的参数，例如AWS的Access Key ID、Secret Access Key、S3 bucket名称等。如果这些参数配置错误，将导致S3缓存无法正常工作。
S3访问权限问题：您需要确认GitLab Runner服务器是否具有访问S3存储桶的权限，如果缺少权限，将导致无法上传或者下载缓存文件。
网络连接问题：在使用S3缓存时，需要保证网络连接正常，否则将无法正常访问S3存储桶，导致缓存无法上传或者下载。
针对以上问题，您可以按照以下步骤进行排查和解决：
确认S3缓存配置文件中的参数是否正确，例如AWS的Access Key ID、Secret Access Key、S3 bucket名称等。
确认GitLab Runner服务器是否具有访问S3存储桶的权限，您可以检查相关权限配置，例如AWS IAM Policy等。
确认网络连接是否正常，您可以检查网络连接状态，例如Ping S3存储桶的地址、使用curl测试网络连接等。
如果以上方法无法解决问题，建议您联系GitLab官方技术支持，获取更进一步的帮助。
这个问题可能是由于缺少正确的网络配置信息导致的。在Kubernetes的Pod中，169.254.169.254是一个特殊的IP地址，用于访问AWS EC2实例元数据服务。因此，如果您没有正确配置Pod的网络，您的请求可能会被重定向到此地址。
为了解决这个问题，您可以尝试以下步骤：
检查Kubernetes中的网络配置是否正确，包括Pod的网络。
确保您正确配置了S3缓存的地址和端口，以及正确的密钥和访问ID。
如果您使用的是代理，请确保正确配置代理，特别是如果您使用的是默认代理设置。
最后，您可能需要联系您的IT管理员或Kubernetes支持团队以获取更多帮助。
希望这能帮助您解决问题！
经过仔细排查，重试，发现gitlab-runner-0.50.1 版本的S3配置实例不正确，重新按照官网的配置重新处理了一次。配置由
cache:
## General settings
cacheType: s3
## s3 启动时加载共享目录的根目录
cachePath: "runner"
cacheShared: true
## S3 settings
s3ServerAddress: 192.168.30.25:20004
# 缓存到哪个目录,需指定 因接口的请求方式 是 http://xxxxxx/cachePath/s3BucketName/后面的目录随机生成
s3BucketName: gitlab-runner
s3BucketLocation:
s3CacheInsecure: true
s3secretName: s3accessgitlabrunner1
改为
config: |
[[runners]]
[runners.cache]
Type = "s3"
Path = "runner"
Shared = true
[runners.cache.s3]
ServerAddress = "192.168.30.25:20004"
BucketName = "gitlab-runner"
BucketLocation =""
Insecure = true
AuthenticationType = "access-key"
问题最终解决