Service Mesh : Telemetry (Kiali) - 동적 트래픽 라우팅

https://www.udemy.com/course/kubernetes-istio-hands-on/

▲섹션5 - 원격 측정

3-kiali-secret.yaml은 abundant하게 됨. 로그인 password를 kiali를 인증 시스템에 통합할 수 있음.

3-kiali-secret.yaml 파일은 원래 Kiali 대시보드에 접근하기 위해 사용자 이름과 비밀번호를 설정하는 용도로 사용되었습니다.
하지만, Istio의 최신 버전에서는 Kiali 접근을 위해 사용자 이름과 비밀번호를 설정할 필요가 없어졌습니다.
이는 Kiali가 자체 인증 메커니즘을 제거하고, 대신 다른 인증 시스템과 통합할 수 있게 되었기 때문입니다.
따라서, 3-kiali-secret.yaml 파일을 적용하지 않아도 Kiali를 사용할 수 있으며, 그 파일은 더 이상 필요하지 않게 되었음.

 

일반적으로 서비스를 ingress gateway에 배포하게 됨 -> 이게 일반적으로 승인을 처리함.

 

4-label-default-namespcae.yaml적용할 때는,

이 yaml파일 안에는 istio구성이 전혀 없음. 그냥 표준 쿠버네티스.

네임스페이스에 레이블을 지정하는 단계를 제외하고 그냥 일반적인 쿠버네티스 응용 프로그램을 배포하면 됨. 그르면 이스티오가 제공하는 원격 측정 기능 모두 사용 가능.

커스텀 라우팅 같은 걸 시작할 때만 yaml을 다루게 됨.

---

2개의 컨테이너 안에서 모든 팟들이 실행되고 있다면 이스티오 데이터 플레인이 실행되고 있는 것

컨테이너들 중 두 번째가 사이드카 프록시임

 

모든 ns의 label을 사이드카 인젝션으로 지정할 필요는 없음.

--> 왜??

 

Istio에서 사이드카 프록시를 모든 네임스페이스에 주입하지 않아도 되는 이유

이유 1: 리소스 효율성

사이드카 프록시는 추가적인 리소스를 소비합니다.

모든 네임스페이스에 사이드카 프록시를 주입하면 불필요한 리소스 사용이 발생할 수 있습니다.

따라서 사이드카 프록시가 필요한 네임스페이스에만 주입하는 것이 효율적입니다.

이유 2: 필요성에 따른 주입

모든 애플리케이션이나 서비스가 Istio의 트래픽 관리, 보안, 관찰 가능성 등의 기능을 필요로 하지 않을 수 있습니다.

Istio의 기능이 필요하지 않은 서비스나 네임스페이스에는 사이드카 프록시를 주입할 필요가 없습니다.

이유 3: 네임스페이스 별 설정 가능

Istio는 네임스페이스 단위로 사이드카 주입을 제어할 수 있습니다.

특정 네임스페이스에만 사이드카 주입을 활성화하여 관리 복잡성을 줄이고, 필요한 경우에만 Istio의 기능을 사용할 수 있습니다.

사이드카 주입 방식

Istio에서 사이드카 주입 방식은 두 가지가 있습니다:

1. 자동 주입(Auto Injection):
   • Istio의 자동 사이드카 주입 기능을 사용하면, 네임스페이스에 istio-injection=enabled 라벨을 설정한 후, 해당 네임스페이스에 생성되는 모든 포드에 사이드카 프록시가 자동으로 주입됩니다.
   • 명령어: kubectl label namespace <namespace> istio-injection=enabled
2. 수동 주입(Manual Injection):
   • 수동으로 사이드카 프록시를 주입할 수 있습니다. 이는 사이드카 주입이 필요한 특정 포드에만 적용할 수 있습니다.
   • 명령어: istioctl kube-inject -f <deployment>.yaml | kubectl apply -f -

네임스페이스에 사이드카 주입 설정

모든 네임스페이스에 사이드카를 주입하지 않아도 되는 설정은 다음과 같은 명령어로 제어할 수 있습니다:

1. 특정 네임스페이스에 사이드카 주입 설정:
2. kubectl label namespace <namespace> istio-injection=enabled
3. 사이드카 주입 비활성화:
4. kubectl label namespace <namespace> istio-injection=disabled

요약

모든 네임스페이스에 사이드카 프록시를 주입하지 않아도 되는 이유는 리소스 효율성, 필요성에 따른 주입, 네임스페이스 별 설정 가능성 등입니다. Istio의 기능이 필요한 네임스페이스에만 사이드카를 주입하여 효율적으로 관리할 수 있습니다.

---

pod bouncing -> 초기화한다는 의미같은.

"Pod bouncing"이란 일반적으로 Kubernetes에서 포드(Pod)가 주기적으로 재시작되는 현상을 의미합니다.

이 용어는 공식적인 Kubernetes 용어는 아니지만, 커뮤니티나 운영 환경에서 흔히 사용됩니다.

Pod Bouncing의 원인

Pod bouncing이 발생하는 이유는 다양할 수 있습니다:

1. 애플리케이션 오류:
   • 포드 안의 컨테이너가 예기치 않게 종료되거나 크래시(Crash)되면, 쿠버네티스는 이를 감지하고 포드를 재시작합니다.
2. 리소스 부족:
   • 클러스터의 CPU, 메모리 등 리소스가 부족할 경우, Kubernetes는 리소스 제한에 따라 포드를 종료하고 재시작할 수 있습니다.
3. 헬스 체크 실패:
   • Liveness probe 또는 Readiness probe가 실패하면, Kubernetes는 해당 포드를 재시작합니다.
4. 설정 변경:
   • 포드 설정(예: 환경 변수, 볼륨 등)이 변경되면, Kubernetes는 새로운 설정을 반영하기 위해 포드를 재시작합니다.
5. 노드 문제:
   • 포드를 호스팅하는 노드가 문제를 일으키면, 포드는 다른 노드로 옮겨지고 재시작될 수 있습니다.

Pod Bouncing의 영향

Pod bouncing은 일시적으로 애플리케이션 가용성에 영향을 줄 수 있습니다. 특히, 다음과 같은 경우 문제가 될 수 있습니다:

• 서비스 다운타임 증가
• 데이터 손실(예: 비영구 데이터 저장 시)
• 클러스터 리소스 낭비

Pod Bouncing 문제 해결 방법

1. 로그 분석:
   • 포드의 로그를 확인하여 애플리케이션이 왜 종료되는지 파악합니다.
2. 리소스 할당 조정:
   • 충분한 CPU 및 메모리를 포드에 할당합니다.
3. 헬스 체크 설정 확인:
   • Liveness probe와 Readiness probe 설정을 검토하고 적절히 조정합니다.
4. 노드 상태 확인:
   • 클러스터 노드의 상태를 확인하고, 문제가 있는 노드를 복구하거나 교체합니다.
5. 쿠버네티스 이벤트 확인:
   • kubectl describe pod <pod-name> 명령어를 사용하여 포드 이벤트를 확인합니다.

요약

Pod bouncing은 포드가 주기적으로 재시작되는 현상을 의미합니다.

이는 애플리케이션 오류, 리소스 부족, 헬스 체크 실패 등 다양한 원인으로 발생할 수 있습니다.

Pod bouncing 문제를 해결하려면 로그 분석, 리소스 할당 조정, 헬스 체크 설정 확인 등을 통해 원인을 파악하고 해결해야 합니다.

istio-system ns로 팟을 받으면

얘는 1개씩이잖음 -> 컨트롤 플레인.

근데 왜 prometheus만 2개지?? 얘는 데이터 플레인인가??
Istio에서 실행 중인 포드들 중에서 Prometheus 포드가 2개의 컨테이너를 가지고 있는 이유는, Prometheus 포드에 사이드카 프록시가 주입되었기 때문입니다. 이와 관련된 자세한 설명은 다음과 같습니다:

Prometheus 포드의 두 개의 컨테이너

Prometheus 포드는 다음 두 개의 컨테이너를 포함할 수 있습니다:

1. Prometheus 컨테이너: 실제로 모니터링 데이터를 수집하고 저장하는 Prometheus 애플리케이션.
2. Envoy 사이드카 컨테이너: Istio의 사이드카 프록시로, 서비스 메시에 트래픽을 라우팅하고 모니터링, 로깅 및 트래픽 제어 기능을 제공하는 Envoy 프록시.

Prometheus 포드에 사이드카 프록시가 주입된 이유는, Prometheus가 Istio 메쉬 내에서 다른 서비스의 메트릭을 수집할 때, Envoy 프록시를 통해 통신하기 때문입니다. 이는 Istio의 모니터링과 관찰 가능성 기능을 활용하기 위함입니다.

컨트롤 플레인 vs 데이터 플레인

Istio의 구성 요소들은 다음과 같이 분류할 수 있습니다:

컨트롤 플레인

• istiod: Istio의 메인 컨트롤 플레인 컴포넌트로, 서비스 메쉬의 설정과 관리, 인증, 라우팅 규칙 등을 담당합니다.

데이터 플레인

• Envoy 프록시: 각 서비스의 사이드카로 주입되어 서비스 간 트래픽을 제어하고 모니터링합니다. 데이터 플레인의 주요 역할을 수행합니다.

네임스페이스 및 레이블

네임스페이스에 사이드카 주입을 설정하면, 해당 네임스페이스 내의 모든 포드에 Envoy 프록시가 자동으로 주입됩니다. Prometheus 포드는 이러한 주입 정책에 따라 사이드카 프록시가 추가된 것입니다.

요약

Prometheus 포드가 2개의 컨테이너를 가지고 있는 이유는 사이드카 주입 설정이 활성화되었기 때문입니다. 이는 Prometheus가 Istio 메쉬 내에서 동작하며, Envoy 프록시를 통해 트래픽을 라우팅하고 모니터링할 수 있도록 하기 위함입니다. Prometheus 포드도 이스티오 데이터 플레인의 일부로 간주할 수 있으며, 이는 메트릭 수집 및 모니터링 기능을 제공하는 데 중요한 역할을 합니다.

---

동적 트래픽 라우팅

❗️이게 뭔지 정확히 알고 가기...

동적 트래픽 라우팅(Dynamic Traffic Routing)은 서비스 간의 트래픽을 실시간으로 제어하고 분배하는 기술입니다.

이는 특히 마이크로서비스 아키텍처에서 유용하며, 다양한 운영 시나리오에서 활용됩니다.

동적 트래픽 라우팅을 통해 트래픽을 특정 서비스 버전으로 유연하게 라우팅하거나, 다양한 라우팅 정책을 적용하여 서비스의 가용성과 성능을 최적화할 수 있습니다.

주요 특징과 활용 사례

1. A/B 테스트:
   • 트래픽의 일부를 새로운 서비스 버전(B)으로 라우팅하고, 나머지는 기존 버전(A)으로 보내어 두 버전을 비교 테스트합니다.
2. 카나리 배포(Canary Release):
   • 새로운 서비스 버전을 단계적으로 배포하여, 트래픽의 일부만 새로운 버전으로 보내고 나머지는 기존 버전으로 라우팅합니다. 이를 통해 새로운 버전의 안정성을 검증할 수 있습니다.
3. 블루-그린 배포(Blue-Green Deployment):
   • 두 개의 거의 동일한 서비스 버전(블루와 그린)을 운영하면서, 트래픽을 일시에 블루에서 그린으로 전환하여 배포의 중단 없이 새 버전을 배포할 수 있습니다.
4. 트래픽 샤딩(Traffic Sharding):
   • 서비스의 부하를 분산시키기 위해 트래픽을 여러 서비스 인스턴스에 분산하여 보내는 방식입니다. 이를 통해 서비스의 성능을 최적화할 수 있습니다.
5. 장애 조치(Failover):
   • 특정 서비스 인스턴스에 장애가 발생했을 때, 자동으로 트래픽을 다른 인스턴스로 라우팅하여 서비스의 가용성을 보장합니다.

동적 트래픽 라우팅의 구현

동적 트래픽 라우팅을 구현하기 위해 Istio와 같은 서비스 메쉬를 사용합니다.

Istio에서는 다음과 같은 주요 구성 요소가 동적 트래픽 라우팅을 지원합니다:

1. VirtualService

VirtualService는 서비스로 들어오는 트래픽의 라우팅 규칙을 정의합니다. 예를 들어, 특정 트래픽의 비율을 새 버전의 서비스로 보내거나, 트래픽을 특정 조건에 따라 분기시키는 규칙을 설정할 수 있습니다.

2. DestinationRule

DestinationRule은 서비스의 트래픽 정책을 정의합니다. 이는 로드 밸런싱, 연결 풀 관리, 장애 조치 등의 설정을 포함합니다.

동적 트래픽 라우팅의 장점

• 유연성: 다양한 트래픽 관리 정책을 실시간으로 적용할 수 있습니다.
• 안정성: 새로운 서비스 버전의 점진적 배포와 장애 조치를 통해 시스템의 안정성을 높일 수 있습니다.
• 성능 최적화: 트래픽 분산과 로드 밸런싱을 통해 서비스의 성능을 최적화할 수 있습니다.

결론

동적 트래픽 라우팅은 마이크로서비스 환경에서 매우 유용한 기술로, 서비스의 배포와 운영을 유연하고 안정적으로 관리할 수 있게 해줍니다. 이를 통해 서비스의 가용성, 성능, 그리고 사용자 경험을 크게 개선할 수 있습니다.

이 fleetman-staff-service에 문제가 있다고 생각해서 들여다 보면

오른쪽 위에 보이는 Actions로 Suspend Traffic을 할 수 있음.

하게되면 이렇게 뜨게 되고,

yaml이 만들어져서 적용이 됨

그러면 저렇게 브랜치 모양 = 일종의 라우팅이 적용되고 있다. 라는 모양이 생긴 걸 확인할 수 있꼬

원래 보이던 staff의 driver이름과 사진을 보여주던 게 셧다운된 걸 볼 수 있음.

staff-service는 이걸 담당하고 있었던 걸 확인 가능.

트래픽 관리 기능은 이스티오가 제공하는 쿠버네티스 객체인 VirtualServices(vs)에 의해 구현됨.

저걸 라우팅 하기 전에 virtualservice랑 destinationrules를 get 해보면 원래 없었는데,

라우팅하면 생기고, 다시 delete하면 없어짐.(쟤네가 트래픽 라우팅을 관리하니까, 쿠버네티스 라우팅 규칙과 정책을 적용함)

VirtualService

VirtualService는 요청 트래픽이 어떻게 라우팅될지 정의합니다.

이는 요청이 들어오는 URL, HTTP 헤더, 메소드 등 다양한 조건을 기반으로 트래픽을 특정 서비스로 라우팅하거나 분할하는 규칙을 설정할 수 있습니다.

• 트래픽 라우팅: 특정 조건에 따라 트래픽을 다양한 서비스로 라우팅합니다.
• 로드 밸런싱: 트래픽을 여러 백엔드 서비스 인스턴스에 분배합니다.
• 페일오버: 특정 백엔드 인스턴스가 응답하지 않을 때 다른 인스턴스로 트래픽을 재라우팅합니다.
• 미러링: 실시간 트래픽을 다른 서비스로 복사하여 테스트합니다.

VirtualService 예시:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - uri:
        prefix: "/v1/"
    route:
    - destination:
        host: reviews
        subset: v1
  - route:
    - destination:
        host: reviews
        subset: v2

위의 예제에서 /v1/로 시작하는 요청은 reviews 서비스의 v1 버전으로 라우팅되고, 그 외의 요청은 v2 버전으로 라우팅됩니다.

DestinationRule

DestinationRule은 VirtualService에 의해 라우팅된 트래픽이 도착하는 서비스의 정책을 정의합니다.

이는 로드 밸런싱, 연결 풀 설정, TLS 설정 등을 포함합니다.

• 서브셋 정의: 서비스의 특정 버전이나 인스턴스 그룹을 정의합니다.
• 로드 밸런싱 정책: 라운드 로빈, 최소 연결, 해시 기반 등 다양한 로드 밸런싱 전략을 설정합니다.
• 연결 풀: 연결 수, 타임아웃 등 연결에 대한 세부 설정을 정의합니다.
• TLS 설정: 서비스 간 통신의 보안 설정을 관리합니다.

DestinationRule 예시:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN

위의 예제에서 reviews 서비스의 두 가지 서브셋(v1, v2)이 정의되고, 라운드 로빈 방식의 로드 밸런싱이 설정되었습니다.

결론

• VirtualService는 어떤 트래픽이 어디로 라우팅될지를 정의합니다.
• DestinationRule은 라우팅된 트래픽이 도착하는 서비스의 세부 설정을 정의합니다.

이 두 가지 객체를 함께 사용하면 Istio를 통해 매우 세밀하고 유연한 트래픽 관리 및 라우팅 정책을 설정할 수 있습니다.

VirtualService는 주로 트래픽의 방향과 분할을 정의하고, DestinationRule은 트래픽이 도착한 후의 처리 방식을 정의합니다.

다시 Istio config를 들여다 보면 HTTP Route가 오류나면 503반환하고

yaml이 이런식으로 구성되어 있어서 만약에 내가 저 코드를 기반으로 시작하고 싶으면 복붙해서 적용시키면 됨.

요 파일 보면 kind:VirtualService인 거 확인 가능

delete하게 되면 요렇게 다시 귀요미 강아지 운전사 사진이 생긴다.