ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

90DaysOfDevOps 实践:在 Minikube 上部署 ArgoCD 并以 GitOps 方式交付 Kubernetes 应用

90DaysOfDevOps 实践:在 Minikube 上部署 ArgoCD 并以 GitOps 方式交付 Kubernetes 应用 文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载导读本篇文章对应 90DaysOfDevOps 2022 路线图的第 76 天2022/Days/day76.md是 CI/CD Pipelines 阶段的收官内容。文章以 ArgoCD 为核心讲解如何在一个本地 Minikube 集群上完成 ArgoCD 的安装、初始管理员密码获取、Web UI 登录并通过 Git 仓库把应用Pac-Man持续部署到 Kubernetes 中。读完本文你将掌握 ArgoCD 的基本部署流程、声明式 GitOps 应用交付思路以及在无负载均衡器的本地集群中处理 Service 状态的实用技巧。为什么需要 ArgoCD从“线上改一下”到“一切可回滚”Argo CD 的官方定位是“Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes”——一个面向 Kubernetes 的声明式 GitOps 持续交付工具。这句话的核心在于“declarative声明式”与“GitOps”两个关键词。在传统运维中我们常常会遇到两类问题直接在环境中临时修改改完就忘了因为系统一切正常“lights are on and everything is green”问题被掩盖或者修改导致故障但可能不是自己改的、也可能故障没有被立刻发现最终业务受损。ArgoCD 给出的解决路径非常明确Application definitions, configurations, and environments should be declarative, and version controlled—— 应用定义、配置与环境都必须声明式且纳入版本控制Application deployment and lifecycle management should be automated, auditable, and easy to understand—— 应用的部署与生命周期管理应当自动化、可审计、易理解。从运维背景出发在做完大量 Infrastructure as Code 工作之后ArgoCD 正是把 IaC 的成果进一步延伸到持续部署 / 持续交付工作流中的下一步Git 仓库成为集群环境的唯一事实来源single source of truth任何变更都可追溯、可回滚、可审计。部署 ArgoCD两条命令拉起整套控制器ArgoCD 官方提供了现成的 manifests 安装包本节的演示环境仍然是项目一贯使用的本地 Minikube Kubernetes 集群。部署只需要两步kubectl create namespace argocd kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml第一步创建独立的argocd命名空间把 ArgoCD 的控制器、服务端与应用部署资源与业务应用隔离第二步直接应用官方 stable 分支的 install.yaml该文件一次性声明了 ArgoCD 运行所需的全部 Kubernetes 资源。从执行输出的资源清单可以看到其中既包括自定义资源定义CRD、ServiceAccount、Role/RoleBinding、ConfigMap、Secret也包括 Deployment、StatefulSet、Service 与 NetworkPolicy 等这正是 ArgoCD 高可用的典型形态。部署完成后验证控制器是否全部就绪kubectl get pods -n argocd从图中可以看到argocd命名空间下的各个 Pod 均处于Running状态就绪数全部为 1/1且没有重启记录说明核心组件包括 argocd-server、argocd-repo-server、argocd-application-controller 等已正常启动。如果想一次性纵览该命名空间中所有资源类型可以执行kubectl get all -n argocd该命令会同时列出 Pod、Service、Deployment、ReplicaSet 和 StatefulSet 等资源帮助你快速确认 ArgoCD 服务端、仓库服务端与应用控制器之间的网络端点是否都已就绪。访问 Web UI端口转发 初始管理员密码集群内服务默认不对外暴露本地体验最直接的方式是使用 kubectl 的端口转发。请在新的终端窗口中执行kubectl port-forward svc/argocd-server -n argocd 8080:443这里把argocd-server服务的 443 端口映射到本机 8080 端口。随后在浏览器中访问https://localhost:8080ArgoCD 在安装时会自动生成一个初始管理员 Secret。登录用户名为admin密码需要从集群中取回并解码命令如下kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath{.data.password} | base64 -d echo该命令利用jsonpath提取 Secret 中的password字段base64 编码再通过base64 -d解码为明文 echo用于换行输出。出于安全考虑首次登录后建议立即在 UI 的 User Info 中修改密码并妥善保管。登录成功后你会进入 ArgoCD 的空白应用面板——此时集群中还没有任何由 ArgoCD 管理的应用。页面上方的NEW APP与SYNC APPS按钮分别用于创建新的 Application 与手动触发应用同步这正是后续把应用接入 GitOps 流程的入口。用 ArgoCD 部署应用以 Pac-Man 为例ArgoCD 的核心能力是从 Git 仓库以及 Helm Chart 仓库拉取应用定义并将集群实际状态持续收敛到仓库声明的期望状态。本节选择的应用是 Pac-Man——经典吃豆人游戏一个在数据管理类演示中被反复使用的示例应用。官方推荐的做法是在 ArgoCD UI 中通过表单逐步完成配置填写应用名称、选择来源仓库与路径、指定目标集群与命名空间然后点击创建并同步。整个交互过程在演示视频中有完整呈现这里不再用截图逐一重复。需要注意的是ArgoCD 管理的应用清单本质上就是 Kubernetes 原生资源声明。本仓库的 2022/Days/Kubernetes/pacman-stateful-demo.yaml 恰好提供了一份可对照的完整示例可以让我们理解 Pac-Man 应用在集群内部的资源拓扑命名空间与安全文件开头定义了pacman命名空间并配套 PodSecurityPolicy、ClusterRole 与 RoleBinding允许该命名空间内的 ServiceAccount 使用相应安全策略并读取 pods/nodes 信息MongoDB 有状态存储StatefulSet 使用bitnami/mongodb:4.4.8镜像数据落在 PVCmongo-storage上并通过 Secretmongodb-users-secret注入MONGODB_ROOT_PASSWORD、MONGODB_DATABASE、MONGODB_USERNAME、MONGODB_PASSWORD等环境变量同时配置了基于mongo ... --evalquit()的就绪探针Pac-Man 无状态应用Deployment 使用quay.io/ifont/pacman-nodejs-app:latest镜像监听 8080 端口配置了 HTTP 类型的 liveness/readiness 探针并通过环境变量与 Secret 引用把 MongoDB 的连接信息主机mongo、认证用户/密码、数据库名、端口 27017、是否启用 SSL 等注入容器服务暴露mongo服务使用 ClusterIP内部访问而pacman服务则声明为LoadBalancer类型将 80 端口转发到容器的 8080 端口。这也正好解释了原文档中的一个重要提示Minikube 默认没有配置负载均衡器因此pacman的 LoadBalancer 类型 Service 会一直处于pending状态表现为应用健康但服务“永远不被满足”。如果你想在本地完整体验游戏可以把 Service 的 type 改为ClusterIP见 pacman-stateful-demo.yaml 中的 Service 定义再利用kubectl port-forward转发到游戏端口即可游玩。此外仓库中还提供了基于 Ingress 的暴露方式2022/Days/Kubernetes/pacman-ingress.yaml 通过networking.k8s.io/v1的 Ingress 资源将主机pacman.com的根路径/路由到pacman命名空间中名为pacman的 Service 的 80 端口适合集群内已启用 Ingress Controller 的场景。把 ArgoCD 放到 CI/CD 的上下文里看第 76 天标志着本阶段 CI/CD Pipelines 内容的收官。正如文档所强调的当前行业对 CI/CD 领域投入了大量关注同时你会越来越多地听到GitOps这个术语——它本质上就是本文所述方法论在 CI/CD 大框架下的具体体现以 Git 为唯一事实来源用自动化同步替代人工变更。在 90DaysOfDevOps 的 2022 路线图见 2022.md中ArgoCD 的章节被明确列入 CI/CD 部分紧接其后的下一站是Observability可观测性——Day 77 起开始讨论监控主题2022/Days/day77.md。这个安排并非巧合当你用 GitOps 把部署做到自动化、可审计之后下一步自然要回答“系统运行得怎么样”也就是监控、日志与告警。可见这条学习路径在设计上是一脉相承的先解决“如何可靠地把东西发布出去”再解决“如何持续观察发布后的状态”。小结ArgoCD 是面向 Kubernetes 的声明式 GitOps 持续交付工具强调“声明式 版本控制 自动化 可审计”本地 Minikube 部署只需kubectl create namespace argocd与kubectl apply两条命令验证用kubectl get pods -n argocd与kubectl get all -n argocd通过kubectl port-forward svc/argocd-server -n argocd 8080:443暴露 UI用初始 Secret 解码出的密码以admin登录应用交付从 Git 仓库声明出发Pac-Man 示例可对照本仓库的 pacman-stateful-demo.yaml 理解其 MongoDB Node.js 的资源拓扑本地无 LoadBalancer 时可将 Pac-Man Service 改为 ClusterIP 并配合端口转发完成体验或改用仓库中的 Ingress 方案暴露。赞分享文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载相关推荐升级旧Mac至新版macOSOpenCore Legacy Patcher 实操完整指南升级旧Mac至新版macOSOpenCore Legacy Patcher 实操完整指南 升级后旧 Mac 可以安装 Sequoia 等新版 macOS图操作系统固件驱动开发JVM Profiler与其他监控工具对比JMX、JProfiler和VisualVM的优劣分析JVM Profiler与其他监控工具对比JMX、JProfiler和VisualVM的优劣分析 在现代Java应用开发中选择合适的JVM监控工具对系统性能HyperFormula入门指南10分钟学会Excel公式解析与计算HyperFormula入门指南10分钟学会Excel公式解析与计算 HyperFormula是一款开源的无头电子表格引擎专为企业级Web应用设计支持40上一篇NodeGui QComboBox 信号接口 QComboBoxSignals 完全指南从 TypeScript 类型定义到底层 C 信号连接下一篇AnyLabeling高级技巧5个实用功能让你的数据标注事半功倍创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表