特别教程:如何利用Kubernetes和Istio实现蓝绿部署

栏目: 编程工具 · 发布时间: 6年前

内容简介:原作by Janakiram MSV 19 Oct 2018原文链接:译者介绍

原作by Janakiram MSV 19 Oct 2018

原文链接: https://thenewstack.io/tutoria ... stio/ (翻译:吴世曦/Heinz Wu)

译者介绍

吴世曦/Heinz Wu,戴姆勒大中华区投资有限公司 IT Service Manager,DockerOne社区译者

Istio是第二代Service Mesh(服务网格)的主流方案之一,它的设计初衷在于加强微服务之间通信的稳定性,透明度和安全性。Istio拦截部署在容器平台(如Kubertenes)服务的内部外部流量。

虽然Istio支持如加密服务间的通信,参数日志自动收集,加强的访问控制策略,限速,配额管理等诸多功能,我们此次教程只专注于流量管理这个特性。

Istio使得DevOps团队通过创建规则,让流量可以被智能的路由到内部的服务。Istio也使得类似熔断,超时,重试这样的服务属性相关的设置变得极为简单,也可以通过一系列的参数设置实现蓝绿部署和金丝雀实施(canary rollouts)。

这个教程的目标就是帮助你理解如何配置Istio实现Kubernetes平台上微服务的蓝绿部署。你只要具备Kubenetes pods ,service相关的基础知识,就能看懂这个教程。我们会从Minikube 到 Istio 再到简单的应用,逐一进行配置。

这个教程会分成四个步骤 - Minikube的安装;Istio的安装和验证;同一个应用的两个不同版本的安装;以及蓝绿部署服务的最终配置。我们已经准备好了两个简单的容器镜像,他们分用于表蓝色(V1)和绿色(V2)的发布。

第一步:安装Minikube

为了减少依赖性,我们用Minikube作为实验平台。因为我们需要对Minikube做定制的配置,所以先删除现有的配置然后设置一些参数并重启集群。

$ minikube start --memory=8192 --cpus=4 --kubernetes-version=v1.10.0 \

--extra-config=controller-manager.cluster-signing-cert-file="/var/lib/localkube/certs/ca.crt" \

--extra-config=controller-manager.cluster-signing-key-file="/var/lib/localkube/certs/ca.key" \

--vm-driver=virtualbox

在Minikube中运行Istio需要至少8GB内存和四核CPU。这里我们等待集群启动。

第二步:安装 Istio

Kubernetes启动以后,开始安装 Istio。我们通过下面的步骤来做配置

$ curl -L https://git.io/getLatestIstio | sh -

你会发现一个叫istio-1.0.2的文件夹,所有的命令也都在这个目录下运行。可以在把istio-1.0.2/bin这个目录加到PATH变量中,这样敲命令就更简单了。

既然我们已经在Minikube中运行了Istio,进行下一步之前我们还需要做个小调整 - 把Ingress网关的服务类型从LoadBalancer 改成 NodePort.

打开istio-1.0.2/install/kubernetes/istio-demo.yaml,搜索LoadBalancer关键字,然后把它改成NodePort

Istio 有很多针对Kubernetes的自定义资源类型Custom Resource Definitions (CRD)。这些资源类型帮助我们利用kubectl操作虚拟服务,规则,网关以及其他Istio相关的对象。在部署Service Mesh(服务网格)之前,我们先要安装自定义资源类型。

$ kubectl apply -f install/kubernetes/helm/istio/templates/crds.yaml

最终我们开始在Kubernetes上安装Istio

$ kubectl apply -f install/kubernetes/istio-demo.yaml

上面的步骤创建了一个叫istio-system的新命名空间,在这个命名空间里我们会继续部署更多的对象

我们能发现很多服务都在 istio-system这个命名空间中自动创建了

几分钟以后,你会看到 Istio部署了很多pods。我们可以通过运行kubectl get pods -n=istio-system来验证。

当所有的pods状态都是运行或者完成的状态,就意味着Istio已经被成功的安装和配置了。

现在我们就已经可以开始部署和配置蓝绿服务的参数了

第三部:部署同一个应用的两个版本

我们用简单的Nginx的容器镜像来作为应用案例– janakiramm/myapp:v1 和janakiramm/myapp:v2。部署完成之后,这两个版本的Nginx会分别显示蓝色或者绿色背景的静态页面。我们用这些图像来完成我们的教程。

apiVersion: v1

kind: Service

metadata:

name: myapp

labels:

app: myapp

spec:

type: ClusterIP

ports:

- port: 80

name: http

selector:

app: myapp

apiVersion: extensions/v1beta1

kind: Deployment

metadata:

name: myapp-v1

spec:

replicas: 1

template:

metadata:

labels:

app: myapp

version: v1

spec:

containers:

- name: myapp

image: janakiramm/myapp:v1

imagePullPolicy: IfNotPresent

ports:

- containerPort: 80

apiVersion: extensions/v1beta1

kind: Deployment

metadata:

name: myapp-v2

spec:

replicas: 1

template:

metadata:

labels:

app: myapp

version: v2

spec:

containers:

- name: myapp

image: janakiramm/myapp:v2

imagePullPolicy: IfNotPresent

ports:

- containerPort: 80

你可以从Github获得相关的YAML文件。

我们先从创建YAML文件开始,来定义V1和V1版本Nginx的部署,同时也设置集群IP把服务暴露出来。请注意我们用不同的标签来区分pods, app和版本。因为两次部署的版本号不一样,app名字可以相同。

这是Istio所希望的,像单一的app那样处理它们,用不同的个版本来区分。

集群的服务定义也是一样的,标签,app: myapp关联了基于不同版本所创建的pods。

通过kubectl来创建deployment和service。注意deployment和service是Kubernetes的相关术语,和Istio没有关系。唯一和Istio的关联是我们为deployment和service创建标签的方式。

$ kubectl apply -f myapp.yaml

配置 Istio之前,我们先来检查一下app的版本。我么可以通过port-forward deployments 访问pods。通过运行下面的命令访问V1的8080端口。准备好CTRL+C 吧。

$ kubectl port-forward deployment/myapp-v1 8080:80

运行下面的命令访问V2的8081端口,继续CTRL+C

$ kubectl port-forward deployment/myapp-v2 8081:80

第四步:配置蓝绿部署

我们的实验目标是让流量有选择的访问某一个部署,而且不能有服务停止。为了达到这目的,我们要告诉Istio依照权重来路由流量。

为了达到这个效果我们需要设置三个对象

网关

Istio网关描述了在网格边界的负载均衡器如何处理进出的 HTTP/TCP连接。着重描述了哪些端口应该被暴露出来,有哪些协议可以用,负载均衡器的SNI配置等等。接下来,我们把网关指向默认的Ingress 网关,它在 Istio安装的时候就被创建出来了。

让我们来创建网关

apiVersion: networking.istio.io/v1alpha3

kind: Gateway

metadata:

name: app-gateway

spec:

selector:

istio: ingressgateway

servers:

- port:

number: 80

name: http

protocol: HTTP

hosts:

- "*"

目的地规则

Istio目的地规则定义了流量被路由以后访问服务的规则。请注意在Kubernete中这个规则是如何利用标签来声明的。

apiVersion: networking.istio.io/v1alpha3

kind: DestinationRule

metadata:

name: myapp

spec:

host: myapp

subsets:

- name: v1

labels:

version: v1

- name: v2

labels:

version: v2

虚拟服务

虚拟服务定义了当主机获得地址以后一系列流量的路由规则。每一条路由规则都定义了某个基于特定协议的流量的匹配规则。当一个流量被匹配了,基于版本,它会被发送到相关的目标服务。在下面的操作中,我们声明了V1和V2的权重都为50,这就意味着流量会被平均分配

apiVersion: networking.istio.io/v1alpha3

kind: VirtualService

metadata:

name: myapp

spec:

hosts:

- "*"

gateways:

- app-gateway

http:

- route:

- destination:

host: myapp

subset: v1

weight: 50

- destination:

host: myapp

subset: v2

weight: 50

你可以把上面的YAML文件合成一个,同样可以用kubectl运行。你可以在Github Gist找到相关的YAML文件。

$ kubectl apply -f app-gateway.yaml

现在我们来继续访问服务,既然我们用了 Minikube和NodePort,我们需要知道Ingress 网关到底运行在哪个端口

运行下面的命令来访问Minikube和Ingress port。

$ export INGRESS_HOST=$(minikube ip)

$ export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].nodePort}')

如果你能通过浏览器访问URL,你就能看到访问蓝色和绿色的流量是平均分配的。你也可以从终端看到结果。在终端运行下面的命令来看来自V1和V2的不同反馈。

while : ;do export GREP_COLOR='1;33';curl -s 192.168.99.100:31380 \

| grep --color=always "V1" ; export GREP_COLOR='1;36';\

curl -s 192.168.99.100:31380 \

| grep --color=always "vNext" ; sleep 1; done

上面的命令在循环运行,现在我们去更改app-gateway.yaml文件,把V1的权重改成0,V2的权重改成100

提交这个新的配置给Istio。

$ istioctl replace -f app-gateway.yaml

当权重变化以后,100%的流量立即就路由到了V2。这个变化可以从第一个终端窗口看到。

你可以继续调整权重并观察流量被动态的重新路由,这些调整并没有产生任何服务终止。

流量管理只是 Istio的特性之一。接下来的文章中,让我们继续探索 Istio的其他功能。


以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Tango with Django

Tango with Django

David Maxwell、Leif Azzopardi / Leanpub / 2016-11-12 / USD 19.00

Tango with Django is a beginner's guide to web development using the Python programming language and the popular Django web framework. The book is written in a clear and friendly style teaching you th......一起来看看 《Tango with Django》 这本书的介绍吧!

JS 压缩/解压工具
JS 压缩/解压工具

在线压缩/解压 JS 代码

CSS 压缩/解压工具
CSS 压缩/解压工具

在线压缩/解压 CSS 代码

URL 编码/解码
URL 编码/解码

URL 编码/解码