Education*
Devops
Architecture
F/B End
B.Chain
Basic
Others
CLOSE
Search For:
Search
BY TAGS
linux
HTTP
golang
flutter
java
fintech
개발환경
kubernetes
network
Docker
devops
database
tutorial
cli
분산시스템
www
블록체인
AWS
system admin
bigdata
보안
금융
msa
mysql
redis
Linux command
dns
javascript
CICD
VPC
FILESYSTEM
S3
NGINX
TCP/IP
ZOOKEEPER
NOSQL
IAC
CLOUD
TERRAFORM
logging
IT용어
Kafka
docker-compose
Dart
Minikube 와 함께하는 Kubernetes Study 6 - Istio Service Mesh
Recommanded
Free
YOUTUBE Lecture:
<% selectedImage[1] %>
yundream
2023-11-01
2023-05-09
4033
이 문서는 [Minikuber와 함께하는 Kubernetes Study](https://www.joinc.co.kr/w/kubernetes_minikube_index) 의 일부분이다. 아직 Minikuber와 함께하는 Kubernetes Study를 읽기 않았다면, 먼저 읽도록 하자. ## Service Mesh란 최신 애플리케이션은 일반적으로 MSA(MicroService Architecture) 모델로 개발이 된다. 이 모델에서 각 마이크로서비스는 독립적으로 작동한다. 아래 그림은 MSA 모델을 따르는 쇼핑몰의 모습을 묘사하고 있다.  MSA는 확장성, 유연성, 민첩성등에서 큰 강점을 가지고 있지만 여러 독립적인 서비스로 분산되기 때문에 복잡도가 추가된다. 이러한 복잡도는 모니터링, 전체 서비스의 가시성 확보, 서비스 검색(Service Discovery) 등을 어렵게 한다. **서비스 메시(Service mesh)** 는 분산된 애플리케이션에서 서비스간 통신을 관리하는데 도움을 주는 네트워크 인프라 계층으로 트래픽관리, 서비스 검색, 로드밸런싱, 보안 및 관찰 가능성에 도움이 되는 서비스를 제공한다. 서비스 메시의 일반적인 구조는 아래와 같다.  서비스 메시라는 용어 때문에 개발자들이 혼동하는 경우가 있는데, 그냥 **Proxy**다. Proxy 서버가 **사이드카 패턴(Sidecar pattern)** 방식으로 배치되기 때문에 **Sidecar Proxy** 라고 부른다. Istio, Linkerd, Consul, Envoy, Traefik Mesh, Nginx Service Mesh 등 다양한 서비스 애플리케이션들이 있다. 여기에서는 **Istio**로 서비스 메시를 구성할 것이다. ## Service Mesh의 구성요소 Service Mesh는 아래의 구성요소들로 구성된다. * Sidecar Proxy: Sidecar Proxy는 단일 인스턴스 혹은 POD와 함께 실행된다. Sidecar Proxy의 목적은 함께 실행되는 컨테이너로 트래픽을 라우팅하거나 프록시하는 일을 한다. Sidecar Proxy는 다른 Sidecar Proxy와 통신하면서 Service Mesh Control Plane에 의해서 관리된다. * Service Discovery: 인스턴스가 다른 서비스와 통신해야 하는 경우 사용가능한 서비스 인스턴스를 찾아야 한다. 일반적으로 인스턴스는 DNS 조회를 수행하는데, 컨테이너 오케스트레이션 시스템(Kubernetes, ECS 등)은 작동중인 인스턴스의 목록과 인스턴스의 DNS 이름을 제공한다. 이 구조에서는 Service Mesh가 Service Discovery 작업을 대신한다. * 인증 및 승인: Service Mesh는 내부/외부 요청을 승인하고 인증하여 검증된 요청만 인스턴스로 보낼 수 있다. * Circuit breaker pattern 제공: 서비스 메시는 비정상 인스턴스를 격리하고, 정상적으로 작동하는 인스턴스 풀로 다시 가져오는 서킷 브레이커 패턴을 지원한다. * 암호화: Service Mesh는 요청과 응답을 대신 암호화 및 복호화 해서 서비스의 부담을 제거한다. ## Istio 서비스 메시 Istio는 Kubernetes에서 실행되는 마이크로서비스 기반 애플리케이션의 연결, 보안, 관리, 제어, 모니터링 솔류션을 제공하는 오픈소스 서비스메시 플랫폼이다. Istio는 아래와 같은 기능을 제공한다. * Service resilience: 서비스 탄력성을 개선하는 메커니즘을 제공한다. 여기에는 서킷 브레이커(circuit breakers), 타임아웃, 재시도와 같은 기능이 포함되어 오류가 확산되는 걸 방지하고 서비스 종속성을 관리하는데 도움을 준다. * Policy enforcement: 속도제한(Rate limiting), 접근 제어(Access control), 요청 할당량 같은 네트워크 수준에서의 정책을 정의하고 적용할 수 있다. 이러한 정책을 이용해서 마이크로서비스 아키텍처 전반의 보안 및 규정 준수 요구사항을 관리할 수 있다. * Traffic management: 지능형 트래픽 라우팅과 로드 밸런싱 기능을 제공한다. 백분율 기반 트래픽 분할, A/B 테스트, 카나리아 배포와 같은 다양한 라우팅 규칙을 적용하여 서비스간 네트워크 트래픽 흐름을 제어할 수 있다. * Security: TLS(Transport Layer Security)인증을 제공하여 서비스간 인증과 암호화 데이터 통신을 지원한다. 또한 세분화된 엑세스 제어 및 권한등을 통해서 서비스를 보호할 수 있다. * Observability: Istio는 분산 추적, 모니터링을 위한 메트릭 수집 등 강력한 관찰 가능성 기능을 제공한다. Jaeger, Prometheus, Grafana와 같은 모니터링 툴과 통합되어서 서비스의 성능, 상태에 대한 중요 정보들을 얻을 수 있다. Istio는 **Envoy** 라고 하는 데이터 플레인 프록시와 이를 관리하고 구성하기 위한 컨트롤 플레인을 제공한다.  **Envoy** Istio는 Envoy의 확장 버전을 사용한다. Envoy는 서비스 메시의 모든 서비스에 대한 인바운드 아웃바운드 트래픽을 중계하는 프락시 서버다. Envoy는 Istio가 관리하는 유일한 데이터 플레인 컴포넌트다. #### Istio Install 아래와 같이 Istio를 다운로드 하자. ```shell $ curl -L https://git.io/getLatestIstio | ISTIO_VERSION=1.2.4 sh - ``` istio 디렉토리로 이동하면, readme 파일과 install 스크립트, sample을 확인 할 수 있다. ```shell $ cd istio-1.2.4 $ ls LICENSE README.md bin install istio.VERSION samples tools ``` #### Istio를 위한 네임스페이스 생성 ```shell $ kubectl create namespace istio-system $ kubectl get namespace istio-system NAME STATUS AGE istio-system Active 7m54s ``` #### Istio Kubernetes 인스톨 Istio를 kubernetes 클러스터에 설치해보자. Istio 출시버전은 [Istio github release](https://github.com/istio/istio/releases/) 에서 확인할 수 있다. 여기에서는 1.17 버전을 설치한다. ```shell $ export ISTIO_VERSION=1.17.2 $ wget -c -nv https://github.com/istio/istio/releases/download/${ISTIO_VERSION}/istio-${ISTIO_VERSION}-linux-amd64.tar.gz ``` 압축을 풀고 bin 디렉토리로 이동해서 **istioctl**을 /usr/bin 디렉토리로 복사한 후 실행해보자. ```shell $ tar -xvzf istio-1.17.2-linux-amd64.tar.gz $ cd istio-1.17.2/bin $ sudo cp istioctl /usr/bin $ which istioctl /usr/bin/istioctl $ istioctl version no running Istio pods in "istio-system" 1.17.2 ``` istioctl experimental precheck 명령을 실행하여 클러스터가 istio 설치요구사항을 충족하는지 검사한다. ```shell $ istioctl experimental precheck ✔ No issues found when checking the cluster. Istio is safe to install or upgrade! To get started, check out https://istio.io/latest/docs/setup/getting-started/ ``` Kubernetes 클러스터에 Istio를 설치한다. install 명령을 실행하며 Istio 설치 매니페스트를 생성하고 클러스터에 적용한다. ```shell $ istioctl install --set profile=demo -y ✔ Istio core installed ✔ Istiod installed ✔ Egress gateways installed ✔ Ingress gateways installed ✔ Installation complete Making this installation the default for injection and validation. Thank you for installing Istio 1.17. Please take a few minutes to tell us about your install/upgrade experience! https://forms.gle/hMHGiwZHPU7UQRWe9 ``` **istio-system** 네임스페이스에 생성된 리소스를 확인해보자. ```shell $ kubectl get deployments,pods -n istio-system NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/istio-egressgateway 1/1 1 1 5m41s deployment.apps/istio-ingressgateway 1/1 1 1 5m41s deployment.apps/istiod 1/1 1 1 5m55s NAME READY STATUS RESTARTS AGE pod/istio-egressgateway-676bf68b54-9jvzg 1/1 Running 0 5m41s pod/istio-ingressgateway-8d56c999d-chv69 1/1 Running 0 5m41s pod/istiod-dbf5ff64-hmdkf 1/1 Running 0 5m55s ``` istio ingress service의 엔드포인트를 확인하자. ```shell kubectl get services -n istio-system NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE istio-egressgateway ClusterIP 10.99.176.78 <none> 80/TCP,443/TCP 6m15s istio-ingressgateway LoadBalancer 10.97.177.234 <pending> 15021:31034/TCP,80:31330/TCP,443:32230/TCP,31400:30617/TCP,15443:30660/TCP 6m15s istiod ClusterIP 10.108.181.6 <none> 15010/TCP,15012/TCP,443/TCP,15014/TCP 6m29s ``` istio와 함께 제공되는 addon을 적용해보자. addon 디렉토리를 보면 어떤 addon이 설치되는지 확인할 수 있다. 모니터링과 추적을 위한 애드온을 확인 할 수 있다. ```shell $ ls samples/addons README.md extras grafana.yaml jaeger.yaml kiali.yaml prometheus.yam ``` apply 명령으로 addon을 로딩한다. ```shell $ kubectl apply -f samples/addons serviceaccount/grafana created configmap/grafana created ``` **istio-system**이 잘 준비됐는지 확인해보자. 방금 설치한 애드온들이 실행된 걸 확인할 수 있을 것이다. ```shell $ kubectl get deployments -n istio-system NAME READY UP-TO-DATE AVAILABLE AGE grafana 1/1 1 1 2m8s istio-egressgateway 1/1 1 1 14m istio-ingressgateway 1/1 1 1 14m istiod 1/1 1 1 15m jaeger 1/1 1 1 2m7s kiali 1/1 1 1 2m7s prometheus 1/1 1 1 2m7s ``` #### Istio ingress endpoint 확인 Istio 인그레스의 서비스 엔드포인트를 확인하자. ```shell $ kubectl get services -n istio-system NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE istio-egressgateway ClusterIP 10.99.176.78 <none> 80/TCP,443/TCP 26d istio-ingressgateway LoadBalancer 10.97.177.234 10.97.177.234 15021:31034/TCP,80:31330/TCP,443:32230/TCP,31400:30617/TCP,15443:30660/TCP 26d ``` istio-ingressgateway는 **LoadBalancer**로 전개된 것을 확인 할 수 있다. kubecel get service 명령으로 istio 인그레스의 IP 주소를 확인 할 수도 있다. ```shell $ kubectl get service istio-ingressgateway \ -n istio-system \ -o jsonpath='{.status.loadBalancer.ingress[0].ip}{"\n"}' 10.97.177.234 ``` 이제 istio-ingressgateway의 엔드포인트 포트번호를 가져오자. ```shell $ kubectl get service istio-ingressgateway \ -n istio-system \ -o jsonpath='{.spec.ports[?(@.name=="http2")].port}{"\n"}' 80 ``` #### Istio sidecar injection istio는 POD안에 envoy proxy container를 sidecdar 패턴으로 생성하여 서비스메시(discovery, connect, monitor)를 제공한다. 아래와 같이 default namespace에 istio-injection을 enabled 해주면 자동으로 사이드카 패턴이 적용된다. ```shell $ kubectl label namespace default istio-injection=enabled ``` 사이드카 패턴은 kubernetes의 컨테이너 오케스트레이션에서 사용하는 디자인 패턴이다. 사이드카라는 의미 그대로 동일한 POD에 기본 애플리케이션과 함께 "사이드카 컨테이너"라고 하는 추가 컨테이너가 실행이 된다. 사이드카 컨테이너는 애플리케이션 앞단에서 로깅, 프록시, 모니터링, 인증, 암호화 작업등을 수행한다. 이를 통해서 아래와 같은 이점을 얻을 수 있다. 1. 모듈화 및 관심사 분리: 공통으로 수행되는 기능을 떼어냄으로써, 애플리케이션은 핵심업무에 집중할 수 있다. 2. 코드 재사용성: 사이드카 컨테이너는 여러 애플리케이션에서 재사용 할 수 있다. 코드 공유를 촉진하고 중복을 줄여서 배포 및 관리 프로세스를 단순화 한다. 3. 교차절단 문제: 로깅, 모니터링, 보안, 서비스 검색, 프록시와 같은 교차절단 문제를 처리할 수 있다. 이런 작업을 사이드카 컨테이너로 오프로드 하여 기본 애플리케이션은 비즈니스 구현에 집중할 수 있다.  #### Istio 예제 애플리케이션 배포 https://github.com/istio/istio/blob/master/samples/helloworld/helloworld.yaml 에 있는 helloworld 예제 설정파일을 다운로드해서 애플리케이션을 배포해 보자. ```shell $ kubectl apply -f helloworld.yaml service/helloworld unchanged deployment.apps/helloworld-v1 unchanged deployment.apps/helloworld-v2 unchanged ``` deployments와 POD 가 만들어졌는지 확인해 보자. ```shell $ kubectl get deployments,pods -l app=helloworld NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/helloworld-v1 1/1 1 1 26d deployment.apps/helloworld-v2 1/1 1 1 26d NAME READY STATUS RESTARTS AGE pod/helloworld-v1-77489ccb5f-pq7zx 1/1 Running 2 (119m ago) 26d pod/helloworld-v2-7bd9f44595-48q6g 1/1 Running 2 (119m ago) 26d ``` 서비스가 실행됐는지 확인해보자. ```shell $ kubectl get services -l app=helloworld NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE helloworld ClusterIP 10.109.120.97 <none> 5000/TCP 26d ``` https://github.com/istio/istio/blob/master/samples/helloworld/helloworld-gateway.yaml 매니페스트를 이용해서 helloworld gateway를 생성하자. ```shell $ kubectl apply -f helloworld-gateway.yaml gateway.networking.istio.io/helloworld-gateway created virtualservice.networking.istio.io/helloworld created ``` Gateway 와 VirtualService가 배포됐는지 확인한다. ```shell $ kubectl get gateways,virtualservices NAME AGE gateway.networking.istio.io/helloworld-gateway 7m20s NAME GATEWAYS HOSTS AGE virtualservice.networking.istio.io/helloworld ["helloworld-gateway"] ["*"] 7m20s ``` 응용 프로그램(helloworld)를 호출하기 위한 URL 경로를 가져온다. ```shell $ kubectl get virtualservice helloworld \ -o jsonpath='{.spec.http[0].match[0].uri}{"\n"}' {"exact":"/hello"} ``` **/hello** 와 정확하게 매칭하면 helloworld 서비스를 호출하는 것을 알 수 있다. 테스트를 해보자. ```shell $ curl -vvv 10.97.177.234/hello * Trying 10.97.177.234:80... * Connected to 10.97.177.234 (10.97.177.234) port 80 (#0) > GET /hello HTTP/1.1 > Host: 10.97.177.234 > User-Agent: curl/7.88.1 > Accept: */* > < HTTP/1.1 200 OK < content-type: text/html; charset=utf-8 < content-length: 60 < server: istio-envoy < date: Tue, 09 May 2023 01:47:14 GMT < x-envoy-upstream-service-time: 67 < Hello version: v1, instance: helloworld-v1-77489ccb5f-pq7zx * Connection #0 to host 10.97.177.234 left intact ``` ## Istio Kiali Dashboard Kiali는 Istio용 모니터링 웹 콘솔로 트래픽을 모니터링하고 네트워크 토폴로지에 대한 레포트를 제공함으로써 서비스 메시의 구조와 상태를 파악하는데 도움을 준다. 다른 터미널에서 kiali 대시보드를 실행해 보자. ```shell $ istioctl dashboard kiali http://localhost:20001/kiali ```  Application을 선택하고 default Namespace를 선택하면 helloworld에 대한 정보를 확인 할 수 있다.  아래와 같이 특정 시간 범위에 대한 트래픽 흐름을 가시적으로 확인 할 수도 있다.   ![]() ## 참고 * [What is a service mesh?](https://www.nginx.com/blog/what-is-a-service-mesh/) * [Guided Exercise: Installing Istio on a Minikube Cluster](https://kubebyexample.com/learning-paths/istio/install)
Recent Posts
MLOps with Joinc - Kubeflow 설치
Vertex Gemini 기반 AI 에이전트 개발 05. 첫 번째 LLM 애플리케이션 개발
LLama-3.2-Vision 테스트
Vertex Gemini 기반 AI 에이전트 개발 04. 프롬프트 엔지니어링
Vertex Gemini 기반 AI 에이전트 개발 03. Vertex AI Gemini 둘러보기
Vertex Gemini 기반 AI 에이전트 개발 02. 생성 AI에 대해서
Vertex Gemini 기반 AI 에이전트 개발 01. 소개
Vertex Gemini 기반 AI 에이전트 개발-소개
생성 AI 모델 Flux.1 설치 및 사용
GPT를 이용한 Reranker 테스트
Archive Posts
Tags
cloud
devops
kubernetes
minikube와 함께하는 kubernetes study
Copyrights © -
Joinc
, All Rights Reserved.
Inherited From -
Yundream
Rebranded By -
Joonphil
Recent Posts
Archive Posts
Tags