24.07.06 istio 등 자료준비 - istio에서 사용중인 포트 확인만 남음

[guswns1659]

키워드

• k8s에도 서비스라는 네트워크 추상화 개념이 있는데 istio가 sidecar로 붙는 이유는? O
• 서비스메쉬 O
• envoy O
• istio의 타입 O
• ingress gateway 타입 : gateway, virtualService, destinationRule

[guswns1659]

deployment yaml에 istio envoy 컨테이너 spec이 없는데 팟이 생성될 때 자동으로 생성되는 이유

Istio 사이드카 프록시(Envoy)를 파드에 자동으로 주입하는 것은 Istio의 주요 기능 중 하나입니다. Istio는 이를 위해 "자동 사이드카 주입(auto sidecar injection)"이라는 메커니즘을 사용합니다. 이는 Istio의 컨트롤 플레인에서 이루어지며, Istio의 istio-sidecar-injector라는 구성 요소가 이를 담당합니다. 이 기능은 파드를 생성할 때, Istio가 자동으로 사이드카 프록시 컨테이너를 파드에 추가하도록 합니다.

자동 사이드카 주입 메커니즘

1. 네임스페이스 라벨링:

   • 특정 네임스페이스에 Istio 사이드카를 자동으로 주입하려면, 해당 네임스페이스에 라벨을 추가해야 합니다.
   • 예시:

     kubectl label namespace <namespace> istio-injection=enabled

2. Webhook 구성:

   • Istio는 Kubernetes의 MutatingAdmissionWebhook 기능을 사용하여 파드가 생성될 때 자동으로 사이드카 프록시를 주입합니다.
   • istio-sidecar-injector라는 MutatingAdmissionWebhook이 파드 생성 요청을 가로채고, 파드 스펙에 Envoy 사이드카 컨테이너를 추가합니다.

3. 파드 생성 시 사이드카 주입:

   • 새로운 파드가 생성될 때, istio-sidecar-injector가 파드의 정의를 수정하여 Envoy 사이드카 컨테이너를 추가합니다.
   • 파드의 원래 스펙에는 Envoy 사이드카 컨테이너가 없지만, 생성되는 과정에서 자동으로 주입됩니다.

예시: 네임스페이스 라벨링 및 파드 생성

1. 네임스페이스 라벨링:

   kubectl label namespace default istio-injection=enabled

2. 파드 생성:

   • 사용자는 평소와 같이 파드 또는 Deployment를 생성합니다. 파드 스펙에는 Envoy 사이드카가 명시되지 않습니다.
   • 예시:

     apiVersion: apps/v1
     kind: Deployment
     metadata:
     name: myapp
     spec:
     replicas: 3
     selector:
      matchLabels:
        app: myapp
     template:
      metadata:
        labels:
          app: myapp
      spec:
        containers:
        - name: myapp-container
          image: myimage:latest
          ports:
          - containerPort: 8080

3. 자동 주입 확인:

   • 파드가 생성될 때, istio-sidecar-injector는 Envoy 사이드카를 파드에 주입합니다.

   • 파드가 실행 중인 상태에서 실제로 사이드카가 주입되었는지 확인할 수 있습니다:

     kubectl get pods

     kubectl describe pod <pod-name>

     파드 설명에서 두 개의 컨테이너가 포함된 것을 확인할 수 있습니다: 하나는 원래의 애플리케이션 컨테이너, 다른 하나는 Envoy 사이드카 컨테이너입니다.

Envoy 사이드카 컨테이너 확인 예시

파드가 생성된 후, 실제로 주입된 사이드카 컨테이너를 확인할 수 있습니다:

kubectl get pods

kubectl describe pod <pod-name>

출력 예시에서 두 개의 컨테이너가 있음을 확인할 수 있습니다:

• myapp-container: 원래 정의된 애플리케이션 컨테이너
• istio-proxy: Istio가 자동으로 주입한 Envoy 사이드카 컨테이너

Containers:
  myapp-container:
    Container ID:   docker://<id>
    Image:          myimage:latest
    ...
  istio-proxy:
    Container ID:   docker://<id>
    Image:          istio/proxyv2:<version>
    ...

요약

• 자동 사이드카 주입: Istio는 istio-sidecar-injector를 사용하여 파드 생성 시 자동으로 Envoy 사이드카를 주입합니다.
• 네임스페이스 라벨링: Istio 사이드카 주입을 위해 네임스페이스에 istio-injection=enabled 라벨을 추가해야 합니다.
• MutatingAdmissionWebhook: Istio는 Kubernetes의 웹훅 기능을 사용하여 파드 생성 요청을 가로채고, 사이드카를 주입합니다.
• 자동 주입 확인: 파드가 생성된 후 kubectl describe pod 명령어를 통해 주입된 사이드카 컨테이너를 확인할 수 있습니다.

[guswns1659]

istio의 타입

istio도 ingressgateway, pliot, envoy 등 다양한 타입이 존재

Istio의 주요 컴포넌트: istiod, IngressGateway, EgressGateway, Envoy

1. Istiod

Istiod는 Istio의 통합된 컨트롤 플레인 컴포넌트입니다. 이전에는 Pilot, Galley, Citadel, 사이드카 주입기(Sidecar Injector) 등의 개별적인 컴포넌트로 구성되었으나, Istio 1.5부터 istiod라는 단일 바이너리로 통합되었습니다.

• 기능:

  • 서비스 디스커버리: 클러스터 내에서 실행 중인 서비스들을 발견하고 추적합니다.
  • 트래픽 관리: 트래픽 라우팅 규칙과 정책을 설정하고, 이를 Envoy 프록시에 전달합니다.
  • 보안: mTLS를 통해 서비스 간 통신을 암호화하고 인증서 발급 및 관리를 담당합니다.
  • 구성 관리: Istio의 구성 파일을 검증하고 배포합니다.

• 이점:

  • 단순화: 여러 컨트롤 플레인 컴포넌트를 하나로 통합하여 설치, 구성 및 유지보수가 간편해졌습니다.
  • 성능 최적화: 통합된 구조로 인해 리소스 사용이 최적화되고, 확장성이 향상되었습니다.

자세한 내용은 Istio 공식 블로그에서 확인할 수 있습니다【110†source】.

2. IngressGateway

IngressGateway는 외부 트래픽을 서비스 메쉬 내부로 라우팅하는 역할을 합니다. 이는 Kubernetes의 Ingress와 유사하지만, Istio의 고급 트래픽 관리 기능을 활용할 수 있습니다.

• 기능:
  • 외부 트래픽 라우팅: 외부 클라이언트가 서비스 메쉬 내부의 서비스를 사용할 수 있도록 트래픽을 라우팅합니다.
  • 로드 밸런싱: 외부 트래픽을 여러 서비스 인스턴스로 분산시켜 부하를 분산합니다.
  • TLS 종료: HTTPS 트래픽을 수신하고 이를 해독한 후 내부 서비스로 전달합니다.
  • 트래픽 제어: 트래픽 정책, 라우팅 규칙 등을 적용하여 외부 트래픽을 세밀하게 제어합니다.

자세한 내용은 Istio 문서에서 확인할 수 있습니다.

3. EgressGateway

EgressGateway는 서비스 메쉬 내부에서 외부로 나가는 트래픽을 관리합니다. 이는 외부 서비스와의 통신을 제어하고 모니터링하는 데 사용됩니다.

• 기능:
  • 외부 트래픽 제어: 서비스 메쉬 내부에서 외부 서비스로 나가는 트래픽을 제어합니다.
  • 정책 적용: 외부로 나가는 트래픽에 대한 접근 제어 정책을 설정하고 적용합니다.
  • 모니터링 및 로깅: 외부 트래픽을 모니터링하고, 로그를 수집하여 분석에 활용합니다.

자세한 내용은 Istio 문서에서 확인할 수 있습니다.

4. Envoy

Envoy는 Istio의 데이터 플레인 컴포넌트로, 각 서비스마다 사이드카 패턴으로 배포됩니다. 모든 서비스 간의 통신을 가로채고 관리하는 역할을 합니다.

• 기능:
  • 트래픽 라우팅: 서비스 간의 트래픽을 라우팅하고, 설정된 정책에 따라 트래픽을 관리합니다.
  • 로드 밸런싱: 서비스 인스턴스 간의 트래픽을 분산시켜 부하를 분산합니다.
  • 트래픽 쉐이핑: 트래픽의 흐름을 제어하고, 특정 조건에 따라 트래픽을 제한하거나 우선 순위를 부여합니다.
  • mTLS 통신: 서비스 간의 통신을 암호화하여 보안을 강화합니다.

자세한 내용은 Envoy 공식 문서에서 확인할 수 있습니다.

요약

• Istiod: 통합된 Istio 컨트롤 플레인으로, 서비스 디스커버리, 트래픽 관리, 보안, 구성 관리를 담당합니다.
• IngressGateway: 외부 트래픽을 서비스 메쉬 내부로 라우팅하고, TLS 종료, 로드 밸런싱, 트래픽 제어 기능을 제공합니다.
• EgressGateway: 서비스 메쉬 내부에서 외부로 나가는 트래픽을 관리하며, 정책 적용 및 모니터링 기능을 제공합니다.
• Envoy: 데이터 플레인의 핵심 컴포넌트로, 트래픽 라우팅, 로드 밸런싱, 트래픽 쉐이핑, mTLS 통신을 수행합니다.

[guswns1659]

istio 아키텍쳐

k8s와 유사하게 컨트롤 플레인과 데이터 플레인으로 나눠진다.

[guswns1659]

envoy가 트래픽을 가로채는 방법

Envoy는 Kubernetes에서 사이드카 패턴을 사용하여 서비스 오브젝트가 파드로 보내는 요청을 가로챕니다. 이는 Envoy 프록시가 각 파드에 사이드카 컨테이너로 주입됨으로써 이루어집니다. 다음은 Envoy가 Kubernetes 서비스 오브젝트를 통해 파드로 보내는 요청을 어떻게 가로채는지 설명합니다.

사이드카 패턴과 Envoy 주입

1. 사이드카 패턴:

   • 사이드카 패턴은 주 애플리케이션 컨테이너와 함께 보조 컨테이너(사이드카)를 실행하여, 네트워크 트래픽을 처리하고 다양한 기능을 제공합니다. Istio는 Envoy 프록시를 사이드카 컨테이너로 사용합니다.
   • Kubernetes에서 파드 정의에 사이드카 컨테이너를 명시적으로 추가하거나, Istio의 자동 주입 기능을 통해 파드 생성 시 자동으로 주입할 수 있습니다.

2. Envoy 사이드카 자동 주입:

   • Istio는 istio-sidecar-injector를 사용하여 새로운 파드가 생성될 때 Envoy 프록시를 자동으로 주입합니다. 이를 위해 네임스페이스에 istio-injection=enabled 라벨을 추가해야 합니다.
   • Envoy 프록시는 각 파드와 함께 배포되며, 파드의 네트워크 네임스페이스에서 트래픽을 가로챕니다.

트래픽 가로채기 메커니즘

1. IP 테이블 설정:

   • Envoy 사이드카는 iptables 규칙을 사용하여 네트워크 트래픽을 가로챕니다. iptables는 Linux 커널에서 패킷 필터링 및 네트워크 주소 변환(NAT)을 수행하는 유틸리티입니다.
   • 파드의 초기화 컨테이너(Init Container)는 iptables 규칙을 설정하여, 파드의 모든 인바운드 및 아웃바운드 트래픽이 Envoy 프록시를 경유하도록 합니다.

2. 트래픽 리디렉션:

   • 설정된 iptables 규칙에 따라, 파드의 모든 네트워크 트래픽은 Envoy 프록시로 리디렉션됩니다.
   • Envoy 프록시는 Istio 컨트롤 플레인(주로 Pilot)에서 제공하는 라우팅 규칙과 정책을 적용하여 트래픽을 처리합니다.

구성 예시

네임스페이스 라벨링

kubectl label namespace default istio-injection=enabled

파드 정의 예시

파드 정의에는 Envoy 프록시가 명시되지 않지만, 파드 생성 시 자동으로 주입됩니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: myimage:latest
        ports:
        - containerPort: 8080

iptables 규칙 설정 예시

Envoy 프록시는 초기화 컨테이너를 통해 다음과 같은 iptables 규칙을 설정합니다:

# Redirect all outbound traffic to Envoy
iptables -t nat -A OUTPUT -p tcp -j REDIRECT --to-port 15001

# Redirect inbound traffic to Envoy
iptables -t nat -A PREROUTING -p tcp -j REDIRECT --to-port 15001

이 규칙들은 파드 내의 모든 트래픽이 Envoy 프록시를 통과하도록 합니다.

참고 문서

• Istio Documentation - Automatic Sidecar Injection
• Istio Architecture
• Envoy Proxy Official Documentation

요약

• Envoy 사이드카 프록시는 사이드카 패턴을 사용하여 파드에 자동으로 주입됩니다.
• iptables 규칙을 설정하여 파드의 모든 네트워크 트래픽을 Envoy 프록시로 리디렉션합니다.
• Istio 컨트롤 플레인(Pilot 등)에서 제공하는 정책과 라우팅 규칙을 적용하여 트래픽을 관리합니다.

[guswns1659]

envoy에서 사용중인 포트 확인

netstat -tuln