사이드 프로젝트와 핵심 작업에 구별없이 서비스 메시는 클라우드 기본 인프라에 필요한 도구다. 이 책은 이스티오를 시작하려는 사람을 대상으로 하며, 이스티오와 서비스 메시를 다룬다
이스티오를 시작하는 데 필요한 단계별 가이드를 제공하며, 각 개념은 이전에 다룬 개념을 바탕으로 논리적이고 체계적인 방식으로 설명한다. 이 책을 통해 이스티오의 주요 기능에 익숙해지고 자신 있게 이스티오를 배포할 수 있을 것이다.

★ 이 책에서 다루는 내용 ★

■ 이스티오가 다루는 관찰 가능성 문제 탐색
■ 요청 라우팅, 트래픽 전환, 결함 주입, 견고한 서비스 메시 실행에 필수적인 기타 기능
■ 원격 측정 정보 생성 및 수집
■ A/B, 블루/그린 및 카나리아를 포함한 다양한 배포 패턴
■ 이스티오 지원으로 실제 애플리케이션을 개발하고 배포하는 방법

★ 이 책의 대상 독자 ★

사이드 프로젝트든 핵심 작업이든 서비스 메시는 클라우드 기본 인프라에 필요한 도구다. 이 책은 이스티오를 시작하려는 독자를 위한 것이다. 독자가 도커나 쿠버네티스에 익숙할 것으로 기대하지만, 네트워킹 또는 리눅스에 관한 기본 지식이 있으면 이스티오를 배우기에 충분하다. Go나 다른 프로그래밍 언어 지식이 있으면 좋지만 꼭 필요하지는 않다.
프로메테우스(Prometheus), 예거(Jaeger), 그라파나(Grafana), 메셔리(Meshery), Envoy 및 OpenTracing과 같은 다양한 클라우드 기본 도구와 주제를 다룬다. 이러한 도구와 주제에 익숙하다면 이상적이나 책 내용을 소화하는 데는 예비 지식만으로 충분하다.

"이 책은 커뮤니티에 엄청난 가치가 있을 것이다."
— 마일스 스테인하우져, 선임 클라우드 엔지니어

"서비스 메시가 클라우드 네이티브 단계에 들어오면서 이 탁월한 책은 현대적인 애플리케이션 관리의 여정에 많은 도움을 줄 것이다."
— Layer5의 서비스 메시 커뮤니티 관리자 기리쉬 랑가나단

1장. 서비스 메시 소개
__서비스 메시란 무엇인가?
____기초
__서비스 메시로 항해하기
____클라이언트 라이브러리: 첫 번째 서비스 메시?
____왜 필요한가?
____이미 컨테이너 플랫폼에 이런 것들을 갖고 있지 않은가?
__지형과 생태계
____지형
____생태계
____중요하며 오류 발생가능한 네트워크
____서비스 메시의 가치
__이스티오 서비스 메시
____이스티오의 기원
____이스티오의 현재 상태
____빈도
____릴리스
____기능 현황
____전망
____이스티오가 아닌 것
____단순한 마이크로서비스가 아니다
__용어


2장. 일관된 관찰 가능성에 대한 클라우드 네이티브 접근 방식
__클라우드 네이티브는 무엇을 의미하나?
____클라우드 네이티브로 가는 길
____패키징과 배포
____애플리케이션 아키텍처
____개발과 운영 프로세스
____클라우드 네이티브 인프라
__관찰 가능성은 무엇인가?
____원격 측정의 기둥들
____로그
____메트릭
____추적
____원격 측정 기둥 결합
____분산 시스템에서 관찰 가능성이 왜 핵심인가?
__서비스 메시를 통한 균일한 관찰 가능성
____클라이언트 라이브러리
____모니터링 시스템과 인터페이스


3장. 이스티오 한눈에 보기
__서비스 메시 아키텍처
__플레인
____이스티오 컨트롤 플레인 구성 요소
____서비스 프록시
____이스티오 데이터 플레인 구성 요소
____게이트웨이
__확장성
____사용자 정의 가능 사이드카
____확장 가능 어댑터
__규모와 성능
__배포 모델


4장. 이스티오 배포
__이스티오를 위한 환경 준비
____설치 환경으로서 도커 데스크톱
____도커 데스크톱 구성
__이스티오 설치
____이스티오 설치 옵션
____이스티오의 사용자 정의 리소스 등록
____이스티오 컨트롤 플레인 구성 요소 설치
____Bookinfo 샘플 애플리케이션 배포
____자동 사이드카 주입으로 샘플 앱 배포
____샘플 앱과 네트워킹
__이스티오 제거
__Helm 기반 설치
____Helm 설치
____Helm 템플릿으로 설치
____Helm 기반 설치 확인
____Helm 기반 설치 제거


5장. 서비스 프록시
__서비스 프록시란 무엇인가?
____iptables 기초
__Envoy 프록시 개요
____왜 Envoy인가?
__이스티오의 Envoy
__사이드카 주입
____수동 사이드카 주입
____애드혹 사이드카 주입
____자동 사이드카 주입
____쿠버네티스 초기화 컨테이너
____사이드카 리소스 관리
__Envoy의 기능
____핵심 구성 요소
____인증서와 트래픽 보호


6장. 보안과 ID
__접근 제어
____인증
____권한 부여
__ID
____SPIFFE
__키 관리 아키텍처
____시타델
____노드 에이전트
____Envoy
____파일럿
__mTLS
__이스티오 인증 정책 구성
____인증 정책: mTLS 구성
____권한 부여 정책: 누가 누구와 대화할 수 있는지 구성


7장. 파일럿
__파일럿 구성
____메시 구성
____네트워킹 구성
____서비스 발견
__구성 제공
__파일럿 디버깅과 문제 해결
____istioctl
____파일럿 문제 해결
__추적 구성
____리스너
____라우트
____클러스터


8장. 트래픽 관리
__이스티오 트래픽 흐름 이해
__이스티오 네트워킹 API 이해
____ServiceEntry
____DestinationRule
____VirtualService
____Gateway
__트래픽 조정과 라우팅
__복원성
____로드 밸런싱 전략
____이상치 탐지
____재시도8
____타임아웃
____결함 주입
__인그레스와 이그레스
____인그레스
____이그레스


9장. 메시의 믹서와 정책
__아키텍처
____정책 시행
__믹서 정책 작동 방식의 이해
____원격 측정 보고
__속성
____보고서 전송
____캐시 확인
__어댑터
____프로세스 내 어댑터
____프로세스 외부 어댑터
__믹서 정책 작성과 어댑터 사용
____믹서 구성
____OPA 어댑터
____프로메테우스 어댑터


10장. 원격 측정
__어댑터 모델
____원격 측정 보고
__메트릭
____메트릭을 수집하도록 믹서 구성
____메트릭 수집 설정과 메트릭 질의
____추적
____추적 비활성화
__로그
____메트릭
__시각화


11장. 이스티오 디버깅
__이스티오 구성 요소 검사
__관리 플레인 문제 해결
____kubectl에 한 번 더 베팅하기
__워크로드 준비
____애플리케이션 구성
____네트워크 트래픽 및 포트
____서비스와 배포
____파드
__이스티오 설치와 업그레이드, 제거
____설치
____업그레이드
____제거
__믹서 문제 해결
__파일럿 문제 해결
__갤리 디버깅
__Envoy 디버깅
____Envoy 관리 콘솔
____503 또는 404 요청
____사이드카 주입
____시타델 디버깅
__버전 호환성


12장. 애플리케이션 배포를 위한 실제 고려 사항
__컨트롤 플레인 고려 사항
____갤리
____파일럿
____믹서
____시타델
__사례 연구: 카나리아 배포
____클러스터 간 배포


13장. 고급 시나리오
__고급 토폴로지 유형
____단일 클러스터 메시
____멀티 클러스터 메시
____사례
__토폴로지 선택
____교차 클러스터 또는 멀티 클러스터?
____교차 클러스터 구성
____DNS 구성과 BookInfo 배포

★ 옮긴이의 말 ★

현재 서비스 메시는 마이크로서비스를 기반으로 클라우드 네이티브 애플리케이션을 개발하는 가장 진보된 아키텍처다. 물론 가장 발전했다고 해서 모든 문제점을 해결해주진 못한다. 최신 기술이기 때문에 해결해야 할 난제도 많다.
그러나 개인적으로 서비스 메시를 평가하자면 클라이언트 라이브러리 기반 로드 밸런싱 기능을 C++와 Java 두 가지 언어로 개발하면서 고생한 경험과 클라우드 네트워크의 모든 문제점을 해결해줄 것으로 기대했던 SDN이 풀지 못했던 문제에 대한 해답을 어느 정도 제시한다는 점에서 다른 이들보다 다소 높은 점수를 줄 수 있겠다.
이스티오는 서비스 메시를 가장 강력하게, 가장 쿠버네티스다운 방식으로 구현한 구현체라고 할 수 있다. 2018년 오픈스택 서밋에서 처음 이스티오를 알게 됐을 때의 신선한 충격은 아직도 생생하다.
이스티오는 쿠버네티스의 일부나 확장팩으로 보더라도 전혀 어색하지 않게 자연스럽게 쿠버네티스에 통합된다. 바꿔 말하면 이스티오를 제대로 이해하고 활용하기 위해서는 쿠버네티스를 잘 알아야 한다. 당장 이스티오를 사용하기 어렵다면 쿠버네티스나 가상 네트워킹을 조금 공부해보면 큰 도움이 될 것이다.
현재 이스티오에는 과도한 트래픽으로 인한 부하 등 여러 문제가 존재하지만, 빠른 개발 속도를 볼 때 이러한 문제점은 곧 개선될 것으로 보인다. 또 이러한 문제를 해결하는 과정에서 보여줄 통찰력은 서비스 메시를 직접 적용하지 않더라도 지켜볼 가치가 있을 것이다. 따라서 향후 몇 년 동안은 이스티오와 서비스 메시가 보여주는 발전에 주목해보기를 독자들께 당부 드린다.
한 가지 팁을 드린다면 이스티오를 잘 이해하려면 VirtualService, ServiceEntry,DestinationRule, Gateway 이 네 가지 리소스가 쿠버네티스를 어떻게 확장하는지, 서비스 메시의 제어판인 컨트롤 플레인을 구성하는 믹서와 파일럿의 차이는 무엇인지에 초점을 맞추는 것이 좋다.
VirtualService, ServiceEntry, DestinationRule, Gateway 네 가지 리소스의 이름은 번역할 수도 있지만, 이스티오의 리소스 타입이라기보다는 일반적인 개념으로 받아들여질 수도 있어 따로 번역하지 않고 그대로 뒀음을 밝힌다. 그러나 대문자로 시작하지 않고 일반적인 개념으로 사용된 경우는 ‘게이트웨이’와 같이 우리말로 번역했다.