问题标签 [canary-deployment]

我有两个类似的服务/部署/入口在两个 GKE/K8S 命名空间中运行：ns-A（旧），ns-B（新）。ns-A 的入口就像myservice.mycompany.com. 所有客户端都myservice.mycompany.com用于访问 ns-A 中的旧服务。

现在，我需要将流量从 ns-A 部署到 ns-B。我需要所有客户端访问 ns-B 中的新服务。我可以在 ns-B: 中为新服务创建一个新入口，myservice-B.mycompany.com并更新所有服务以使用这个新端点。

但我有很多客户。可以使用其他方式将金丝雀从 ns-A 部署到 ns-B。我查看了轮廓，但轮廓不能支持两个命名空间的推出。

是否可以使用 DNS 切换或集群内部 DNS 名称来推出金丝雀？你能提供更多细节吗？谢谢

我有以下nginx.config文件：

我有两个 nodejs 服务器在端口 8090 和 8091 上侦听，我正在访问 URL http://localhost:7080，我的期望是 Nginx 会随机将流量拆分到version_1a上游version_1b，但是，所有流量都将流向version_1a. 对为什么会发生这种情况有任何见解吗？

（我想对金丝雀流量进行此配置）

我正在研究 Canary 部署策略。安装trafik 网格后，我使用服务网格接口。第一次使用命令启动程序时

它应该部署整个应用程序，即 4 个副本，但它只部署了应用程序的 20%（1 个副本），并且它进入了进度状态并出现错误：

TrafficRoutingErro: the server could not find the requested resource (post trafficsplits.splits.smi-spec.io) TrafficSplitNotCreated: Unable to create traffic Split 'demo-traefficsplit'

这是我的清单：

argocd-rollout.yaml

applications.yaml

我使用了许多解决方案，例如 Istio、spinnaker 等，但它们没有提供执行 Canary 发布（加权路由）的方法，也没有应用会话亲和性来坚持特定的 pod。

可以实现 Canary 特性，也可以自己实现会话亲和性（sticky session），但是由于 envoy 代理的限制，我们无法实现两者的结合。

是否有任何解决方案可以为 Kubernetes 提供具有会话亲和性功能的 Canary 版本？

在“HTTP API”与“REST API”比较中没有提到金丝雀部署。

据我所知 ， https: //boto3.amazonaws.com/v1/documentation/api/latest/reference/services/apigateway.html 用于“REST API”，而 https://boto3.amazonaws.com/v1/ documentation/api/latest/reference/services/apigatewayv2.html 用于“HTTP API”，我没有看到后者提到“金丝雀”。

他们只是使用不同的术语还是有另一种方式？

我是 ArgoCD 的新手，我收到以下错误：

我的 rollout.yaml 文件的内容：

当我kubectl apply -f rollout.yaml使用“ArgoCD UI”执行或部署它时，我收到此错误。

Istio 和 ArgoCD pod 正在我的集群设置中运行。

K8 的版本：1.20

码头工人：20.10.5

集群设置：Kubeadm

我已经搜索了几天尝试在网络上找到的各种东西，包括 AWS 的文档，但我仍然在 Canary 部署方面苦苦挣扎。最终，我们希望根据需要使用 Terraform 和 AWS CLI 来编排部署 - 但现在我只是试图通过 AWS 控制台手动让金丝雀工作（根据需要使用 AWS CLI）。

第一步

• 我有一个 API GW 设置
• 连接到舞台的 lambda 函数
• 金丝雀未在阶段启用
• 方法的集成请求中的 Lambda 函数没有 lambda 的版本或别名（只是 lambda 函数的名称）*** Lambda 返回最新响应 ***

第二步

• 我在 API GW 阶段通过控制台启用金丝雀。
• 我通过添加当前的 lambda 版本来更新集成请求 -> Lambda 函数。
• 我在 API GW 中“部署 API”。我看到阶段和金丝雀部署ID是相同的。我相信此时最新的部署（包括最新的 lambda 版本和 API GW 设置中的所有其他内容）都保存为最新部署的版本和“非金丝雀”/“以前”/“产品”版本。*** Lambda 返回最新的响应 *** 我认为这没问题，因为自从启用金丝雀后我还没有对 lambda 进行更改。

第三步

• 我更改 lambda 函数以返回不同的值
• 我点击“部署”将更改推送到 lambda 函数
• 然后我“发布新版本”
• 此时我假设我需要返回 API GW -> 集成请求并在“Lambda 函数”字段中更新到最新版本
• 现在“部署 API” 现在我假设之前的部署仍然是 prod/previous/non-canary 版本，而刚刚发生的部署是具有所有最新代码、版本、API GW 设置等的 canary 版本。

现在事情变得棘手了：如果我将 Canary 百分比设置为 10%，我希望看到来自 API 的 10% 的响应具有最新响应，而 90% 是以前版本的响应 - 但是它被翻转了，我得到了90% 的金丝雀响应。如果我在 API GW -> Stage -> Canary 中将 Canary 百分比更改为 90%，则在测试时我平均 10% 与最新响应。

如果可能的话，我宁愿避免使用 lambda 别名或阶段变量（为了简单起见）。我假设金丝雀在 2 个部署快照之间切换，而最新的部署是金丝雀。如果这是正确的，我不需要在“集成请求 - > Lambda 函数”中使用 stageVariable 来映射到版本。而且由于我不想通过 Lambda 流量拆分来做金丝雀 - 我不需要制作 lambda 别名。

我还使用 AWS CLI 命令尝试了上述大部分步骤（除了修改 Lambda 函数代码和创建新的 lambda 版本）。这产生了类似的结果。

我还没想在这里变得花哨。没有 CloudFormation、CodeDeploy、Terraform 等。一旦我了解 API GW 级别的金丝雀是如何工作的，下一步就是自动化。我也不想做蓝绿色的金丝雀。

谢谢！期待看到它是明显/简单的修复。;)

我正在考虑在 Istio 中使用金丝雀部署，但它似乎会根据权重将请求随机分配到新旧版本。这意味着业务中的用户可能会在一分钟内看到一种行为，下一分钟会看到不同的行为，并且团队中的人可能会遇到彼此不同的行为。出于这个原因，如果我希望用户或团队的行为保持一致，我需要建立自己的推出机制，我可以控制谁继续使用新的服务版本。

我是正确的还是我误解了 Istio 金丝雀推出的工作原理？

我有一个使用 EF Core 作为ORM的 .NET 应用程序，并且所有 db 修改都是使用EF 中的Db Migrations完成的。

该应用程序托管在生产环境中的多个虚拟机上的云上，在完成所有测试后，启动滚动部署以一次使用一个虚拟机，部署新应用程序，等等。

数据库本身托管在具有多可用/复制设置的托管 Db 服务（如 aws RDS、Azure SQL）上。

主要目标是确保没有停机时间（0 停机时间），并在发生任何问题时回滚（或相应地手动分发金丝雀加权请求）

主要问题是，如果应用程序成功部署到一个实例，并且该实例接收到连接，这将导致数据库迁移到新版本，导致所有其他实例请求失败（因为 EF 将在旧实例）

如何对现有的 istio 自定义设置进行金丝雀升级。

要求：

• 我们已经为 AKS 1.18.14 定制了 istio 1.7.3（使用 istoctl 方法安装，没有为此设置修订版）。
• 现在我们需要升级到 istio 1.8 没有停机时间或最小化。
• 升级应该更安全，并且不会以任何方式破坏我们的产品环境。

我们如何安装当前的 istio 定制环境：

1. 创建清单。

2. 安装了 istio。

3. 针对已部署的清单验证了 istio。

计划升级过程^参考

1. 预检查升级。

2. 使用以下命令将 istio 当前使用的配置导出到 yaml 文件。

3. 下载 istio 1.8 二进制文件并解压目录并将目录导航到我们拥有 1.8 版本 istioctl 二进制文件的位置。

4. 从新版本的 istio 目录中，为 istio(1.8) 创建一个具有正确修订集的新控制平面，并使用之前导出的安装状态“iop.yaml”。

预计它将创建具有现有成本配置的新控制平面，现在我们将有两个控制平面部署和服务并排运行：

5. 在此之后，我们需要更改所有需要注入 istio 代理容器的集群命名空间的现有标签。需要移除旧的“istio-injection”标签，并添加 istio.io/rev 标签以指向金丝雀版本 1-8。

希望，在这一点上，旧的 istio 配置环境也是稳定的，我们可以决定哪些应用程序 pod 可以重新启动，以根据我们的停机时间进行新的控制平面更改，并允许使用旧的控制平面运行一些应用程序和另一个在这一点上具有新的控制器平面配置。例如：

6. 一旦我们计划停机并按照我们的决定重新启动部署，请确认所有 pod 现在仅使用 1.8 版的 dataplane 代理注入器

7. 验证 test-ns 命名空间中的新 pod 是否正在使用与 canary 版本对应的 istiod-canary 服务

8. 升级控制平面和数据平面后，可以卸载旧的控制平面

升级前需要清除以下几点。

1. 上面为升级准备的所有步骤是否适用于高度使用的 Prod 环境？

2. 通过导出已安装的状态 iop 是否足以让所有自定义步骤进行金丝雀升级？还是有可能阻止升级或丢失任何设置？

3. 上面的步骤 4 是否会创建 1.8 istio 控制平面，其中包含我们已经拥有的所有自定义功能，而不会出现任何中断或遗漏什么？

4. 在第 4 步之后，我们是否需要任何与 istiod 服务配置相关的额外配置> 后面的文档并不清楚，

5. 对于上面的步骤 5，我们如何识别所有命名空间，我们启用了 istio-injection 并且只修改这些命名空间而让其他命名空间保持原样？

6. 那么对于上面的第 8 步，如何确保我们只卸载旧的控制平面？我们必须获取旧控制平面的二进制文件（在我的情况下为 1.7）并使用相同导出的二进制文件/tmp/iop.yaml？

7. 不知道如何回滚之间发生的任何问题..在旧控制平面删除之前或之后