쿠버네티스 실습: Istio로 서비스 메시(Service Mesh) 구축하기

쿠버네티스 실습: Istio로 서비스 메시(Service Mesh) 구축하기

앞선 글에서는 운영 중 발생할 수 있는 주요 트러블슈팅 사례 — CrashLoopBackOff, PVC 바인딩 실패, Ingress 비정상 동작, HPA 미확장 등 — 을 해결하는 방법을 실습했습니다.
이제 한 단계 더 나아가, 대규모 마이크로서비스 환경에서의 트래픽 제어, 보안, 관찰성을 위해 서비스 메시(Service Mesh) 개념을 배우고, 이를 Istio로 실습합니다.

---

1) 서비스 메시(Service Mesh)란?

기본 개념

• 마이크로서비스 아키텍처에서는 수십~수백 개의 서비스가 통신합니다.
• 단순 Ingress나 LoadBalancer로는 보안, 트래픽 제어, 모니터링이 어렵습니다.
• 이를 해결하기 위해 등장한 것이 Service Mesh입니다.

핵심 기능

1. 트래픽 제어 – Canary 배포, Blue-Green 배포, 요청 라우팅, Fault Injection 등
2. 보안 – 서비스 간 mTLS 자동 적용
3. 관찰성 – 요청 단위 트레이싱, 대시보드 제공
4. 정책 제어 – Rate Limit, 인증, 접근 제어

구성 요소

• Data Plane: 각 Pod에 주입되는 사이드카 프록시(Envoy)
• Control Plane: 트래픽 정책, 인증, 라우팅을 제어하는 Istiod

---

2) Istio 설치

2-1. Istio CLI 설치

curl -L https://istio.io/downloadIstio | sh -
cd istio-1.*
export PATH=$PWD/bin:$PATH

2-2. 기본 프로파일로 설치

istioctl install --set profile=demo -y

설치 확인:

kubectl get pods -n istio-system

예상 출력:

NAME                                    READY   STATUS    AGE
istiod-xxxxx                            1/1     Running   2m
istio-ingressgateway-xxxxx              1/1     Running   2m

---

3) 네임스페이스 라벨링 (자동 사이드카 주입)

반응형

Istio는 특정 네임스페이스의 Pod에 Envoy 프록시를 자동으로 주입할 수 있습니다.

kubectl label namespace team-a istio-injection=enabled

이제 team-a 네임스페이스에 배포되는 모든 Pod에는 Envoy 프록시가 함께 주입됩니다.

---

4) 예시 앱 배포

hello-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: hello
  namespace: team-a
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: hello
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello
  namespace: team-a
spec:
  replicas: 2
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
      - name: hello
        image: hashicorp/http-echo
        args: ["-text=Hello from Istio"]
        ports:
        - containerPort: 8080

적용:

kubectl apply -f hello-service.yaml

확인:

kubectl get pods -n team-a

→ 각 Pod에 Envoy 사이드카가 자동 주입된 것을 확인할 수 있습니다 (2/2 READY).

---

5) VirtualService와 DestinationRule

Istio에서는 Ingress 대신 VirtualService와 DestinationRule로 트래픽 라우팅을 제어합니다.

hello-virtualservice.yaml

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: hello
  namespace: team-a
spec:
  hosts:
  - "hello.team-a.local"
  http:
  - route:
    - destination:
        host: hello
        port:
          number: 80

hello-destinationrule.yaml

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: hello
  namespace: team-a
spec:
  host: hello
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL

적용:

kubectl apply -f hello-virtualservice.yaml
kubectl apply -f hello-destinationrule.yaml

---

6) mTLS 활성화 및 트래픽 관찰

Istio는 서비스 간 통신을 자동으로 mTLS로 암호화합니다.
또한, Kiali(시각화 대시보드)를 함께 설치하면 트래픽 흐름을 시각적으로 볼 수 있습니다.

kubectl apply -f samples/addons
kubectl get pods -n istio-system

접속:

istioctl dashboard kiali

→ 브라우저에서 서비스 간 요청 흐름, 에러율, 응답 시간 등을 확인 가능.

---

7) Canary 배포 예시

hello 앱의 새 버전(예: v2)을 20% 트래픽만 받게 설정:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: hello
  namespace: team-a
spec:
  hosts:
  - "hello.team-a.local"
  http:
  - route:
    - destination:
        host: hello
        subset: v1
      weight: 80
    - destination:
        host: hello
        subset: v2
      weight: 20

→ 점진적 배포가 가능하며, 문제 발생 시 즉시 롤백 가능.

---

8) 정리

• Istio는 서비스 간 통신을 자동 관리하고, 보안·트래픽·관찰성을 통합 제공.
• Envoy 사이드카로 애플리케이션 코드 수정 없이 기능 확장 가능.
• VirtualService + DestinationRule로 정교한 트래픽 제어 가능.
• Canary, Blue-Green, mTLS, 트레이싱 등 운영 안정성을 크게 높일 수 있음.

다음 글에서는 Prometheus + Grafana + Kiali + Jaeger를 이용한 모니터링 스택을 완성하고, 전체 관찰성(Observability) 체계 구축을 실습하겠습니다.

---

 

쿠버네티스,서비스메시,Istio,Envoy,Canary배포,트래픽제어,mTLS,DevOps,Minikube,K8s실습

 

✅ 보강 제안 및 참고 자료

1. 설치 프로파일 선택과 커스터마이즈

• Istio는 여러 프로파일(profiles) 을 제공하며, demo, minimal, default 등 각기 다른 설정 조합을 갖고 있습니다. (Istio)
• 예를 들어 istioctl install --set profile=demo -y 명령은 demo 프로파일을 선택해 기본적인 기능을 활성화한 환경을 설치합니다. (Istio)
• 문서에서는 “demo 프로파일 설치” 외에, 프로파일 비교나 istioctl profile dump demo 등을 설명해 주면 좋습니다. (Medium)

---

2. 네임스페이스 라벨링 및 사이드카 자동 주입 설명 강화

• 네임스페이스에 istio-injection=enabled 라벨을 붙이면 해당 네임스페이스에 배포되는 Pod들에 Envoy 사이드카가 자동 주입됩니다. (Istio)
• 다만, 기존에 이미 배포된 Pod에는 사이드카가 주입되지 않으므로, 라벨링 후 다시 배포해야 한다는 설명을 추가하세요.

---

3. Gateway 리소스 도입 및 Edge 트래픽 처리

• 현재 예제는 Ingress 대신 VirtualService 위주인데, Istio를 사용할 땐 보통 Istio Gateway 리소스를 이용해 외부 트래픽을 Mesh 내부로 연결합니다.
  즉, Gateway + VirtualService 조합으로 외부 호스트/도메인을 내부 서비스와 연결하는 패턴이 일반적입니다. (Medium)
• 예제에 Gateway 리소스를 추가하고, VirtualService의 gateways 필드를 설정하는 예시를 포함하면 더 현실적입니다. (예: gateways: ["myapp-gateway"]) (Medium)

---

4. DestinationRule / TLS 충돌 주의 설명

• DestinationRule의 trafficPolicy.tls.mode 설정이 Istio의 기본 mTLS 설정과 충돌할 수 있습니다. 예를 들어, 클러스터 전체에 mTLS가 활성화된 상태에서 DestinationRule이 TLS 모드를 꺼버리면 요청이 503 에러가 날 수 있습니다. (Istio)
• 문서 내에 “TLS 모드 설정은 반드시 클러스터 전역 정책과 일치해야 한다”는 주의 문구를 넣어 주세요.
• 또한, broken VirtualService/DestinationRule 조합이 무시되는 경우가 있어서, trafficPolicy TLS 모드와 Gateway 설정이 일치하지 않으면 라우팅이 동작하지 않을 수 있다는 경고도 같이 넣으면 좋습니다. (Istio)

---

5. 트래픽 관리 베스트 프랙티스 (Canary, subset 추가 순서 등)

• Istio 공식 문서에서는 subset을 DestinationRule에 먼저 추가하고, VirtualService에서 이를 참조하는 방식을 권장합니다. 이를 통해 다운타임 없이 안전하게 Canary 배포가 가능합니다. (Istio)
• 즉, 단계는 다음과 같이:
  1. DestinationRule에 subset v2 추가
  2. 기다림 (sidecar가 설정 반영할 시간)
  3. VirtualService 수정하여 v2 트래픽 일부 라우팅
• 이 과정을 설명해 주면 독자가 실전에 유용한 배포 패턴을 이해할 수 있어요.

---

6. 일반적인 오류 사례 + 진단 팁 추가

아래 오류 사례와 진단 팁을 문서에 추가하면 실습에서 매우 유용합니다:

• 503 에러 발생: DestinationRule이 TLS 설정을 잘못 건드려서 발생하는 경우가 많음. trafficPolicy.tls.mode 설정을 기본 클러스터 수준 설정과 일치시켜야 함. (Istio)
• VirtualService 라우팅 무시됨: Gateway 설정이 빠졌거나, VirtualService의 hosts / gateways 설정이 잘못됨
• mTLS 충돌: 일부 서비스만 TLS/Plain 통신 설정하려 할 때 설정 충돌 발생 가능 — DestinationRule을 적절히 조정하거나 서비스별 TLS 설정을 제어해야 함 (Stack Overflow)
• DestinationRule 우선순위 문제: 같은 호스트에 여러 DestinationRule이 존재할 경우, 네임스페이스 우선순위 또는 규칙 충돌이 있을 수 있음 (GitHub)

---

✍️ 보강된 문서 예시 (일부 발췌)

아래는 본문 중 일부를 보강한 예시입니다:

---

서비스 메시 설치 (보강)

istioctl install --set profile=demo -y
kubectl get pods -n istio-system

설치 시, 여러 프로파일 중 demo 프로파일이 선택됨을 설명하고, istioctl profile dump demo로 구체 설정을 확인할 수 있음을 안내합니다. (Istio)

네임스페이스 라벨링:

kubectl label namespace team-a istio-injection=enabled
kubectl rollout restart deployment -n team-a  # 기존 파드 재배포 필요

---

Gateway 및 트래픽 진입 예시 (보강)

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: fuel-gateway
  namespace: team-a
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - api.fuel.local
    - www.fuel.local
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: fuel-routing
  namespace: team-a
spec:
  hosts:
  - api.fuel.local
  - www.fuel.local
  gateways:
  - fuel-gateway
  http:
  - match:
    - uri:
        prefix: /api
    route:
    - destination:
        host: fuelstation-backend.team-a.svc.cluster.local
        port:
          number: 3000
  - route:
    - destination:
        host: fuelstation-frontend.team-a.svc.cluster.local
        port:
          number: 3000

---