[DevOps] Istio란 무엇인가요?
안녕하세요? 정리하는 개발자 워니즈 입니다. 이번시간에는 서비스 메시의 구성 방식과 envoy proxy에 대한 개요 그리고 Istio라는 오픈소스에 대해서 정리를 해보도록 하겠습니다. Istio를 알기전에 먼저 서비스 메쉬에 대해서 알아야 될것 같습니다.
istio관련된 시리즈는 아래에서 확인이 가능합니다.
1. Micro Service Architecture 란?
마이크로 서비스 소프트웨어 아키텍처는 서로 연결되어 있지만 독립적으로 작동하는 소프트웨어 모듈을 기반으로하며 다른 프로젝트에서 쉽게 교체, 제거 및 재사용 할 수 있습니다. 기본적으로 각각 고유한 목적을 가진 작은 블록을 사용하여 최종 소프트웨어 제품인 더큰 건물을 건설하는 것과 같습니다.
마이크로 서비스 아키텍처 이점
- 전체 소프트웨어 제품의 소스 코드를 파헤치지 않고 가능한 짧은 시간에 새로운 구성 요소를 추가할 수 있습니다.
- 업그레이드 되거나 릴리스로 출시되는 소프트웨어 제품의 내결함성 문제를 쉽게 해결 할 수 있습니다.
- 계층적구성 대신 대칭적으로 구성하고, 피어 투 피어 종속성을 형성하여 앱 아키텍처를 단순화 할 수 있습니다.
마이크로 서비스 아키텍처 단점
- 거대해진 MSA 시스템에 대한 관리포인트가 많아질 수 있습니다.
바로 이러한 단점때문에 서비스 메시의 개념이 도입이 되었습니다.
2. 서비스 메시란?
서비스 메시는 위와 같이 작은 서비스(MIcro Service)간의 통신을 연결해둔 모습이 마치 메시소재와 같이 연결되어있는 것을 지칭합니다. 서비스 메시는 서비스 간 통신을 처리하기 위한 전용 인프라 계층입니다. 서비스 메시 솔루션은 여러가지가 있지만 본 포스팅에서는 Istio에 대해서 소개합니다.
서비스 메시는 다르게 동작하는 두개의 컴포넌트로 구성이 되어있습니다.
- 데이터 플레인 : 사이트카로 배치되어, 마이크로 서비스 간의 모든 네트워크 통신을 중재하고 제어합니다.
- 컨트롤 플레인 : 트래픽 라우팅 및 프록시를 관리하고 구성합니다. 전책을 시행하고 분석을 할 수 있도록 메트릭을 수집합니다.
3. Istio의 구성요소
- envoy proxy
- 서비스 간 인바운드 아웃바운드 트래픽을 투명하게 처리합니다.
- pilot
- envoy 사이드카에 대한 서비스 검색, 라우팅을 위한 트래픽 관리 기능(a/b 테스트, 카나리 배포 등) 및 복원력 (타임 아웃, 리트라이, 서킷브레이커 등)을 제공합니다.
새로운 서비스가 시작되게 되면, Pilot의 어댑터가 수신을 하고 Abstract model로 등록을 하게 되면, 이후에 Pilot이 envoy에 설정을 배포합니다.
- citadel
- 자격 증명 관리를 통해 강력한 서비스 인증을 지원합니다.
- 보안 모듈, 인증, TLS 암호화, 인증서 관리
- Gallery
- Istio의 구성 유효성 검사, 수집, 처리 및 배포 구성 요소입니다.
Istio의 기능
- 트래픽 제어
- 서비스간의 트래픽 흐름과 API 호출을 제어 할 수 있습니다.
- 보안
- 기본적으로 envoy를 통해 통신하는 모든 트래픽을 자동으로 TLS암호화를 합니다.
- 정책
- 서비스간 access, role등의 정책을 설정하여 리소스가 각 서비스에 분배 되도록 제어 합니다.
- 모니터링
- 강력한 모니터링 및 로깅 기능을 제공하여 문제를 빠르고 효율적으로 감지할 수 있게 합니다.
4. Istio 설치 방법
Istio 설치 버전 : 1.10.0
istio 다운로드
# istio version 변수 선언
echo 'export ISTIO_VERSION="1.10.0"' >> ${HOME}/.bash_profile
source ${HOME}/.bash_profile
# istio download
cd ~/environment
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=${ISTIO_VERSION} sh -
# istioctl binary 이동
cd ${HOME}/environment/istio-${ISTIO_VERSION}
sudo cp -v bin/istioctl /usr/local/bin/
# 설치 버전 체크
istioctl version --remote=false
istio 설치
#istio profile 설치
yes | istioctl install --set profile=minimal
✔ Istio core installed
✔ Istiod installed
✔ Ingress gateways installed
✔ Installation complete
istio 설치시 profile에 따라 설치 되는 컴포넌트가 다르게 명시되어있습니다. 필자는 default로 설치를 진행했습니다.
istio 설치 검증
# istio 서비스 목록 확인
$kubectl -n istio-system get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
stio-ingressgateway LoadBalancer 10.100.15.31 abc1fcfe168bb4d9e8264e8952758806-1033162489.us-east-2.elb.amazonaws.com 15021:30819/TCP,80:30708/TCP,443:32447/TCP,31400:31433/TCP,15443:30201/TCP 107s
istiod ClusterIP 10.100.133.178 15010/TCP,15012/TCP,443/TCP,15014/TCP 117s
# istio 파드 목록 확인
$kubectl -n istio-system get pods
NAME READY STATUS RESTARTS AGE
istio-ingressgateway-78f7794d66-9jbw5 1/1 Running 0 2m35s
istiod-574485bfdc-wtjcg 1/1 Running 0 2m45s
5. envoy proxy injection 방법
istio설치가 완료가 되었다면, envoy sidecar를 설정해주어야 합니다. Sidecar-injection 이란 sidecar를 실제 배포된 어플리케이션 pod 옆에 배치하는 것으로 수동과 자동 2가지 방법이 있습니다.
Injection Rule
- Rule-1. namespace selector 매칭 여부 (mutatingwebhoolkconfiguration에서 설정)
$ kubectl get mutatingwebhookconfiguration istio-sidecar-injector -o yaml | grep "namespaceSelector:" -A5 namespaceSelector: matchLabels: istio-injection: enabled rules: - apiGroups: - "" - Rule-2. istio default policy
$ kubectl -n istio-system get configmap istio-sidecar-injector -o jsonpath='{.data.config}' | grep policy: policy: enabled - Rule-3. pod template
$ kubectl get deployment httpbin -o yaml | grep "sidecar.istio.io/inject:" -C3 template: metadata: annotations: sidecar.istio.io/inject: "true" labels: app: httpbin - kube-system,kube-public namespace 는 injection 되지 않습니다.
- host network를 사용하는 pod 에는 injection 되지 않습니다.
Injection 방법
- Manual 방식
istioctl kube-inject CLI를 사용
$ kubectl apply -f <(istioctl kube-inject -f istio-1.2.2/samples/httpbin/httpbin.yaml)
$ istioctl kube-inject -f istio-1.2.2/samples/httpbin/httpbin.yaml | kubectl apply -f -
- Automatic 방식
namespace 에 istio-injection=enabled 라벨링
istio-injection 라벨에 enabled/disabled 값을 지정하여 namespace 에 pod 가 생성 될 때마다 injection 작업 체크 및 수행
Automatic injection 이 정상 동작하기 위해서는 istio-system 에 istio-sidecar-injector 가 정상 동작하고 있어야 합니다.
$ kubectl label namespace default istio-injection=enabled
$ kubectl apply -f istio-1.2.2/samples/httpbin/httpbin.yaml
6. 마치며..
이번시간에는 Istio의 설치 및 간단한 컴포넌트의 내용에 대해서 정리를 해보았습니다. Istio를 사용하게된 계기는 grpc Load 부하분산을 실시하기 위해서 L7 레이어에 프록시가 필요했고, envoy가 http2통신 즉, grpc를 적절히 처리하는데 능하다고 해서 사용하게 되었습니다. 하지만, 단순히 injection만 하고 트래픽 제어라던지, 메트릭 수집에 대해서는 따로 사용하는 방법을 숙지하지 못했습니다. 다음시간에는 이부분에 대해서 정리를 해보도록 하겠습니다.
