📚 课程目录第2章 OpenShift GitOps Operator安装与初始化

2. OpenShift GitOps Operator安装与初始化

在 OpenShift 上落地 GitOps，第一步不是急着写 Application，而是把“控制平面”装好、把边界划清、把入口打通。OpenShift GitOps Operator 负责在集群中安装并托管 Argo CD 及其配套组件，它把 Argo CD 从“一个需要手工维护的部署”变成“由 Operator 管理的受管实例”。本节围绕四件事展开：Operator 订阅、Argo CD 实例创建、命名空间规划、初始访问配置。

一、Operator 订阅：从 OperatorHub 到受管实例

OpenShift GitOps Operator 通过 OLM（Operator Lifecycle Manager）安装。OLM 的核心对象是 Subscription，它声明“我要订阅哪个包、走哪个通道、由谁批准升级”。安装前先确认集群可用的包与通道：

oc get packagemanifest openshift-gitops-operator \
  -n openshift-marketplace \
  -o jsonpath='{.status.channels[*].name}'
# 示例输出：stable gitops-1.11 gitops-1.12

通道决定版本节奏：stable 跟随稳定版，gitops-1.x 锁定次版本，适合需要可预测升级窗口的生产集群。随后创建命名空间与订阅。Operator 通常安装在 openshift-gitops-operator 命名空间：

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-gitops-operator
  namespace: openshift-gitops-operator
spec:
  upgradeStrategy: Default
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-gitops-operator
  namespace: openshift-gitops-operator
spec:
  channel: stable
  installPlanApproval: Automatic
  name: openshift-gitops-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace

关键参数有三个：channel 决定版本线；installPlanApproval 为 Automatic 时补丁与次版本自动升级，为 Manual 时需人工批准 InstallPlan，生产环境常选后者以控制变更窗口；source 指向目录源，离线环境需替换为镜像目录源。订阅创建后，用 oc get csv -n openshift-gitops-operator 观察 CSV 是否进入 Succeeded，这是 Operator 就绪的判据。

二、Argo CD 实例创建：默认实例与自定义实例

Operator 就绪后，它会自动在 openshift-gitops 命名空间创建一个名为 openshift-gitops 的默认 Argo CD 实例，并附带路由、RBAC 与集群级权限。这个默认实例适合快速体验，但生产环境通常需要自定义实例，以便控制资源规格、高可用、SSO 与权限边界。自定义实例通过 ArgoCD CR 声明：

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: gitops-prod
  namespace: gitops-prod
spec:
  server:
    route:
      enabled: true
    replicas: 2
  repo:
    replicas: 2
  ha:
    enabled: true
  rbac:
    defaultPolicy: 'role:readonly'
    policy: |
      g, gitops-admins, role:admin
    scopes: '[groups]'
  sso:
    provider: dex
    dex:
      openShiftOAuth: true

这里 server.replicas 与 repo.replicas 控制 API Server 与仓库服务的副本数，ha.enabled 启用 Redis HA；rbac.defaultPolicy 设为只读，避免匿名用户获得写权限；sso 段把 Argo CD 登录接入 OpenShift OAuth，用户直接用集群身份登录，无需另建账号。创建后观察 Pod 就绪：

oc get pods -n gitops-prod
# gitops-prod-server-xxx        2/2  Running
# gitops-prod-repo-server-xxx   1/1  Running
# gitops-prod-redis-ha-server-0 2/2  Running
# gitops-prod-application-controller-0 1/1 Running

若 server 长期处于 Pending，优先检查 PVC 与节点资源；若 repo-server 反复重启，检查其内存限制是否过小。

三、命名空间规划：控制平面与工作负载分离

命名空间规划的核心原则是“控制平面与工作负载分离”。建议至少划分三类命名空间：

openshift-gitops-operator：仅放 Operator 订阅与 CSV，不部署业务。
gitops-prod / gitops-dev：放 Argo CD 实例本身，按环境隔离，避免一套 Argo CD 同时管理生产与开发导致权限过大。
app-*：业务工作负载命名空间，由 Argo CD 通过 Application 部署，Argo CD 实例不直接运行这些负载。

此外，Argo CD 需要跨命名空间部署资源，因此要明确它的“可管理范围”。默认实例拥有集群级权限，可管理所有命名空间；自定义实例可通过 spec.sourceNamespaces 限制 Application 只能引用指定命名空间中的仓库凭据，通过 spec.rbac 限制用户可操作的项目。规划时先画清“谁管谁”，再决定权限粒度。

四、初始访问配置：路由、SSO 与初始凭据

实例就绪后，先取访问地址：

oc get route gitops-prod-server -n gitops-prod \
  -o jsonpath='{.spec.host}'
# 示例：gitops-prod-server-gitops-prod.apps.example.com

若未启用 SSO，Argo CD 会生成初始 admin 密码，存放在 Secret 中：

oc get secret gitops-prod-cluster -n gitops-prod \
  -o jsonpath='{.data.admin\.password}' | base64 -d

生产环境不建议长期使用 admin 本地账号，应启用 SSO 并把 rbac.defaultPolicy 设为只读，再通过 g, <group>, role:admin 把 OpenShift 组映射为 Argo CD 管理员。登录后第一件事是确认“谁能看到什么”：用只读账号访问，应只能查看 Application 与资源状态，不能 Sync 或删除。若发现匿名可写，说明 defaultPolicy 未生效或 RBAC ConfigMap 未同步，需检查 argocd-rbac-cm 是否被 Operator 覆盖。

初始化完成的判据：Operator CSV 为 Succeeded；Argo CD 各 Pod 全部 Running；Route 可访问且 SSO 登录成功；只读账号无法执行 Sync。四项同时满足，才进入后续的仓库接入与 Application 编排。

最后提醒一个常见误区：不要用默认的 openshift-gitops 实例直接管理生产。默认实例权限大、配置少，适合验证；生产应创建独立实例，明确命名空间、副本数、RBAC 与 SSO，再接入仓库。这样后续做多环境、多租户时，边界已经清晰，不会因为“一开始图省事”而反复返工。