KubeSphere DevOps 扩展全景指南Jenkins 流水线、ArgoCD 与多集群 CI/CD 实践【免费下载链接】kubesphereThe container platform tailored for Kubernetes multi-cloud, datacenter, and edge management ⎈ ☁️项目地址: https://gitcode.com/GitHub_Trending/ku/kubesphere导读本文以 KubeSphere 仓库中的 skills/kubesphere-devops-overview/SKILL.md 为核心骨架系统讲解 KubeSphere DevOps 扩展的能力模型与落地方法从DevOps 项目本质上就是带标签的 Kubernetes 命名空间这一关键认知出发覆盖资源映射关系、InstallPlan 安装与多集群调度、Jenkins/ArgoCD 集成、Pipeline 类型选型与常见故障排查。读完本文你将掌握在 KubeSphere 中安装 DevOps 扩展、创建与管理流水线、打通 Git 仓库与代码质量工具以及在多集群环境下按集群差异化部署的完整实战方案。何时使用 KubeSphere DevOpsKubeSphere DevOps 通过 Jenkins 集成提供 CI/CD 能力同时支持图形化流水线编辑与基于 Jenkinsfile 的流水线并内置ArgoCD 集成以实现 GitOps 持续部署。它适用于以下典型场景在 KubeSphere 中搭建 CI/CD 流水线配置 Jenkins 集成管理 DevOps 项目与流水线排查流水线执行问题对接 GitHub、GitLab 或 SVN 仓库配置 SonarQube 进行代码质量检查。核心概念三层资源映射KubeSphere DevOps 将资源映射到三个层面KubeSphere 抽象层、Kubernetes 资源层与 Jenkins 对象层。理解这张映射表是理解整个 DevOps 功能的前提KubeSphere Kubernetes Jenkins ───────────────────────────────────────────────────────────── Workspace Workspace CR (authorization) └── DevOpsProject ├── DevOpsProject CR └── Folder (Namespace) └── Namespace (with label) └── Pipeline ├── Pipeline CR └── WorkflowJob └── Run ├── PipelineRun CR └── Build #N关键认知KubeSphere 中的 DevOps 项目 本质上是一个带有devops.kubesphere.io/managedtrue标签的Kubernetes 命名空间。DevOpsProject CR 只是一个包装wrapper资源当你查询可访问的 DevOps 项目时实际交互的是namespaces而非直接操作 DevOpsProject CR。租户视角的 API租户应使用/kapis/devops.kubesphere.io/v1alpha3/workspaces/{workspace}/namespaces端点来列出可访问的 DevOps 项目返回的是 namespace 资源而/apis/devops.kubesphere.io/v1alpha3/devopsprojects端点需要集群级权限租户调用会返回 403。DevOps 项目命名约定DevOps 项目存在两种名称形式这是最容易踩坑的地方名称类型示例来源用途Shortname短名devopstest.metadata.generateNameDevOpsProject CR面向用户展示的名称Fullname全名devopstestc2nj7.metadata.nameDevOpsProject CR 与 Namespace实际资源标识符要点全名才是真正的 Kubernetes 命名空间名称例如devopstestc2nj7当以短名devopstest创建 DevOps 项目时KubeSphere 会自动追加随机字符生成唯一全名所有 API 操作都使用全名命名空间名而非短名当用户以短名指代项目且存在多个匹配时务必先向用户确认再继续操作。DevOps 项目与工作空间的关联DevOpsProject 通过标签归属到某个 WorkspaceapiVersion: devops.kubesphere.io/v1alpha3 kind: DevOpsProject metadata: name: my-project labels: kubesphere.io/workspace: demo # 关联到 Workspace demo创建并关联的完整步骤# 1. 创建 Workspace kubectl apply -f - EOF apiVersion: tenant.kubesphere.io/v1beta1 kind: Workspace metadata: name: demo EOF # 2. 创建带标签的 DevOpsProject kubectl apply -f - EOF apiVersion: devops.kubesphere.io/v1alpha3 kind: DevOpsProject metadata: name: my-project labels: kubesphere.io/workspace: demo EOF从源码结构看tenant.kubesphere.io/v1beta1的 Workspace 是 KubeSphere 多租户模型的基础资源DevOps 项目通过kubesphere.io/workspace标签与租户隔离体系挂钩这保证了不同工作空间之间的流水线与凭据互相隔离。DevOps 项目内包含的组件┌──────────────────────────────────────────────────────────────┐ │ DevOps Project │ │ (Namespace with devops.kubesphere.io/managedtrue label) │ └──────────────────────┬───────────────────────────────────────┘ │ ┌──────────────┼──────────────┐ │ │ │ ┌───────▼──────┐ ┌─────▼─────┐ ┌──────▼──────┐ │ Pipelines │ │Credentials│ │ Webhooks │ │ │ │ │ │ │ │ - Graphical │ │ - SSH │ │ - GitHub │ │ - Jenkinsfile│ │ - Basic │ │ - GitLab │ │ - Multi-branch│ │ - Token │ │ - Generic │ └──────────────┘ └───────────┘ └─────────────┘流水线、凭据Credentials对应 Kubernetes 中的v1/Secret资源与 Webhook 共同构成一个 DevOps 项目的主体能力。安装 DevOps 扩展使用 InstallPlan生产环境推荐最小化安装使用默认配置—— 推荐apiVersion: kubesphere.io/v1alpha1 kind: InstallPlan metadata: name: devops namespace: kubesphere-system spec: extension: name: devops version: 1.2.4 enabled: true upgradeStrategy: Manual # 生产环境必填 # 说明省略 spec.config 以使用扩展默认值何时使用最小化安装首次安装以验证默认配置无特殊资源需求的常规部署希望使用扩展经过测试的默认值。自定义配置仅在需要时覆盖默认值apiVersion: kubesphere.io/v1alpha1 kind: InstallPlan metadata: name: devops namespace: kubesphere-system spec: extension: name: devops version: 1.2.4 enabled: true upgradeStrategy: Manual # 生产环境必填 config: | # 覆盖 DevOps chart 的 values.yaml 配置 agent: jenkins: Master: NodeSelector: {} resources: requests: cpu: 500m memory: 4Gi limits: cpu: 2000m memory: 8Gi Agent: Image: jenkins/inbound-agent Tag: 3309.v27b_9314fd1a_4-1-jdk21 Privileged: false重要提醒生产环境务必使用upgradeStrategy: Manualconfig为可选字段——省略或留空即使用扩展默认值config中的值会覆盖扩展values.yaml的对应设置DevOps 是关键基础设施组件升级需谨慎规划。InstallPlan 的字段级解释依据仓库中的 CRD 定义 config/ks-core/charts/ks-crds/crds/kubesphere.io_installplans.yaml 及其 Go 类型 staging/src/kubesphere.io/api/core/v1alpha1/types.go#L230-L237spec.extension.name/spec.extension.version必填指定要安装的扩展名与版本spec.enabled必填布尔值控制扩展启用/禁用spec.upgradeStrategy默认为Manualkubebuilder:default:Manual生产环境要求显式设置spec.config字符串以 YAML/Values 形式覆盖扩展 Helm chart 的默认值spec.clusterScheduling多集群调度配置包含placement部署位置与overrides按集群覆盖详见下文。从实现角度InstallPlan 由 pkg/controller/core/installplan_controller.go 中的InstallPlanReconciler驱动它仅在 host 集群角色上启用Enabled方法返回clusterRole ClusterRoleHost通过 Helm 执行器以system:serviceaccount:{targetNamespace}:helm-executor.{extension}的身份安装扩展并为每个被调度集群生成{extension}-agent形式的 agent 发布对应 pkg/controller/core/installplan_controller.go#L1045 的agentReleaseFormat %s-agent。状态字段state、conditions、configHash、targetNamespace、releaseName、clusterSchedulingStatuses等由控制器持续同步可通过kubectl get installplan devops -n kubesphere-system观察安装进度。多集群安装要在成员集群上安装 DevOps agent需在 InstallPlan 中添加clusterSchedulingapiVersion: kubesphere.io/v1alpha1 kind: InstallPlan metadata: name: devops namespace: kubesphere-system spec: extension: name: devops version: 1.2.4 enabled: true upgradeStrategy: Manual config: | # 所有集群共享的基础配置 agent: jenkins: Master: resources: requests: cpu: 500m memory: 4Gi clusterScheduling: placement: clusters: - host # 安装在 host 集群 - member1 # 安装在 member1 - member2 # 安装在 member2 # 可选按集群覆盖 overrides: member1: | agent: jenkins: Master: resources: limits: memory: 8Gi # 为 member1 分配更大的 master member2: | agent: jenkins: Agent: NodeSelector: zone: west关键点clusterScheduling.placement.clusters列出运行 DevOps agent 的集群clusterScheduling.placement.clusterSelector除显式集群列表外还支持标签选择器方式对应类型定义 staging/src/kubesphere.io/api/core/v1alpha1/types.go#L195-L205 中的Placement.ClusterSelector控制器会将其转换为标签查询以动态匹配目标集群clusterScheduling.overrides按集群覆盖配置以map[clusterName]string形式给出不配置clusterScheduling时DevOps 仅运行在 host 集群overrides 与基础 config 合并overrides 优先级更高。使用 Helm备选方案helm upgrade --install devops kse-extensions/devops \ -n kubesphere-devops-system \ --create-namespace安装后验证# 检查 DevOps 相关 Pod kubectl get pods -n kubesphere-devops-system # 检查 InstallPlan 状态 kubectl get installplan devops -n kubesphere-system # 多集群场景检查各集群上的 agent 状态 kubectl get installplan devops -n kubesphere-system -o jsonpath{.status.clusterSchedulingStatuses}InstallPlan 的status.clusterSchedulingStatuses字段staging/src/kubesphere.io/api/core/v1alpha1/types.go#L239-L244以map[clusterName]InstallationStatus形式记录每个被调度集群上子 chart 的安装状态这是多集群部署排障时最直接的观测入口。架构与组件组件用途命名空间devops-jenkinsJenkins masterkubesphere-devops-systemdevops-apiserverDevOps API 服务kubesphere-devops-systemdevops-controller资源控制器kubesphere-devops-systemdevops-argocd-*ArgoCDGitOpsargocdJenkins Agent流水线执行器动态随流水线创建Jenkins 集成KubeSphere DevOps 通过 Jenkins 执行 CI/CD。Secretdevops-jenkins中保存了直接访问 Jenkins 的 admin token# 获取 Jenkins admin token TOKEN$(kubectl -n kubesphere-devops-system get secret devops-jenkins -o jsonpath{.data.jenkins-admin-token} | base64 -d) # 调用 Jenkins API kubectl run curl-jenkins --rm -i --restartNever --imagecurlimages/curl \ -- http://admin:${TOKEN}devops-jenkins.kubesphere-devops-system:80/api/jsonJenkins NodePortkubectl get svc devops-jenkins -n kubesphere-devops-system # 默认端口30180访问 Jenkins 控制台URLhttp://node-ip:30180用户名admin密码从上述 Secret 获取ArgoCD 集成KubeSphere DevOps 内置ArgoCD v2.11.7用于 GitOps 持续部署ArgoCD 组件组件用途application-controller管理 Application 状态applicationset-controller管理 ApplicationSet 资源dex-serverSSO 认证notifications-controller事件通知repo-server仓库操作argocd-serverAPI/UI 服务redis缓存层访问 ArgoCD# 获取 ArgoCD server URL kubectl get svc devops-agent-argocd-server -n argocd # 获取 admin 密码 kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath{.data.password} | base64 -d关键特性声明式 GitOps 部署多源 Application 支持自动化同步策略通过 Dex 实现 SSO 集成通知 Webhook从源码层面看ArgoCD 组件正是通过上一节的多集群调度机制以devops-agent发布形式部署到目标集群的因此kubectl get installplan devops -n kubesphere-system -o jsonpath{.status.clusterSchedulingStatuses}同样能反映 ArgoCD 相关组件的部署状态。核心资源一览资源API 版本用途Pipelinedevops.kubesphere.io/v1alpha3CI/CD 流水线定义DevOpsProjectdevops.kubesphere.io/v1alpha3DevOps 项目命名空间包装Credentialv1/Secret仓库与部署凭据常用快捷命令# 列出 DevOps 项目 kubectl get devopsprojects # 列出某项目下的流水线 kubectl get pipelines -n devops-project-namespace # 获取流水线运行记录 kubectl get pipelineruns -n devops-project-namespace # 检查 Jenkins 状态 kubectl -n kubesphere-devops-system get pods -l appdevops-jenkins # 查看 Jenkins 日志 kubectl -n kubesphere-devops-system logs -l appdevops-jenkins # 获取 Jenkins admin 密码 kubectl -n kubesphere-devops-system get secret devops-jenkins -o jsonpath{.data.jenkins-admin-password} | base64 -d流水线类型选型类型描述适用场景图形化Graphical可视化流水线编辑器简单流水线无需编写代码JenkinsfileSCM流水线定义在仓库中需要版本控制的流水线Jenkinsfile内联流水线定义在 KubeSphere 中快速测试多分支Multi-branch自动发现分支GitFlow、特性分支常见问题排查问题修复方法流水线报错 No agent检查 Jenkins agent 配置无法访问 Git 仓库验证凭据与 Webhook 配置kubeconfig 凭据失败使用string类型而非kubeconfigContentv1.2Jenkins 内存不足增大 Jenkins master 资源流水线卡住检查 agent Pod 状态与资源限制版本兼容性DevOpsJenkins说明v1.2.x2.504.1 LTS已移除 kubernetes-cd 插件v1.1.x2.346.3 LTS支持旧版 kubeconfigContent需要注意版本差异带来的行为变化例如 v1.1.x 中支持的kubeconfigContent凭据类型在 v1.2 中已不推荐应改用string类型这与常见问题排查一节中的修复建议相互印证。在升级 DevOps 扩展前务必核对当前版本对应的 Jenkins 基线避免流水线语法与插件行为不兼容。结语KubeSphere DevOps 的核心心智模型可以概括为三句话DevOps 项目就是命名空间带devops.kubesphere.io/managedtrue标签所有 API 操作使用全名namespace 名安装与多集群调度统一由 InstallPlan 驱动。在此基础上通过 Jenkins 承担 CI 执行、ArgoCD 承担 GitOps 持续部署即可构建从代码提交到生产发布的完整闭环。建议生产环境从最小化 InstallPlan 开始验证默认行为后再按需覆盖 Jenkins master 资源与 agent 镜像最后通过clusterScheduling将 agent 扩展到成员集群实现跨集群统一的 CI/CD 能力。【免费下载链接】kubesphereThe container platform tailored for Kubernetes multi-cloud, datacenter, and edge management ⎈ ☁️项目地址: https://gitcode.com/GitHub_Trending/ku/kubesphere创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 KubeSphere DevOps 扩展全景指南：Jenkins 流水线、ArgoCD 与多集群 CI/CD 实践
KubeSphere DevOps 扩展全景指南Jenkins 流水线、ArgoCD 与多集群 CI/CD 实践【免费下载链接】kubesphereThe container platform tailored for Kubernetes multi-cloud, datacenter, and edge management ⎈ ☁️项目地址: https://gitcode.com/GitHub_Trending/ku/kubesphere导读本文以 KubeSphere 仓库中的 skills/kubesphere-devops-overview/SKILL.md 为核心骨架系统讲解 KubeSphere DevOps 扩展的能力模型与落地方法从DevOps 项目本质上就是带标签的 Kubernetes 命名空间这一关键认知出发覆盖资源映射关系、InstallPlan 安装与多集群调度、Jenkins/ArgoCD 集成、Pipeline 类型选型与常见故障排查。读完本文你将掌握在 KubeSphere 中安装 DevOps 扩展、创建与管理流水线、打通 Git 仓库与代码质量工具以及在多集群环境下按集群差异化部署的完整实战方案。何时使用 KubeSphere DevOpsKubeSphere DevOps 通过 Jenkins 集成提供 CI/CD 能力同时支持图形化流水线编辑与基于 Jenkinsfile 的流水线并内置ArgoCD 集成以实现 GitOps 持续部署。它适用于以下典型场景在 KubeSphere 中搭建 CI/CD 流水线配置 Jenkins 集成管理 DevOps 项目与流水线排查流水线执行问题对接 GitHub、GitLab 或 SVN 仓库配置 SonarQube 进行代码质量检查。核心概念三层资源映射KubeSphere DevOps 将资源映射到三个层面KubeSphere 抽象层、Kubernetes 资源层与 Jenkins 对象层。理解这张映射表是理解整个 DevOps 功能的前提KubeSphere Kubernetes Jenkins ───────────────────────────────────────────────────────────── Workspace Workspace CR (authorization) └── DevOpsProject ├── DevOpsProject CR └── Folder (Namespace) └── Namespace (with label) └── Pipeline ├── Pipeline CR └── WorkflowJob └── Run ├── PipelineRun CR └── Build #N关键认知KubeSphere 中的 DevOps 项目 本质上是一个带有devops.kubesphere.io/managedtrue标签的Kubernetes 命名空间。DevOpsProject CR 只是一个包装wrapper资源当你查询可访问的 DevOps 项目时实际交互的是namespaces而非直接操作 DevOpsProject CR。租户视角的 API租户应使用/kapis/devops.kubesphere.io/v1alpha3/workspaces/{workspace}/namespaces端点来列出可访问的 DevOps 项目返回的是 namespace 资源而/apis/devops.kubesphere.io/v1alpha3/devopsprojects端点需要集群级权限租户调用会返回 403。DevOps 项目命名约定DevOps 项目存在两种名称形式这是最容易踩坑的地方名称类型示例来源用途Shortname短名devopstest.metadata.generateNameDevOpsProject CR面向用户展示的名称Fullname全名devopstestc2nj7.metadata.nameDevOpsProject CR 与 Namespace实际资源标识符要点全名才是真正的 Kubernetes 命名空间名称例如devopstestc2nj7当以短名devopstest创建 DevOps 项目时KubeSphere 会自动追加随机字符生成唯一全名所有 API 操作都使用全名命名空间名而非短名当用户以短名指代项目且存在多个匹配时务必先向用户确认再继续操作。DevOps 项目与工作空间的关联DevOpsProject 通过标签归属到某个 WorkspaceapiVersion: devops.kubesphere.io/v1alpha3 kind: DevOpsProject metadata: name: my-project labels: kubesphere.io/workspace: demo # 关联到 Workspace demo创建并关联的完整步骤# 1. 创建 Workspace kubectl apply -f - EOF apiVersion: tenant.kubesphere.io/v1beta1 kind: Workspace metadata: name: demo EOF # 2. 创建带标签的 DevOpsProject kubectl apply -f - EOF apiVersion: devops.kubesphere.io/v1alpha3 kind: DevOpsProject metadata: name: my-project labels: kubesphere.io/workspace: demo EOF从源码结构看tenant.kubesphere.io/v1beta1的 Workspace 是 KubeSphere 多租户模型的基础资源DevOps 项目通过kubesphere.io/workspace标签与租户隔离体系挂钩这保证了不同工作空间之间的流水线与凭据互相隔离。DevOps 项目内包含的组件┌──────────────────────────────────────────────────────────────┐ │ DevOps Project │ │ (Namespace with devops.kubesphere.io/managedtrue label) │ └──────────────────────┬───────────────────────────────────────┘ │ ┌──────────────┼──────────────┐ │ │ │ ┌───────▼──────┐ ┌─────▼─────┐ ┌──────▼──────┐ │ Pipelines │ │Credentials│ │ Webhooks │ │ │ │ │ │ │ │ - Graphical │ │ - SSH │ │ - GitHub │ │ - Jenkinsfile│ │ - Basic │ │ - GitLab │ │ - Multi-branch│ │ - Token │ │ - Generic │ └──────────────┘ └───────────┘ └─────────────┘流水线、凭据Credentials对应 Kubernetes 中的v1/Secret资源与 Webhook 共同构成一个 DevOps 项目的主体能力。安装 DevOps 扩展使用 InstallPlan生产环境推荐最小化安装使用默认配置—— 推荐apiVersion: kubesphere.io/v1alpha1 kind: InstallPlan metadata: name: devops namespace: kubesphere-system spec: extension: name: devops version: 1.2.4 enabled: true upgradeStrategy: Manual # 生产环境必填 # 说明省略 spec.config 以使用扩展默认值何时使用最小化安装首次安装以验证默认配置无特殊资源需求的常规部署希望使用扩展经过测试的默认值。自定义配置仅在需要时覆盖默认值apiVersion: kubesphere.io/v1alpha1 kind: InstallPlan metadata: name: devops namespace: kubesphere-system spec: extension: name: devops version: 1.2.4 enabled: true upgradeStrategy: Manual # 生产环境必填 config: | # 覆盖 DevOps chart 的 values.yaml 配置 agent: jenkins: Master: NodeSelector: {} resources: requests: cpu: 500m memory: 4Gi limits: cpu: 2000m memory: 8Gi Agent: Image: jenkins/inbound-agent Tag: 3309.v27b_9314fd1a_4-1-jdk21 Privileged: false重要提醒生产环境务必使用upgradeStrategy: Manualconfig为可选字段——省略或留空即使用扩展默认值config中的值会覆盖扩展values.yaml的对应设置DevOps 是关键基础设施组件升级需谨慎规划。InstallPlan 的字段级解释依据仓库中的 CRD 定义 config/ks-core/charts/ks-crds/crds/kubesphere.io_installplans.yaml 及其 Go 类型 staging/src/kubesphere.io/api/core/v1alpha1/types.go#L230-L237spec.extension.name/spec.extension.version必填指定要安装的扩展名与版本spec.enabled必填布尔值控制扩展启用/禁用spec.upgradeStrategy默认为Manualkubebuilder:default:Manual生产环境要求显式设置spec.config字符串以 YAML/Values 形式覆盖扩展 Helm chart 的默认值spec.clusterScheduling多集群调度配置包含placement部署位置与overrides按集群覆盖详见下文。从实现角度InstallPlan 由 pkg/controller/core/installplan_controller.go 中的InstallPlanReconciler驱动它仅在 host 集群角色上启用Enabled方法返回clusterRole ClusterRoleHost通过 Helm 执行器以system:serviceaccount:{targetNamespace}:helm-executor.{extension}的身份安装扩展并为每个被调度集群生成{extension}-agent形式的 agent 发布对应 pkg/controller/core/installplan_controller.go#L1045 的agentReleaseFormat %s-agent。状态字段state、conditions、configHash、targetNamespace、releaseName、clusterSchedulingStatuses等由控制器持续同步可通过kubectl get installplan devops -n kubesphere-system观察安装进度。多集群安装要在成员集群上安装 DevOps agent需在 InstallPlan 中添加clusterSchedulingapiVersion: kubesphere.io/v1alpha1 kind: InstallPlan metadata: name: devops namespace: kubesphere-system spec: extension: name: devops version: 1.2.4 enabled: true upgradeStrategy: Manual config: | # 所有集群共享的基础配置 agent: jenkins: Master: resources: requests: cpu: 500m memory: 4Gi clusterScheduling: placement: clusters: - host # 安装在 host 集群 - member1 # 安装在 member1 - member2 # 安装在 member2 # 可选按集群覆盖 overrides: member1: | agent: jenkins: Master: resources: limits: memory: 8Gi # 为 member1 分配更大的 master member2: | agent: jenkins: Agent: NodeSelector: zone: west关键点clusterScheduling.placement.clusters列出运行 DevOps agent 的集群clusterScheduling.placement.clusterSelector除显式集群列表外还支持标签选择器方式对应类型定义 staging/src/kubesphere.io/api/core/v1alpha1/types.go#L195-L205 中的Placement.ClusterSelector控制器会将其转换为标签查询以动态匹配目标集群clusterScheduling.overrides按集群覆盖配置以map[clusterName]string形式给出不配置clusterScheduling时DevOps 仅运行在 host 集群overrides 与基础 config 合并overrides 优先级更高。使用 Helm备选方案helm upgrade --install devops kse-extensions/devops \ -n kubesphere-devops-system \ --create-namespace安装后验证# 检查 DevOps 相关 Pod kubectl get pods -n kubesphere-devops-system # 检查 InstallPlan 状态 kubectl get installplan devops -n kubesphere-system # 多集群场景检查各集群上的 agent 状态 kubectl get installplan devops -n kubesphere-system -o jsonpath{.status.clusterSchedulingStatuses}InstallPlan 的status.clusterSchedulingStatuses字段staging/src/kubesphere.io/api/core/v1alpha1/types.go#L239-L244以map[clusterName]InstallationStatus形式记录每个被调度集群上子 chart 的安装状态这是多集群部署排障时最直接的观测入口。架构与组件组件用途命名空间devops-jenkinsJenkins masterkubesphere-devops-systemdevops-apiserverDevOps API 服务kubesphere-devops-systemdevops-controller资源控制器kubesphere-devops-systemdevops-argocd-*ArgoCDGitOpsargocdJenkins Agent流水线执行器动态随流水线创建Jenkins 集成KubeSphere DevOps 通过 Jenkins 执行 CI/CD。Secretdevops-jenkins中保存了直接访问 Jenkins 的 admin token# 获取 Jenkins admin token TOKEN$(kubectl -n kubesphere-devops-system get secret devops-jenkins -o jsonpath{.data.jenkins-admin-token} | base64 -d) # 调用 Jenkins API kubectl run curl-jenkins --rm -i --restartNever --imagecurlimages/curl \ -- http://admin:${TOKEN}devops-jenkins.kubesphere-devops-system:80/api/jsonJenkins NodePortkubectl get svc devops-jenkins -n kubesphere-devops-system # 默认端口30180访问 Jenkins 控制台URLhttp://node-ip:30180用户名admin密码从上述 Secret 获取ArgoCD 集成KubeSphere DevOps 内置ArgoCD v2.11.7用于 GitOps 持续部署ArgoCD 组件组件用途application-controller管理 Application 状态applicationset-controller管理 ApplicationSet 资源dex-serverSSO 认证notifications-controller事件通知repo-server仓库操作argocd-serverAPI/UI 服务redis缓存层访问 ArgoCD# 获取 ArgoCD server URL kubectl get svc devops-agent-argocd-server -n argocd # 获取 admin 密码 kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath{.data.password} | base64 -d关键特性声明式 GitOps 部署多源 Application 支持自动化同步策略通过 Dex 实现 SSO 集成通知 Webhook从源码层面看ArgoCD 组件正是通过上一节的多集群调度机制以devops-agent发布形式部署到目标集群的因此kubectl get installplan devops -n kubesphere-system -o jsonpath{.status.clusterSchedulingStatuses}同样能反映 ArgoCD 相关组件的部署状态。核心资源一览资源API 版本用途Pipelinedevops.kubesphere.io/v1alpha3CI/CD 流水线定义DevOpsProjectdevops.kubesphere.io/v1alpha3DevOps 项目命名空间包装Credentialv1/Secret仓库与部署凭据常用快捷命令# 列出 DevOps 项目 kubectl get devopsprojects # 列出某项目下的流水线 kubectl get pipelines -n devops-project-namespace # 获取流水线运行记录 kubectl get pipelineruns -n devops-project-namespace # 检查 Jenkins 状态 kubectl -n kubesphere-devops-system get pods -l appdevops-jenkins # 查看 Jenkins 日志 kubectl -n kubesphere-devops-system logs -l appdevops-jenkins # 获取 Jenkins admin 密码 kubectl -n kubesphere-devops-system get secret devops-jenkins -o jsonpath{.data.jenkins-admin-password} | base64 -d流水线类型选型类型描述适用场景图形化Graphical可视化流水线编辑器简单流水线无需编写代码JenkinsfileSCM流水线定义在仓库中需要版本控制的流水线Jenkinsfile内联流水线定义在 KubeSphere 中快速测试多分支Multi-branch自动发现分支GitFlow、特性分支常见问题排查问题修复方法流水线报错 No agent检查 Jenkins agent 配置无法访问 Git 仓库验证凭据与 Webhook 配置kubeconfig 凭据失败使用string类型而非kubeconfigContentv1.2Jenkins 内存不足增大 Jenkins master 资源流水线卡住检查 agent Pod 状态与资源限制版本兼容性DevOpsJenkins说明v1.2.x2.504.1 LTS已移除 kubernetes-cd 插件v1.1.x2.346.3 LTS支持旧版 kubeconfigContent需要注意版本差异带来的行为变化例如 v1.1.x 中支持的kubeconfigContent凭据类型在 v1.2 中已不推荐应改用string类型这与常见问题排查一节中的修复建议相互印证。在升级 DevOps 扩展前务必核对当前版本对应的 Jenkins 基线避免流水线语法与插件行为不兼容。结语KubeSphere DevOps 的核心心智模型可以概括为三句话DevOps 项目就是命名空间带devops.kubesphere.io/managedtrue标签所有 API 操作使用全名namespace 名安装与多集群调度统一由 InstallPlan 驱动。在此基础上通过 Jenkins 承担 CI 执行、ArgoCD 承担 GitOps 持续部署即可构建从代码提交到生产发布的完整闭环。建议生产环境从最小化 InstallPlan 开始验证默认行为后再按需覆盖 Jenkins master 资源与 agent 镜像最后通过clusterScheduling将 agent 扩展到成员集群实现跨集群统一的 CI/CD 能力。【免费下载链接】kubesphereThe container platform tailored for Kubernetes multi-cloud, datacenter, and edge management ⎈ ☁️项目地址: https://gitcode.com/GitHub_Trending/ku/kubesphere创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考