[Ingress-nginx/Istio] How do ingress-nginx work with istio smoothly. Reducing status 503 or 5xx.

Mình chắc hẳn nhiều công ty đang chạy k8s thì các applications or workload được public ra thông qua:
– ingress-nginx.
– Kong-gateway.
– NodePort luôn.

Chúng ta sẽ migrate từ từ các workload sang istio.

Phase 1: inject Istio for all workload.
vậy lúc này ingress-nginx workload với istio-proxy. Lúc này bạn cảm thấy có 1 số workload sẽ phát sinh tình trạng 503 or 5xx.

1) Prepare basic.

Những cái này mình cũng đã nhắc trong các bài viết trước và bạn có thể click link bên dưới.

1.4 Test với Service GRPC (update thu 30 Sep 2021)

Istio có thể automatically detect có 2 cách

This can be configured in two ways:

• By the name of the port: name: <protocol>[-<suffix>].
• In Kubernetes 1.18+, by the appProtocol field: appProtocol: <protocol>.

Mình chia thành 2 phần inbound và outbound

2) For Inbound calls: ingress-nginx to istio-proxy

The materials to refer to:
https://www.tetrate.io/blog/using-istio-with-other-ingress-proxies/
https://www.giffgaff.io/tech/using-istio-with-nginx-ingress

Mode mình test là:
– ingress-nginx to istio-proxy
– mTLS mode Strict
– Inject Istio for ingress-nginx

2.1) inject istio for ingress-nginx.

Mình cũng đã hướng dẫn các bạn cài ingress-nginx:

Nhưng nếu bạn cấu hình value helm như mình sẽ ko inject istio cho ingress-nginx được.
https://github.com/istio/istio/issues/11973#issuecomment-466442370

A little digging later, and it turns out you can’t do injection on host-network installs of nginx

Bạn config value of helm là:

controller:
  name: controller
  podAnnotations:
    sidecar.istio.io/inject: true

Và thưc hiện redeploy mà thưởng thức

2.2) Discovering traffic from ingress-nginx to istio

Mình show cho các bạn coi config ingress

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    field.cattle.io/creatorId: user-2hcxk
    field.cattle.io/ingressState: '{"ZmxlZXRtYW4td2ViYXBwLWluZy9kZWZhdWx0L2ZsZWV0bWFuLXdlYmFwcC1pbmcubmltdGVjaG5vbG9neS5jb20vLy84MA==":""}'
    field.cattle.io/publicEndpoints: '[{"addresses":["192.168.101.220"],"port":80,"protocol":"HTTP","serviceName":"default:fleetman-webapp","ingressName":"default:fleetman-webapp-ing","hostname":"fleetman-webapp-ing.nimtechnology.com","path":"/","allNodes":false}]'
    kubernetes.io/ingress.class: nginx
  creationTimestamp: "2021-11-25T08:48:38Z"
  generation: 1
  labels:
    cattle.io/creator: norman
  managedFields:
  - apiVersion: extensions/v1beta1
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
          f:field.cattle.io/publicEndpoints: {}
    manager: rancher
    operation: Update
    time: "2021-11-25T08:49:18Z"
  - apiVersion: networking.k8s.io/v1beta1
    fieldsType: FieldsV1
    fieldsV1:
      f:status:
        f:loadBalancer:
          f:ingress: {}
    manager: nginx-ingress-controller
    operation: Update
    time: "2021-11-26T12:08:27Z"
  - apiVersion: extensions/v1beta1
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
          .: {}
          f:field.cattle.io/creatorId: {}
          f:field.cattle.io/ingressState: {}
          f:kubernetes.io/ingress.class: {}
        f:labels:
          .: {}
          f:cattle.io/creator: {}
      f:spec:
        f:rules: {}
    manager: Go-http-client
    operation: Update
    time: "2021-12-10T15:31:34Z"
  name: fleetman-webapp-ing
  namespace: default
  resourceVersion: "64087793"
  uid: f4686483-4b9c-48c5-959e-c7e5bbb40f1e
spec:
  rules:
  - host: fleetman-webapp-ing.nimtechnology.com
    http:
      paths:
      - backend:
          serviceName: fleetman-webapp
          servicePort: 80
        path: /
        pathType: ImplementationSpecific
status:
  loadBalancer:
    ingress:
    - ip: 192.168.101.220

Cấu hình là ingress đi vào service name.

What’s exactly happening

It’s important to understand some concepts about how NGINX ingress works. The NGINX ingress controller does not use Services to route traffic to the pods. Instead it uses a list of all endpoints (Pod IP/port) in the NGINX upstream configuration in order to bypass kube-proxy to allow NGINX features like session affinity and custom load balancing algorithms.

Câu trên gần như là giải thích tại có traffic ingress-nginx sang passthroughCluster rồi đi thằng workload

Giờ mình sẽ thực hiện bài test: 100 request/s trong vòng 5phut và trong lúc đó có redeploy workload
và mình sài vegeta he.

echo "GET http://fleetman-webapp-ing.nimtechnology.com/api/vehicles/driver/City%20Truck" | vegeta attack -duration=300s -rate=100 | vegeta report --type=text

2.2.1) Appear 503, 5xx when redeploy workload or deploy new workload.

Ta thấy traffic ingress-nginx đi qua passthroughCluster có chút vàng vàng

Mình soi tất cả các chart thì chỉ co chart inbound của ingress-nginx là có chút status 503

report của vegeta

503 từ đầu của client nhần về hơn 1% tổng số request cũng hơi nhiều òi ý ha.

2.2.2) Avoid 503, 5xx

Vậy giờ có cách nào ko nhỉ?

Bạn sẽ thêm các annotation dưới đây vào từng ingress của workload nhé

  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/service-upstream: "true"
    nginx.ingress.kubernetes.io/upstream-vhost: fleetman-webapp.default.svc.cluster.local

Mục đích để làm gì:

Instead of routing the outbound traffic to the list of endpoints in the NGINX upstream configuration, you should configure NGINX ingress to route to a single upstream service, so that the outbound traffic is intercepted by the istio sidecar.

Giờ thực hiện test lại

echo “GET http://fleetman-webapp-ing.nimtechnology.com/api/vehicles/driver/City%20Truck” | vegeta attack -duration=300s -rate=100 | vegeta report –type=text

Giờ chờ report vegeta thôi.