阿里云istio使用初体验

由于阿里云在整合istio时, 进行了内部定制,导致好多外部资料上编写的通过istioctl指令操作的步骤,无法在ask/asm上实施.

参考: https://help.aliyun.com/document_detail/176082.html?spm=a2c4g.11186623.6.556.2b562f596DWhZn

istioctl指令

0x01 部署服务端

部署内容为python接口服务, 有两个版本, 对应两个deployment.
这里直接用kubectl 部署两个版本应用, 同时部署一份service

• v1

apiVersion: apps/v1
kind: Deployment
metadata:
  name: flaskapp-v1
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: flaskapp
        version: v1
    spec:
      containers:
        - name: flaskapp
          image:  {falskapp.image.url}
          imagePullPolicy: IfNotPresent
          env:
            - name: version
              value: v1
  selector:
    matchLabels:
      app: flaskapp
      version: v1
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: flaskapp-v2
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: flaskapp
        version: v2
    spec:
      containers:
        - name: flaskapp
          image: {imageUrl}
          imagePullPolicy: IfNotPresent
          env:
            - name: version
              value: v2
  selector:
    matchLabels:
      app: flaskapp
      version: v2
---
apiVersion: v1
kind: Service
metadata:
  name: flaskapp
  labels:
    app: flaskapp
spec:
  selector:
    app: flaskapp
  ports:
    - port: 80
      name: http

由于上一篇文章中, 已经对当前namespace做了自动注入istio-agent的label, 所以, 在查看pod 信息的时候, 会发现pod里的containers 为2

0x02 部署客户端

编写纯k8s风格的部署文件:

apiVersion: v1
kind: Service
metadata:
  name: sleep
  labels:
    app: sleep
    version: v1
spec:
  selector:
    app: sleep
    version: v1
  ports:
    - name: ssh
      port: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sleep
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: sleep
        version: v1
    spec:
      containers:
        - name: sleep
          image: dustise/sleep
          imagePullPolicy: IfNotPresent
      restartPolicy: Always
  selector:
    matchLabels:
      app: sleep
      version: v1

0x03 验证

第2步相当于在集群内部署了一份客户端, 现在可以通过kubectl 登录到客户端上, 进行服务验证

kubectl exec -it sleep-d798b647b-wfx72 -c sleep bash

关于 http 指令:
usage: http [--json] [--form] [--compress] [--pretty {all,colors,format,none}] [--style STYLE] [--print WHAT] [--headers] [--body] [--verbose] [--all] [--history-print WHAT] [--stream] [--output FILE] [--download] [--continue]
[--session SESSION_NAME_OR_PATH | --session-read-only SESSION_NAME_OR_PATH] [--auth USER[:PASS]] [--auth-type {basic,digest}] [--ignore-netrc] >[--offline] [--proxy PROTOCOL:PROXY_URL] [--follow] [--max-redirects MAX_REDIRECTS] [--max-headers MAX_HEADERS]
[--timeout SECONDS] [--check-status] [--path-as-is] [--verify VERIFY] [--ssl {ssl2.3,tls1,tls1.1,tls1.2}] [--cert CERT] [--cert-key CERT_KEY] [--ignore-stdin] [--help] [--version] [--traceback] [--default-scheme DEFAULT_SCHEME] [--debug]
[METHOD] URL [REQUEST_ITEM [REQUEST_ITEM ...]]

登录后, 执行pod里自带的http命令, 进行服务验证
多次执行: http --body http://flaskapp/env/version, 查看结果:

http 服务验证

小结

• 在istio中发布的deployment , 必需都要配置相应的Service , 否则istio 无法处理
• http://flaskapp/env/version 其中的 flaskapp, 正在是上面的service 名称, 由于 service 中没有对两个版本进行权重设置, 两个应用以相同的机率返回结果.

0x04 配置DestinationRule

利用pod 的label, 把pod分成两类, 流量定义如下

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: flaskapp
spec:
  host: flaskapp
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

其中, host字段的值, 可以理解为Service 的名称.

注意: 这里的 apiVersion 是istio独有的, 所以在发布时候, 要使用asm的config, 进行发布.

0x05 配置 VirtualService

定义一个istio的vs(VirtualService), 指定默认的请求流量, 全部打到 v2 的 pod上,
这里的 v2 由上面的 dr 来定义

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: flaskapp-default-v2
spec:
  hosts:
    - flaskapp
  http:
    - name: "default-v2"
      route:
        - destination:
            host: flaskapp
            subset: v2

此时, 再来请求:

k exec -it sleep-d798b647b-wfx72 -n m7 -c sleep bash
http --body http://flaskapp/env/version
http --body http://flaskapp/env/version
http --body http://flaskapp/env/version

v2流量

此时, 发现所有请求, 全部打到了 v2 节点上.

0x06 部署网关

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name:  flask-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 81
        name: http
        protocol: HTTP
      hosts:
        - "*"

如上apiVersion所示, 这里使用的是istio的crd, 所以要使用istio的config进行部署.

这里为什么要设置端口 81 呢, 主要是集群里已经有了一个80端口占用,这里直接使用istio ingress 的4层协议, 增加一个81端口转发:

手动增加ingress gateway端口

同时, 需要修改上面的VirtualService 配置:
可以使用在线修改方式: kubectl edit vs flaskapp-default-v2 -n demo

spec:       
  gateways:
  - flask-gateway
  hosts: 
  - '*'  
  http:  
  - name: default-v2
    route:
    - destination:
        host: flaskapp                                                                                                                                                             
        subset: v2

主要修改点两个:

• 关联入口网关
• 修改hosts 为 "*"

然后, 就可以在集群外部, 测试这个接口请求:

curl 172.16.64.222:81/env/version
v2

到此, 一个完整的istio发布过程结束

0x07 小结

• 学会使用 sleep 镜像, 在集群内部进行调试, 支持指令: wget, curl, http... 等.
• 初步体验了 istio 中的 Deployment, Service, DestinationRule, VirtualServce 使用方法.
• 结合上一篇, 基本可以和外部的 gateway 串起来.

访问关系图