[Istio] why does workload inject Istio that workload always connects fail database? – hold Application

Khi mà anh em apply istio lên các workload trên k8s thì sẽ có 1 vần đề
Các container trên 1 pod sẽ start lên cùng lúc.

Như hình trên nếu container app ready nhanh hơn istio-proxy, và container app liền connect với database.
Nhưng lúc đó istio proxy chưa ready .. nên chắc chắn là app bị lỗi kết nối database.

Chúng ta sẽ sử lý như thế nào.?

1) Resolve problem.

1.1) Develop.

Ở phía các bạn dev họ sẽ code
– retry connect database
– cấu hình healtch cho app. k8s call api /healthcheck -> check đã connect database chưa?
Nếu connect databse ok thì trả về status 200 OK

1.2) Devops.

Chúng ta có phần là config holdApplication trong istio.

1.2.1) holdApplication in Istio Operator.

apiVersion: install.istio.io/v1alpha2
kind: IstioOperator
spec:
  meshConfig:
    defaultConfig:
      holdApplicationUntilProxyStarts: true

Sau đó bạn gen manifest:

1.2.2) holdApplication in Config Map istio.

Bạn thấy trong config istio sẽ có phần thêm vào đó là

apiVersion: v1
data:
  mesh: |-
    defaultConfig:
      discoveryAddress: istiod-1-9-9.istio-system.svc:15012
      holdApplicationUntilProxyStarts: true
      proxyMetadata: {}
      tracing:
        zipkin:
          address: zipkin.istio-system:9411

Hoặc là bạn thêm

1.2.3) holdApplication in Annotation of workload.

annotations:
  proxy.istio.io/config: '{ "holdApplicationUntilProxyStarts": true }'

Tài liệu tham khảo:
https://www.solo.io/blog/challenges-of-running-istio-distroless-images/
Ở link trên mình thấy có phần hay là: Gracefully terminating connections on pod shutdown
lưu đây khi nào coi.

1.2.4) result after config holdApplication

Mọi chuyện vẫn chưa dừng ở đó âu:

Bạn sẽ thấy container mặc định của pod này là busybox.

Giờ redeploy sau khi đã config hold app

1.2.4.1) deep dive the problem after config hold app

Ok giờ có vấn đề nữa.
bạn chạy kubectl exec hay là log thì nó auto chạy vào container istio-proxy, bởi vì giờ đang container istio-proxy là default của pod.

root@work-space-u20:~# kubectl -n default exec -it pod/busybox-deployment-77fd748ccb-pnhtz -- sh 
Defaulted container "istio-proxy" out of: istio-proxy, busybox, istio-init (init)

Hướng sử lý đơn giản và hiệu quả là thêm flag container

root@work-space-u20:~# kubectl -n default exec -it pod/busybox-deployment-77fd748ccb-pnhtz -c busybox -- sh 
/home # 

Còn cách nữa là sử dụng annotation trên workload để sác định container default.

https://kubernetes.io/docs/reference/labels-annotations-taints/#kubectl-kubernetes-io-default-container

kubectl.kubernetes.io/default-container: "front-end-app"

The value of the annotation is the container name that is default for this Pod. For example, kubectl logs or kubectl exec without -c or --container flag will use this default container.

Nhưng là tính năng này chỉ mới có trên kubectl 1.21

Để kiểm chứng là kubectl 1.21 ++ mới chơi được trò này.

docker run --rm --name kubectl -v ~/.kube/config:/.kube/config bitnami/kubectl:1.21 -n cicd exec -it nginx-promtail-7d74f4fb78-6w4xh bash