트래픽 관리
트래픽 컨트롤은 VirtualService 와 DestinationRule 설정을 통해서 동작한다
- 클라이언트 PC → Istio ingressgateway 파드 → (Gateway, VirtualService + DestinationRule) → Cluster(Endpoint - 파드)
- Gateway : 지정한 인그레스 게이트웨이로부터 트래픽이 인입, 프로토콜 및 포트, HOSTS, Proxy 등 설정 가능
- VirtualService : 인입 처리할 hosts 설정, L7 PATH 별 라우팅, 목적지에 대한 정책 설정 가능 (envoy route config) - 링크
사용 예시 : 헤더 매칭에 따라서, 각기 다른 destination 으로 라우팅
apiVersion: networking.istio.io/v1alpha3 kind: **VirtualService** metadata: name: reviews spec: hosts: - reviews http: - **match**: - headers: end-user: exact: jason route: - **destination**: host: reviews subset: **v2** - route: - **destination**: host: reviews subset: **v3**VirtualService 는 DestinationRule 에서 설정된 **서브셋(subset)**을 사용하여 트래픽 컨트롤을 할 수 있다
hosts 필드 : 목적지 주소 - IP address, a DNS name (FQDN), 혹은 k8s svc 이름 , wildcard (”*”) prefixes
Routing rules : HTTP 경우 - Match 필드(예, 헤더) , Destination(istio/envoy 에 등록된 대상, subnet 에 DestinationRule 활용)
- HTTPRoute : redirect , rewrite , fault(장애 주입) , mirror(복제, 기본 100%) , corsPolicy(CORS 삽입) , headers(헤더 조작) 등 - 링크
Routing rule precedence : Routing rules are evaluated in sequential order from top to bottom - 위에서 순차적 적용
- DestinationRule : 실제 도착지(서비스와 1:1 연결)의 정교한 정책(부하분산, 연결 옵션, 서킷 브레이크, TLS 등)을 설정 - 링크
사용 예시 : 3개의 subsets for the
my-svcdestination service 에 3개의 subsets 이 있고, 이중 v1/v3 은 RAMDOM 이고 v2 는 ROUND_ROBINapiVersion: 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: v3Load balancing options : Round robin(기본값) , Random , Weighted , Least requests - 링크
- Destination Rule : TrafficPolicy , Subset , ConnectionPoolSettings 등 - 링크
- 서브셋(subsets)을 정의할 수 있어 마이크로서비스 버전별로 라우팅할 때 사용한다
실습
Request Routing
샘플 파일들 확인
cd ~/istio-$ISTIOV/samples/bookinfo/networking
tree
기본 DestinationRule 적용
k apply -f destination-rule-all.yaml
DestinationRule 확인 dr(=destinationrules) : KIALI Services 확인 시 GW, VS, DR 확인
k get dr
NAME HOST AGE
details details 5s
productpage productpage 5s
ratings ratings 5s
reviews reviews 5s
virtual-service-all-v1.yaml => 4개 서비스 모두 v1의 서브셋에 전송하는 정책 테스트
k apply -f virtual-service-all-v1.yaml
k get virtualservices
NAME GATEWAYS HOSTS AGE
bookinfo ["bookinfo-gateway"] ["*"] 21m
details ["details"] 13s
productpage ["productpage"] 13s
ratings ["ratings"] 13s
reviews ["reviews"] 13s
virtual-service-reviews-test-v2.yaml : User Identity 기반 라우팅, end-user 커스텀 헤더에 jason 매칭 시 reviews v2 로 전달
k apply -f virtual-service-reviews-test-v2.yaml
Fault Injection
Fault injection은 HTTP 결함 주입 - 의도적으로 지연(Latency)를 발생시키거나 중단허는데 사용한다.
end-user 가 jason 는 ratings v1 에 7초 지연 발생, 그외 사용자는 ratings v1 정상 연결
k apply -f virtual-service-ratings-test-delay.yaml
end-user 가 jason 는 ratings v1 에 500 에러 리턴, 그외 사용자는 ratings v1 정상 연결
k apply -f virtual-service-ratings-test-abort.yaml
Traffic Shifting
카나리 전략시에 사용한다.
기본 설정
k apply -f virtual-service-all-v1.yaml
v1 50%, v3 50%
k apply -f virtual-service-reviews-50-v3.yaml
v1 80%, v2 20%
k apply -f virtual-service-reviews-80-20.yaml
v1 90%, v2 10%
k apply -f virtual-service-reviews-90-10.yaml
Request Timeout
기본적으로 request timeout은 비활성이지만, 덮어쓰기로 설정이 가능하다.
2초 지연 설정
reviews service 는 reviews v2 만 호출 설정
k apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v2
EOF
ratings service 호출 시 2초 지연 설정 >> 가장 끝단에서 장애 상황이라고 재연 >> 앞단의 모든 서비스가 영향을 받는다
k apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings
spec:
hosts:
- ratings
http:
- fault:
delay:
percent: 100
fixedDelay: 2s
route:
- destination:
host: ratings
subset: v1
EOF
보안
제로 트러스트 (ZT: Zero Trust)는 ‘아무것도 신뢰할 수 없다는 가정하에, 사용자 및 다양한 정보를 바탕으로 최소한의 권한과 세밀한 통제를 지속적으로 수행하는 보안 활동’입니다. 이 컨셉에서는 내부자에 의해 내부 환경도 보안이 충분히 탈취될 수 있다고 가정하기 때문에 아무것도 신뢰할 수 없다고 가정하여 보안성을 높입니다. 서비스 매쉬환경을 구성하여 쿠버네티스 환경을 구성하면 기본적으로 Istio proxy 통신이 모두 내부적으로 mtls 통신을 하기 때문에 전체 제로 트러스트 컨셉의 통신 보안효율성을 높일 수 있습니다.
TLS vs mTLS
TLS- 암호화방식 인증서 Handshake- TLS는 네트워크로 통신을 하는 과정에서 도청, 간섭, 위조를 방지하기 위해서 설계됨. 암호화를 통해 인증, 통신 기밀성을 제공.
- TLS의 3단계 기본 절차: (1) 지원 가능한 알고리즘 서로 교환 (2) 키 교환, 인증 (3) 대칭키 암호로 암호화하고 메시지 인증
TLSvsMTLS- 링크 소개- MTLS 절차 : 서버측도 클라이언트측에 대한 인증서를 확인 및 액세스 권한 확인
Istio의 인증서 발급 및 관리 과정
- istiod는 gRPC 서비스를 제공하여 인증서 서명 요청(CSR)을 처리한다
- Istio-agent는 시작 시 개인 키와 인증서 서명 요청(CSR)을 생성하고, 이 CSR을 자신의 자격 증명과 함께 istiod로 전송한다.
- istiod에 있는 인증 기관(CA)이 CSR에 포함된 자격 증명을 검증한다. 검증이 성공하면, CA는 CSR을 서명하여 인증서를 발급한다.
- 워크로드(서비스 A)가 시작되면, Envoy 프록시는 동일한 컨테이너에 있는 Istio 에이전트에게 인증서와 개인 키를 요청한다. 이 요청은 Envoy의 gRPC기반 SDS API를 통해 이루어진다.
- Istio 에이전트는 istiod로부터 받은 인증서와 개인 키를 Envoy에 전달한다. 이 과정 역시 Envoy SDS API를 통해 수행된다.
- Istio 에이전트는 워크로드 인증서의 만료를 모니터링하며, 주기적으로 인증서와 개인 키를 갱신하기 위해 위의 과정을 반복한다.
인증 지원 종류
- 피어 인증(Peer Authentication): 위에서 본 것처럼 mTLS 기반 서비스 간 인증으로, 연결을 시도하는 클라이언트를 검증하는 데 사용된다.
- 요청 인증(Request Authentication): JWT(JSON Web Token) 검증을 통해 요청 수준의 인증을 지원하며, 맞춤형 인증 제공자나 OpenID Connect 제공자를 사용할 수 있다.
실습
Istio STRICT 모드
네임스페이스 생성
k create ns test
파드 생성
cat <<EOF | k create -f -
apiVersion: v1
kind: Pod
metadata:
name: netpod
namespace: test
spec:
containers:
- name: netshoot-pod
image: nicolaka/netshoot
command: ["tail"]
args: ["-f", "/dev/null"]
terminationGracePeriodSeconds: 0
EOF
사이드카 존재유무확인
k get pod -n test
NAME READY STATUS RESTARTS AGE
netpod 0/1 ContainerCreating 0 14s
ratings 서비스 확인
k get svc ratings
로컬 접속 시도 확인
k exec -it -n test netpod -- curl ratings.default:9080/health ;echo
{"status":"Ratings is healthy"}
모드 전환
Peer authentication 설정 변경 : PERMISSIVE(mTLS 사용/미사용 모두 허용) → STRICT(반드시 mTLS 사용, 미사용 시 거부)
cat <<EOF | k create -f -
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default-strict
spec:
mtls:
mode: STRICT
EOF
접속시도
k exec -it -n test netpod -- curl ratings.default:9080/health ;echo
curl: (56) Recv failure: Connection reset by peer
command terminated with exit code 56
HTTP Traffic AuthorizationPolicy
k apply -f - <<EOF
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: allow-nothing
namespace: default
spec:
{}
EOF
확인
k get AuthorizationPolicy
NAME ACTION AGE
allow-nothing 25s
설정 변경
k apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: "productpage-viewer"
namespace: default
spec:
selector:
matchLabels:
app: productpage
action: ALLOW
rules:
- to:
- operation:
methods: ["GET"]
EOF
k get AuthorizationPolicy
NAME ACTION AGE
allow-nothing 3m4s
productpage-viewer ALLOW 4s
결과: # 확인 : productpage 는 200 ok 이지만, reviews/details 는 403 에러
k apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: "details-viewer"
namespace: default
spec:
selector:
matchLabels:
app: details
action: ALLOW
rules:
- from:
- source:
principals: ["cluster.local/ns/default/sa/bookinfo-productpage"]
to:
- operation:
methods: ["GET"]
EOF
k apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: "reviews-viewer"
namespace: default
spec:
selector:
matchLabels:
app: reviews
action: ALLOW
rules:
- from:
- source:
principals: ["cluster.local/ns/default/sa/bookinfo-productpage"]
to:
- operation:
methods: ["GET"]
EOF
k apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: "ratings-viewer"
namespace: default
spec:
selector:
matchLabels:
app: ratings
action: ALLOW
rules:
- from:
- source:
principals: ["cluster.local/ns/default/sa/bookinfo-reviews"]
to:
- operation:
methods: ["GET"]
EOF
