一种金丝雀发布方法、装置和可读存储介质与流程

1.本发明涉及计算机应用程序发布领域，尤其涉及一种金丝雀发布方法、装置和可读存储介质。


背景技术：

2.现有技术中，在kubernetes系统中实现金丝雀发布时，需要在希望进行发布的deployment中生成用于金丝雀发布的pod的配置信息，并且将金丝雀pod对应的配置信息中的标签设置得与deployment管理的其他pod的配置信息中的标签不同，以便在同一个deployment中可以同时存在两种配置信息的pod。此方案修改了用于处理当前线上业务的deployment的环境，存在影响当前业务处理的风险。
3.其他基于kubernetes系统实现金丝雀发布的第三方工具需要利用kubernetes的自定义资源功能向kubernetes中引入第三方自定义资源，实现的金丝雀发布系统复杂，无法简单实现快速应用。
4.在实现本发明过程中，申请人发现现有技术中至少存在如下问题：
5.现有技术实现的金丝雀发布方法复杂，需要修改当前线上运行环境。


技术实现要素：

6.本发明实施例提供一种金丝雀发布方法、装置和可读存储介质，解决了现有技术实现的金丝雀发布方法复杂，需要修改当前线上运行环境的问题。
7.为达上述目的，一方面，本发明实施例提供一种金丝雀发布方法，包括：
8.在kubernetes系统中找到要进行金丝雀发布的指定deployment；
9.根据所述指定deployment管理的pod的配置信息，生成金丝雀pod的配置信息，所述金丝雀pod的配置信息中的选择标签与所述指定deployment管理的pod的配置信息中的选择标签相同；所述选择标签用于所述指定deployment相应的service实例将业务请求转发给所述金丝雀pod和所述指定deployment管理的pod；
10.将所述金丝雀pod的配置信息中的镜像地址设置为指定目标镜像的地址；
11.调用kubernetes系统的接口根据所述金丝雀pod的配置信息直接生成金丝雀pod；
12.如果判断出所述金丝雀pod所提供服务的业务逻辑验证结果为通过，则将所述指定deployment的镜像地址设置为所述指定目标镜像的地址，完成发布上线。
13.进一步地，在所述在kubernetes系统中找到要进行金丝雀发布的指定deployment之前，还包括：
14.收到金丝雀发布请求时，调用打包工具将指定业务代码打包为所述指定目标镜像，并将所述指定目标镜像添加到镜像仓库中；
15.所述金丝雀发布请求包括所述指定deployment的名称、所述指定deployment的命名空间、所述镜像仓库的地址和所述打包工具的名称。
16.进一步地，还包括：
17.如果判断出所述金丝雀pod的状态为非运行状态，则发出异常报警；
18.所述异常报警表示所述金丝雀pod不可用。
19.进一步地，还包括：
20.如果判断出所述金丝雀pod所提供服务的业务逻辑验证结果为没有通过，则将所述金丝雀pod下线。
21.进一步地，所述将所述金丝雀pod下线，具体为：
22.将所述金丝雀pod的配置信息中的选择标签修改为与所述指定deployment管理的pod的配置信息中的选择标签不相同。
23.进一步地，还包括；
24.在每次重新执行金丝雀发布前，将上次执行金丝雀发布时生成的金丝雀pod删除。
25.进一步地，还包括：
26.当收到的回滚请求时，将所述指定deployment的镜像地址设置为指定镜像地址；
27.所述指定镜像地址是在本次金丝雀发布执行前所述指定deployment使用过的任一镜像文件的地址。
28.进一步地，所述根据所述指定deployment管理的pod的配置信息，生成金丝雀pod的配置信息，包括：
29.从所述指定deployment管理的pod中选择一个pod作为特定pod；
30.克隆所述特定pod对应的配置信息得到所述金丝雀pod对应的配置信息；
31.删除所述金丝雀pod对应的配置信息中的状态信息、节点信息、ip信息和级联关系信息；
32.将所述金丝雀pod对应的配置信息中的级联关系信息修改为继承自所述特定pod。
33.另一方面，本发明实施例提供一种金丝雀发布装置，包括：
34.查找deployment单元，用于在kubernetes系统中找到要进行金丝雀发布的指定deployment；
35.金丝雀pod配置信息生成单元，用于根据所述指定deployment管理的pod的配置信息，生成金丝雀pod的配置信息，所述金丝雀pod的配置信息中的选择标签与所述指定deployment管理的pod的配置信息中的选择标签相同；所述选择标签用于所述指定deployment相应的service实例将业务请求转发给所述金丝雀pod和所述指定deployment管理的pod；
36.金丝雀pod镜像设置单元，用于将所述金丝雀pod的配置信息中的镜像地址设置为指定目标镜像的地址；
37.金丝雀pod生成单元，用于调用kubernetes系统的接口根据所述金丝雀pod的配置信息直接生成金丝雀pod；
38.正式上线单元，用于如果判断出所述金丝雀pod所提供服务的业务逻辑验证结果为通过，则将所述指定deployment的镜像地址设置为所述指定目标镜像的地址，完成发布上线。
39.进一步地，还包括：
40.接收发布请求单元，用于收到金丝雀发布请求时，调用打包工具将指定业务代码打包为所述指定目标镜像，并将所述指定目标镜像添加到镜像仓库中；
41.所述金丝雀发布请求包括所述指定deployment的名称、所述指定deployment的命名空间、所述镜像仓库的地址和所述打包工具的名称。
42.进一步地，还包括：
43.异常报警单元，用于如果判断出所述金丝雀pod的状态为非运行状态，则发出异常报警；
44.所述异常报警表示所述金丝雀pod不可用。
45.进一步地，还包括：
46.金丝雀pod下线单元，用于如果判断出所述金丝雀pod所提供服务的业务逻辑验证结果为没有通过，则将所述金丝雀pod下线。
47.进一步地，所述金丝雀pod下线单元，具体用于：
48.将所述金丝雀pod的配置信息中的选择标签修改为与所述指定deployment管理的pod的配置信息中的选择标签不相同。
49.进一步地，还包括；
50.金丝雀pod删除单元，用于在每次重新执行金丝雀发布前，将上次执行金丝雀发布时生成的金丝雀pod删除。
51.进一步地，还包括：
52.回滚单元，用于当收到的回滚请求时，将所述指定deployment的镜像地址设置为指定镜像地址；
53.所述指定镜像地址是在本次金丝雀发布执行前所述指定deployment使用过的任一镜像文件的地址。
54.进一步地，所述金丝雀pod配置信息生成单元，包括：
55.pod选择模块，用于从所述指定deployment管理的pod中选择一个pod作为特定pod；
56.配置信息克隆模块，用于克隆所述特定pod对应的配置信息得到所述金丝雀pod对应的配置信息；
57.基本信息清除模块，用于删除所述金丝雀pod对应的配置信息中的状态信息、节点信息、ip信息和级联关系信息；
58.继承关系设置模块，用于将所述金丝雀pod对应的配置信息中的级联关系信息修改为继承自所述特定pod。
59.另一方面，本发明实施例提供一种可读存储介质，其存储有用于实现如前述的任一项所述的方法对应的程序代码。
60.上述技术方案具有如下有益效果：通过直接使用kubernetes系统的接口根据指定deployment管理的pod的配置信息创建金丝雀pod，使得到的金丝雀pod独立于任何deployment，在不改变当前线上的指定deployment以及无需为kubernetes系统额外引入自定义资源的情况下实现基于kubernetes的简单易用的自动金丝雀发布，达到在不添加第三方自定义资源，以最小资源开销的情况下实现基于kubernetes环境下的业务服务金丝雀发布的技术效果；进一步地，创建的金丝雀pod独立于任何deployment，在不改变当前线上的指定deployment的情况下实现自动金丝雀发布，达到对原有环境影响小，只需要操作一个pod即可完成金丝雀发布，其他kubernetes资源不需要修改的技术效果。充分利用
kubernetes系统自身的service组件根据选择标签向pod分发请求的机制和deployment的回滚机制以最小开发成本实现了金丝雀发布过程的重复发布、流量上线、流量下线、回滚，达到显著提高实现金丝雀发布功能的效率，同时充分利用kubernetes的现有已经验证稳定可用的功能，使实现的金丝雀发布功能更加稳定可靠。
附图说明
61.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
62.图1是本发明实施例之一的一种金丝雀发布方法的流程图；
63.图2是本发明实施例之一的一种金丝雀发布业务处理示意图；
64.图3是本发明实施例之一的一种金丝雀发布装置的架构图。
具体实施方式
65.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
66.首先对以下使用到的英文名称进行适当说明：
67.kubernetes系统是本领域技术人员熟知的一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化；
68.deployment是kubernetes系统中用于管理pod的组件，为pods和replicasets提供声明式的更新能力；
69.pod是可以在kubernetes系统中创建和管理的、最小的可部署的计算单元；
70.ingresss是kubernetes系统中的组件，是用于对集群中服务的外部访问进行管理的api对象，典型的访问方式是http，可以提供负载均衡、ssl终结和基于名称的虚拟托管；
71.service是kubernetes系统中的组件，将运行在一组pods上的应用程序公开为网络服务的抽象方法；service实例是service组件在运行时实例化的对象。
72.api server即api服务器负责提供http api，以供用户、集群中的不同部分和集群外部组件相互通信；
73.jenkins是本领域技术人员熟知的一个可扩展的持续集成引擎；
74.gitlab runner是本领域技术人员熟知的另一个持续集成工具。
75.以下对本发明实施例进行说明：
76.一方面，如图1所示，本发明实施例提供了一种金丝雀发布方法，包括：
77.步骤s100，在kubernetes系统中找到要进行金丝雀发布的指定deployment；
78.步骤s101，根据所述指定deployment管理的pod的配置信息，生成金丝雀pod的配置信息，所述金丝雀pod的配置信息中的选择标签与所述指定deployment管理的pod的配置信息中的选择标签相同；所述选择标签用于所述指定deployment相应的service实例将业
务请求转发给所述金丝雀pod和所述指定deployment管理的pod；
79.步骤s102，将所述金丝雀pod的配置信息中的镜像地址设置为指定目标镜像的地址；
80.步骤s103，调用kubernetes系统的接口根据所述金丝雀pod的配置信息直接生成金丝雀pod；
81.步骤s104，如果判断出所述金丝雀pod所提供服务的业务逻辑验证结果为通过，则将所述指定deployment的镜像地址设置为所述指定目标镜像的地址，完成发布上线。
82.在一些实施例中，可以通过给定deployment的名称和deployment的命名空间指定deployment；并通过kubernetes系统中的api server查找到指定deployment；根据指定deployment管理的pod的配置信息生成金丝雀pod的配置信息，使金丝雀pod的运行环境尽可能与指定deployment管理的pod一致，例如可以根据指定deployment管理的pod的配置信息设置金丝雀pod的配置信息中的关键项，优选地，可以克隆指定deployment管理的pod的配置信息作为金丝雀pod的配置信息，还可以在克隆的基础上，对得到的金丝雀pod的配置信息进行适当的修改；具体的生成金丝雀pod的配置信息的方法可以根据具体情况实现；进一步地，为了使针对指定deployment管理的pod的请求也能均衡的转发给金丝雀pod，将金丝雀pod的配置信息中的选择标签设置为与指定deployment管理的pod的配置信息中的选择标签相同。将金丝雀pod的配置信息中的镜像地址设置为指定目标镜像的地址，指定目标镜像是本次金丝雀发布要发布的版本的镜像，指定目标镜像可以是预先生成好的镜像，也可以是在接收到发布请求时，调用打包工具将指定业务代码打包为指定目标镜像，并保存在指定目标镜像的地址处；指定目标镜像可以保存在包括但不限于镜像仓库中；调用kubernetes系统的接口根据所述金丝雀pod的配置信息直接生成金丝雀pod，金丝雀pod通过直接调用kubernetes系统的相关接口创建，而不是通过deployment内部的控制器创建，所以金丝雀pod不受任何deployment的管理；在创建金丝雀pod的过程中，也没有对指定deployment产生任何影响，无需改变当前版本的线上业务的运行。可以生成一个或多个金丝雀pod，可根据具体需求决定；优选地，生成一个金丝雀pod，如图2所示，由于金丝雀pod的配置信息中的选择标签与指定deployment管理的pod的配置信息中的选择标签相同，所以终端用户的请求经kubernetes系统的ingress和service被分发给金丝雀pod和指定deployment管理的pod01、pod02和pod03处理，从而指定deployment管理的pod运行在version1版本上，金丝雀pod运行在要升级测试或要上线的version2版本上，实现了对部分流量的version2版本测试或上线。如果在金丝雀pod上针对version2版本的服务的业务逻辑验证通过，则可以进行正式上线；验证过程可以是通过人工验证，也可以是通过自动测试或者通过自动化监控实现对各种业务指标的跟踪检验，最终对服务的业务逻辑进行验证；人工或自动验证的结果可以发送给本实施例，经判断所述金丝雀pod所提供服务的业务逻辑验证结果为通过时，将指定deployment的镜像地址设置为所述指定目标镜像的地址，kubernetes系统中的机制会触发指定deployment执行上线操作，实现指定deployment管理的各pod被重新创建，旧的pod会被删除，从而完成金丝雀发布的正式上线。
83.本发明实施例具有如下技术效果：通过直接使用kubernetes系统的接口根据指定deployment管理的pod的配置信息创建金丝雀pod，使得到的金丝雀pod独立于任何deployment，在不改变当前线上的指定deployment以及无需为kubernetes系统额外引入自
定义资源的情况下实现基于kubernetes的简单易用的自动金丝雀发布。
84.进一步地，在所述在kubernetes系统中找到要进行金丝雀发布的指定deployment之前，还包括：
85.收到金丝雀发布请求时，调用打包工具将指定业务代码打包为所述指定目标镜像，并将所述指定目标镜像添加到镜像仓库中；
86.所述金丝雀发布请求包括所述指定deployment的名称、所述指定deployment的命名空间、所述镜像仓库的地址和所述打包工具的名称。
87.在一些实施例中，指定业务代码是由开发人员预先编写的准备通过金丝雀发布方式发布到指定deployment所管理的pod中的业务代码，如图2所示，在收到发布请求时，可以从请求中获得指定deployment的名称和指定deployment的命名空间，根据指定deployment的名称和指定deployment的命名空间可以在kubernetes系统中查找到指定deployment，此指定deployment即要进行金丝雀发布的deployment；调用发布请求指定的打包工具将指定业务代码打包为指定目标镜像，并将指定目标镜像添加到请求中指定的镜像仓库。打包工具包括但不限于jenkins和gitlab runner。如果针对指定业务代码的打包失败，会通知开发人员，开发人员会修改指定业务代码后，重新发出发布请求。
88.本发明实施例具有如下技术效果：在接收到发布请求时，自动根据发布请求中的信息调用打包工具自动对业务代码打包并存入镜像仓库中，进一步实现了金丝雀发布的自动化，降低开发人员重复执行打包操作，让开发人员只需关注代码编写，提高开发人员的开发测试效率。
89.进一步地，还包括：
90.如果判断出所述金丝雀pod的状态为非运行状态，则发出异常报警；
91.所述异常报警表示所述金丝雀pod不可用。
92.在一些实施例中，如果金丝雀pod没有正常运行，由于在kubernetes系统中service组件有检测机制，发现金丝雀pod的状态不是运行状态，终端请求将不会发送到金丝雀pod上面，从而实现了检验金丝雀pod所提供服务可用性的效果。
93.进一步地，还包括：
94.如果判断出所述金丝雀pod所提供服务的业务逻辑验证结果为没有通过，则将所述金丝雀pod下线。
95.在一些实施例中，如图2所示，在金丝雀pod与指定deploymentg管理的pod一起提供服务后，部分终端用户请求会通过ingress和service分发到金丝雀pod上，通过此部分流量对金丝雀pod上的version2版本应用的服务的业务逻辑进行验证，若验证没有通过，则将金丝雀pod下线，由于金丝雀pod与指定deployment相互独立，所以金丝雀pod下线后，会将部分流量重新转回指定deployment，系统整体影响较小，无需中断系统服务，对用户体现无影响。
96.进一步地，所述将所述金丝雀pod下线，具体为：
97.将所述金丝雀pod的配置信息中的选择标签修改为与所述指定deployment管理的pod的配置信息中的选择标签不相同。
98.在一些实施例中，如图2所示，如果金丝雀pod正常运行，终端用户的请求便可以到达金丝雀pod上面，此时可以检测服务的业务逻辑是否有问题。如果人工验证方式下，发现
业务逻辑有问题，开发人员可以发出下线流量请求，或者在自动化测试或监控方式下，由自动化测试或监控组件发出下线流量请求，当通过下限流量请求判断出验证没有通过时，可以通过调用kubernetes系统的api server，操作金丝雀pod，修改金丝雀pod的配置信息中的选择标签的内容，使金丝雀pod的配置信息中的选择标签的内容不同于指定deployment管理的pod的配置信息中的选择标签的内容，以便指定deployment对应的service实例不能通过标签找到金丝雀pod，终端用户请求便不会请求到金丝雀pod上面。这样可以避免问题扩大，实现金丝雀发布的快速流量下线功能。
99.进一步地，还包括；
100.在每次重新执行金丝雀发布前，将上次执行金丝雀发布时生成的金丝雀pod删除。
101.在一些实施例中，如果前次金丝雀发布失败，例如下线流量后，开发人员修改了指定业务代码后，需要再次进行金丝雀发布，那么在重新执行金丝雀发布前，为了使重新执行发布时，金丝雀pod的配置信息是最新的，需要删除掉前次金丝雀发布期间创建的金丝雀pod，以便在本次重新执行发布时，重新创建金丝雀pod。本发明实施例可以确保每次执行金丝雀发布时，金丝雀pod的配置信息都是最新的，不会收到前次发布的干扰，保证每次金丝雀发布的稳定性。
102.进一步地，还包括：
103.当收到的回滚请求时，将所述指定deployment的镜像地址设置为指定镜像地址；
104.所述指定镜像地址是在本次金丝雀发布执行前所述指定deployment使用过的任一镜像文件的地址。
105.在一些实施例中，指定目标镜像正式上线完成后，如果发现服务的业务逻辑有问题，可以在接收到回滚请求时对指定deployment进行回滚，回滚的镜像可以由指定镜像地址定义，可以固定使用某个已知稳定版本的镜像的地址，也可以在回滚请求中指明要回滚的版本的镜像地址。在收到回滚请求后，通过调用api server，修改指定deployment的镜像地址。指定deployment的控制器发现指定deployment的镜像地址被修改后，会触发指定deployment管理的pod的滚动更新，完成业务回滚。
106.本发明实施例具有如下技术效果：本发明技术方案充分利用了kubernetes提供的现有机制实现了在业务代码正式上线后，可以在发现服务的业务逻辑有问题后，快速安全的回滚，简化了金丝雀发布方法的复制性，金丝雀发布方法简单易用。
107.进一步地，所述根据所述指定deployment管理的pod的配置信息，生成金丝雀pod的配置信息，包括：
108.从所述指定deployment管理的pod中选择一个pod作为特定pod；
109.克隆所述特定pod对应的配置信息得到所述金丝雀pod对应的配置信息；
110.删除所述金丝雀pod对应的配置信息中的状态信息、节点信息、ip信息和级联关系信息；
111.将所述金丝雀pod对应的配置信息中的级联关系信息修改为继承自所述特定pod。
112.在一些实施例中，如图2所示，指定业务代码打包完成后，返回打包信息，并调用api server，查找需要金丝雀发布的指定deployment，找到对应的指定deployment后，根据deployment的uid，找到指定deployment管理的三个pod，随机选取一个pod，获取此pod的配置信息。如图2所示，在本实施例中获取的pod为pod 03。克隆一份pod 03的配置信息得到金
丝雀pod对应的配置信息，然后删除掉金丝雀pod对应的配置信息中的状态信息、节点信息、ip信息、级联关系信息。由于金丝雀pod的配置信息是克隆自指定deployment管理的pod的配置信息，所以金丝雀pod的配置信息中的标签信息与指定deployment管理的pod的配置信息中的标签信息相同，而配置信息中的选择标签是配置信息中的标签信息的一部分或全部，所以自然能保证金丝雀pod的配置信息中的选择标签与指定deployment管理的pod的配置信息的选择标签相同，从而金丝雀pod和指定deployment管理的pod可以被同一个service实例均衡的调用。将金丝雀pod对应的配置信息中的级联关系信息修改为继承自pod03。修改金丝雀pod的镜像地址为新发布的version2版本的镜像地址。通过kubernetes系统的接口根据金丝雀pod的配置信息创建金丝雀pod，并在最终确认金丝雀发布成功后，开始正式上线，通过调用api server将指定deployment的镜像地址更新为指定目标镜像的地址。指定deployment的控制器发现指定deployment被修改后，会触发指定deployment管理的pod的滚动更新。即：重新创建新的pod的，等待新的pod正常运行后再删除旧的pod。如图2所示，滚动更新完的结果是：原有的pod01、pod02和pod03都将被删除，会有三个新pod被创建。依赖于kubernetes gc垃圾回收机制，金丝雀pod的关联关系设置为继承自pod 03，pod 03在正式上线完成后已经被删除，kubernetes gc将触发垃圾回收机制删除金丝雀pod。保障最终上线完成后，整个新版本的环境和之前的版本的环境是完全相同的。
113.本发明实施例具有如下技术效果：从指定deployment管理的pod中克隆配置信息可以使金丝雀pod的环境与指定deployment管理的pod中运行的当前线上业务的环境保持相同，确保金丝雀发布过程中对服务的业务逻辑验证的准确性。将金丝雀pod设置为继承自指定deployment管理的pod，在指定deployment进行正式上线时，可以利用kubernetes gc的垃圾回收机制，在指定deployment删除金丝雀pod所继承的pod时，同时删除金丝雀pod，达到在正式上线后，不改变指定deployment也没有在系统中遗留用于金丝雀发布的金丝雀pod的效果。
114.另一方面，如图3所示，本发明实施例提供一种金丝雀发布装置，包括：
115.查找deployment单元300，用于在kubernetes系统中找到要进行金丝雀发布的指定deployment；
116.金丝雀pod配置信息生成单元301，用于根据所述指定deployment管理的pod的配置信息，生成金丝雀pod的配置信息，所述金丝雀pod的配置信息中的选择标签与所述指定deployment管理的pod的配置信息中的选择标签相同；所述选择标签用于所述指定deployment相应的service实例将业务请求转发给所述金丝雀pod和所述指定deployment管理的pod；
117.金丝雀pod镜像设置单元302，用于将所述金丝雀pod的配置信息中的镜像地址设置为指定目标镜像的地址；
118.金丝雀pod生成单元303，用于调用kubernetes系统的接口根据所述金丝雀pod的配置信息直接生成金丝雀pod；
119.正式上线单元304，用于如果判断出所述金丝雀pod所提供服务的业务逻辑验证结果为通过，则将所述指定deployment的镜像地址设置为所述指定目标镜像的地址，完成发布上线。
120.进一步地，还包括：
121.接收发布请求单元，用于收到金丝雀发布请求时，调用打包工具将指定业务代码打包为所述指定目标镜像，并将所述指定目标镜像添加到镜像仓库中；
122.所述金丝雀发布请求包括所述指定deployment的名称、所述指定deployment的命名空间、所述镜像仓库的地址和所述打包工具的名称。
123.进一步地，还包括：
124.异常报警单元，用于如果判断出所述金丝雀pod的状态为非运行状态，则发出异常报警；
125.所述异常报警表示所述金丝雀pod不可用。
126.进一步地，还包括：
127.金丝雀pod下线单元，用于如果判断出所述金丝雀pod所提供服务的业务逻辑验证结果为没有通过，则将所述金丝雀pod下线。
128.进一步地，所述金丝雀pod下线单元，具体用于：
129.将所述金丝雀pod的配置信息中的选择标签修改为与所述指定deployment管理的pod的配置信息中的选择标签不相同。
130.进一步地，还包括；
131.金丝雀pod删除单元，用于在每次重新执行金丝雀发布前，将上次执行金丝雀发布时生成的金丝雀pod删除。
132.进一步地，还包括：
133.回滚单元，用于当收到的回滚请求时，将所述指定deployment的镜像地址设置为指定镜像地址；
134.所述指定镜像地址是在本次金丝雀发布执行前所述指定deployment使用过的任一镜像文件的地址。
135.进一步地，所述金丝雀pod配置信息生成单元301，包括：
136.pod选择模块，用于从所述指定deployment管理的pod中选择一个pod作为特定pod；
137.配置信息克隆模块，用于克隆所述特定pod对应的配置信息得到所述金丝雀pod对应的配置信息；
138.基本信息清除模块，用于删除所述金丝雀pod对应的配置信息中的状态信息、节点信息、ip信息和级联关系信息；
139.继承关系设置模块，用于将所述金丝雀pod对应的配置信息中的级联关系信息修改为继承自所述特定pod。
140.本领域技术人员可以根据关于一种金丝雀发布方法的实施例说明理解一种金丝雀发布装置对应的实施例，在此不再赘述。
141.另一方面，本发明实施例提供一种可读存储介质，其存储有用于实现如前述的任一项所述的方法对应的程序代码。
142.本发明实施例具有如下有益效果：通过直接使用kubernetes系统的接口根据指定deployment管理的pod的配置信息创建金丝雀pod，使得到的金丝雀pod独立于任何deployment，在不改变当前线上的指定deployment以及无需为kubernetes系统额外引入自定义资源的情况下实现基于kubernetes的简单易用的自动金丝雀发布，达到在不添加第三
方自定义资源，以最小资源开销的情况下实现基于kubernetes环境下的业务服务金丝雀发布的技术效果；进一步地，创建的金丝雀pod独立于任何deployment，在不改变当前线上的指定deployment的情况下实现自动金丝雀发布，达到对原有环境影响小，只需要操作一个pod即可完成金丝雀发布，其他kubernetes资源不需要修改的技术效果。充分利用kubernetes系统自身的service根据选择标签向pod分发请求的机制和deployment的回滚机制以最小开发成本实现了金丝雀发布过程的重复发布、流量上线、流量下线、回滚，达到显著提高实现金丝雀发布功能的效率，同时充分利用kubernetes的现有已经验证稳定可用的功能，使实现的金丝雀发布功能更加稳定可靠。
143.下面结合具体的应用实例对本发明实施例上述技术方案进行详细说明，实施过程中没有介绍到的技术细节，可以参考前文的相关描述。
144.api server是由kubernetes对外提供的api接口，逻辑处理模块通过此服务操作kubernetes上的各种资源，如ingress、service、deployment、pod、金丝雀pod等。
145.打包模块，主要作用是把业务代码即指定业务代码打包成镜像文件并推送镜像文件到镜像仓库中。这里逻辑处理模块只负责调用打包工具(如：jenkins、gitlab runner)的接口进行代码打包，打包结果会返回给逻辑处理模块用于判断打包是否成功。
146.逻辑处理模块(即金丝雀发布装置)：
147.如图2所示，开发需要进行金丝雀发布时，需要提供业务的deployment命名、deployment所在的命名空间、镜像仓库的地址、打包模块名称信息，发送http请求给逻辑处理模块；
148.逻辑处理模块收到请求后，会调用打包模块的接口触发打包工具(jenkins或者gitlab runner)进行代码的打包操作，打包完成后会把打包的镜像推送到镜像仓库中。如：此次打包的镜像版本为version2。
149.打包完成后，返回打包信息，如果打包成功逻辑处理模块，会调用api server，查找开发需要金丝雀发布的deployment(即指定deployment)，找到对应的deployment(即指定deployment)后，根据指定deployment的uid，找到指定deployment管理的三个pod(即图2中的pod01、pod02、pod03)，随机选取一个pod，获取此pod的配置信息。本发明实施例获取的pod为pod 03。如果打包失败，逻辑处理模块会返回给开发，告知打包失败，开发可以修改自己的代码后重新在进行金丝雀发布。
150.获取pod 03的配置信息后，克隆一份pod 03的配置信息，然后删除掉配置信息的状态信息、节点信息、ip信息、级联关系信息。
151.经过修改后的pod配置信息，会重新添加级联关系信息，此级联关系是pod 03与金丝雀pod的级联关系，为了让金丝雀pod，知道金丝雀pod是由pod 03克隆过来的。
152.修改金丝雀pod的镜像地址为新发布的version2版本的镜像地址，而不是pod 03中的version1的镜像地址。
153.终端用户通过域名请求服务后，请求会先到达ingress，ingress通过配置的service名，找到service，service再通过选择标签找到指定deployment管理的pod，最终由pod01、pod02和pod03对请求进行处理，由于金丝雀pod的标签配置与pod 03的相同，所以service也可以选择到金丝雀pod，从而请求也会分配到金丝雀pod上面。
154.如果金丝雀pod没有正常运行，由于service有检测机制，发现金丝雀pod的状态不
是运行状态，请求将不会发送到金丝雀pod上面，这样就达到了金丝雀发布的一个目的，检验服务的可用性。
155.如果金丝雀pod正常运行，请求便可以到达金丝雀pod上面，此时可以检测服务的业务逻辑是否有问题。如果发现业务逻辑有问题，开发可以发送下线流量请求给逻辑处理模块，逻辑处理模块调用api server，操作金丝雀pod，修改其标签信息，修改标签后service便不能通过标签找到金丝雀pod，终端用户请求便不会请求到金丝雀pod上面。这样可以避免问题扩大，达到了金丝雀发布的另一个目的，快速流量下线功能。
156.下线流量后开发修改代码后，可以再次进行金丝雀发布。此次发布，逻辑处理模块会删掉之前创建的金丝雀pod，保证金丝雀pod的配置是最新的，然后在重新创建金丝雀pod。
157.最终开发确认金丝雀发布成功后，逻辑处理模块开始正式上线，逻辑处理模块会调用api server更新指定deployment的镜像地址。指定deployment控制器发现指定deployment被修改后，会触发指定deployment管理的pod的滚动更新。即：重新创建新的pod的，等待新的pod正常运行后再删除旧的pod。滚动更新完的结果是：pod 01、pod02、pod03都将被删除，会有三个新pod被创建。
158.依赖于kubernetes gc垃圾回收机制，金丝雀pod的关联关系指向的是pod 03，pod 03在正式上线完成后已经被删除，kubernetes gc将触发垃圾回收机制删除金丝雀pod。保障最终上线完成后，整个新版本的环境和之前的版本的环境是完全相同的。
159.到此，整个金丝雀发布完成。用户请求的服务从version 1版本变成version 2版本。
160.如果开发正式上线完成后如发现服务的业务逻辑有问题，可以发送回滚请求给逻辑处理模块，请求里说明要回滚的版本。逻辑处理模块收到请求后调用api server，修改指定deployment的镜像地址。指定deployment控制器发现指定deployment被修改后，会触发pod的滚动更新，完成业务回滚。
161.本发明实施例具有如下技术效果：在不需要利用kubernetes系统的自定义资源功能引入自定义资源的情况下，即可实现基于kubernetes业务的金丝雀发布；对原有环境影响小，只需要操作一个pod即可完成金丝雀发布，其他kubernetes资源不需要修改。金丝雀发布过程，可以重复发布、流量上线、流量下线、回滚。
162.应该明白，公开的过程中的步骤的特定顺序或层次是示例性方法的实例。基于设计偏好，应该理解，过程中的步骤的特定顺序或层次可以在不脱离本公开的保护范围的情况下得到重新安排。所附的方法权利要求以示例性的顺序给出了各种步骤的要素，并且不是要限于所述的特定顺序或层次。
163.在上述的详细描述中，各种特征一起组合在单个的实施方案中，以简化本公开。不应该将这种公开方法解释为反映了这样的意图，即，所要求保护的主题的实施方案需要比清楚地在每个权利要求中所陈述的特征更多的特征。相反，如所附的权利要求书所反映的那样，本发明处于比所公开的单个实施方案的全部特征少的状态。因此，所附的权利要求书特此清楚地被并入详细描述中，其中每项权利要求独自作为本发明单独的优选实施方案。
164.为使本领域内的任何技术人员能够实现或者使用本发明，上面对所公开实施例进行了描述。对于本领域技术人员来说；这些实施例的各种修改方式都是显而易见的，并且本
文定义的一般原理也可以在不脱离本公开的精神和保护范围的基础上适用于其它实施例。因此，本公开并不限于本文给出的实施例，而是与本技术公开的原理和新颖性特征的最广范围相一致。
165.上文的描述包括一个或多个实施例的举例。当然，为了描述上述实施例而描述部件或方法的所有可能的结合是不可能的，但是本领域普通技术人员应该认识到，各个实施例可以做进一步的组合和排列。因此，本文中描述的实施例旨在涵盖落入所附权利要求书的保护范围内的所有这样的改变、修改和变型。此外，就说明书或权利要求书中使用的术语“包含”，该词的涵盖方式类似于术语“包括”，就如同“包括：”在权利要求中用作衔接词所解释的那样。此外，使用在权利要求书的说明书中的任何一个术语“或者”是要表示“非排它性的或者”。
166.本领域技术人员还可以了解到本发明实施例列出的各种说明性逻辑块(illustrative logical block)，单元，和步骤可以通过电子硬件、电脑软件，或两者的结合进行实现。为清楚展示硬件和软件的可替换性(interchangeability)，上述的各种说明性部件(illustrative components)，单元和步骤已经通用地描述了它们的功能。这样的功能是通过硬件还是软件来实现取决于特定的应用和整个系统的设计要求。本领域技术人员可以对于每种特定的应用，可以使用各种方法实现所述的功能，但这种实现不应被理解为超出本发明实施例保护的范围。
167.本发明实施例中所描述的各种说明性的逻辑块，或单元都可以通过通用处理器，数字信号处理器，专用集成电路(asic)，现场可编程门阵列或其它可编程逻辑装置，离散门或晶体管逻辑，离散硬件部件，或上述任何组合的设计来实现或操作所描述的功能。通用处理器可以为微处理器，可选地，该通用处理器也可以为任何传统的处理器、控制器、微控制器或状态机。处理器也可以通过计算装置的组合来实现，例如数字信号处理器和微处理器，多个微处理器，一个或多个微处理器联合一个数字信号处理器核，或任何其它类似的配置来实现。
168.本发明实施例中所描述的方法或算法的步骤可以直接嵌入硬件、处理器执行的软件模块、或者这两者的结合。软件模块可以存储于ram存储器、闪存、rom存储器、eprom存储器、eeprom存储器、寄存器、硬盘、可移动磁盘、cd-rom或本领域中其它任意形式的存储媒介中。示例性地，存储媒介可以与处理器连接，以使得处理器可以从存储媒介中读取信息，并可以向存储媒介存写信息。可选地，存储媒介还可以集成到处理器中。处理器和存储媒介可以设置于asic中，asic可以设置于用户终端中。可选地，处理器和存储媒介也可以设置于用户终端中的不同的部件中。
169.在一个或多个示例性的设计中，本发明实施例所描述的上述功能可以在硬件、软件、固件或这三者的任意组合来实现。如果在软件中实现，这些功能可以存储与电脑可读的媒介上，或以一个或多个指令或代码形式传输于电脑可读的媒介上。电脑可读媒介包括电脑存储媒介和便于使得让电脑程序从一个地方转移到其它地方的通信媒介。存储媒介可以是任何通用或特殊电脑可以接入访问的可用媒体。例如，这样的电脑可读媒体可以包括但不限于ram、rom、eeprom、cd-rom或其它光盘存储、磁盘存储或其它磁性存储装置，或其它任何可以用于承载或存储以指令或数据结构和其它可被通用或特殊电脑、或通用或特殊处理器读取形式的程序代码的媒介。此外，任何连接都可以被适当地定义为电脑可读媒介，例
如，如果软件是从一个网站站点、服务器或其它远程资源通过一个同轴电缆、光纤电缆、双绞线、数字用户线(dsl)或以例如红外、无线和微波等无线方式传输的也被包含在所定义的电脑可读媒介中。所述的碟片(disk)和磁盘(disc)包括压缩磁盘、镭射盘、光盘、dvd、软盘和蓝光光盘，磁盘通常以磁性复制数据，而碟片通常以激光进行光学复制数据。上述的组合也可以包含在电脑可读媒介中。
170.以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。