kubernetes 部署_Kubernetes和Istio的部署策略

kubernetes 部署

在这篇文章中，我将讨论各种部署策略以及如何使用K8和Istio实施它们。 基本上，所有策略的实现都基于K8同时运行微服务的多个版本的能力以及消费者只能通过某个入口点访问微服务的概念。 在那个入口点，我们可以控制应该将消费者路由到哪个版本的微服务。

本文的示例应用程序将是包装在Docker映像中的简单Spring Boot应用程序。 所以有两个图像
superapp：old和superapp：new分别代表应用程序的旧版本和新版本：

docker run -d –name old -p 9001：8080 eugeneflexagon / superapp：old

docker run -d –name new -p 9002：8080 eugeneflexagon / superapp：new

卷曲http：// localhost：9001 / version

{“ id”：1，“ content”：“ old”}

卷曲http：// localhost：9002 / version

{“ id”：1，“ content”：“ new”}

假设应用程序的旧版本已部署到运行在Oracle Kubernetes Engine上的K8s集群， 并且具有以下清单：

 apiVersion: apps/v1beta1  kind: Deployment  metadata: 
   name: superapp  spec: 
   replicas: 3 
   template: 
     metadata: 
        labels: 
          app: superapp 
     spec: 
       containers: 
         - name: superapp 
           image: eugeneflexagon/superapp:old 
           ports: 
             - containerPort: 8080 

因此，有一个Pod的三个副本运行旧版本的应用程序。 还有一项服务将流量路由到这些吊舱：

 apiVersion: v1  kind: Service  metadata: 
   name: superapp  spec: 
   selector: 
     app: superapp 
   ports: 
     - port: 8080 
       targetPort: 8080 

滚动更新

此部署策略以滚动更新的方式更新Pod，并逐一更改。

这是K8s群集本身处理的默认策略，因此我们只需要参考新映像来更新superapp部署：

 apiVersion: apps/v1beta1  kind: Deployment  metadata: 
   name: superapp  spec: 
   replicas: 3 
   template: 
     metadata: 
        labels: 
          app: superapp 
     spec: 
       containers: 
         - name: superapp 
           image: eugeneflexagon/superapp: new 
           ports: 
             - containerPort: 8080 

但是，我们可以通过在清单文件中为此部署策略提供参数来微调滚动更新算法：

 spec: 
   replicas: 3 
   strategy: 
     type: RollingUpdate 
     rollingUpdate: 
        maxSurge: 30 % 
        maxUnavailable: 30 % 
   template: 
   ... 

maxSurge参数定义可以在所需数量的容器上创建的最大容器数。 它可以是百分比或绝对数字。 默认值为25％。

maxUnavailable参数   定义在更新过程中不可用的Pod的最大数量。 它可以是百分比或绝对数字。 默认值为25％。

重新建立
这种部署策略将杀死所有旧的Pod，然后创建新的Pod。

 spec: 
   replicas: 3 
   strategy: 
     type: Recreate 
   template: 
   ... 

很简单。

蓝绿

此策略将应用程序的旧版本定义为绿色 ，将新版本定义为蓝色 。 用户始终只能访问绿色版本。

 apiVersion: apps/v1beta1  kind: Deployment  metadata: 
   name: superapp- 01  spec: 
   template: 
     metadata: 
        labels: 
          app: superapp 
          version: "01"  ...  apiVersion: v1  kind: Service  metadata: 
   name: superapp  spec: 
   selector: 
     app: superapp 
     version: "01"  ... 

该服务仅将流量路由到标签版本为“ 01”的窗格。

我们将蓝色版本部署到K8s集群，并使其仅用于QA或测试自动化工具（通过单独的服务或直接端口转发）。

 apiVersion: apps/v1beta1  kind: Deployment  metadata: 
   name: superapp- 02  spec: 
   template: 
     metadata: 
        labels: 
          app: superapp 
          version: "02"  ... 

一旦测试了新版本，我们就将服务切换到它并按比例缩小旧版本：

 apiVersion: v1  kind: Service  metadata: 
   name: superapp  spec: 
   selector: 
     app: superapp 
     version: "02"  ... 

 kubectl scale deployment superapp- 01 --replicas= 0 

完成此操作后，所有用户都将使用新版本。

因此，到目前为止，没有Istio。 一切都由开箱即用的K8s集群处理。 让我们继续下一个策略。

金丝雀
我喜欢这种部署策略，因为它可以让用户测试应用程序的新版本，而他们甚至都不知道。 我们的想法是，我们部署该应用程序的新版本，并将10％的流量路由到该应用程序。 用户对此一无所知。

如果一段时间，我们可以将流量平衡为70/30，然后是50/50，最后是0/100。
即使仅通过使用新旧Pod的数量就可以使用K8的资源来实施此策略，但使用Istio实施该方法更为方便。 因此，新旧应用程序定义为以下部署：

 apiVersion: apps/v1beta1  kind: Deployment  metadata: 
   name: superapp- 01  spec: 
   template: 
     metadata: 
        labels: 
          app: superapp 
          version: "01"  ... 

 apiVersion: apps/v1beta1  kind: Deployment  metadata: 
   name: superapp- 02  spec: 
   template: 
     metadata: 
        labels: 
          app: superapp 
          version: "02"  ... 

该服务将流量路由到它们两个：

 apiVersion: v1  kind: Service  metadata: 
   name: superapp  spec: 
   selector: 
     app: superapp  ... 

最重要的是，我们将使用以下Istio资源：
VirtualService和DestinationRule。

 apiVersion: networking.istio.io/v1alpha3  kind: DestinationRule  metadata: 
   name: superapp  spec: 
   host: superapp 
   subsets: 
   - name: green 
     labels: 
       version: "01" 
   - name: blue 
     labels: 
       version: "02"  ---  apiVersion: networking.istio.io/v1alpha3  kind: VirtualService  metadata: 
   name: superapp  spec: 
   hosts: 
     - superapp 
   http: 
   - match: 
     - uri: 
         prefix: /version 
     route: 
     - destination: 
         port: 
           number: 8080 
         host: superapp 
         subset: green 
       weight: 90 
     - destination: 
         port: 
           number: 8080 
         host: superapp 
         subset: blue 
       weight: 10 

VirtualService将根据提供的权重（90/10）将进入超级应用程序服务（主机）的所有流量路由到绿色和蓝色吊舱。

A / B测试

通过这种策略，我们可以精确地控制将哪些用户，哪些设备，部门等路由到该应用程序的新版本。

例如，在这里我们将分析请求标头，如果其自定义标签“最终用户”等于“ xammer” ，它将被路由到应用程序的新版本。 其余请求将路由到旧请求：

 apiVersion: networking.istio.io/v1alpha3  kind: VirtualService  metadata: 
   name: superapp  spec: 
   gateways: 
     - superapp 
   hosts: 
     - superapp 
   http: 
   - match: 
     - headers: 
         end-user: 
           exact: xammer 
     route: 
     - destination: 
         port: 
           number: 8080 
         host: superapp 
         subset: blue 
   - route: 
     - destination: 
         port: 
           number: 8080 
         host: superapp 
         subset: green 

GitHub上提供了此文章的所有示例和清单文件，因此您可以自己使用各种策略和复杂的路由规则。 您只需要预装Istio的K8s集群（例如，笔记本电脑上的Minikube）。 部署愉快！

而已！

翻译自: https://www.javacodegeeks.com/2019/04/deployment-strategies-kubernetes-istio.html

kubernetes 部署