K8S 金丝雀部署之 Istio

什么是金丝雀发布?

金丝雀发布（Canary）：也是一种发布策略，和国内常说的灰度发布是同一类策略。蓝绿部署是准备两套系统，在两套系统之间进行切换，金丝雀策略是只有一套系统，逐渐替换这套系统。

什么是 Istio ?

使用云平台可以为组织提供丰富的好处。然而，不可否认的是，采用云可能会给 DevOps 团队带来压力。开发人员必须使用微服务以满足应用的可移植性，同时运营商管理了极其庞大的混合和多云部署。Istio 允许您连接、保护、控制和观测服务。

在较高的层次上，Istio 有助于降低这些部署的复杂性，并减轻开发团队的压力。它是一个完全开源的服务网格，可以透明地分层到现有的分布式应用程序上。它也是一个平台，包括允许它集成到任何日志记录平台、遥测或策略系统的 API。Istio 的多样化功能集使您能够成功高效地运行分布式微服务架构，并提供保护、连接和监控微服务的统一方法。

为什么要使用 Istio ?

Istio 提供一种简单的方式来为已部署的服务建立网络，该网络具有负载均衡、服务间认证、监控等功能，只需要对服务的代码进行一点或不需要做任何改动。想要让服务支持 Istio，只需要在您的环境中部署一个特殊的 sidecar 代理，使用 Istio 控制平面功能配置和管理代理，拦截微服务之间的所有网络通信：

  • HTTP、gRPC、WebSocket 和 TCP 流量的自动负载均衡。
  • 通过丰富的路由规则、重试、故障转移和故障注入，可以对流量行为进行细粒度控制。
  • 可插入的策略层和配置 API，支持访问控制、速率限制和配额。
  • 对出入集群入口和出口中所有流量的自动度量指标、日志记录和追踪。
  • 通过强大的基于身份的验证和授权，在集群中实现安全的服务间通信。

Istio 旨在实现可扩展性，满足各种部署需求

Istio 架构

Istio 服务网格逻辑上分为数据平面和控制平面。

  • 数据平面：由一组以 sidecar 方式部署的智能代理（Envoy）组成。这些代理可以调节和控制微服务及 Mixer之间所有的网络通信。
  • 控制平面：负责管理和配置代理来路由流量。此外控制平面配置 Mixer 以实施策略和收集遥测数据。

下图显示了构成每个面板的不同组件：

Istio 金丝雀部署

  • 定义 service 服务
apiVersion: v1
kind: Service
metadata:
  name: demo4
  namespace: test1
  labels:
    app: demo4
spec:
  ports:
    - port: 80
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app: demo4
  • 定义两个版本的 deploy 文件，两个版本都包含服务选择标签 app：demo4
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: demo4-deployment-v1
  namespace: test1
spec:
  replicas: 1
  template:
    metadata:
      annotations:
        # 允许注入 sidecar
        sidecar.istio.io/inject: "true"
      labels:
        app: demo4
        version: v1
    spec:
      containers:
      - name: demo4-v1
        image: mritd/demo
        livenessProbe:
          httpGet:
            path: /
            port: 80
            scheme: HTTP
          initialDelaySeconds: 30
          timeoutSeconds: 5
          periodSeconds: 10
          successThreshold: 1
          failureThreshold: 5
        readinessProbe:
          httpGet:
            path: /
            port: 80
            scheme: HTTP
          initialDelaySeconds: 30
          timeoutSeconds: 5
          periodSeconds: 10
          successThreshold: 1
          failureThreshold: 5
        ports:
          - name: http
            containerPort: 80
            protocol: TCP

---

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: demo4-deployment-v2
  namespace: test1
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: demo4
        version: v2
      annotations:
        sidecar.istio.io/inject: "true"
    spec:
      containers:
      - name: demo4-v2
        image: mritd/demo
        livenessProbe:
          httpGet:
            path: /
            port: 80
            scheme: HTTP
          initialDelaySeconds: 30
          timeoutSeconds: 5
          periodSeconds: 10
          successThreshold: 1
          failureThreshold: 5
        readinessProbe:
          httpGet:
            path: /
            port: 80
            scheme: HTTP
          initialDelaySeconds: 30
          timeoutSeconds: 5
          periodSeconds: 10
          successThreshold: 1
          failureThreshold: 5
        ports:
          - name: http
            containerPort: 80
            protocol: TCP

上面定义和普通k8s定义蓝绿部署是一样的

  • 设置路由规则来控制流量分配。如将 10％ 的流量发送到金丝雀版本（v2）。后面可以渐渐的把所有流量都切到金丝雀版本（v2），只需要修改weight: 10参数，注意v1和v2版本和一定要等于100
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: demo4-vs
  namespace: test1
spec:
  hosts:
  - demo4.a.com
  gateways:
  - demo4-gateway
  http:
  - route:
    - destination:
        host: demo4.test1.svc.cluster.local
        subset: v1
      weight: 90
    - destination:
        host: demo4.test1.svc.cluster.local
        subset: v2
      weight: 10

---

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: demo4
  namespace: test1
spec:
  host: demo4.test1.svc.cluster.local
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

当规则设置生效后，Istio 将确保只有 10% 的请求发送到金丝雀版本，无论每个版本的运行副本数量是多少。

高层次的金丝雀部署

  • 只允许特定网站上50％的用户流量路由到金丝雀（v2）版本，而其他用户则不受影响
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: demo4-vs
  namespace: test1
spec:
  hosts:
  - demo4.a.com
  gateways:
  - demo4-gateway
  http:
  - match:
    - headers:
        cookie:
          regex: "^(.*?;)?(email=[^;]*@some-company-name.com)(;.*)?$"
    route:
    - destination:
        host: demo4.test1.svc.cluster.local
        subset: v1
        weight: 50
    - destination:
        host: demo4.test1.svc.cluster.local
        subset: v2
        weight: 50
  - route:
    - destination:
        host: demo4.test1.svc.cluster.local
        subset: v1

VirtualService 与 DestinationRule 解释

  • Istio Virtual Service，用于控制当前deployment和金丝雀deployment流量分配的权重
  • Istio Destination Rule，包含当前deployment和金丝雀deployment的子集（subset）
  • Istio Gateway（可选），如果服务需要从容器集群外被访问则需要搭建gateway

总结

本文中，我们看到了 Istio 如何支持通用可扩展的金丝雀部署。Istio 服务网格提供了管理流量分配所需的基础控制，并完全独立于部署缩放。这允许简单而强大的方式来进行金丝雀测试和上线。

支持金丝雀部署的智能路由只是 Istio 的众多功能之一，它将使基于大型微服务的应用程序的生产部署变得更加简单。查看 istio.io 了解更多信息。

参考链接

关注我

欢迎大家关注交流，定期分享自动化运维、DevOps、Kubernetes、Service Mesh和Cloud Native

原文地址：https://blog.51cto.com/yangpeng14/2453422

时间： 2024-08-01 08:18:15

K8S 金丝雀部署之 Istio的相关文章

K8S二进制部署master节点

在完成前面的K8S基础组件配置之后,我们就可以正式开始K8S的部署工作.本文介绍在k8s master组件的二进制部署过程,由于环境为内网开发和测试环境,所以仅考虑etcd组件的高可用,api-server.controller-manager和scheduler的高可用暂不考虑,后续可以使用keepalive的方式实现. 一.软件包下载地址Server包: https://dl.k8s.io/v1.9.6/kubernetes-server-linux-amd64.tar.gz 二.部署mas

持续集成之应用k8s自动部署

原文:持续集成之应用k8s自动部署 持续集成之应用k8s自动部署 Intro 上次我们提到了docker容器化及自动化部署,这仅仅适合个人项目或者开发环境部署,如果要部署到生产环境,必然就需要考虑很多因素,比如访问量大了如何调整部署,如何更好的应对大并发的情况,如何不停机更新应用,如果想要将Docker应用于具体的业务实现,是存在困难的--编排.管理和调度等各个方面,都不容易.于是,人们迫切需要一套管理系统,对Docker及容器进行更高级更灵活的管理,于是 k8s 就出现了. K8S,就是基于容

K8S CoreDNS部署失败，发现的一个问题

K8S CoreDNS部署失败,查看错误日志,提示如下 root >> kubectl get all --all-namespaces -o wide root >> kubectl logs -f coredns-56f56989d6-krs6h -n kube-system 错误提示,如下: Failed to list *v1.Namespace: Get https://10.3.0.1:443/api/v1/namespaces?limit=500&resour

k8s二进制部署

k8s二进制部署 1.环境准备 主机名 ip地址 角色 k8s-master01 10.0.0.10 master k8s-master02 10.0.0.11 master k8s-node01 10.0.0.12 node k8s-node02 10.0.0.13 node 初始化操作 关闭防火墙 关闭selinux 关闭swap 安装ntp使时间同步 配置域名解析 配置免密 k8s-master01 到其他机器. 安装docker 2.生成配置CFSSL CFFSL能够构建本地CA,生成后

Spark on K8S环境部署细节

Spark on K8S环境部署细节 sparkk8s time: 2020-1-3 Spark on K8S环境部署细节 Spark operator安装 准备kubectl客户端和Helm客户端 安装spark operator Spark wordcount 读写OSS 准备oss依赖的jar包 准备core-site.xml 打包支持读写oss的镜像 下载spark安装包解压 打包发布镜像 准备wordcount作业 1. spark submit 提交 2. spark operato

k8s中部署基于nfs的StorageClass

k8s中部署基于nfs的StorageClass ? storageclass相当于是一个动态的存储,即每个pod需要多少容量,直接在配置资源清单中声明即可;但是nfs默认是不支持storageclass动态存储的. ? 总结一下就是: ? 1. 平时使用过程中,如果是静态的存储,那么过程是先准备好存储,然后基于存储创建PV;然后在创建PVC,根据容量他们会找对应的PV ? 2. 使用动态存储,那么就是先准备好存储,然后直接创建PVC,storageclass会根据要求的大小自动创建PV 首先安

kubernetes实战(十四)：k8s持久化部署gitlab集成openLDAP登录

1.基本概念 使用k8s安装gitlab-ce,采用GlusterFS实现持久化,并集成了openLDAP. 注意:我公司使用的gitlab是独立于k8s集群之外的. 2.安装部署 最一开始使用的是helm安装gitlab,网上的文档应该全部都是使用的这个chart:https://github.com/helm/charts/tree/master/stable/gitlab-ce 但是这个chart已经被弃用,并推荐我们使用官方的chart 官方chart:https://docs.gitl

K8S CoreDNS部署失败，问题分析

1. 查询k8s集群部署pod的基本情况 如下图,我们可知容器coredns和dnsutils都部署成功,但是由于域名解析的问题,导致coredns和dnsutils的容器不断重启(原因heath检查,无法请求成功,被kubelet重启了pod) 命令如下: root >> kubectl get all --all-namespaces -o wide root >> kubectl describe pod coredns-57bbd778b9-kxl7b -n kube-sy

K8S安装部署在centos7下

所有节点操作 K8S的安装部署可以参考文档: 需要在每一台机器上执行的操作 l 各节点禁用防火墙 # systemctl stop firewalld # systemctl disable firewalld l 禁用SELINUX: # setenforce 0 # sed -i ‘s/SELINUX=enforcing/SELINUX=disabled/g‘ /etc/selinux/config # SELINUX=disabled l 创建/etc/sysctl.d/k8s.conf文