1. DockerHub 限制 终究还是绕不过下面这个报错: 1 Error response from daemon: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit DockerHub 从 2020 年 11 月 2 日，正式开始限制非付费用户的拉取频率: 匿名用户，每 6 小时只允许 pull 100 次 已登录用户，每 6 小时只允许 pull 200 次 好吧，正常情况下，到这里就友尽了，不让用就不

1. 什么是 GitHub Actions 在前面的文档中，我对 GitLab 提供的 CI 功能进行了实践，点击查看 。使用 GitLab 的好处是可以私有化部署、无限的私有仓库数量、CI 配置简单、能接入自建的 Runner 。但随着 GitHub 越来越开放，GitLab 的这些优势在逐步丧失。 从 CICD 的角度看，越接近 Git 仓库的功能，越贴

1. 典型适用场景 在 CI 中，通常会有一个 CI Engine 负责解析流程，控制整个构建过程，而将真正的构建交给 Agent 去完成。例如，Jenkins 、GitLab 均是如此。 如下图, 连接 CI Engine 的 Agent, 种类很多。这是为了满足不同项目对构建环境的要求。 同时 Agent 是动态的，构建时才需要，

Kubernetes 依靠 kube-proxy 组件实现 Service 的通信与负载均衡。在这个过程中，由于使用了 SNAT 对源地址进行了转换，导致 Pod 中的服务拿不到真实的客户端 IP 地址信息。本篇主要解答了在 Kubernetes 集群中负载如何获取客户端真实 IP 地址这个问题。 1. 创建一个后端服务 1.1 服务选择 这里选择 containous/whoami 作为后端服务镜