개요

쿠버네티스에서 활용할 수 있는 대표적인 서비스 메시 툴.
어플리케이션 간 트래픽을 연결 관리하면서, 보안이나 모니터링을 용이하게 해준다.
가령 자체적으로 mTLS를 적용하거나 로드밸런싱, 트래픽 미러링 등의 작업을 할 수 있다.
전반적인 기능에 대해서는 서비스 메시#기능을 참고하자.

2017년에 처음 발표되고 CNCF에 기증되어 쿠버네티스, 프로메테우스와 비슷한 시기에 졸업 프로젝트가 됐다.
구글과 IBM이 파트너십을 체결하고 개발에 착수했으며, Envoy를 만든 Lyft팀과 결합하여 개발됐다.

이스티오의 언어적 의미는 그리스 언어로 "Sail", 즉 항해를 의미한다.
그리스어로 조타수를 의미하는 쿠버네티스와 언어적 연관성을 두는 작명이라 할 수 있겠다.

최근 다양한 CNI들이 서비스 메시적인 기능을 제공하기 시작했다.
그러나 이들이 자체 표준으로 서비스 메시를 제공하는 것은 아니며, 어떤 것을 쓸지는 선택이다.
다만 이스티오는 훨씬 성숙하고, 정제된 형태로 발전해왔으며 게이트웨이API도 실질적으로 이스티오를 전신으로 둔 채로 개발된 것이나 다름없다는 점을 생각하면 이스티오의 대안이 있다고 해서 이스티오가 가뿐히 무시될 만하다고 보기는 힘들다고 생각한다.

구조

이스티오는 1.26 버전 현재 사이드카 모드와 앰비언트 모드, 두 가지 방식의 서비스 메시 구조를 지원한다.

두 모드라고는 하지만, 거시적인 관점에서 각종 설정을 총체적으로 관리하는 컨트롤 플레인과, 데이터 플레인에 서비스들의 트래픽을 관리하는 프록시를 두는 구조 자체는 결국 똑같다.
그 세부 구현과 기능에서 어마무시한 차이가 있기는 하지만.. 서비스 메시를 처음 알게 됐다면 이러한 구조로 이뤄져있다고 알면 좋겠다.

컨트롤 플레인 - istiod

이스티오 컨트롤 플레인은 istiod라고 부르며, 이건 어떤 모드를 사용하건 간에 똑같다.
(이러한 방식 덕에, 두 모드를 동시에 사용하며 통합하는 것이 가능하다)

사이드카 모드

사이드카 모드는 서비스 메시라 할 때 아주 기본적으로 생각되던 방식이다.
무슨 말이냐, 모든 워크로드에 개별적으로 사이드카 프록시를 배치해서 메시를 구성하는 방식이다.
엔보이를 프록시로서 활용하며, 이스티오의 전반적인 모든 기능이 지원되고 있다.
자세한 내용은 문서 참고.

이스티오 관련해서 각종 정리한 내 노트들은 기본적으로 사이드카 모드를 기반으로 설명한다.
애초에 이스티오가 사이드카 모드를 전제로 설계됐고, 모든 기능을 사용할 수 있는 건 사이드카 모드이기 때문이다.

앰비언트 모드

앰비언트 모드는 22년에 새롭게 선보여진 방식으로, 24년에 GA가 됐다.
이 모드는 각 워크로드 별로 프록시를 배치하지 않고 노드 별로 프록시를 배치한다.
그러면서도 각 워크로드를 개별적으로 관리할 수 있도록 하기 위해 각종 기술들이 들어가는데, 덕분에 자원 소모량이나 속도에서 월등한 차이를 보여준다.
심지어는 이스티오를 활용하지 않는 환경보다도 레이턴시가 작다는 실험 결과도 있다.^[1]
당연히 테스트 환경을 간단하게 구성했으니 가능한 거지만, 이런 결과가 나온다는 것 자체는 충분히 괄목할 만하다.

나온지 오래 되지 않아서 그런지 GA라고는 하지만 아직 기능이 제한적인 구석이 더러 있다.

커스텀 리소스

이스티오는 컨트롤 플레인에 설정을 넣기 위한 다양한 CRD 리소스를 제공하고 있다.
실제로 트래픽을 처리하는 것은 데이터플레인에 위치한 엔보이이므로, 이 리소스들에 대한 설정은 궁극적으로 엔보이에 적용된다.

설치

이스티오는 현재 크게 2가지의 설치 방식을 지원한다.^[2]

• istioctl을 이용한 설치
• 헬름 기반 설치

이전에는 IstioOperator 커스텀 리소스를 이용한 오퍼레이터 패턴도 존재했으나, 현재 이 방식은 사라졌다.

istioctl을 통한 설치

istioctl은 이스티오를 관리할 때 매우 유용한 툴이다.
이걸 이용해서 이스티오를 설치하는 것도 가능한데, 이때 설정 파일은 IstioOperator 양식을 따른다.
즉 쿠버네티스의 커스텀 리소스로서 관리되는 오퍼레이터는 사라졌지만, istioctl을 이용한 설치는 여전히 해당 양식을 기반으로 한다는 것이다.
istioctl을 이용해서 설치하지 않더라도, 이 툴은 이스티오를 관리하는데 있어서는 거의 필수적인 툴이니 꼭 설치해서 사용하자.

istioctl install --set profile=demo

istioctl을 사용해 설치할 때는 이렇게 헬름 설치하는 것 마냥 세팅을 해주면 된다.
-f를 통해 설정 파일을 넘겨서 더욱 많은 커스텀을 편리하게 설정하는 것도 가능하다.
이때 사용되는 것이 위에서 말한 istio operator 양식 파일이다.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  profile: default
  hub: gcr.io/istio-testing
  tag: latest
  revision: 1-8-0
  meshConfig:
    accessLogFile: /dev/stdout
    enableTracing: true
  components:
    egressGateways:
    - name: istio-egressgateway
      enabled: true
  values:
    ...

양식은 대충 이런 식으로 작성하면 되며, 추가적인 세팅들은 profile 필드에 나온 프로필에 덮어쓰기된다.^[3]
meshConfig는 컨트롤 플레인 전반 설정, components 필드에서 각 세부 컴포넌트들을 세팅한다.
values는 설치 시 같이 세팅되는 모니터링이나 일련의 툴들에 대한 세팅을 하는 필드인데, 사실 이건 헬름을 통해 설치할 때 사용하는 values 파일을 그대로 가져다둔 것이다.^[4]
이스티오는 문서 구조가 조금 난해한 것 같아서, 핵심이 되는 문서 링크도 각주를 달아두겠다..^[5]

istioctl을 이용해서 설치하는 방법의 장점은 각종 설정 양식의 검증 체크가 확실하다는 것이다.
반면 단점도 존재하는데, 상대적으로 버전 관리가 어렵다는 것이다.
하나의 여러 개의 설정 파일을 두고 하나의 이스티오를 세팅하는데 사용할 수 있는데, 이때 이 설정 파일 간 덮어씌워지는 설정은 뭐고 아닌 건 뭐고 이런 거 체크가 잘 안 된다.
그래서 isioctl로 설치한다면, 가급적 설정 파일은 하나만 사용하는 것을 추천한다.

헬름 기반 설치

helm repo add istio https://istio-release.storage.googleapis.com/charts
helm repo update
helm install istio-base istio/base -n istio-system --set defaultRevision=default --create-namespace
helm install istiod istio/istiod -n istio-system --wait

# 게이트웨이 워크로드도 설치하고 싶다면
helm install istio-ingress istio/gateway -n istio-ingress --wait

# 앰비언트 모드라면 아래도 전부 해야 함
kubectl get crd gateways.gateway.networking.k8s.io &> /dev/null || \
  kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.3.0/standard-install.yaml
helm install istio-cni istio/cni -n istio-system --set profile=ambient --wait
helm install ztunnel istio/ztunnel -n istio-system --wait

헬름으로 설치할 때는 위와 같이 각종 컴포넌트를 독립적으로 설치해야 한다.
먼저 CRD를 설치하고, 이후에 컨트롤 플레인을 설치하는 방식이다.
헬름을 이용한 설치는 버전 관리가 상대적으로 잘 되고 깃옵스와 궁합이 좋다는 것이 큰 장점이다.
위에 잠시 보이지만, revision 값을 세팅해서 점진적 업그레이드를 하는 것도 가능하다.
(참고로 1.26 기준으로 앰비언트는 카나리 불가.^[6])

헬름을 통해 설치할 때 다양한 컴포넌트들을 독립적으로 배포하는 불편함을 메꾸고자 최근에 나온 것이 Sail Operator라는 오퍼레이터다.^[7]
구체적으로는 이전의 IstioOperator을 대체하기 위해 나온 거긴 한데, 아무튼 헬름의 장점을 살리면서 설치를 간소화시키는 장점이 있다.

프로필

두 설치 방식 모두 공통적으로 등장하는 필드가 profile이다.
이스티오는 배포, 플랫폼 프로필의 개념을 이용하여 요구사항에 맞게, 환경에 맞게 설치 방식을 더 세분화시킨다.
이스티오에 필요한 세팅들을 전부 일일히 세팅하기 귀찮으니 몇 가지 템플릿을 제공하는 것이라 보면 된다.
그래서 프로필을 무조건 뭘로 해야지만 제대로 동작하고 어떤 거 하면 어떤 기능이 제한되고 이런 개념은 아니다.

배포 프로필의 종류는 이렇다.

• default - IstioOperator api를 이용한 가장 기본적인 세팅으로, 멀티 클러스터 중 기본이 되는 클러스터에 세팅하기 좋다.
• demo - 이스티오의 기능을 보여주기 위한 세팅으로, 높은 단계의 로깅과 트레이싱이 활성화돼있다.
• minimal - 기본과 동일하나 컨트롤 플레인 컴포넌트만 설치된다.
• remote - 멀티 클러스터에서 2차 클러스터를 위한 설정
• ambient - 앰비언트 모드 설정
• empty - 커스텀 설정을 넣기 위해 존재하는, 아무것도 없는 설정
• preview - 실험적 기능이 들어가는 설정

플랫폼 프로필에는 위 종류들이 있다.

하위 문서

관련 문서

EXPLAIN - 파생 문서

기타 문서