在这篇指南中，你将获得使用 KubeRnetes 和 Istio 使用 GitOps 进行渐进式交付的实际经验。
介绍
GitOps 是什么?
GitOps 是一种进行持续交付的方式，它使用 Git 作为声明性基础设施和工作负载的真实来源。对于 KubeRnetes，这意味着使用 Git push 而不是 kubectl apply/delete 或 helm install/upgrade。
在这个 workshop 中，您将使用 GitHub 来托管配置存储库，并将 Flux 作为 GitOps 交付解决方案。
什么是渐进式交付?
渐进交付是高级部署模式的总称。渐进交付技术通过让应用程序开发人员和 SRE 团队对爆炸半径进行细粒度控制，从而降低在生产中引入新软件版本的风险。
在这个 workshop 中，您将使用 Flagger 和 Prometheus 为您的应用程序自动执行 Canary 发布和 A/B Testing。
准备工作
您将需要具有 loadbalancer 支持的 Kubernetes 集群 v1.16 或更高版本。出于测试目的，您可以使用带有 2 个 CPU 和 4GB 内存的 minikube。
使用 Homebrew 安装 flux CLI：
brew install fluxcd/tap/flux
MacOS AMD64/ARM64、Linux AMD64/ARM 和 Windows 的二进制文件可在 flux2 Release page 下载。
验证您的集群是否满足前提条件：
flux check –pre
使用 Homebrew 安装 jq 和 yq：
brew install jq yq
Fork 这个仓库并克隆它：
Git clone https://Github.com//Gitops-istio cd Gitops-istio Cluster bootstrap
使用 flux bootstrap 命令，您可以在 Kubernetes 集群上安装 Flux 并将其配置为从 Git 存储库管理自身。如果集群上存在 Flux 组件，则 bootstrap 命令将在需要时执行升级。
通过指定您的 GitHub 存储库 fork URL 来引导 Flux：
flux bootstrap Git –author-email= –url=SSH://Git@Github.com//Gitops-istio –branch=Main –path=clusters/My-cluster
上面的命令需要 SSH-agent，如果您使用的是 Windows，请参阅 flux bootstrap Github 文档。
在引导时，Flux 生成一个 SSH key 并打印 public key。为了用 Git 同步你的集群状态，你需要复制 public key并使用 write 创建一个 deploy key 访问你的 GitHub 仓库。在 GitHub 上转到 settings > Deploy keys 点击 Add deploy key， 勾选 Allow write access，粘贴 Flux public key 并单击 Add key。
当 Flux 访问你的存储库时，它会做以下事情：
安装 Istio operator 等待 Istio 控制平面准备好 安装 Flagger、Prometheus 和 Grafana 创建 Istio 公共网关 创建 Prod 命名空间 创建负载测试器 deployment 创建前端 deployment 和 Canary 创建后端 deployment 和 Canary
使用 Istio 引导集群时，定义 apply 顺序很重要。对于要使用 Istio sidecar 注入的应用程序 pod，Istio 控制平面必须在应用程序之前启动并运行。
在 Flux v2 中，你可以通过定义对象之间的依赖关系来指定执行顺序。例如，在 clusters/My-cluster/apps.yaml 中我们告诉 Flux，apps 的协调取决于一个 istio-system ：
APIversion: kustomize.toolkit.fluxcd.io/v1beta1 kind: Kustomization Metadata: name: apps Namespace: flux-system spec: interval: 30m0s dependsOn: – name: istio-system sourceRef: kind: GitRepository name: flux-system path: ./apps
首先观测 Flux 安装 Istio，然后观测 DEMO apps：
Watch flux get kustomizations
您可以使用以下命令跟踪 Flux Reconciliation 日志：
flux logs –all-namespaces –follow –tail=10 Istio 定制和升级
您可以使用位于 istio/system/Profile.yaml 的 IstioOperator 资源自定义 Istio 安装：
APIversion: install.istio.io/v1alpha1 kind: IstioOperator Metadata: name: istio-default Namespace: istio-system spec: Profile: DEMO components: pilot: k8s: Resources: requests: CPU: 10m Memory: 100Mi
修改 Istio 设置后，您可以将更改推送到 Git，Flux 将在集群上应用它。Istio operator 将根据您的更改重新配置 Istio 控制平面。
当新的 Istio 版本可用时，update-istio GitHub Action workflow 工作流将打开一个 pull Request，其中包含升级 Istio Operator 所需的清单更新。新的 Istio 版本通过 e2e workflow 在 Kubernetes Kind 上进行测试，当 PR 合并到主分支时，Flux 将在集群内升级 Istio。
应用程序引导
当 Flux 将 Git 存储库与您的集群同步时，它将创建前端/后端部署、HPA 和一个金丝雀对象。Flagger 使用 Canary 定义创建了一系列对象：Kubernetes deployments、ClusterIP services、Istio destination rules 和 virtual services。这些对象在网格上公开应用程序，并推动金丝雀分析和推广。
检查 Flagger 是否成功初始化了金丝雀：
kubectl -n Prod get canaries NAME STATUS WEIGHT backend Initialized 0 frontend Initialized 0
当 frontend-primary 部署上线时，Flagger 会将所有流量路由到主 Pod，并将 frontend 部署 scale 到零。
使用以下命令查找 Istio 入口网关地址：
kubectl -n istio-system get svc istio-ingressgateway -o json | jq .status.loadbalancer.ingress
打开浏览器并导航到入口地址，您将看到前端 UI。
金丝雀发布
Flagger 实现了一个控制循环，该控制循环在测量关键性能指标的同时，逐步将流量转移…
您可以通过以下方式监控所有金丝雀：
Watch kubectl get canaries –all-namespaces Namespace NAME STATUS WEIGHT Prod frontend Progessing 100 Prod backend Succeeded 0 基于 Istio 指标的回滚
Flagger 使用 Istio 遥测提供的指标来验证金丝雀工作负载。前端应用 analYsis 定义了两个指标检查：
Metrics: – name: Error-Rate templateref: name: Error-Rate namespace: istio-system thresholdRange: Max: 1 interval: 30s – name: latency templateref: name: latency namespace: istio-system thresholdRange: Max: 500 interval: 30s
用于检查错误率和延迟的 Prometheus 查询，位于 Flagger-Metrics.yaml
在金丝雀分析期间，您可以生成 HTTP 500 Errors 和高延迟来测试 Flagger 的回滚。
生成 HTTP 500 Errors：
Watch curl -b ”type=insideR” http:///status/500
生成延迟：
Watch curl -b ”type=insideR” http:///delay/1
当失败的检查次数达到金丝雀分析阈值时，流量将路由回主服务器，金丝雀缩放为零，并将推出标记为失败。
您可以使用针对 Prometheus、Datadog 和 Amazon CloudWatch 的自定义指标检查来扩展分析。
有关为 Slack、MS Teams、Discord 或 Rocket 配置金丝雀分析警报的信息，请参阅文档。
