1. Istio가 Kubernetes에서 실행되는 이유가 뭔가?
  2. 클라우드 환경에서 배포되는 애플리케이션 아키텍처에서 Kubernetes와 Service Mesh의 역할이 무엇인가?
  3. Istio는 Kubernetes의 어떤 측면(aspect)를 확장하는가? 혹은 어떤 문제점을 해결해주는가?
  4. Kubernetes, Envoy, Istio의 관계는 무엇인가?

​

대충 이런 궁금증

​

​

​

Service Mesh의 이해

Service간의 마이크로화로 인해 Service의 수도 많아지고, 상호간의 연결 복잡도가 증가하면서 각 Service들을 효율적으로 관리할 필요가 생겼다.

 

Service Mesh : Service를 발견-연결-모니터링하는 과정

​

애플리케이션에 대한 라우팅, 보안 및 안정성 기능을 추가하고 네트워크 흐름을 관리하고 제어하기 위한 개념

프로젝트가 확장됨에 따라서 마이크로서비스 간의 통신을 관리하기가 훨씬 복잡해짐

ex) User → Order → Delivery 처럼 chain 형태

​

​

서비스 메시의 이점

분산 애플리케이션 내에서 복잡한 서비스간의 통신을 처리하는 인프라 계층을 제공

​

  • 서비스 검색(Discovery)
    • Service Registry를 사용해서 Mesh 내의 모든 Service를 동적으로 트래킹
    • Service는 위치나 기반 인프라에 관계없이 서로 원활하게 찾아서 통신
  • 로드 밸런싱
    • 라운드 로빈, 최소 연결, 가중치 로드밸런싱 등 LB 정책을 선택하여 Service Instance에 지능적으로 분산
  • 트래픽 관리
    • 요청 라우팅 및 트래픽 동작을 제어하는 고급 트래픽 관리 기능
  • 트래픽 분할
    • 보안(서비스간 호출에서 mTLS 암호화, 인증 및 권한 부여 지원)
    • 요청 비율 제한(Rate Limiting 구성)

​

그럼 서비스 메시를 꼭 써야하나요?

프로젝트의 요구사항, 규모, 복잡성, 보안 및 관리 요소를 모두 판단해서 결정해야한다.

​

  • 마이크로 서비스의 수도 적고, 프로젝트 규모가 적으면 오버 엔지니어링이 될 수 있다.
  • 인프라 전문 인력 등의 인적 리소스가 부족하다면 관리 부담만 추가된다.
  • 기존 아키텍처가 안정적이면 필요 없음
  • 추가 리소스가 부족한 상황에서 인프라 부족

​

Istio에 대해 알아보자

Service간의 연결을 Proxing으로 제어하는 오픈소스

 

https://istio.io/latest/docs/

​

가시성, 트래픽 관리, 보안, 정책을 단순화할 수 있는 서비스 메시

사이드카 서비스 모델 : 애플리케이션 수준의 수정,배포 없이 간편하게 구성할 수 있다.

​

​

Connect

Service간의 로드밸런싱 및 트래픽 제어(Canary 배포 - Timeout, Circuit Breaker, Retries)

 

Secure

Service 인증, 권한 제어 밒 통신 암호화(TLS)

 

Control

정책 관리(유랑 제어, 라우팅 정책 -접근하는 사용자, Device 등에 따른 Service 연결)

 

Observe Services

logging 및 metrics 수집

​

​

탄생 배경

처음 Netflix가 공개한 Service mesh 오픈소스가 사용하기 복잡했다.

또 Spring Framework로 추상화해서 쓰기 쉽게 만들었는데, Java만 사용 가능하다

​

그래서 애플리케이션 수준이 아니라 인프라 수준에서 Service mesh를 해결하려는 시도

  ↔  Date Plane : Service간의 트래픽 제어를 담당하는 프록시 그룹

​

 

네트워크 계층에서 Service 연결 문제를 해결하고자 함(각 Service마다 Proxy를 통해 연결을 제어)

→ Control Plane 등장 : Proxy 구성 설정을 저장하고 전달하는 프록시 통제 그룹

​

 

여기서 Istio의 역할이 Date Plane을 통제하여 Service Mesh를 수행하는 것이다.

​

 

Istio는 Envoy라는 프록시 소프트웨어를 사용한다.

Envoy는 사절 외교관이라는 의미로 Lyft 사에서 개발한 클라우드 전용 L7 프록시 모듈이다.

​

​

​

Istio의 아키텍처

잘봐라

Pord 시작시 서비스마다 프록시(Envoy)가 구성된다.

이게 사이드카 패턴이고, Service의 내부 In/Outbound는 모두 프록시를 거쳐서 지나간다.

​

Data Plane

Service Mesh 수행 그룹으로, 마이크로 서비스간의 모든 네트워크 연결을 관리한다.

​

프록시(Proxy)

  • Envoy 프록시가 Service간의 In/Outbound 트래픽을 중계
  • 각 Service마다 Envoy가 1:1 sidecar 형태로 구성되어 트래픽을 제어

Mixer : 서비스 라우팅 정책 관리와 모니터링

​

​

Control Plane(Istiod)

Data plain 제어 그룹으로, Envoy에 트래픽이 연결될 수 있도록 관리한다.

​

  • Pilot : 엔드포인트 관리, 로드밸런싱, 트래픽 제어
    • Service Discovery : envoy에게 Service 엔드포인트(IP, Port) 제공
    • 로드밸런싱, 트래픽 제어(Service resiliency. timeout,circuit breaker, retries)
  • Gallery : 구성 정보를 수집,처리,배포하는 컴포넌트
  • Citadel : 인증/인가및 인증서 관리
    • Autentication & Authorization(TLS 등), Credential(인증서) 관리

​

Istio의 주요 기능

1. 트래픽 관리

  • 트래픽 분리 - 복수 개의 버전으로 트래픽을 라우팅
    • ex) A/B Test, Canary 배포, Blue/Green 배포 등
  • 실패 주입 - 테스트를 위해 네트워크 수준의 장애 주입
    • ex) delay나 연결 실패 주입으로 일부 케이스 시뮬레이션
  • Circuit breakers
    • 신속하게 요청이 실패하고, 가능한 빠르게 하부 단에 부하가 생기지 않도록 연결 차단

2. 모니터링

  • 네트워크 개요
  • 서비스 맵

3. 보안

  • 서비스간 트래픽 인증(mTLS)
  • 라우팅 정책

 

​

Service Mesh Maturity Model

하; 그럼 Service Mesh의 모든 기능을 다 적용해야하는가???

​

네트워크 가시성 확보 → 트래픽 관리 → 상호 인증 → Role 기반 인증 → 멀티 클러스터 확장

​

​

​

Kubernetes 환경에서 Istio 설치하기

Helm Charts : https://istio.io/latest/docs/setup/install/helm/

 

helm repo add istio https://istio-release.storage.googleapis.com/charts
helm repo update

kubectl create namespace istio-system
helm install istio-base istio/base -n istio-system --set defaultRevision=default
helm ls -n istio-system

istio/base는 동작에 관련된 Custom Resource Definitions(CRDs)를 정의한다

​

Control Plane에 해당하는 istiod(demon)을 설치한다

 

helm install istiod istio/istiod -n istio-system --wait
// 기본에 이미 설치하다 말았으면 install -> upgrade

helm status istiod -n istio-system
kubectl get deployments -n istio-system --output wide

// 외부에서 구성할 것이라 Ingress도 구성(AWS LoadBalanceController 사용)
kubectl create namespace istio-ingress
helm install istio-ingress istio/gateway -n istio-ingress --wait --set service.annotations."service\.beta\.kubernetes\.io/aws-load-balancer-scheme"=internet-facing,service.annotations."alb\.ingress\.kubernetes\.io/target-type"=ip

​

기존 프로젝트에서는 Terraform 코드를 수정해서 Istio Port에 대한 접근을 허용해줘야한다.

 

https://istio.io/latest/docs/ops/deployment/platform-requirements/

​

생성된 LoadBalancer의 scheme가 Internet-facing이도록 Terraform의 정책을 허용

​

​

.template/gateway.yaml

apiVersion: networking.stio.io/v1alpha3
kind: Gateway
metadata:
	name: {{ include "membership-service-charts.fullname" . }}
	labels:
		{{- include "membership-service-chart.labels" . | nindent 4 }}
spec:
	selector:
		istio: ingress
	servers:
	- port:
			number: 80
			name: http
			protocol: HTTP
		hosts:
		- "*"

 

.template/vutualservice.yaml

apiVersion: networking.stio.io/v1alpha3
kind: VirtualService
metadata:
	name: {{ include "membership-service-charts.fullname" . }}
	labels:
		{{- include "membership-service-chart.labels" . | nindent 4 }}
spec:
	hosts:
	- "*"
	gateways:
	- {{ include "membership-service-chart.fullname" . }}
	http:
	- match:
		- url:
				prefix: /
		route:
		- destination:
				host: {{ include "membership-service-chart.fullname . }}
				port:
					number: {{ .Values.service.port }}

모든 들어오는 요청을 membership-servic Service로 라우팅하고 포트를 number 형태로 적어주면 된다.

​

$ kubelctl label namespace default istio-injection=enabled

defualt에 생성되는 Pod는 모두 사이드카를 자동으로 주입받도록 한다.

​

이제 변경한 membership-service를 defualt 네임스페이스로 프로비져닝하면 사이드카 형태로 프록시 모듈이 같이 생성된다.

​

Pod 상세보기로 들어가면 컨테이너가 3개 뜬다.

  • istio-init
  • istio-proxy
  • membership-service-chart

​

​

마지막으로, 로드밸런서의 DNS 이름/actuator/health 로 접속해서 Envoy에 잘 라우팅되지도 확인해보자

​

Istio Ingress Gateway를 타고 응답을 정상적으로 라우팅해서 가져온다.

  • IngressGateway : k8s cluster 외부에서 들어오는 트래픽을 관리
  • VirtualService : 내부 서비스에 대한 라우팅 및 트래픽 제어를 담당

​

​

Spring Boot Actuator 설정을 했으면 잘 뜬다.

흠. gRPC도 공부하고 싶다

​

​

출처 및 인용.

https://istio.io/latest/about/service-mesh/

https://thenewstack.io/why-do-you-need-istio-when-you-already-have-kubernetes/

저작자표시 비영리 동일조건

'kubernetes' 카테고리의 다른 글

ArgoCD를 이용한 무중단 배포하기(Canary 방식, argo-rollout)  (0) 2024.11.19
Spring Boot Actuator를 이용한 Kubernetes Pod의 Health check  (0) 2024.11.19
kubernetes Pod의 Graceful Shutdown (feat. Kafka)  (0) 2024.11.19
kubernetes 환경에서 Apache Kafka cluster를 구성해보자 (Operator 패턴)  (0) 2024.11.19
kubernetes 환경에서 MySQL, Redis를 구성해보자  (0) 2024.11.19

티스토리툴바