K3s集群跨命名空间访问私有镜像仓库的全局配置问询

针对你遇到的自定义命名空间拉取GitLab私有镜像报403、且希望避免手动重复创建Secret/ServiceAccount的需求，以下几种方案可实现全局化配置：

方案1：修改集群默认ServiceAccount（通用Kubernetes方案） #

Kubernetes每个命名空间默认存在default ServiceAccount，未指定SA的Pod会自动使用它。我们可以批量给现有命名空间的default SA添加镜像拉取Secret，并通过准入控制器自动为新命名空间完成配置。

步骤1：创建通用镜像拉取Secret #

在kube-system命名空间创建可复用的凭证Secret：

kubectl create secret docker-registry gitlab-registry-secret \
    --docker-server=<你的GitLab镜像仓库域名> \
    --docker-username=<GitLab用户名> \
    --docker-password=<GitLab访问令牌（需含read_registry权限）> \
    --docker-email=<关联邮箱> \
    -n kube-system

步骤2：批量更新现有命名空间的default SA #

用脚本一次性给所有已存在的命名空间的default SA添加镜像拉取Secret：

for ns in $(kubectl get namespaces -o jsonpath='{.items[*].metadata.name}'); do
  kubectl patch serviceaccount default -n $ns -p '{"imagePullSecrets": [{"name": "gitlab-registry-secret"}]}'
done

步骤3：自动为新命名空间配置default SA #

使用轻量政策引擎Kyverno实现自动配置：

1. 安装Kyverno（K3s环境可通过Helm快速部署）
2. 创建ClusterPolicy，自动为新命名空间的default SA添加凭证：

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-imagepullsecret-to-default-sa
spec:
  rules:
  - name: inject-imagepullsecret
    match:
      any:
      - resources:
          kinds:
          - Namespace
    mutate:
      targets:
        - apiVersion: v1
          kind: ServiceAccount
          name: default
          namespace: "{{request.object.metadata.name}}"
      patchStrategicMerge:
        imagePullSecrets:
        - name: gitlab-registry-secret

方案2：K3s专属全局镜像仓库配置（最简洁） #

K3s支持通过registries.yaml直接配置containerd的镜像仓库认证，无需在Kubernetes层面管理Secret，所有节点会自动使用该凭证拉取镜像。

步骤1：创建registries配置文件 #

在K3s服务器节点的/etc/rancher/k3s/目录下创建registries.yaml：

mirrors:
  <你的GitLab镜像仓库域名>:
    endpoint:
      - "https://<你的GitLab镜像仓库完整地址>"
configs:
  <你的GitLab镜像仓库域名>:
    auth:
      username: <GitLab用户名>
      password: <GitLab访问令牌>

步骤2：重启K3s服务生效 #

systemctl restart k3s

重启后，所有命名空间的Pod无需额外配置即可拉取指定私有镜像。

方案3：Namespace模板自动同步资源（GitOps场景适用） #

若需每个命名空间有独立的资源配置，可通过GitOps工具（如Argo CD）或Namespace模板，在创建命名空间时自动同步Secret、ServiceAccount等资源。但此方案需维护模板配置，复杂度高于前两种，仅推荐在有特定隔离需求时使用。

关键注意事项 #

• 方案2为K3s原生优化方案，无需管理Kubernetes层面资源，优先推荐使用
• GitLab访问令牌需确保拥有read_registry权限，否则仍会出现403错误
• 方案1中的Secret需确保所有命名空间的default SA有权限引用（默认权限即可满足）

内容的提问来源于stack exchange，提问作者Duarte