在日常工作中，我们经常升级该应用程序的应用程序版本，该应用程序在互联网公司中特别频繁，主要是为了满足快速业务开发。我们通常使用的发布方法包括滚动更新，蓝色绿色发布和灰色发布。
在这里，如果通过Ingress-nginx控制器实现灰度版本，我们将主要与您分享。
本文的轮廓如下。
Ingress-Nginx是Kubernetes推荐的官方入口控制器。它是基于NGINX实现的，并为其他功能添加了一组LUA插件。
为了获得灰度释放，Ingress-Nginx通过定义宣传来实现不同场景的灰色释放。其支持的规则如下：
我们还通过上述注释实现灰度出版。这个想法如下：
Intress-nginx的方法实施了灰度释放和我们自己的实施思想。这是释放灰色版本的内容。
如果在生产中向外界提供了A应用程序，则目前开发和修复了一些错误，并且需要将A2版本发布到在线版本上，但是我们不想将所有流量直接连接到新的A2版本，但Hopeenter将10％的流量分为A2，并且在A2稳定后，所有流量将连接到原始A版本。
为了实现这一目标，您只需要将以下注释添加到Canary的入口。
这意味着打开金丝雀，表明我们设置的重量。
基于重量的发布方案相对粗糙。它是所有用户的20％，不能限制特定用户。
有时我们有这样的需求，例如我们在广东，北京和四个地区的三个区域中有用户，并且版本的应用为这三个区域提供了服务。由于需求的更新，我们需要发布A2应用程序。但是，我们不希望所有区域访问A2应用程序，但我们希望只有Sichuan用户才能访问它。只有在四川地区的反馈意见没有问题之后，我们才能在其他地区开放。
为此，我们需要将以下注释添加到Canary的入口。
主要是上面的两个版本，将在下面的这两个场景中进行实验。
我在这里准备了两个镜子，一个是稳定的稳定版本，另一个是灰色金丝雀版本。
由于两种情况的配置与入口处的配置不一致，因此其他情况是相同的，因此这里两个版本的应用程序在这里很好地部署了。
（1）稳定版本
访问效果如下：
（2）金丝雀版本
访问效果如下：
该应用程序已在上面部署，并且将针对权重和用户请求的两种情况进行测试。
（1）配置入口的稳定版本
（2）配置入口的金丝雀版本
然后我们通过访问进行测试，效果如下：
基本上维护。
（1）配置入口的稳定版本
（2）配置入口的金丝雀版本
当我们访问时不带标头时，我们只访问稳定版本的应用程序，如下：
如果我们在访问时带上标头，我们只会访问Canary版本应用程序，如下：
实现非常简单吗？
我们现在考虑另一个问题。以上所有操作都是手动的。我们应该如何自动化？我应该如何设计组装线？
让我们谈谈我的个人想法。
首先，该过程：
整个过程很简单，但是不允许将标签直接针对那些很好地部署的人进行修改。这次，我可以直接更新Canary版本测试后的稳定版本的镜子吗？当然，在那里，将是滚动更新的过程。
然后，我们的装配线可以像这样设计，如下所示：
该设计存在无法确定的问题。如果等待时间很长，它不仅会消耗资源，而且会自动退出。
我们可以将其分成两条组装线吗？该过程如下：
我更喜欢第二种类型。运行后运行后将退出，并且不会占用其他资源。
在开发装配线之前，我们需要定义命名标准，以便更方便地操作。
定义标准后，实现时要简单得多。
代码位置：https：//gitee.com/coolops/gary-devops.git
我定义了两个jenkinsfile，一个叫canary.jenkinsfile，另一个称为stable.jenkinsfile。它们用于部署金丝雀和稳定版本。
然后，我们将创建两个汇编行，如下所示：其中用于部署金丝雀版本，另一个是部署稳定版本。
现在在集群中运行稳定版本，如下：
我们修改了需求，更改代码，并如下更改：
首先发行金丝雀薄膜，并完成当前水管的发行。您可以在集群中看到豆荚和入口的金丝雀版本，如下所示：
查看金丝雀设定的内容，以查看我们是否需要的内容，如下所示：
可以发现我们与我们的预设相同。
访问测试很好，如下：
您现在可以发布稳定版本，运行稳定版本的汇编线。发布后，群集中只有稳定版本的应用程序，如下：
通过域名访问也与期望一致。
在这一点上，它基本上实现了他自己的想法。
注意：Jenkinsfile涉及的用户名和密码存储在Jenkins的凭据中。插头需要安装Kubernetes部署插头，并搜索插头 - 中心。
- 版本匹配策略，头部格式如下
- 版本重量策略，标题格式如下
- 策略，头部格式如下，选择一个
- 刷新标题格式如下如下
-IP地址和端口匹配策略，标题格式如下以下
- 环境隔离，动态环境匹配策略
- 摄制论真实 - 时间流量绝对是无损的，并且是全球情况的唯一ID屏蔽策略
- 驱车流量绝对是无损的，IP地址和端口屏蔽策略
当外部值标头时，网关还设置并通过同名的标题，并且需要确定哪个标头传递给后来的服务。您需要控制以下开关：
在上面，我们基本上实现了灰度释放的过程，并且只将手册变成了自动。但是您是否发现任何问题？
首先，您需要切换管道以进行释放。其次，发布控制不是很友好。例如，要添加金丝雀版本的节点，我们需要手动进行。
实际上，我还建议将Argo-Rollout与ArgoCD合并用于灰度释放。Argo-Rollout已定制了一组CRD来控制发布过程，这可以节省大量手动操作过程。ArgOCD是一组基于Gitops实施的软件，这对于我们很方便，可以促进我们。CDControl还提供了UI面板进行操作。但是，您需要更改现有的发布方法和应用程序模板。它并不复杂，但是有一定的风险，需要在一定程度上进行测试。
原始：https：//juejin.cn/post/7107075962415611940