Kubernetes

Istio add headers to a request

使用 containous/whoami 作为 deploy ，这个镜像可以方便的看到 headers

Hostname: whoami-f449bb88d-9lldn
IP: 127.0.0.1
IP: ::1
IP: 10.42.0.139
IP: fe80::389a:bcff:fe2b:d62d
RemoteAddr: 192.168.194.183:43655
GET / HTTP/1.1
Host: 192.168.194.183:30087
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.5
Connection: keep-alive
Upgrade-Insecure-Requests: 1

DestinationRule

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: who-desrule 
  namespace: who
spec: 
  host: whoamisvc.who.svc.cluster.local
  subsets:
  - name: v1 
    labels: 
      version: v1

Gateway

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: who-gateway
  namespace: who
spec:
  selector:
    istio: ingressgateway # use istio default controller
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*.com"

VirtualService

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: who-default
  namespace: who
spec:
  hosts:
  - "who.lizhe.com"
  gateways:
  - who-gateway
  http:
  - route:
    - destination:
        host: whoamisvc.who.svc.cluster.local
        subset: v1

在没开始加header之前我们看一下

然后我们修改 VirtualService来添加一个header

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: who-default
  namespace: who
spec:
  hosts:
  - "who.lizhe.com"
  gateways:
  - who-gateway
  http:
  - headers:
      request:
        add:
          lizhetoken: test123456789
    route:
    - destination:
        host: whoamisvc.who.svc.cluster.local
        subset: v1

不过如果你在请求中提前设置了 header，那么add动作将 不会覆盖 你设置的内容

curl who.lizhe.com -H lizhetoken:9999999

此时需要将 add改为 set

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: who-default
  namespace: who
spec:
  hosts:
  - "who.lizhe.com"
  gateways:
  - who-gateway
  http:
  - headers:
      request:
        set:
          lizhetoken: test123456789
    route:
    - destination:
        host: whoamisvc.who.svc.cluster.local
        subset: v1

而且 如果 header key 不存在， set 也会帮你添加

Nginx ingress 和 Istio ingressgateway 共存

默认情况下，rancher会安装 nginx ingress，占用 80 和 443 端口，使用的是 hostport

此时，如果想要再使用 istio 的边界网关，就无法使用 80 端口了，例如这里我们使用的是 nodeport

rancher默认会使用 443，我们可以把 nginx ingress上的80端口拆掉
这里我替换成 82

然后修改 istio ingressgateway 的端口，添加一个 80，并映射到 8080

同理也可以切换 https

重点是找准 ingress 服务的deploy

• rke2-ingress-nginx-controller
• istio-ingressgateway

Istio 整体架构

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

其中 控制平面 Pilot 负责管理 和 配置代理 来路由流量，并配置 Mixer 以实施策略和收集遥测数据
数据平面由一组 Envoy 以sidecar的方式组成，这些代理可以调节和控制微服务及Mixer之间所有的网络通信。

• Pilot 用于管理流量，例如 熔断、超时、重试 和 金丝雀发布等
• Mixer 用于提供策略控制 和 遥测数据收集等功能，是一个独立于平台的组件，负责在网格上执行 访问控制 和 使用策略，并从Envoy代理和其他服务收集遥测数据。
• Citadel 用于提供安全功能，例如 身份验证TLS加密等
• Galley 用于验证用户编写的 Istio API 配置

Envoy 代理

进程外：Envoy是一个独立进程，Envoy 之间形成一个透明的通信网格，每个应用程序发送消息到本地主机或者从本地主机接收消息，无需关心网络拓扑

单进程多线程模型：Envoy使用了单进程多线程的架构模型。一个主线程管理各种琐碎的任务，而一些工作子线程负责执行监听、过滤 和 转发功能

下游（Downstream）：连接到Envoy并发送请求，然后接收 response 的主机叫做下游

上游（Upstream）：接收请求的主机叫上游

监听器：监听器是命名网络地址，包括 端口、unix domain socket 等，可以被下游主机连接。Envoy暴露一个或者多个监听器给下游主机连接。

流量复制

流量复制可以把指向一个服务版本的流量复制到另一个版本的服务。这一功能能够将生产流量导入测试应用，在复制出来的镜像流量发出之后不会等到response。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: nginx-default-v2
  namespace: version
spec:
  hosts:
  - "hello.lizhe.com"
  gateways:
  - nginx-gateway
  http:
  - route:
    - destination:
        host: nginx-service.version.svc.cluster.local
        subset: v2
    mirror:
      host: nginx-service.version.svc.cluster.local
      subset: v3

通过上面的配置，我们把发给 v2 的流量同时复制给了 v3

注入中断

可以通过向服务调用过程注入中断的方式，测试服务通信中断的后果

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: nginx-default-v2
  namespace: version
spec:
  hosts:
  - "hello.lizhe.com"
  gateways:
  - nginx-gateway
  http:
  - route:
    - destination:
        host: nginx-service.version.svc.cluster.local
        subset: v2
    fault:
      delay:
        fixedDelay: 1s
        percentage:
          value: 100
      abort:
        httpStatus: 500
        percentage:
          value: 50

注入延迟

通过向服务调用注入延迟，可以测试服务通信不畅的后果。

1. 注入延迟

virtualservice.networking.istio.io/nginx-default-v2 configured
root@istio1:~/ver# cat vs.yaml 
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: nginx-default-v2
  namespace: version
spec:
  hosts:
  - "hello.lizhe.com"
  gateways:
  - nginx-gateway
  http:
  - route:
    - destination:
        host: nginx-service.version.svc.cluster.local
        subset: v2
    fault:
      delay:
        fixedDelay: 7s
        percentage:
          value: 100

服务熔断

没有使用 熔断 的 DestinationRule

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

可以看到 无论是 1 连接并发，还是 10 连接并发 都没有错误返回 （ 非 200 ）

服务熔断是一种保护措施，在服务实例无法正常提供服务的情况下，将其从负载均衡器中移除，不再分配任务

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: nginx-desrule 
  namespace: version
spec: 
  host: nginx-service.version.svc.cluster.local
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutiveErrors: 1
      interval: 1s
      baseEjectionTime: 3m
      maxEjectionPercent: 100
  subsets:
  - name: v1 
    labels: 
      version: v1
  - name: v2
    labels: 
      version: v2
  - name: v3
    labels: 
      version: v3

wrk -c 1 -t 1 http://hello.lizhe.com:31380/helloworld.html

加入了熔断之后，1 连接时候仍然是正常的，10连接并发的时候 75640 次请求中，出现了 71660 次错误

核心配置中

  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutiveErrors: 1
      interval: 1s
      baseEjectionTime: 3m
      maxEjectionPercent: 100

HTTP 和 TCP 连接池大小都是 1

maxConnections: 1
http1MaxPendingRequests: 1

每连接最大请求数

maxRequestsPerConnection: 1

只允许出错 1 次 （此方法已经过时）

consecutiveErrors: 1

没1秒做一次请求计数

interval: 1s

发生故障的的 pod 最少在被移除 3 分钟之后才能再次加入负载均衡池

baseEjectionTime: 3m

可以从负载均衡池中移除 100% 的 pod

maxEjectionPercent: 100

maxRequestsPerConnection 过时后 新的 配置

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: nginx-desrule 
  namespace: version
spec: 
  host: nginx-service.version.svc.cluster.local
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutive5xxErrors: 1
      consecutiveGatewayErrors: 1
      interval: 1s
      baseEjectionTime: 3m
      maxEjectionPercent: 100
  subsets:
  - name: v1 
    labels: 
      version: v1
  - name: v2
    labels: 
      version: v2
  - name: v3
    labels: 
      version: v3

outlier detection consecutive errors is deprecated, use consecutiveGatewayErrors or consecutive5xxErrors instead
destinationrule.networking.istio.io/nginx-desrule configured

Istio配置文件中的host

不使用gateway的情况

如果没有gw，那么只需要 DestinationRule 和 VirtualService 就可以了

在DestinationRule中，host 需要对应的是 Kubernetes中的service

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: nginx-desrule 
  namespace: lizhe
spec: 
  host: nginx-service
  subsets:
  - name: v1 
    labels: 
      version: v1
  - name: v2
    labels: 
      version: v2
  - name: v3
    labels: 
      version: v3

对应的VirtualService

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: nginx-default
  namespace: version
spec: 
  hosts:
  - nginx-service
  http:
  - route: 
    - destination: 
        host: nginx-service
        subset: v2

此时使用以下3种内部dns都可以访问

curl nginx-service/helloworld.html
curl nginx-service.version/helloworld.html
curl nginx-service.version.svc/helloworld.html

使用Gateway的情况

创建一个 Gateway

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: nginx-gateway
  namespace: version
spec:
  selector:
    istio: ingressgateway # use istio default controller
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*.lizhe.com"

再创建DestinationRule

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

最后用一个VirtualService把它们两个粘在一起

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: nginx-default-v2
  namespace: version
spec:
  hosts:
  - "hello.lizhe.com"
  gateways:
  - nginx-gateway
  http:
  - route:
    - destination:
        host: nginx-service.version.svc.cluster.local
        subset: v2

对于service可以使用全量名

下面是一个错误例子

不过可以使用 通配符 *

root@istio1:~/yamls# cat dr.yaml 
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: nginx-desrule 
  namespace: version
spec: 
  host: nginx-service.version.svc.cluster.local
  subsets:
  - name: v2
    labels: 
      version: v2

root@istio1:~/yamls# cat vs.yaml 
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: nginx-default
  namespace: version
spec: 
  hosts:
  - "*.version.svc.cluster.local"
  http:
  - route: 
    - destination: 
        host: nginx-service.version.svc.cluster.local
        subset: v2

root@istio1:~/yamls# kubectl apply -f ./
destinationrule.networking.istio.io/nginx-desrule unchanged
virtualservice.networking.istio.io/nginx-default configured
root@istio1:~/yamls# 

gw和vs匹配

使用2个 VirtualService ，一个持有 Gateway，一个不持有Gateway

Traefik sticky session

Traefik的模型是

route -> traefik service -> k8s service -> pod

这里构建了3个pod，分别对应3个 k8s service

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: whoingressroute
  namespace: who
spec:
  entryPoints:
    - web
  routes:
  - match: Host(`who.lizhe.com`)
    kind: Rule
    services:
    - name: whots
      kind: TraefikService

apiVersion: traefik.containo.us/v1alpha1
kind: TraefikService
metadata:
  name: whots
  namespace: who
spec:
  weighted:
    services:
      - name: whoami1
        weight: 3  # 定义权重
        port: 80
        kind: Service  # 可选，默认就是 Service
      - name: whoami2
        weight: 3  # 定义权重
        port: 80
        kind: Service  # 可选，默认就是 Service
      - name: whoami3
        weight: 3  # 定义权重
        port: 80
        kind: Service  # 可选，默认就是 Service

修改ts

apiVersion: traefik.containo.us/v1alpha1
kind: TraefikService
metadata:
  name: whots
  namespace: who
spec:
  weighted:
    sticky:
      cookie:
        name: traefiktoken
    services:
      - name: whoami1
        weight: 3  # 定义权重
        port: 80
        kind: Service  # 可选，默认就是 Service
      - name: whoami2
        weight: 3  # 定义权重
        port: 80
        kind: Service  # 可选，默认就是 Service
      - name: whoami3
        weight: 3  # 定义权重
        port: 80
        kind: Service  # 可选，默认就是 Service

这种模型上，很难受的一个点是，它的负载均衡不是落在 pod 上的，而是落在 service 上，这样pod在伸缩之后，你还需要修改对应的 service，实际应用没有 ingress 那么方便

更新

不使用 traefik service 的话，可以直接将 sticky 写在 ingress route 上

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: backendingress
  namespace: backend
spec:
  entryPoints:
    - web
  routes:
    - match: Host(`nginx.lizhe.com`) && PathPrefix(`/backend`)
      kind: Rule
      services:
        - name: myservice
          port: 8080
          sticky:
            cookie:
              httpOnly: true
              name: mytickytoken
      middlewares:
        - name: backend-stripprefix

上面的例子也可以直接使 IngressRoute 指向 kubernetes的service

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: whoingressroute
  namespace: lizhe
spec:
  entryPoints:
    - web
  routes:
  - match: Host(`who.lizhe.com`)
    kind: Rule
    services:
    - name: whoami
      port: 80
      sticky:
        cookie:
          httpOnly: true
          name: lizhetoken
          

Ingress sticky session

测试用的 deployment

测试用的 ingress

使用的镜像是 containous/whoami ， 显示出来的效果是这样的

把 pod 数改成 3 之后，很容易就可以得到下面的情况，请求会在3个pod之间轮训

添加annotation就可以了

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/affinity: "cookie"
    nginx.ingress.kubernetes.io/session-cookie-name: "ingresscoookie"
    nginx.ingress.kubernetes.io/session-cookie-hash: "sha1"
    nginx.ingress.kubernetes.io/session-cookie-expires: "172800"
    nginx.ingress.kubernetes.io/session-cookie-max-age: "172800"