Author: studyk8s

对Ingress gateway的补充

Ingressgateway 人如其名，毕竟还是 ingress，那ingress是按照 URL 地址来匹配资源的，而且受 namespace 影响

如果把 Gateway 的 hosts 从 * 改成 地址，那么就只能用地址来访问了

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

当然要把 diynocap.com 指向对应的 IP地址

但是因为 服务是通过 nodeport 暴露的，所以提供的是 高位端口

如何使ingressgateway使用 80 端口呢？

当然可以使用 hostport

设置dns

故障重试

配置如下

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: nginx-default-v2
  namespace: lizhe
spec: 
  hosts:
  - nginx-service
  http:
  - match:
    - headers:
        ver: 
          exact: v2
    timeout: 3s
    retries:
      attempts: 3
    route: 
    - destination:
        host: nginx-service
        subset: v2
  - match:
    - headers:
        ver: 
          exact: v3
    redirect:
      uri: /index.html
  - route: 
    - destination: 
        host: nginx-service
        subset: v1
    timeout: 3s
    retries:
      attempts: 3

Timeout控制

为了避免按照程序本身的默认超时时间等待，可以加入 timeout

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: nginx-default-v2
  namespace: lizhe
spec: 
  hosts:
  - nginx-service
  http:
  - match:
    - headers:
        ver: 
          exact: v2
    timeout: 3s
    route: 
    - destination:
        host: nginx-service
        subset: v2
  - match:
    - headers:
        ver: 
          exact: v3
    redirect:
      uri: /index.html
  - route: 
    - destination: 
        host: nginx-service
        subset: v1
    timeout: 3s

URI重定向

还有另一种对目标路由的分流方式，根据URL进行重定向

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: nginx-default-v2
  namespace: lizhe
spec: 
  hosts:
  - nginx-service
  http:
  - match:
    - headers:
        ver: 
          exact: v2
    route: 
    - destination:
        host: nginx-service
        subset: v2
  - match:
    - headers:
        ver: 
          exact: v3
    redirect:
      uri: /index.html
  - route: 
    - destination: 
        host: nginx-service
        subset: v1

按来源服务分流

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: nginx-default-v2
  namespace: lizhe
spec: 
  hosts:
  - nginx-service
  http:
  - match:
    - sourceLabels:
        app: v2
    route: 
    - destination:
        host: nginx-service
        subset: v2
  - match:
    - sourceLabels:
        app: v3
    route: 
    - destination:
        host: nginx-service
        subset: v3
  - route: 
    - destination: 
        host: nginx-service
        subset: v1

然后我们给 nginx 打个label

然后去把label改成 v3

按Header分流

按照 HTTP Header 分流的一个重要好处就是可以固定某些用户在某些特定的版本上

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: nginx-default-v2
  namespace: lizhe
spec: 
  hosts:
  - nginx-service
  http:
  - match:
    - headers:
        ver: 
          exact: v2
    route: 
    - destination:
        host: nginx-service
        subset: v2
  - match:
    - headers:
        ver: 
          exact: v3
    route: 
    - destination:
        host: nginx-service
        subset: v3
  - route: 
    - destination: 
        host: nginx-service
        subset: v1

上面规则的 默认会将流量导入到 v1 ，如果 request header 中指定了版本，那么会导入到指定的版本

curl http://nginx-service/helloworld.html
curl http://nginx-service/helloworld.html -H 'ver:v2'
curl http://nginx-service/helloworld.html -H 'ver:v3'

按权重分流

我们修改之前的 VirtualService ， 添加一些权重

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: nginx-default-v2
  namespace: lizhe
spec: 
  hosts:
  - nginx-service
  http:
  - route: 
    - destination: 
        host: nginx-service
        subset: v1
      weight: 10
    - destination: 
        host: nginx-service
        subset: v2
      weight: 10
    - destination: 
        host: nginx-service
        subset: v3
      weight: 80

然后进行一下测试

for i in `seq 20`; do curl http://nginx-service/helloworld.html;echo "" ;done

Istio http流量管理

在Kubernetes中 service 和 Deployment 或者其他负载的关系通常是 一对一 的，
而在Istio中，Service经常会对应不同的 Deployment。

Istio 主要通过 DestinationRule 和 VirtualService 来实现该功能，可以简单理解成将原始的 Kubernetes service 拆成了两个单独的部分

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

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

多个 host 的例子

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  gateways:
  - bookinfo-gateway
  - mesh
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v3

Kubectl port-forward

先创建一个测试用的nginx

以往的情况，如果要测试的话，可能需要一个 nodeport ，但是这里要介绍的是 kubectl port-forward

kubectl get pod -n test
kubectl -n test port-forward nginxtest-567f8d7d65-5snfq 82:80

当然也可以通过label来获取 pod id

kubectl -n test get pod -l workload.user.cattle.io/workloadselector -o jsonpath='{.items[0].metadata.name}'

这样命令可以改为

kubectl -n test port-forward $(kubectl -n test get pod -l workload.user.cattle.io/workloadselector -o jsonpath='{.items[0].metadata.name}') 82:80

Kiali配置

要手动安装 Kiali 请参考Kiali helm安装

同时你还需要安装 prometheus、grafana 和 jaeger

最终目标是让 Kiali 能正确查询流量

完整的配置

auth:
  openid: {}
  openshift:
    client_id_prefix: kiali
  strategy: anonymous
deployment:
  accessible_namespaces:
  - '**'
  additional_service_yaml: {}
  affinity:
    node: {}
    pod: {}
    pod_anti: {}
  custom_dashboards:
    excludes:
    - ""
    includes:
    - '*'
  hpa:
    api_version: autoscaling/v2beta2
    spec: {}
  image_pull_policy: Always
  image_pull_secrets: []
  ingress_enabled: false
  logger:
    log_format: text
    log_level: info
    sampler_rate: "1"
    time_field_format: 2006-01-02T15:04:05Z07:00
  namespace: istio-system
  node_selector: {}
  override_ingress_yaml:
    metadata: {}
  pod_annotations: {}
  pod_labels: {}
  priority_class_name: ""
  replicas: 1
  repository: rancher/mirrored-kiali-kiali
  resources: {}
  secret_name: kiali
  service_annotations: {}
  service_type: ""
  tag: v1.32.0
  tolerations: []
  version_label: v1.32.0
  view_only_mode: false
enabled: true
external_services:
  custom_dashboards:
    enabled: true
  grafana:
    in_cluster_url: http://grafana.grafana.svc:80
    url: http://grafana.grafana.svc:80
  prometheus:
    custom_metrics_url: http://pro.prometheus.svc:9090
    url: http://pro.prometheus.svc:9090
  tracing:
    in_cluster_url: http://tracing.istio-system.svc:16686/jaeger
global:
  cattle:
    clusterId: local
    clusterName: local
    rkePathPrefix: ""
    rkeWindowsPathPrefix: ""
    systemDefaultRegistry: ""
    url: https://krancher.com
  defaultPodDisruptionBudget:
    enabled: true
  proxy:
    repository: rancher/mirrored-istio-proxyv2
    tag: 1.9.3
  proxy_init:
    repository: rancher/mirrored-istio-proxyv2
    tag: 1.9.3
  rbac:
    pspEnabled: false
  systemDefaultRegistry: ""
identity:
  cert_file: ""
  private_key_file: ""
istio_namespace: istio-system
login_token:
  signing_key: sc5QF1IE4Q3X1zF6
server:
  metrics_enabled: true
  metrics_port: 9090
  port: 20001
  web_root: /kiali
web_root_override: true

其中重点是

  grafana:
    in_cluster_url: http://grafana.grafana.svc:80
    url: http://grafana.grafana.svc:80
  prometheus:
    custom_metrics_url: http://pro.prometheus.svc:9090
    url: http://pro.prometheus.svc:9090
  tracing:
    in_cluster_url: http://tracing.istio-system.svc:16686/jaeger

grafana 地址实际上就是 控制台 地址

prometheus 地址也是 控制台 地址

jaeger 地址 也是 控制台 地址