DevOps - istio(2)

istio를 실무에서 사용하는 방법

클러스터 내 서비스 간의 보안 통신을 위해 istio를 주로 사용함

주로 Sidecar mode를 이용

-> 파드 단위로 트래픽 제어 또는 보안정책, 모니터링이 필요하기 때문

sidecar로 주입되기 때문에 애플리케이션 코드 수정없이 관리 가능

하지만 sidecar이기 때문에 리소스 사용량이 조금 높으면서, sidecar이기 때문에 파드 생성 시, 주입되어야 해서 느림

 

ambient mode

-> 노드 단위에서 프록시를 관리

파드보다 위에서 관리함(L4기반)

리소스 효율적이거나 대규모일 때 고려할 만 함

 

 

istio 관리 운영

helm, istioctl 로 제어가 가능하지만

istio는 직접 관리하지 않고 istio operator로 간접관리 경우가 있음

istioctl을 래핑하고 CRD를 만들어서 istio operator를 만들어서 관리

https://istio.io/v1.21/docs/setup/install/operator/

어떻게 운영하는지는 클러스터의 istio 상태로 알 수 있음

 

 

Istio Architecture

기본

https://istio.io/latest/docs/ops/deployment/architecture/

 

2 부분으로 이루어짐

data plane and a control plane.

• The data plane is composed of a set of intelligent proxies (Envoy) deployed as sidecars. These proxies mediate and control all network communication between microservices. They also collect and report telemetry on all mesh traffic.
• The control plane manages and configures the proxies to route traffic.

 

 

Components

Envoy

Istio uses an extended version of the Envoy proxy.

Envoy is a high-performance proxy developed in C++ to mediate all inbound and outbound traffic for all services in the service mesh.

Envoy proxies are the only Istio components that interact with data plane traffic.

 

• Listener : 어떠한 IP, 포트 등을 처리할지를 정의
  • 예를 들어, 0.0.0.0:80으로 바인딩한 뒤 example.com 이라는 도메인에 대해서만 요청을 처리
• Route : Listener로 들어온 요청을 어디로 라우팅할 것인지를 정의
  • 이 때, 라우팅 대상은 일반적으로 Cluster라는 것에 대한 것
• Cluster : 실제 요청이 처리되는 IP 또는 여타 엔드포인트의 묶음을 의미
• Endpoint : 172.17.0.2, 172.17.0.3과 같이 실제로 접근 가능한 엔드포인트를 의미
  • 엔드포인트가 모여서 하나의 Cluster

 

envoy.yaml 파일을 까보면 CDS, LDS 등은 모두 ADS라는 항목으로부터 받아오도록 설정

ADS는 최종적으로 xds-grpc 클러스터를 가리킴

xds-grpc 클러스터는 istio-pilot.istio-system을 가리킴(istiod)

 

 

• LDS (Listener Discovery Service): Envoy가 수신할 리스너(포트, 프로토콜 등)를 정의합니다.
• RDS (Route Discovery Service): 리스너에 대한 라우팅 규칙을 설정합니다.
• CDS (Cluster Discovery Service): Envoy가 통신할 백엔드 클러스터(서비스)를 지정합니다.
• EDS (Endpoint Discovery Service): 클러스터의 구체적인 엔드포인트(예: 파드 IP)를 제공합니다.
• SDS (Secret Discovery Service): TLS 인증서와 같은 보안 설정을 전달합니다.

 

ADS (Aggregated Discovery Service): 위의 xDS 서비스를 하나의 gRPC 스트림으로 통합하여 구성 요소 간의 일관성을 유지합

 

Kubernetes에서 MutatingWebhook은 파드가 생성되기 전에 해당 파드의 설정을 동적으로 변경할 수 있도록 해주는 기능

istio-sidecar-injector: Istio 컨트롤 플레인에 배포되는 MutatingWebhook 설정과 웹훅 서비스를 제공하는 Kubernetes Deployment

MutatingWebhookConfiguration (Istio): Kubernetes API 서버에 등록된 Istio의 MutatingWebhook 설정으로, 특정 조건의 파드 생성 시 istio-sidecar-injector 웹훅 서비스를 호출하도록 정의

Istio의 기본 설정은 istio-injection=enabled 레이블이 있는 네임스페이스 또는 파드에 대해 웹훅을 활성화

 

 

Istiod

Istiod provides service discovery, configuration and certificate management.

It abstracts platform-specific service discovery mechanisms and synthesizes them into a standard format that any sidecar conforming with the Envoy API can consume.

 

You can use Istio’s Traffic Management API to instruct Istiod to refine the Envoy configuration to exercise more granular control over the traffic in your service mesh.

Istiod security 

enables strong service-to-service and end-user authentication with built-in identity and credential management.

You can use Istio to upgrade unencrypted traffic in the service mesh.

Using Istio, operators can enforce policies based on service identity rather than on relatively unstable layer 3 or layer 4 network identifiers.

Additionally, you can use Istio’s authorization feature to control who can access your services.

Istiod acts as a Certificate Authority (CA) and generates certificates to allow secure mTLS communication in the data plane.

 

 

istiod는 xDS(Discovery Service)라는 API를 통해 Envoy를 제어

• LDS (Listener Discovery Service): Envoy가 수신할 리스너(포트, 프로토콜 등)를 정의.
• RDS (Route Discovery Service): 리스너에 대한 라우팅 규칙을 설정
• CDS (Cluster Discovery Service): Envoy가 통신할 백엔드 클러스터(서비스)를 지정
• EDS (Endpoint Discovery Service): 클러스터의 구체적인 엔드포인트(예: 파드 IP)를 제공
• SDS (Secret Discovery Service): TLS 인증서와 같은 보안 설정을 전달

 

 

Istiod는 Kubernetes API 서버를 지속적으로 감시

-> 서비스, 파드, 엔드포인트 등의 변화를 실시간으로 파악

 

Envoy는 Istiod에 연결하여 xDS API를 통해 설정을 요청하고,

Istiod는 이에 맞는 설정(LDS, RDS, CDS, EDS 등)을 제공

 

Ingress Gateway

• Istio 서비스 메쉬로 들어오는 외부 트래픽을 관리하는 컴포넌트
• Envoy 프록시 기반으로 구현되며, 외부 요청을 수신하고 VirtualService 및 Gateway CR 설정을 기반으로 메쉬 내부 서비스로 라우팅
• TLS 종료, HTTP/HTTPS 라우팅, 프록시 프로토콜 등을 지원

 

 

 

Istio Custom Resource

 

 

• Traffic Management:
  • VirtualService: 서비스 메쉬 내의 트래픽 라우팅 규칙을 정의
    • 호스트 이름, 경로, 헤더, 포트 등을 기반으로 트래픽을 특정 대상으로 라우팅하거나, 트래픽 분할 (Canary Deployment), HTTP 리디렉션/재작성, 타임아웃/재시도 정책 등을 설정
  • DestinationRule: 트래픽이 라우팅될 수 있는 대상 서비스의 속성을 정의
    • 로드 밸런싱 알고리즘, 연결 풀 설정, 이상 감지 (Outlier Detection), TLS 설정 등을 구성
  • Gateway: 서비스 메쉬의 경계에서 외부 트래픽 (Ingress) 또는 내부 트래픽 (Egress)을 관리하는 로드 밸런서 설정을 정의합니다. 호스트, 포트, TLS 설정 등을 지정
  • ServiceEntry: Kubernetes 서비스 레지스트리에 없는 외부 서비스에 대한 엔드포인트를 정의
  • 이를 통해 메쉬 내부 서비스가 외부 서비스를 마치 메쉬 내부 서비스처럼 접근하고 Istio의 트래픽 관리 기능을 적용
  • Sidecar: 특정 네임스페이스 또는 워크로드에 주입되는 Envoy 사이드카 프록시의 설정을 세밀하게 제어
    • 프록시가 가로챌 트래픽 범위, 리소스 설정 등을 지정
• Security:
  • PeerAuthentication: 서비스 간의 상호 TLS (mTLS) 설정을 정의
    • 메쉬 전체 또는 특정 워크로드에 대해 mTLS를 활성화/비활성화하고, 인증 방법을 지정
  • AuthorizationPolicy: 서비스에 대한 접근 제어 정책을 정의
    • 요청의 주체 (Principal), 네임스페이스, IP 주소, HTTP 메서드, 경로 등을 기반으로 접근을 허용하거나 거부하는 규칙을 설정
  • RequestAuthentication: 최종 사용자 인증 (End-User Authentication) 설정을 정의
    • JWT (JSON Web Tokens) 검증 규칙을 지정하여 요청에 포함된 토큰의 유효성을 검사하고, 인증된 사용자의 정보를 기반으로 권한 부여 정책을 적용할 수 있습니다.
• Policy and Telemetry (Legacy 및 대체):
  • Policy (Legacy): (Istio 1.11에서 제거됨) 
  • Telemetry: (Istio 1.20에서 도입) 서비스 메쉬의 텔레메트리 (메트릭, 로그, 트레이싱) 구성을 중앙 집중식으로 관리하기 위한 CRD
    • OpenTelemetry Collector와 통합하여 다양한 백엔드 시스템으로 데이터를 내보냄
  • WasmPlugin: Envoy 프록시에 WebAssembly (Wasm) 기반의 사용자 정의 확장을 배포하고 관리하기 위한 CRD
    • 이를 통해 트래픽 처리 로직, 보안 정책, 텔레메트리 수집 등을 사용자 정의.
• Extensibility:
  • EnvoyFilter: Envoy 프록시의 설정을 직접 수정할 수 있는 강력한 CRD
    • 고급 트래픽 관리, 보안, 로깅 등의 기능을 사용자 정의할 수 있지만, 잘못된 설정은 메쉬의 안정성에 영향을 미칠 수 있으므로 주의해서 사용

 

 

 

 

 

 

---

 

istio pilot 역할

현재는 istiod로 하나의 바이너리로 통합됨

Pilot 아키텍쳐 - 트래픽 관리

 

 

 

 

 

 

istio service discovery

 

• 서비스 제공자(예: Kubernetes 또는 Consul)로부터 서비스 정보를 가져옴
• K8S API 서버(K8S CRD 리소스)에서 트래픽 규칙 가져오기
• 서비스 정보와 트래픽 규칙은 데이터 플레인이 이해할 수 있는 형식으로 변환되고, 표준 데이터 플레인 API를 통해 메시의 각 사이드카로 전송

 

 

 

 

---

 

istio를 거쳐서 pod 로 도달하는 과정

전제 조건:

• Istio가 클러스터에 정상적으로 설치되어 있고, 자동 사이드카 주입이 활성화
• 트래픽이 도달하려는 파드는 Istio 서비스 메쉬에 속해 있으며, Envoy 사이드카 프록시가 함께 실행
• Ingress Gateway가 적절하게 설정되어 외부 트래픽을 수신하고 Istio 메쉬 내부로 라우팅할 수 있도록 구성

 

트래픽 흐름:

1. 외부 클라이언트의 요청: 외부의 클라이언트가 Istio 서비스 메쉬 내부의 특정 서비스로 트래픽을 보냄
2. Ingress Gateway 도착: 클러스터로 들어오는 트래픽은 Istio의 Ingress Gateway 컴포넌트에 먼저 도달
   • Ingress Gateway는 서비스 메쉬의 경계에서 로드 밸런서 역할을 하며, 외부 트래픽을 수신하고 메쉬 내부의 서비스로 라우팅하는 역할을 담당
   • Ingress Gateway는 Kubernetes의 Service (Type: LoadBalancer 또는 NodePort) 형태로 노출되어 외부 트래픽을 받음
   • Ingress Gateway는 Envoy 프록시 기반으로 구현되어 Istio의 트래픽 관리 기능을 그대로 활용
3. Ingress Gateway의 Envoy 프록시 처리: Ingress Gateway에 도달한 트래픽은 Gateway 파드 내에서 실행 중인 Envoy 프록시에 의해 처리
   • Envoy 프록시는 수신된 요청의 헤더, 경로, 포트, 프로토콜 등의 정보를 기반으로 라우팅 규칙을 적용
   • 이 라우팅 규칙은 Istio의 Gateway와 VirtualService 설정을 통해 정의
     • Gateway: 외부 트래픽을 수신할 호스트, 포트, TLS 설정 등을 정의
     • VirtualService: Gateway를 통해 들어온 트래픽을 어떤 내부 서비스로 라우팅할지, 트래픽 분할, 헤더 조작, 리디렉션 등의 트래픽 관리 정책을 정의
   • Envoy 프록시는 설정된 VirtualService 규칙에 따라 트래픽의 목적지 서비스 (Kubernetes Service 이름)를 결정
4. 내부 서비스로 라우팅: Ingress Gateway의 Envoy 프록시는 결정된 목적지 서비스의 파드 IP 주소로 트래픽을 전달
   1. Kubernetes Service는 여러 개의 파드 IP 주소를 가질 수 있으며, Envoy 프록시는 설정된 로드 밸런싱 정책 (Round Robin, Least Connections 등)에 따라 파드를 선택
5. 목적지 파드의 Envoy 사이드카 도착: 트래픽은 선택된 목적지 파드의 네트워크 인터페이스에 도착
   1. Istio의 자동 사이드카 주입 기능에 의해 해당 파드에는 애플리케이션 컨테이너와 함께 Envoy 사이드카 프록시 컨테이너가 실행
6. Envoy 사이드카 프록시 처리 (수신): 파드에 도착한 트래픽은 먼저 해당 파드 내에서 실행 중인 Envoy 사이드카 프록시에 의해 가로채짐
   • Istio는 iptables (또는 CNI)를 사용하여 파드의 모든 인바운드/아웃바운드 트래픽을 Envoy 사이드카 프록시로 리디렉션
   • Envoy 사이드카 프록시는 수신된 요청에 대해 다음과 같은 Istio 기능을 적용할 수 있습니다.
     • 보안 (Security): mTLS (Mutual TLS) 인증 및 권한 부여 정책을 적용하여 클라이언트의 신원을 확인하고 접근 권한을 검사
     • 트래픽 관리 (Traffic Management): VirtualService와 DestinationRule에 정의된 트래픽 정책 (타임아웃, 재시도, 서킷 브레이커 등)을 적용
     • 텔레메트리 (Telemetry): 메트릭, 로그, 트레이싱 데이터를 수집하여 Istio의 관찰성 기능을 지원
     • 정책 적용 (Policy Enforcement): Istio의 Policy CRD (Custom Resource Definition)를 통해 정의된 사용자 정의 정책 (할당량, 속도 제한 등)을 적용
7. 애플리케이션 컨테이너로 전달: Envoy 사이드카 프록시가 모든 필요한 처리를 완료하면, 트래픽은 동일한 파드 내에서 실행 중인 애플리케이션 컨테이너로 전달
   1. 이 과정은 일반적으로 로컬 네트워크 인터페이스를 통해 이루어짐
8. 애플리케이션 처리 및 응답: 애플리케이션 컨테이너는 수신된 요청을 처리하고 응답을 생성

 

역순으로 다시 응답

 

 

 

istio operator를 통한 운영

https://luv-n-interest.tistory.com/1652