Istio
Istio란
- istio는 kubernetes를 확장하여 envoy proxy를 사용해 프로그래밍 가능한 애플리케이션 인식 네트워크를 구축한다.
- kubernetes와 전통적인 워크로드와 함께 작동하는 istio는 복잡한 배포에 표준, 범용 트래픽 관리, 원격 측정 및 보안을 제공한다.
- 현재 다양한 service mesh에는 istio 말고도 다양한 service mesh가 존재하는데 가장 대표적으로 많이 사용되고 있는 것이 istio이다.
- istio와 함께 kiali, jaeger등의 monitoring tool을 사용하여 웹 대시보드 형태 모니터링 할 수 있다.
kiali - 웹 대시보드 형태로 Istio 정책을 제어하고 Istio 동작을 확인할 수 있는 기능을 지원 jaeger - 웹 대시보드 형태로 각 서버 간의 요청 관계가 복잡해질수록 장애 및 병목 지점을 찾아내는 기능을 지하며 서버 내부의 어느 함수에서 시간을 많이 소요하는지, 어느 경우에 레이턴시가 튀는지 등을 확인하기 위한 용도로 사용 가능
- service mesh를 도입하는 이유로는 대표적으로 가시성(Observability), 트래픽 관리(Traffic Management), 보안(Security) 그리고 계층(Layer)의 4가지 측면에서 살펴볼 수 있다.
4가지 측면
가시성(Observability)
- 가시성을 구성하는 3대 요소로 log, metric, trace가 있다.
- 이 3가지는 각각 다른 방법으로 수집되고 다른 용도로 사용되지만 가각 혹은 함께 보았을때 인프라 및 애플리케이션에 대한 중요한 인사이트 정보를 제공해주며, 점차 자동화되고 있는 IT 환경에서 중요성을 보여주고 있다.
- Service mesh는 애플리케이션 바깥에서 벌어지는 일에 대한 가시성을 자동화 계층이 처리함으로써 애플리케이션의 품질을 개선하거나 신규 기능을 추가하는 할 수 있다.
- 이 자동화 계층은 istio에서 내부적으로 사용하는 envoy proxy를 통해 이루어 지는데, Observability 기능을 사용하여 쉽게 log, metric, tracing을 구현할 수 있다.
트래픽 관리(Traffic Management)
- service mesh는 서비스간의 통신을 컨트롤한다.
- 여러 팀에서 독립적으로 micro service를 개발하거나 배포하는 동적인 환경에서 트래픽을 어떤 서비스로 보내야하는지 어플리케이션 내부에서 관리하게 되면, 경로가 바뀔대마다 애플리케이션을 수정하여 매번 새로 배포해야 할 수 도있다.
- 이를 방지하기 위해 config server 형태로 관리하더라도 바뀐 경로를 reload하는 작업을 wrebhook 등의 애플리케이션 코드로 별로 구현 해야될 수도 있다.
- 하지만 istio의 sidecar pattern을 이용하여 애플리케이션 코드의 변경 없이 작업자가 Istio의 Custom Resource를 통해 VirtualService와 DestinationRule를 사용하여 손쉽게 원하는 서비스로 트래픽을 보낼 수 있게 만들어 준다.
- 이 기능을 활용하면 VirtualService의 weight와 subset을 변경하는 것 만으로 Canary 배포 등의 작업을 쉽게 수행할 수 있다.
- kubernetes만으로 replica의 개수를 조정하여 pod 수를 늘릴 수 있지만 이러한 과정을 단순화할 수 있다.
- 또한 envoy proxy 기능을 통해 Header와 Path 등 L7 라우팅 역시 매우 손쉽게 설정할 수 있다.
Sidecar Pattern: Pod 내에 Envoy proxy가 Sidecar로 같이 있으면서 새로운 트래픽 설정을 실시간으로 반영보안(Security)
- service mesh는 모두 서비스를 인증/인가하는 기능을 제공하고 있다.
- 대표적인 기능이 istio에서 쉽게 설정할 수 있는 mTLS(Mutual TLS) 설정이다.
- 이를 통해, istio Control Plane이 알지 못하는 서비스와는 아예 통신할 수 없도록 막을 수 있으며, Policy를 통해 어떤 서비스가 어떤 서비스와 통신할 수 있고 없는지 여부를 코드화하여 관리 할 수 있다.
- 이런 service mesh의 보안 기능을 활용하면 애플리케이션 코드의 변경 없이 클러스터의 보안을 강화할 수 있다.
계층(Layer)
service mesh가 없더라도 가시성, 트래픽 관리, 보안등 모두 애플리케이션 코드 혹은 kubernetes 설정을 통해 근접하게 구현해낼 수 있다.
하지만 이 기능을 별도의 계층으로 분리하는 접근 덕분에 애플리케이션 개발자는 집중해야할 대상이 명확해진다.
또한, 애플리케이션 코드와 service mesh영역이 Decoupling(비동조화)되어 있기 때문에, 동일 워크로드를 istio가 아닌 다른 service mesh들(App mesh, consul, Linkerd)과 연동한다고 하더라도 애플리케이션 코드에서 변경은 필요 없다.
출처
https://kr.linkedin.com/pulse/istio는-무엇이고-왜-중요할까-sean-lee
service mesh - istio 설치 및 샘플 앱 bookinfo 배포하기
- 쿠버네티스 버전에 맞는 Istio 버전을 확인해서 curl 명령어로 설치(1.17.1 설치)
# 필요한 버전 설치 $ curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.17.1 sh - # 최신 버전 설치 $ curl -L https://istio.io/downloadIstio | sh -
- 환경 변수 설정
# export ISTIOHOME=/home/yangseunghyun/istio-1.17.1
- Istio가 제공하는 profile을 확인후 demo 설치
# istioctl profile list # istioctl install --set profile=demo -y
- 데모 앱 Bookinfo pod에 Invoy sidecar container 주입을 위해 라벨추가
# 만약 nsmaspace에 istio-injection 라벨을 추가하기 전 애플리케이션을 배포 했다면 해당 애플리케이션은 재시작 혹은 재배포를 해주어야 sidecar가 해당 파드에 컨테이너 형태로 붙을수 있다. $ kubectl label namespace default istio-injection=enabled
- 라벨 확인
$ kubectl get ns --show-labels
- bookinfo 앱 및 게이트웨이 배포
$ kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml -n [namespace name] # bookinfo-gateway.yaml을 배포하게 되면 ingress gateway가 service 형태로 동작하게 되고 loadbalancer가 생성되어 routing 규칙이 적용된다. $ kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml -n [namespace name]
- bookinfo 샘플 앱에 invoy sidecar 주입이 되었는지 확인 후 없으면 bookinfo 앱 삭제 후 재배포 진행
# 확인 $ kubectl get pod # 삭제 후 배포 $ kubectl delete -f samples/bookinfo/platform/kube/bookinfo.yaml -n [namespace name] $ kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml -n [namespace name] # 혹은 pod 재시작 $ kubectl rollout restart [object or pod] [[object or pod name] -n [namespace name]
- istio ingressgateway 80번 포트와 맵핑 되어 있는 노드포트 확인 후 외부에서 접속
$ kubectl get pod -n istio-system
- 외부 브라우저 URL에서 IP:port/productpage 검색 후 refresh하게 되면 review 서비스의 v1,v2,v3 버전이 호출된다.
- 전체 istio 문제여부 확인
$ istioctl analyze
