“

当你开始在 Kubernetes 或 OpenShift 上规模化落地 Ansible 自动化时，第一件很“上头”的事就是：如何把 AWX（Ansible Tower 的社区版）以更云原生、更可维护的方式部署和运维起来？ansible/awx-operator 正是为此而生的一把“瑞士军刀”。它用 Operator SDK + Ansible 把 AWX 的安装、升级、伸缩、网络与存储配置、备份与恢复等日常工作全部纳入 Kubernetes 的声明式管理之中，让你用一个 CR（Custom Resource）就能描述一整套 AWX 实例的期望状态，并由 Operator 持续对齐。

”

一、它能为你解决什么问题

• 一次声明，持续对齐：通过 AWX 自定义资源（AWX CR）声明目标状态，Operator 负责创建并维护 Deployment、Service、Ingress/Route、PostgreSQL 等对象，让 AWX 从“手工部署”走向“声明式运维”。
• 安装路径清晰：支持 Kustomize 一键部署，也可以配合 OperatorHub/OLM 在集群内以可视化方式安装。本文主要演示 Kustomize 路径。
• 网络与暴露灵活：同一套 CR 内即可切换 ClusterIP/NodePort/LoadBalancer，以及 Ingress 或 OpenShift Route，满足内外网、云厂商 LB、服务网格等多样化场景。
• 弹性与扩缩容：可分别为 web 与 task 组件设置副本数，也能与 HPA 共存（交由 HPA 控制副本、Operator 让权）。
• 数据可靠：内置 AWXBackup 与 AWXRestore CRD，方便把控制器与数据库状态打包到 PVC 并按需恢复。
• 数据库选型稳妥：默认随 Operator 版本匹配合适的 PostgreSQL（文档当前指向 PG15），也支持接入外部数据库。

二、5 分钟快速上手（Kustomize）

1. 克隆并切换到发布标签（重要）
   选择一个发布 tag 冻结版本，避免用浮动的 devel 分支。若你从 fork 做了修改，还需显式导出 VERSION，否则可能遇到 ImagePullBackOff。

   git clone git@github.com:ansible/awx-operator.git
   cd awx-operator
   git tag
   git checkout tags/<tag>
   
   # 如果来自 fork 且有变更，需指定 VERSION
   export VERSION=<tag>
   

2. 准备 kustomization.yaml
   官方推荐使用内置的 config/default 清单，并将镜像 tag 与所选 git tag 对齐。如果你需要自定义 operator 的资源限制等，可在该文件底部添加 patches。

   apiVersion: kustomize.config.k8s.io/v1beta1
   kind:Kustomization
   resources:
   # 最新可用标签见 releases 页面
   -github.com/ansible/awx-operator/config/default?ref=<tag>
   images:
   -name:quay.io/ansible/awx-operator
       newTag:<tag>
   
   # 指定安装命名空间
   namespace:awx
   

   应用：

   kubectl apply -k .
   # 片刻后：
   kubectl get pods -n awx
   

   你应能看到 awx-operator-controller-manager 处于 Running。

3. 声明一个最小可用的 AWX 实例
   在同一目录创建 awx-demo.yml，并将其加入 kustomization.yaml 的 resources 中：

   ---
   apiVersion: awx.ansible.com/v1beta1
   kind: AWX
   metadata:
     name: awx-demo
   spec:
     service_type: nodeport
   

   将 awx-demo.yml 写入 kustomization.yaml：

   resources:
     - github.com/ansible/awx-operator/config/default?ref=<tag>
     - awx-demo.yml
   

   部署：

   kubectl apply -k .
   kubectl get pods -l "app.kubernetes.io/managed-by=awx-operator"
   kubectl get svc  -l "app.kubernetes.io/managed-by=awx-operator"
   

   默认管理员账户为 admin，密码存放在 <name>-admin-password Secret 中：

   kubectl get secret awx-demo-admin-password \
     -o jsonpath="{.data.password}" | base64 --decode ; echo
   

   完成后即可通过 NodePort 访问 AWX Web 界面。

三、网络与入口配置最佳实践

• Service 类型三选一：ClusterIP（默认，集群内访问）、NodePort（快速暴露到宿主机端口）、LoadBalancer（云上直连负载均衡）。NodePort 可自定义 nodeport_port；LoadBalancer 支持自定义协议、端口、LB IP、LB class（例如 AWS NLB）。

• Ingress/Route 两套模式：

  示例（Ingress 多域名 + TLS）：

  spec:
    ingress_type:ingress
  ingress_hosts:
      -hostname:awx-demo.example.com
      -hostname:awx-demo.sample.com
        tls_secret:sample-tls-secret
  ingress_annotations: |
      environment: testing
  

  示例（OpenShift Route）：

  spec:
    ingress_type: route
    route_host: awx-demo.example.com
    route_tls_termination_mechanism: Passthrough
    route_tls_secret: custom-route-tls-secret-name
  

• ingress_type: ingress 时，按 Kubernetes Ingress 标准对象生成，可指定 ingress_hosts（支持多个主机名及 TLS Secret）、ingress_class_name、annotations 等。
• ingress_type: route 时，在 OpenShift 自动创建 Route，并可设定 route_host、TLS 终止方式（Edge/Passthrough）等。

四、弹性伸缩：副本数与 HPA 同时玩转

• 精细化副本控制：除统一的 replicas 外，可用 web_replicas 与 task_replicas 分别调整 Web 与 Task 两个 Deployment 的副本数；若设定了 web_replicas/task_replicas，将覆盖 replicas 对应组件的值。
• 与 HPA 协同：当你启用 HPA 时，建议让 Operator 不再管理副本数（web_manage_replicas/task_manage_replicas 置为 false），把伸缩权交给 HPA，避免冲突。

五、数据库：默认稳、外部易接入

• 默认 PostgreSQL：文档当前指出与最新 awx-operator 搭配的 AWX 默认使用 PostgreSQL 15。若采用 Operator 管理的内置数据库，不建议强行指定其他版本，以免升级流程出错。
• 外部数据库：支持通过 postgres_configuration_secret 等参数将 AWX 接到外部托管数据库，解耦存储与计算，便于统一数据库运维。

六、持久化与备份恢复：把“后悔药”写进 CR

安装 Operator 时会创建三类 CRD：AWX、AWXBackup、AWXRestore。你可以：

• 通过 AWXBackup 将数据打包进指定 PVC；
• 通过 AWXRestore 从 PVC 恢复到同名或新部署。

这让跨集群迁移、容灾演练与版本升级前的保护都可用声明式方式完成。

一个常见的操作流（示例思路）：

• 为备份准备 PVC；
• 创建 AWXBackup，指定 deployment_name 与 backup_pvc；
• 需要恢复时创建 AWXRestore，指定 backup_pvc（必要时还可配合 backup_name/backup_dir）。

七、常用进阶配置清单（摘选）

• 私有仓库镜像与指定 AWX 版本：当镜像来自私有仓库或你需要锁定某个 AWX 版本时，参照“Using images from private registries/Deploying a specific version of AWX”文档配置。
• 挂载项目目录持久化：把 projects 目录持久化到外部存储，升级或迁移更安心。
• 指定节点/容忍：通过 node_selector/tolerations 将 AWX 或 Postgres Pod 约束在特定节点池，满足异构节点、专用资源池等需求。
• Mesh Ingress：在服务网格环境下的入口配置指南（如 Istio/Contour 等场景）。
• 升级指引：按官方步骤升级 Operator 与 AWX，关键版本变更前务必先做 AWXBackup。

八、排障思路（最有用的几条）

• 看 Operator 日志：安装逻辑在 operator 容器的 installer 角色里执行，看到 AWX CR Status=Failed 时，第一时间看 awx-manager 容器日志。

  kubectl logs -f deployments/awx-operator-controller-manager -c awx-manager
  

• 观察被管理对象：awx/awxbackup/awxrestore/pod/deployment/pvc/service/ingress/route/secrets/serviceaccount 等，用 describe/get -o yaml 定位失败细节。

九、典型应用场景建议

• 团队试用/功能验证：使用 NodePort 最快出网，几分钟即可体验完整的 AWX Web UI 与 API。
• 企业内网/多环境：用 Ingress 统一北向网关策略，结合 projects 持久化与外部 PostgreSQL，将存算分离、版本升级与异地容灾纳入日常流程。
• 弹性负载与弹性执行：为 web 与 task 分别设定副本数，或交由 HPA 自动扩缩；配合节点选择与容忍，将执行面调度到更贴近资源池的节点。

十、一步到位的安装清单（可复制）

1. 安装 Operator（Kustomize）

   # 文件：kustomization.yaml
   apiVersion:kustomize.config.k8s.io/v1beta1
   kind:Kustomization
   resources:
   -github.com/ansible/awx-operator/config/default?ref=<tag>
   images:
   -name:quay.io/ansible/awx-operator
       newTag:<tag>
   namespace:awx
   

   kubectl apply -k .
   

2. 创建 AWX 实例（NodePort 示例）

   # 文件：awx-demo.yml
   apiVersion: awx.ansible.com/v1beta1
   kind: AWX
   metadata:
     name: awx-demo
   spec:
     service_type: nodeport
   

   并在 kustomization.yaml 的 resources 中加入 awx-demo.yml，随后：

   kubectl apply -k .
   

3. 取回初始管理员密码并访问

   kubectl get secret awx-demo-admin-password \
     -o jsonpath="{.data.password}" | base64 --decode ; echo
   

同类项目推荐（如何选）

awx-operator-helm（官方社区 Helm Chart）

• 适合偏好 Helm 的团队：通过 helm repo/add/install 的方式将 awx-operator 以 Chart 部署到集群，可在 CI/CD 中更轻松地参数化与版本化。
• 常用命令：
• 添加仓库：

  helm repo add awx-operator https://ansible-community.github.io/awx-operator-helm/
  

• 安装：

  helm install my-awx-operator awx-operator/awx-operator
  

• 指定版本与命名空间：

  helm install my-awx-operator awx-operator/awx-operator \
    -n awx --create-namespace -f my-values.yml --version <chart-version>
  

• 卸载：

  helm delete my-awx-operator
  

• 选型建议：若你的平台工程体系以 Helm 为主（如 Argo CD/Flux 大量使用 HelmRelease），或希望通过 values.yaml 统一差异化配置，优先考虑该路径；若团队更熟悉 Kustomize/纯 kubectl 流程或需要细粒度 patch，直接使用 awx-operator 仓库内的 Kustomize 模板即可。