kubernetes의 정책 관리 - Istio

오늘은 kubernetes의 정책 관리를 맡고 있는 Istio에 대해서 포스팅 해보도록 하겠습니다. 

 

DevOps 엔지니어 모집 공고를 보면 "Istio를 기반으로한 서비스 메쉬에 대한 이해가 높으신 분" 같은 문구를 종종 볼 수 있습니다. 

 

이것이 제가 쿠버네티스 아키텍처에서 Istio를 제일 먼저 공부하게 된 계기입니다. 어떤 놈이고 어떤 일을 하는지 공식 문서와 GPT를 이용해 공부해봤습니다. 

 

Istio

우선 쿠버네티스 아키텍처를 먼저 짚고 넘어가겠습니다. 

 

 

여기서 서비스 메시라고 적혀있는 Istio가 오늘의 주인공입니다. 

 

서비스 메시가 뭘까요? 

 

서비스 메시란 마이크로 서비스로 이루어진 네트워크망을 뜻합니다. 즉 쿠버네티스 내부적인 네트워크 망이라고 보시면 되겠습니다. 

 

이제 본격적으로 Istio에 대해서 알아보도록 하겠습니다. 아, 참고로 읽는 방법은 '이스티오' 입니다. 처음에 아이에스티오라고 불렀다가 면접관이 못알아먹길래 찾아봤습니다...

 

Istio의 키워드

Istio의 키워드는 

 

• 트래픽 관리
• 보안
• 관찰
• 회복

이렇게 네가지 입니다. 이제 이것에 대해서 한번 알아보죠. 

 

트래픽 관리

Istio의 트래픽 라우팅 규칙은 서비스 사이에서 API 호출이나 트래픽 흐름을 컨트롤 하기 쉽게 해줍니다. Istio를 사용하면 A/B테스팅이나, 카나리 배포나, 블루그린 배포같은 중요한 작업을 간단하게 처리할 수 있게 해주죠. 

 

우선 이 말만 들으면 아하 배포할 때 네트워크 관리를 해주는 거구나 싶지만 하는 일이 더 있습니다. 

 

Istio의 service registry를 사용해서 만든 Envoy 프록시는 마이크로 서비스 베이스인 애플리케이션에서 여러개의 인스턴스를 연결하는 로드밸런싱의 역할을 하기도 합니다. Istio의 Envoy 프록시의 특이한 점이라면 동적으로 로드밸런싱을 진행하여 많은 요청을 받고 있는 호스트에겐 트래픽을 보내지 않습니다. 

 

Envoy 프록시에 대해서 잠깐 짚고 넘어갈까요?

 

Envoy 프록시

Envoy 프록시란 모든 서비스에 대하여 인바운드 혹은 아웃바운드 트래픽을 완화하기 위해 사용되는 Istio의 high-performance를 위한 프록시입니다.

 

우리의 메시 서비스에서 보내거나 받는 모든 트래픽은 Envoy를 통해 프록시화 되고 이것들은 우리의 서비스에서 어떠한 변화도 없이 트래픽들을 컨트롤하기 쉽게 만들어줍니다. 

 

이제 간단하게 Istio가 로드밸런싱 하는 방법에 대해서 알아보도록 하겠습니다. 

 

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookinfo
spec:
  hosts:
    - bookinfo.com
  http:
  - match:
    - uri:
        prefix: /reviews
    route:
    - destination:
        host: reviews
  - match:
    - uri:
        prefix: /ratings
    route:
    - destination:
        host: ratings

 

이렇게 어떤 API가 어떤 호스트로 연결될지 결정할 수 있습니다. 이를 라우팅 규칙이라고도 하죠. 

 

spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 75
    - destination:
        host: reviews
        subset: v2
      weight: 25

 

이런식으로 퍼센테이지를 줄 수도 있습니다. 

 

destination rule을 설정해서 Envoyu의 트래픽 정책을 커스터마이징 할 수도 있는데 예를 들어서 개발자가 선호하는 로드밸런싱 모델 (알고리즘) 을 선택할 수도 있고 TLS 모드도 원한다면 추가할 수 있으며 서킷 브레이커 세팅도 할 수 있습니다. 

 

이 부분에 대해서는 뒤에서 더 자세히 알아보도록 하죠. 

 

TMI로 로드밸런싱 알고리즘은 공식문서에선 Random, Weighted Least Connection, Round Robin이 있습니다. 몇개 더 있던데 유명한 알고리즘은 아니라서 제외했습니다. 

 

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-destination-rule
spec:
  host: my-svc
  trafficPolicy:
    loadBalancer:
      simple: RANDOM
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
    trafficPolicy:
      loadBalancer:
        simple: ROUND_ROBIN
  - name: v3
    labels:
      version: v3

 

이렇게 trafficPolicy 밑에 보시면 ROUND_ROBIN 이라고 적혀있는 것을 볼 수 있습니다. 참고로 대소문자를 구별하니까 적으실 땐 주의하셔야합니다. 

 

 

보안

모놀리식 아키텍처와 다르게 마이크로 서비스 아키텍처에선 다양한 보안적 문제를 검토해야합니다. man-in-the-middle에 대응하기 위해 트래픽 암호화도 필요하고, 유연한 서비스 접근 제어를 위해 상호 TLS를 설정하거나 섬세한 접근 정책이 필요하고 누가 무엇을 얼마나 어떻게 사용할지도 정해줘야하죠. 

 

Istio의 보안 아키텍처는 다음과 같습니다. 

 

잘 보시면 기본적으로 Istio에서 CA도 제공해주고 Authentication Policy나 Authorization Policy도 제공해주는 것을 볼 수 있습니다. 

 

그리고 서비스 간에 통신은 상호 TLS로 이뤄지죠. 이에 대해서 자세히 알아봅시다!

 

 

 

우리는 보안에서 가장 중요한 인증과 인가에 대해서 알아볼겁니다. 

 

인증 (Authentication)

Istio의 신원 확인은 클라이언트 단에선 서버의 신원은 인가된 것인지 보기 위해 Secure Naming정보를 기반하여 체크합니다. 반대로 서버 단에선 클라이언트가 인가 정책에 기반하여 서버의 자원에 접근할 수 있는지를 결정합니다.

 

Istio에선 두 가지 인증 방식을 제공해줍니다. 

 

• 상호 인증 (Peer Authentication) : 커넥션을 이루는 클라이언트를 증명하기 위해 service-to-service 인증을 사용합니다. Istio는 인증을 제공하기위한 풀스택 솔루션으로 상호 TLS를 제공해줍니다. 
  
  그리고 이것은 service 코드를 변경하지 않아도 사용할 수 있습니다. 네트워크 트래픽 중 TLS 트래픽과 plain-text를 둘 다 허용하는 가장 유연한 단계인 PERMISSIVE와 TLS만 허용하는 STRICT 그리고 아무것도 허용하지 않는 DISABLE이 있습니다. 
• 요청 인증 (Request Authentication) : 요청에 대한 credential을 증명하기 위해 유저 끝단에서 인증을 사용합니다. Istio는 request-level 인증인 JWT 검증을 사용합니다. 

 

아마 마이크로 서비스 아키텍처에선 stateless한 인증 방식이 필요하기 때문에 JWT를 사용하는게 아닐까 싶네요. 

 

여기서 잠깐 짚고 넘어갈 개념이 바로 상호 TLS (Mutual TLS) 입니다. 

 

Mutual TLS는 기존의 TLS와 다르게 몇가지가 추가됩니다. 

 

1. 클라이언트가 서버에 ClientHello를 보낸다.
2. 서버는 ClientHello 안에 있는 Cipher Suite를 선택하고 TLS 프로토콜을 정한다음 인증서를 클라이언트에게 보낸다.
3. 클라이언트가 서버의 인증서를 복호화해서 서버가 인증되면 클라이언트가 서버에게 본인의 인증서를 보낸다. (이 부분이 기존 TLS와 다른 부분입니다.)
4. 서버가 클라이언트의 인증서를 복호화하고 session key를 생성한 뒤 사용한다. 

 

기존 TLS에는 없던 클라이언트가 서버에게 인증서를 보낸다는 점이 추가되어 보안적으로 더 뛰어나다고 할 수 있습니다. 

 

 

인가 (Authorization)

인가에 대해선 깊이있게 공부하지 않아도 될 것 같아서 깊이있게 공부하진 않았습니다. 표면적인 정보만 알려드리고 넘어가겠습니다. 

 

기본적으로 Istio는 RBAC (Role-Based Access Control)을 따르고 있습니다. 하지만 원한다면 누가 어떤 서비스에 접근할 것인지 동적으로 정해줄 수도 있습니다. 

 

예를 들어서 service name에 따라서 정해줄 수도 있고, service namespace에 따라서도 정해줄 수 있습니다. 또한, method, path에 따라서도 접근할 수 있는 권한을 부여할 수 있습니다. 

 

 

관측 가능성 (Obervability)

Istio는 메시 안에서 모든 서비스 커뮤니케이션에 대한 세부적인 측정이 가능합니다. 이러한 측정은 서비스의 동작이나 트러블 슈팅, 유지보수, 애플리케이션의 최적화를 할 수 있고 이를 관측 가능성이라고 부릅니다. 

 

이 관측 가능성을 위해서 서비스 개발자에겐 추가적인 짐이 지워지진 않습니다. 

 

여기서 잠깐!

관측 가능성을 Istio가 지원하긴 하지만 하드웨어 메트릭이나 소프트웨어 메트릭은 프로메테우스와 그라파나를 주로 사용하기 때문에 그냥 짚고만 넘어가겠습니다. 

 

Istio는 관측 가능성을 위해 메트릭을 제공해주는데 해당 메트릭은 모니터링을 하기 위해 사용되는 메트릭이며 프록시 레벨에서의 메트릭을 지원해준다는 특징이 있습니다. 

 

프록시 레벨에서의 메트릭 뿐만 아니라 서비스 레벨에서도 메트릭을 지원합니다. 이를 통해 지연시간, 트래픽, 에러 등의 메트릭을 수집하고 대쉬보드로 만들 수 있습니다. 

 

이건 개인적으로 놀라웠던 부분인데 Istio는 secure naming을 이용해 인증을 진행하기 때문에 전적으로 kubernetes의 control plane위에서 동작합니다. 때문에 control plane의 메트릭도 잡아서 보여줄 수 있습니다. 

 

 

마치며

여기까지 kubernetes의 정책을 관리하는 Istio에 대해서 알아봤습니다. 

 

공식 문서 정말 길더라구요 다 읽는데만 거의 네시간 가까이 걸렸습니다. 

 

이번엔 GPT에 도움을 많이 받지 않았습니다. 왜냐하면 GPT는 깊이있게 공부할 땐 좋은데 이렇게 표면적으로 공부할 땐 그닥 좋은 것 같진 않습니다. 

 

기존 CS 공부나 이런 것들은 깊이있게 공부해도 상관 없을정도로 쉬운 지식들이 많아서 GPT로 공부했지만 이번에는 공식 문서를 이용해봤습니다. 

 

긴 글 읽어주셔서 감사합니다. 오늘도 즐거운 하루 되세요!

 

 

출처

https://istio.io/latest/docs/concepts/traffic-management/

Traffic Management

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

Security

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

Observability