Istio 문서 Concepts > Traffic Management를 보고 정리한 글
현재 기준 latest(1.20) 문서 참고
트래픽 관리라고 하는 것의 대표적인 예시는 다음이 있다:
•
회로 차단기(circuit breaker)
•
timeouts
•
A/B 테스트
•
canary, staged rollouts
•
% 기반 트래픽 분배
용어
Introducing Istio traffic management
•
트래픽 관리를 위해 서비스와 엔드포인트를 알아야 함 ← 쿠버네티스의 경우 istio를 잘 설치하면 알아 냄(svc , endpoint)
•
서비스 레지스트리 → envoy proxy → 트래픽을 제어
◦
서비스 → 엔드포인트(로드밸런싱 풀); 기본적으로 least conn
•
트래픽 관리 API(=쿠버네티스 CRD)로 세세한 트래픽 구성 가능
◦
A/B 테스트(% 기반 분배), least conn 외의 로드밸런싱 정책, …
◦
메시 바깥의 트래픽에 규칙(rule) 적용, 메시 외부 종속성을 서비스 레지스트리에 추가, …
•
Virtual services
•
요청이 서비스로 라우팅 되는 방식 구성
◦
연결과 검색은 istio + 플랫폼(쿠버네티스)에서 제공
•
destination rules와 함께 istio 트래픽 라우팅 기능의 핵심 요소
•
구성: 라우팅 규칙 셋
◦
순서대로 평가 됨
◦
메시 내 목적지(destination)에 요청을 일치
Why use virtual services?
•
virtual service 없는 (envoy) 기본 동작은 least conn이지만,
•
virtual service로 세세한 동작을 정의할 수 있다.
◦
e.g. canary rollout
◦
20% of calls go to the new version
◦
calls from these users go to version 2
•
여러 서비스에 대한 같은 트래픽 정책을 하나의 virtual service로 할 수 있다
◦
e.g. 네임스페이스 내의 모든 서비스에 대해 하나의 virtual service 적용
▪
모놀리식 → 마이크로 서비스 전환에 사용
▪
calls to these URIs of monolith.com go to microservice A
•
gateway와 조합하여 ingress/egree 트래픽 제어
Virtual service example
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews # IPs, DNS names, ... wildcard(*) 사용 가능
http: # HTTPRoute; (tcp|tls) 도 사용 가능
- match: # HTTPMatchRequest
- headers:
end-user:
exact: jason
route:
- destination:
host: reviews # svc 이름. (FQDN 권장)
subset: v2
- route:
- destination:
host: reviews
subset: v3
YAML
복사
•
특정 사용자(jason)은 v2, 나머지는 v3로 라우팅
•
.spec.hosts : 호스트네임. “실제” 주소, 서비스 레지스트리 안에 구성될 필요 없음
•
.spec.http[].route[].destination.host : 서비스 레지스트리에 구성된 목적지(destination)
•
라우팅 규칙은 위에서부터 순서대로 평가 됨
•
virtual service에 항상 하나 이상의 일치 평가가 되도록 마지막 규칙에
◦
default “no condition” 규칙을
◦
또는 가중치 기반 규칙 사용 권장
More about routing rules
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: bookinfo
spec:
hosts:
- bookinfo.com
http:
- match:
- uri:
prefix: /reviews
route:
- destination:
host: reviews
- match:
- uri:
prefix: /ratings
route:
- destination:
host: ratings
YAML
복사
•
(ingress처럼) 하나의 호스트에서 uri(path) 조건을 줄 수 있음
◦
옵션 exact, prefix, regex, …
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
weight: 75
- destination:
host: reviews
subset: v2
weight: 25
YAML
복사
•
A/B 테스트를 위한 % 가중치 라우팅
•
그 외
◦
헤더 추가/삭제
◦
url rewrite(오!)
◦
목적지마다 재시도 정책
Destination Rules
•
virtual service (routing rule) → destination. 이후 목적지에서 트래픽 제어 구성
•
virtual service routing rule 평가 후 “실제” 목적지에 적용
•
서비스 서브셋(특정 이름의 인스턴스 모음)으로 트래픽 제어
◦
e.g. 서비스 버전별 라우팅
•
envoy 트래픽 정책 지정 가능
◦
e.g. 로드밸런싱 모델
◦
TLS 보안 모드
◦
회로 차단기 설정
Load balancing options
•
(default) leat conn
•
random
•
weighted
•
rr
Destination rule example
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: my-destination-rule
spec:
host: my-svc
trafficPolicy:
loadBalancer:
simple: RANDOM
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
- name: v3
labels:
version: v3
YAML
복사
•
subsets마다 labels 가 쿠버네티스 서비스에 붙어? 식별한다.
•
subsets 이 아닌 전체에 trafficPolicy 를 지정할 수도, subsets 마다 지정할 수도 있다.
Gateways
•
메시 ingress/egress 트래픽에 대한 관리.
•
워크로드 사이드카 envoy가 아닌, 메시 끝단의 standalone envoy에 구성
•
vs. k8s Ingress
◦
L4-6의 로드밸런싱 속성(포트, TLS, …)을 구성할 수 있다.
◦
virtual services에 바인딩 할 수 있다
•
보통 ingress에 사용, egress 구성도 가능
◦
e.g. 전용 출구 노드 구성, 보안 강화
•
기본적인 사전 구성 deploy 제공; istio-ingressgateway, istio-egressgateway
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: ext-host-gwy
spec:
selector:
app: my-gateway-controller
servers:
- port:
number: 443
name: https
protocol: HTTPS
hosts:
- ext-host.example.com
tls:
mode: SIMPLE
credentialName: ext-host-cert
YAML
복사
•
외부에서 ingress gateway에 대한 구성
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: virtual-svc
spec:
hosts:
- ext-host.example.com
gateways:
- ext-host-gwy
YAML
복사
•
라우팅은 virtual service 의 .spec.gateways 로 구성 가능
Service Entries
•
서비스 레지스트리에 (쿠버네티스 svc, endpoint 외에) 추가로 등록하는 entry
•
메시의 서비스 중 하나로 여기게 됨
•
메시 바깥의 트래픽이 관리 가능해진다.
◦
외부 목적지에 리다이렉션 또는 포워딩; web API, 레거시 인프라의 서비스
◦
외부 목적지에 대한 재시도, timeout 또는 장애 주입 정책
◦
VM에서 메시 운영
•
모든 외부 서비스를 메시에 등록하지 않아도 동작은 가능하다.
◦
요청은 기본적으로 envoy를 통과함
◦
다만, 제어는 불가하다.
Service entry example
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: svc-entry
spec:
hosts: # 외부 서비스(의존성) 정의
- ext-svc.example.com
ports:
- number: 443
name: https
protocol: HTTPS
location: MESH_EXTERNAL
resolution: DNS
YAML
복사
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: ext-res-dr
spec:
host: ext-svc.example.com
trafficPolicy:
connectionPool:
tcp:
connectTimeout: 1s
YAML
복사
•
서비스 엔트리로 등록된 외부 서비스의 TCP 연결 timeout 제어
Sidecars
•
기본적으론 envoy 프록시는 워크로드의 모든 포트에서 트래픽을 받고, 모든 워크로드에 트래픽을 포워딩한다.
•
사이드카 구성으로 이를 제어할 수 있다:
◦
트래픽을 받을 포트와 프로토콜 조정
◦
envoy proxy가 도달할 서비스 셋 제한
▪
특정 네임스페이스
▪
특정 워크로드(workloadSelector)
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
name: default
namespace: bookinfo
spec:
egress:
- hosts:
- "./*"
- "istio-system/*"
YAML
복사
Network resilience and testing
•
런타임 동적 ‘옵트인 장애 복구’ 및 ‘장애 주입 기능’이 있다.
◦
애플리케이션 reliability 
◦
메시의 장애 노드 toleration
◦
국지적 장애 확산 방지
Timeouts
•
요청 후 서비스 hang 방지. 예측 가능한 시간 내에 성공이나 실패를 보장한다.
•
HTTP timout은 기본으로 비활성화 되어 있다.
•
virtual service routing rule에 구성 가능하다.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings
spec:
hosts:
- ratings
http:
- route:
- destination:
host: ratings
subset: v1
timeout: 10s
YAML
복사
Retries
•
서비스 초기 요청이 실패했을 때, 다시 연결을 시도하는 최대 횟수를 구성할 수 있다.
•
일시적인 네트워크/서비스 과부하 시 요청이 실패하지 않도록 하는 장치이다.
•
재시도 간격(interval)은 랜덤(25ms+, istio가 판단)
•
HTTP 기본 재시도는 2번.
•
virtual service routing rule에 구성 가능하다.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings
spec:
hosts:
- ratings
http:
- route:
- destination:
host: ratings
subset: v1
retries:
attempts: 3
perTryTimeout: 2s
YAML
복사
Circuit breakers
•
서비스에 대한 요청 제한하는 메커니즘이다.
◦
e.g. 동시 연결 수(concurrent connections)
◦
실패한 요청 수
•
제한에 도달하면 “trip” 된다. → 더 이상 서비스로의 요청이 불가해진다.
•
서비스 과부하 방지
•
destination rule(”실제” 메시 목적지)에 구성 가능하다.
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: reviews
spec:
host: reviews
subsets:
- name: v1
labels:
version: v1
trafficPolicy:
connectionPool:
tcp:
maxConnections: 100
YAML
복사
Fault injection
•
장애 복구 정책이 있는 네트워크를 테스트 할 수 있다.
◦
테스트 대상(메트릭): 장애 복구 용량(failure recovery capacity)
같은 virtual service에 retry나 timeout과 같이 구성할 수 없다.
(Virtual service with fault injection and retry/timeout policies not working as expected)
•
애플리케이션 계층의 장애 주입이 가능하다.
◦
e.g. HTTP 오류 응답 코드
•
virtual service에 구성할 수 있는 두 가지 타입:
◦
지연(delay): 타이밍 장애. 네트워크 지연이나 업스트립 서비스 과부하를 모방함.
◦
중단(abort): 충돌(crash) 장애. 업스트림 장애를 모방함.
▪
보통 HTTP 오류 코드나 TCP 연결 실패의 형태.
# 1/1000 비율로 5초 딜레이 발생
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings
spec:
hosts:
- ratings
http:
- fault:
delay:
percentage:
value: 0.1
fixedDelay: 5s
route:
- destination:
host: ratings
subset: v1
YAML
복사
Working with your applications
•
애플리케이션의 장애 복구 기능과 겹칠 수 있다.
◦
e.g. 애플리케이션에서 2초의 timeout vs. envoy 3초 timout
◦
→ envoy의 기능은 동작하지 않는다.
•
istio 장애 복구 기능은 “메시 수준에서 서비스 안정성과 가용성”을 높이지만,
애플리케이션에서 장애나 오류에 대한 처리가 필요하다.
◦
e.g. 애플리케이션에서 503 fallback 처리가 있어야 한다.