我们将使用 k8s-native Argo Rollouts 部署控制器和 GitlabCI 来运行到 Kubernetes 的 Canary 部署
本系列文章
- （本文）
- 使用 Istio 进行金丝雀部署
- 使用 Jenkins-X Istio Flagger 进行金丝雀部署
金丝雀部署
我们希望您阅读 ，我们简要解释了什么是金丝雀部署。 我们还展示了如何使用标准 Kubernetes 资源来实现它。
Argo 推出
Argo Rollouts 是 Kubernetes 原生部署控制器。 它为 Kubernetes 提供了 CRD（自定义资源定义）。 多亏了它，我们可以使用一个新的实体： Rollout，它使用各种配置选项管理蓝绿和金丝雀部署。
自定义资源使用的 Argo Rollouts 控制器
Rollout,允许额外的部署策略，例如 Kubernetes 的蓝绿和金丝雀。 资源Rollout提供同等功能Deployment，仅具有额外的部署策略。
资源Deployments有两种部署策略：RollingUpdateиRecreate。 尽管这些策略适用于大多数情况，但为了大规模部署到服务器，需要使用其他策略，例如蓝绿或金丝雀，这些策略在部署控制器中不可用。 要在 Kubernetes 中使用这些策略，用户必须在其部署之上编写脚本。 Argo Rollouts Controller 将这些策略公开为简单的、声明性的、可配置的参数。
还有 Argo CI，它提供了一个方便的 Web 界面，可与 Rollouts 一起使用，我们将在下一篇文章中介绍它。
安装 Argo 部署
服务器端
kubectl create namespace argo-rolloutskubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml
在我们的基础设施萝卜（见下文）中，我们已经添加了 install.yaml 作为 i/k8s/argo-rollouts/install.yaml。 这样 GitlabCI 就会将其安装到集群中。
客户端（kubectl 插件）
应用示例
为应用程序代码和基础设施建立单独的存储库是一种很好的做法。
应用程序的存储库
这是一个非常简单的 Python+Flask API，以 JSON 形式返回响应。 我们将使用 GitlabCI 构建包并将结果推送到 Gitlab 注册表。 在注册表中我们有两个不同的发行版本：
- wuestkamp/k8s-部署-示例-应用程序：v1
- wuestkamp/k8s-部署-示例-应用程序：v2
它们之间的唯一区别是返回的 JSON 文件。 我们使用此应用程序尽可能轻松地可视化我们正在与哪个版本进行通信。
基础设施存储库
在此存储库中，我们将使用 GitlabCI 部署到 Kubernetes，.gitlab-ci.yml 如下所示：
image: traherom/kustomize-dockerbefore_script:
- printenv
- kubectl versionstages:
- deploydeploy test:
stage: deploy
before_script:
- echo $KUBECONFIG
script:
- kubectl get all
- kubectl apply -f i/k8s only:
- master要自己运行它，您需要一个集群，您可以使用 Gcloud：
gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b
gcloud compute firewall-rules create incoming-80 --allow tcp:80你需要分叉 并创建一个变量 KUBECONFIG 在 GitlabCI 中，其中将包含访问配置 kubectl 到您的集群。
您可以阅读有关如何获取集群 (Gcloud) 凭据的信息。
基础设施 YAML
在基础设施存储库中我们有服务：
apiVersion: v1
kind: Service
metadata:
labels:
id: rollout-canary
name: app
spec:
ports:
- port: 80
protocol: TCP
targetPort: 5000
selector:
id: app
type: LoadBalancer和 rollout.yaml ：
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: rollout-canary
spec:
replicas: 10
revisionHistoryLimit: 2
selector:
matchLabels:
id: rollout-canary
template:
metadata:
labels:
id: rollout-canary
spec:
containers:
- name: rollouts-demo
image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
imagePullPolicy: Always
strategy:
canary:
steps:
- setWeight: 10
# Rollouts can be manually resumed by running `kubectl argo rollouts promote ROLLOUT`
- pause: {}
- setWeight: 50
- pause: { duration: 120 } # two minutesRollout 与部署的工作方式相同。 如果我们不设置更新策略（例如这里的金丝雀），它将表现得像默认的滚动更新部署。
我们在 yaml 中定义了金丝雀部署的两个步骤：
- 10%流量到canary（等待手动OK）
- 前往金丝雀的流量为 50%（等待 2 分钟，然后继续达到 100%）
执行初始部署
初始部署后，我们的资源将如下所示：
我们仅从应用程序的第一个版本获得响应：
执行金丝雀部署
第1步：10%流量
要开始金丝雀部署，我们只需像通常的部署那样更改映像版本：
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: rollout-canary
spec:
...
template:
metadata:
labels:
id: rollout-canary
spec:
containers:
- name: rollouts-demo
image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
...我们推送更改，因此 Gitlab CI 确实进行了部署，并且我们看到了更改：
现在如果我们访问该服务：
伟大的！ 我们正处于金丝雀部署过程中。 我们可以通过运行来查看进度：
kubectl argo rollouts get rollout rollout-canary
第2步：50%流量：
现在让我们继续下一步：重定向 50% 的流量。 我们将此步骤配置为手动运行：
kubectl argo rollouts promote rollout-canary # continue to step 2
我们的应用程序返回了新版本响应的 50%：
以及推出回顾：
精细。
第3步：100%流量：
我们将其设置为 2 分钟后 50% 步骤自动结束并开始 100% 步骤：
以及应用程序输出：
以及推出回顾：
金丝雀部署完成。
Argo 推出的更多示例
这里还有更多的例子，比如如何基于canary设置环境预览和比较：
有关 Argo 推出和 Argo CI 的视频
我真的推荐这个视频，它展示了 Argo Rollouts 和 Argo CI 如何协同工作：
总
我真的很喜欢使用 CRD 来管理其他类型的部署或副本集的创建、重定向流量等的想法。 与他们的合作进展顺利。 接下来我想测试与 Argo CI 的集成。
然而，Argo CI 和 Flux CI 似乎即将进行大规模合并，所以我可能会等到新版本发布： .
您有过 Argo Rollouts 或 Argo CI 的经验吗？
另请阅读我们博客上的其他文章：
来源： habr.com