이번 시간에도 마찬가지로
Istio 설정들이 진짜 엄청 많기 때문에
설정 위주보다는
Service Mesh 설계를 어떻게 해야할지
어떤 구조인지 흐름인지를 공부하려고 합니다.
설정들은 진짜 중요한 설정들이 있으면 나중에 따로 글을 또 써보려고 합니다.
Service Mesh
Service Mesh : MSA 환경에서 서비스들이 거미줄 처럼 부르는 명칭
이러한 서비스의 복잡도를 추상화 시켜 서비스들을 관리하게 편하게 나온 아키텍처입니다.
Service Mesh 구성
- Data Plane
- Control Plane
Service 끼리의 직접 통신이 아닌 Proxy를 통한 통신을 이루는 구성을 가지고 있습니다.
Istio란?
Istio 기능
- 서킷 브레이크
- Service Discovery
- 인증
- 로드 밸런싱
Pilot
- Service Discovery 역할
- Envoy에 대한 설정관리
Eureka랑 비슷한 역할을 합니다.
Mixer
- Service Mesh 전체에서 액세스 제어 및 정책 관리
- 각종 모니터링 지표의 수집
Galley
- Istio 설정 검증
Citadel
- 보안 역할
- 서비스를 사용하기 위한 인증
- TLS(SSL)암호화, 인증서 관리
Istiod
istio-1.5.0 버전 이상부터는
위 구성요소들이 하나로 합쳐진 istiod 통합되었다고 합니다.
또한 Pilot이 Mixer 역할도 같이 동작합니다.
Pod에 Sidecar Injection 적용
apiVersion: apps/v1
kind: Deployment
metadata:
name: test-api-deployment
labels:
app: test-api
spec:
replicas: 3
selector:
matchLabels:
app: test-api
strategy:
type: RollingUpdate
template:
metadata:
labels:
app: test-api
sidecar.istio.io/inject: "true" # namespace 클러스터에 사이드카 Envoy 적용
spec:
containers:
- name: test-api
image: test-api
imagePullPolicy: Always
ports:
- containerPort: 8080
....사이드카(Envoy) 의존성 주입을 허용해주는 옵션입니다.
kubectl label namespace default istio-injection=enabled
해당 CLI로도 동작이 가능하나 yaml 파일 관리가 훨씬 좋다고 생각하기 때문에 yaml 으로 관리하였습니다.
해당 Deployment로 배포하면 Pod 스키마 metadata.annotaion에 istio.init, istio.envoy 등등등 생기더라고요.
제가 원하는 Istio 구성
일부 인증은 Istio 사용을 해야하고
라우팅은 Spring Cloude Gateway 가 해줘야 하는 상황인데
Eureka 사용 시에는 URI를 lb:test-api 이런식으로 써줬는데
클러스터에서 Istio 사용 시에는 URI를 클러스터 IP를 작성해줘야 하는건지,
k8s DNS에 타 클러스터를({namesapce}.svc.cluster.local) 써줘야 하는건지는 삽질하면서 알아봐야겠네요
토스가 진짜 제가 원하는 구성으로 구축하였는데 전체적인 아키텍쳐는 설명해줬지만 안에 세세한 설정은 공유를 안해줬더라고요 ㅠㅠㅠ (당연한 이야기)
Istio Gateway도 대안이긴 하나
Spring Cloud Gateway에서 단순 라우팅 규칙이 아니라서
Istio Gateway로는 적합하지 않은 Gateway 입니다.
느낀 점
EKS 쓰면 편해지지 않을까요?........
Kiali 도 구성해서 대쉬보드 구성해야지...
프로메테우스 해줘야지....
하...
네이티브 쿠버네티스를 구성하면서
k8s 대한 이해도가 많이 높아져서 좋기는 한데
뭐 하나 할때마다 모르는 거 엄청 튀어나와서 죽을 지경입니다...
참고
