1.kiali

Telemetry (원격 측정) (172.30.36.176)

kubectl describe ns <namespace>

namesapce에 대한 정보 특히 어떤 Label이 적용되어있는지 확인할 수 있다. (특히 istio injection)

kubectl delete po --all -n <namespace>

namespace의 모든 pod를 한번에 삭제
deployment가 있는 상황에서 모든 pod를 삭제하면 pod들이 변경사항을 바탕으로 새로 생성됨을 이용할 수 있음.

kiali

먼저 kiali를 사용하기 전에 kiali service가 어떻게 구성되어 있는지 확인해보자.

NodePort는 외부에서 Cluster의 Node IP를 통해 접근 가능한 service이다. service의 Cluster IP는 10.99.100.178으로 할당되어 있으며, 할당된 내부 port는 20001, 9090이고 외부 port는 31000과 30289이다. 결과적으로 외부 url에서 해당 service에 접근하기 위해서는 unbuntu ip:외부 port를 사용하면 접속할 수 있다.
이론상 k8s가 설치되어있는 ubuntu 내부에서 cluster IP와 내부 port를 이용해도 접속이 가능하나 이 점은 참고한 하면 될 것 같다. 참고로 해당 service는 31000만 이용하여 접속한다. 표준은 아니고 yaml 파일에서 service type과 port를 설정해 주었다고 한다.

다음은 Graph에서 볼 수 있는 요소들을 정리해 놓은 표이다.

특정 요소를 더블 클릭하면 해당 요소와 관련된 요소들만 간단하게 표시되니 참고하자.
또, display에서 Traffic Animation을 클릭하면 traffic 흐름 방향을 보여주느 참고하자.

처음에는 service 들만 정리되어 있는 service graph를 이용해 전체적인 흐름을 파악하는 것이 편하다. 전체적인 흐름을 파악한 후, 특정 service를 왼쪽 클릭하면 detail, traffic, inbound metric에 대한 정보도 나오니 확인해보면 좋다. 예를 들어 service를 구성하고 있는 workload 등이 나온다. (inbound metric은 grafana와 연결되는 것 같다)

workload가 pod 1개를 의미하기 때문에 오른쪽 클릭을 하면 해당 pod의 로그, 관련 service, 생성된 경로(replicaset), label 등을 확인할 수 있다.

다음은 kiali 동적 트래픽에 대해서 소개한다.

istio 환경에서 traffic을 관리하는 기능이 있는데, 이는 k8s의 객체 중 하나인 VirtualServices와 destinationrules에 의해 구현된다. kubectl get virtualservies -A, k get vs -A or kubectl get destinationrules -A k get dr -A를 통해 해당 resource를 확인할 수 있다.

특정 service의 detail에 들어가면 오른쪽 위의 Action을 보면 traffic을 중지할 수 있는 “Suspend Traffic”이 존재한다.

자세한 설정은 건드리지 않고 create를 해주면 ‘Istio Config created’라는 문구와 함께 service가 중지되며, 아래에서 Istio Config를 보면 VirtualService와 DestinationRule이 생성된 것을 확인할 수 있다.

이러한 설정은 모두 yaml 파일을 통해서 설정되는데 이를 확인하면 다음과 같이 내용을 확인할 수 있었다.

또한 cli에서도 이를 확인할 수 있었당.

cli에서 위의 yaml 파일 내용을 확인하기 위해서는 k get dr/vs <service name> -o yaml

원래 sidecar injection은 namespace 별로만 할 수 있는 줄 알았는데, kiali를 둘러보다가 pod(workload) 단위로 sidecar injection을 조절할 수 있는 옵션을 발견하였다.
workload의 deatil에 들어가 action에 들어가면 다음 총 3가지 옵션을 마주할 수 있다.

Disable Auto Injection: namespace 단위로 주입된 sidecar가 비활성화됨. 이를 선택하면 기존에 주입된 pod에는 영향을 주지 않지만, 새로운 pod에 대해서만 sidecar 주입이 중지됨.
Remove Auto Injection: 해당 workload에 주입된 sidecar가 삭제됨.
Enable Auto Injection: 해당 workload에 sidecar가 자동으로 주입됨.

즉, 2번 옵션을 사용하면 pod 단위로 sidecar proxy injection을 주입할 수 있다는 것이다. 내가 필요했던 기능이였기 때문에 ai/ml framework에 적용해보고 와야겠다!