diff --git a/kubernetes/gitops/README.md b/kubernetes/gitops/README.md index 5fc7ea07..70d63c03 100644 --- a/kubernetes/gitops/README.md +++ b/kubernetes/gitops/README.md @@ -2,15 +2,24 @@ ## Flux vs Argo CD -1. Flux - 1. 简单小巧，只做一件事，并且把这件事做得很好。 - 1. 是基于 kustomize 拓展的，也就是说它原生支持 overlays，一套基础配置打上不同的 overlays 就能应用到各种不同的 dev/staging/prod 环境，能极大地降低配置文件的重复度。 2. Argo CD 1. 可视化做得比较好，有个漂亮且信息丰富的 Web UI. - 2. 可通过 Web UI 对新配置进行 Diff 确认变更内容，出问题在 Web UI 上能快速回滚。 + 1. 可通过 Web UI 对新配置进行 Diff 确认变更内容，出问题在 Web UI 上能快速回滚。 1. Web UI 支持多租户多集群多名字空间，可接入 LDAP。 + 1. 支持设置维护窗口、自动同步模式下支持自愈（覆盖集群中的手动修改）。 + 1. 可在 Web UI 上手动选择只同步部分配置，并让其他配置保持 out of sync 状态。 + 1. 支持设置 Hooks，在同步的不同阶段部署不同的 K8s Job / Argo Workflow 等资源。可通过它实现发送 IM 消息、邮件、数据库迁移等功能。 +1. Flux + 1. 功能相对 Argo CD 要少很多，更适合高级用户或者说极客。 + 1. 没有 Web UI，只能通过 Git 仓库配置或 CLI 来操作，而且 CLI 的操作因为不可审计，Flux 对往 CLI 中添加功能非常克制。 + 1. 是基于 kustomize 拓展的，也就是说它原生支持 overlays，一套基础配置（kustomize 跟 helm chart 都行）打上不同的 overlays 就能应用到各种不同的 dev/staging/prod 环境，能极大地降低配置文件的重复度。 + 1. Argo CD 相对没这么灵活，它的 kustomize overlays 必须统一放在仓库某个目录下。它的 Helm values 也必须跟 chart 一起存在 Git 仓库中。存储外部 Helm Chart 的全部内容到 Git 仓库中能确保数据不会丢，但它实际污染了 GitOps 仓库，放了一堆并不由我们自己维护的东西在仓库里，在做 git diff 跟 review 的时候，这真的很烦。 + 1. 对于 Helm Chart，Argo CD 中的一个解法是创建一个空 chart 并在它的依赖中声明你真正想部署的 chart，然后在其 values.yaml 中定义对应的自定义值。但这确实不太优雅，搞出很多重复的东西。 + 1. Flux 还能直接在 Helm Chart 上加一个 postRenderer 对它做二次 patch，非常强大。 + 1. Flux 对数据一致性的追求更极致，对于集群配置被手动修改的情况都是直接覆盖，也不提供维护窗口（关闭同步功能）之类的功能。 + 1. Flux 支持定义依赖关系，不过 Kustomization 只能依赖另一个 Kustomization，HelmRelease 只能依赖另一个 HelmRelease，不能跨类型依赖。ArgoCD 缺失此特性。 - +总的来说，Flux 更强大，但 Argo CD 更易用、可视化做得更好。 相关资料： @@ -24,8 +33,16 @@ 1. 这个是最适合使用 GitOps 的，因为这些配置通常由集群管理员编写维护，它们具有很专业的 K8s 与 GitOps 知识，使用此类工具不会带来额外负担，而另一方面，集群状态与 Git 仓库中的配置完全一致带来的好处是相当明显的。 1. 集群中运行的业务服务及其配置： 1. 对于做内部平台的企业，通常业务开发者并不会直接操作集群，而是通过内部平台的 UI 来操作，因此业务服务相关的配置不太适合接入 GitOps，也就不适合使用 ArgoCD 或 Flux。 + 1. 或许平台上的服务版本管理，底层可以使用 GitOps 工具实现，但这些对开发人员而言是透明的。 + 1. 如果内部定义一堆 CRD 给业务侧用于 GitOps，简是简化了，但是这种无法复用的知识，开发人员一般是不情愿学习的，这相对 Web UI 而言并无明显优势。 1. 对于 DevOps 文化比较浓厚的企业，业务开发者对 K8s 也有一定了解，那么业务服务的配置就也比较适合接入 GitOps。 +比较理想的情况是： + +1. 只有 SRE 有权限直接操作集群，而且他们也只是在紧急情况下才会这么做。 +1. SRE 日常使用 GitOps 工具管理集群核心组件与配置，配置 Merge 阶段会有 CI 流程进行验证。 +1. 业务开发者使用内部平台管理业务服务与配置。 + ## 相关问题 diff --git a/kubernetes/gitops/argocd/README.md b/kubernetes/gitops/argocd/README.md index 0546ea10..385ff8f9 100644 --- a/kubernetes/gitops/argocd/README.md +++ b/kubernetes/gitops/argocd/README.md @@ -9,4 +9,4 @@ ArgoCD 阿里云文档有介绍，国内也有一定用户在使用。 3. 支持 LDAP 等多种验证方式，设定权限。（对比：flux 没有任何权限概念，仅面向运维） 4. 等等 -待研究 \ No newline at end of file +待研究 diff --git a/kubernetes/gitops/fluxcd/README.md b/kubernetes/gitops/fluxcd/README.md index 37571d16..c802067a 100644 --- a/kubernetes/gitops/fluxcd/README.md +++ b/kubernetes/gitops/fluxcd/README.md @@ -1,5 +1,4 @@ -# [FLux2](https://github.com/fluxcd/flux2/) +# [Flux2](https://github.com/fluxcd/flux2/) -flux 目前已经推出了完全重构的 flux v2，不知道和 argo cd 比如何。 +TODO -待研究 diff --git a/kubernetes/gitops/fluxcd/fluxcd-v1-values.yaml b/kubernetes/gitops/fluxcd/fluxcd-v1-values.yaml deleted file mode 100644 index 72f1f393..00000000 --- a/kubernetes/gitops/fluxcd/fluxcd-v1-values.yaml +++ /dev/null @@ -1,59 +0,0 @@ - -# 本地测试可以通过 NodePort 暴露 api -service: - type: NodePort - port: 3030 - nodePort: 3030 - -git: - # URL of git repo with Kubernetes manifests; e.g. git.url=git@github.com/fluxcd/flux-get-started - # 这里千万别用 ssh:// 开头，坑！ - url: "git@gitee.com:ryan_yin/flux-get-started" - # Branch of git repo to use for Kubernetes manifests - branch: "master" - # Path within git repo to locate Kubernetes manifests (relative path) - path: "workloads" - # Set to `true` if you intend for Flux to not be able to push changes to git. - # Also configure state.mode to `secret` since storing state in a git tag will no longer be possible. - readonly: false - # Username to use as git committer - user: "Weave Flux" - # Email to use as git committer - email: "support@weave.works" - # (git pull)多久从 git 仓库拉取一次新提交 - # Duration after which git operations time out - timeout: "20s" - # The secret name can be used to supply your own SSH key, instead of - # relying on Flux to generate one for you: - # 1. Generate a SSH key named identity: ssh-keygen -q -N "" -f ./identity - # 2. Create a Kubernetes secret: kubectl -n flux create secret generic flux-ssh --from-file=./identity - # 3. Delete the private key: rm ./identity - # 4. Add ./identity.pub as a deployment key with write access in your Git repo - # 5. Set the secret name (flux-ssh) below - secretName: "flux-git-deploy" # 和前面使用 ssh key 创建的 secret 名称一致 - -sync: - # use `.sync.state: secret` to store flux's state as an annotation on the secret (instead of a git tag) - state: git - # Duration after which sync operations time out (defaults to 1m) - timeout: - # (kubectl apply)多久部署一次 git 新内容到 kubernetes - interval: "2m" - -# SSH 主机指纹 -ssh: - # 这里填之前扫描得到的 known_hosts 文件的内容，注意多行文字要缩进两个空格。 - # 这里我以 gitlab 为例，请使用自己的 known_hosts 替换掉它！ - known_hosts: | - github.com ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ== - gitlab.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCsj2bNKTBSpIYDEGk9KxsGh3mySTRgMtXL583qmBpzeQ+jqCMRgBqB98u3z++J1sKlXHWfM9dyhSevkMwSbhoR8XIq/U0tCNyokEi/ueaBMCvbcTHhO7FcwzY92WK4Yt0aGROY5qX2UKSeOvuP4D6TPqKF1onrSzH9bx9XUf2lEdWT/ia1NEKjunUqu1xOB/StKDHMoX4/OKyIzuS0q/T1zOATthvasJFoPrAjkohTyaDUz2LN5JoH839hViyEG82yB+MjcFV5MU3N1l1QL3cVUCh93xSaua1N85qivl+siMkPGbO5xR/En4iEY6K2XPASUEMaieWVNTRCtJ4S8H+9 - gitlab.com ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBFSMqzJeV9rUzU4kWitGjeR4PWSa29SPqJ1fVkhtj3Hw9xjLVXVYrU9QlYWrOLXBpQ6KWjbjTDTdDkoohFzgbEY= - gitlab.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAfuCHKVTjquxvt6CM6tdG4SLp1Btn/nOeHHE5UOzRdf - -# 如果你使用的镜像仓库不是 dockerhub，就关掉镜像仓库的扫描 -registry: - disableScanning: true -memcached: # 镜像仓库元信息存放位置，关掉 - enabled: false - -# 其他参数请按需修改 \ No newline at end of file diff --git a/kubernetes/gitops/fluxcd/fluxcd-v1.md b/kubernetes/gitops/fluxcd/fluxcd-v1.md deleted file mode 100644 index 7c2e7b23..00000000 --- a/kubernetes/gitops/fluxcd/fluxcd-v1.md +++ /dev/null @@ -1,135 +0,0 @@ -# [Flux v1](https://github.com/fluxcd/flux) - -> 已过期！ - ->Flux 基本没有可视化，目前提供的唯一 UI 还需要用到 grafana，不是很方便。 -而且只支持单仓库单集群，可以说是很简陋。 - -Flux 是一个 K8s 集群的配置同步工具， -它遵循 GitOps 理念，以一个 Git 仓库为数据来源，始终保持集群状态和 Git 仓库中的配置描述一致。 - -使用了 Flux 之后，集群管理员（一般情况下）就不需要直接通过 `kubectl` 去操控集群了。只需要修改 Git 仓库的配置，然后 Commit+Push， -Flux 就会帮你完成接下来的一切工作。 - ->[Flux+Flagger+Istio](https://github.com/stefanprodan/gitops-istio)，可以完成应用的自动灰度更新，自动根据监控指标增加灰度或回滚。 - -## 一、安装 Flux - -### 1. 生成 ssh 密钥对 - -Flux 通过 ssh 协议定时 pull Git 仓库，因此需要首先生成一个密钥对： - -```shell -# -t 算法 dsa | ecdsa | ed25519 | rsa -# -m 私钥使用 pem 格式 -# -C 描述 -ssh-keygen -t cd25519 -f id_rsa_flux -m pem -C "ssh key for flux test" -``` - -直接回车跳过 `passphrase` （密钥的密码）的设置，然后当前目录下就会多出如下两个文件： - -``` -id_rsa_flux id_rsa_flux.pub -``` - -以 `.pub` 结尾的是公钥，另一个是私钥。私钥请妥善保管，千万别泄漏了！ - -### 2. 新建 Git 配置仓库，配置 SSH 公钥 - ->注：Gitee 码云的「部署公钥(Deploy Keys)」不支持写入，你可能需要配置账户全局的 SSH 公钥。 - -在 Github/Gitlab/Gitee 或者你私有的 Git 平台中新建一个专门存放 Kubernetes 集群配置的仓库（可以使用 [flux-get-started](https://github.com/fluxcd/flux-get-started) 中的配置进行测试）， -同时在「Settings」-「Deploy Keys」设置仓库专属的 SSH 公钥。 - - -### 3. 扫描 Git 平台的 SSH 指纹 - -SSH 协议会使用 SSH 指纹对服务端进行验证，防止中间人攻击。 -但是 Flux 只内置了 Github/Gitlab/BitBukit 等平台的 SSH 指纹，如果你使用的 Git 服务不在该范围内（比如私有 Git 仓库、国内的 Gitee 等）， -那就需要手动将仓库的指纹添加到 Flux 的配置中。 - -通过如下命令扫描出指纹： - -```shell -# 请替换示例域名 -ssh-keyscan gitlab.svc.local >> known_hosts -``` - -扫描得到的 known_hosts 文件的内容，需要配置在 `custom-values.yaml` 的 `ssh.known_hosts` 属性中，后续部署会使用到这个配置文件。 - -### 4. 将部署 Flux 部署到集群中 - -接下来将 flux 部署到一个专用名字空间 `flux` 中，需要提前安装好 `helm3` 和 `fluxctl` - -```shell -# 创建名字空间 -kubectl create ns flux -# 使用生成好的 SSH 私钥创建 k8s secret，后面 flux 会挂载这个 secret -kubectl create --namespace flux secret generic flux-git-deploy --from-file=identity=id_rsa_flux - -# 部署 flux 的自定义资源 -kubectl apply -f https://raw.githubusercontent.com/fluxcd/helm-operator/master/deploy/crds.yaml -``` - -最后使用 helm 进行部署： - -```shell -# 下载 flux 的 charts，我们需要修改其中一些配置 -helm repo add fluxcd https://charts.fluxcd.io -# 查看历史版本 -helm search repo fluxcd/flux -l | head -# 下载并解压 chart，目的是方便 gitops 版本管理 -helm pull fluxcd/flux --untar --version 1.5.0 - -# 查看生成出的 kubernetes yaml 内容 -helm template ./flux --namespace flux -f custom-values.yaml > flux-all.yaml - - -# 安装或更新 -helm upgrade --install flux --namespace flux -f custom-values.yaml ./flux - -# 卸载 -helm uninstall flux --namespace flux -``` - -部署中用到了自定义配置文件 `custom-values.yaml`，请自行查看详细内容。 - -接下来可以使用 `fluxctl` 同步仓库配置了： - -```shell -# 查看 flux 的 ssh 公钥，验证 ssh 密钥配置正确 -fluxctl identity --k8s-fwd-ns flux - -# 立即同步 git 仓库配置到 k8s 集群中（默认是 5m 同步一次） -fluxctl sync --k8s-fwd-ns flux - -# 查看所有 flux 管理的工作负载 -fluxctl list-workloads --all-namespaces -``` - -现在尝试修改 git 仓库的配置，然后观察 flux 的工作状况。 -可以手动修改 flux 的同步间隔以快速查看效果。 - -修改了 `values.yaml` 或者升级了 flux 版本后，可以通过如下命令快速部署该修改： - -```shell -helm upgrade flux --namespace flux -f custom-values.yaml ./flux -``` - -## 二、使用 Flux - -```shell -# 测试阶段可以暴露 api 端口出来，这样不需要 kubeconfig 就能使用 fluxctl -export FLUX_URL=http://flux.k8s.local:3030/api/flux - -# 连接 Flux 实例所在的命名空间 flux -fluxctl --k8s-fwd-ns=flux list-workloads - -# 查询 Flux 使用的 SSH 密钥，flux 容器日志中也可以查看 -fluxctl identity --k8s-fwd-ns flux - -# Flux 同步 git 仓库默认为5分钟，此命令可立即同步 -fluxctl sync --k8s-fwd-ns flux -``` - -