Kubernetes Service Mesh 구축 가이드, Istio에 대한 이해와 Istio Operator 설치 방법

안녕하세요. J4J입니다.

 

이번 포스팅은 kubernetes service mesh 구축을 위한 istio에 대한 이해와 istio operator 설치하는 방법에 대해 적어보는 시간을 가져보려고 합니다.

 

 

 

Service Mesh

 

kubernetes 환경에서 마이크로 서비스를 제공하는 아키텍처가 도입되면서 1개의 서비스에 많은 기능들이 담겨 있는 모놀리식과 다르게 작은 단위의 애플리케이션 서비스들이 각 도메인 별로 분산 및 배포되어 운영되고 있습니다.

 

그리고 이를 운영/관리하는 프로젝트 팀에서는 모든 서비스에 공통적인 트래픽 관리, 인증, 트레이싱 등을 적용해야 하는 상황이 불가피하게 발생합니다.

 

하지만 현실적으로 다양하게 파생되는 모든 서비스에 공통적인 설정들을 매번 해주는 것은 불가능합니다.

 

그래서 더 편리한 방식으로 서비스 간 네트워크 트래픽을 관리할 수 있도록 service mesh가 등장하게 되었습니다.

 

 

 

service mesh는 프록시를 사용하여 마이크로 서비스 간 통신을 인프라 레벨에서 관리할 수 있도록 도와주는 인프라 계층입니다.

 

즉, service mesh가 사용된다면 모든 애플리케이션 서비스에 공통적인 트래픽 관리 설정 등을 하지 않게 되며 설정을 위한 소스 코드도 별도로 필요하지 않게 됩니다.

 

대신 관리하는 레벨 자체를 인프라 쪽으로 올리게 되고, 한 번 설정한 정보들을 이용하여 동일 service mesh 내부에 있는 모든 서비스에 일괄 적용할 수 있게 됩니다.

 

 

 

service mesh가 수행할 수 있는 역할들은 대표적으로 다음과 같습니다.

 

[ 트래픽 관리 ]

 

먼저 service mesh는 라우팅, 부하 분산, 장애 격리 등 다양한 트래픽 관리를 할 수 있도록 도와줍니다.

 

대표적으로 header/cookie/요청 경로 등의 정보가 무엇인지에 따라 트래픽이 전달되어야 하는 목적지를 관리하도록 설정할 수 있습니다.

 

또는 새로운 버전을 배포하는 상황에서 가중치를 조절하여 점진적으로 새로운 버전에 대한 트래픽 처리가 이루어질 수 있도록 관리하는 방식도 적용할 수 있습니다.

 

timeout과 retry 설정도 제공하여 일시적인 오류가 발생에 대한 대처도 가능하며, 오류가 지속적으로 발생하는 서비스에 대해서는 격리하는 설정도 함께 제공됩니다.

 

 

 

[ 보안 ]

 

서비스 간 통신을 할 때 공통적인 보안 설정을 제공하여 신뢰할 수 있는 네트워크 통신이 이루어질 수 있도록 도와줍니다.

 

대표적으로 mTLS (Mutual TLS) 설정이 있습니다.

 

mTLS는 각 서비스에 자동으로 인증서를 발급하여 서비스 간 통신을 할 때 서로의 인증서를 확인하도록 도와줍니다.

 

mTLS 모드 설정에 따라 반드시 인증서가 필요한 경우와 평문이 허용되는 경우를 설정할 수 있고, 반드시 인증서가 필요한 경우에는 동일 service mesh에 포함되는 서비스 간 통신만 허용되는 구조입니다.

 

또한 일반 사용자로부터 전달되는 요청에 대한 보안 설정을 위해 JWT 인증 토큰을 이용할 수도 있습니다.

 

JWT 인증 토큰을 발급하고 사용자의 요청 header에 토큰 정보가 담겨 있는지를 검증하여 인증 처리를 수행할 수 있습니다.

 

 

 

인증뿐만 아니라 인가 처리도 수행할 수 있습니다.

 

예를 들어, user라는 namespace에 존재하는 frontend 서비스에서만 product라는 namespace에 존재하는 backend 서비스로 요청이 가능하도록 설정할 수 있습니다.

 

또한 http method에 대해서도 상세하게 설정할 수 있으며, 요청 경로에 대한 prefix 설정도 함께 적용하여 서비스 별 호출할 수 있는 권한에 대한 정책을 관리할 수 있습니다.

 

 

 

[ 가시성 ]

 

가시성의 대표적인 케이스로는 로깅, 트레이싱, 메트릭 등이 존재합니다.

 

먼저 서비스 간 통신이 이루어지는 모든 상황에 대한 로깅 정보가 자동으로 구성됩니다.

 

요청/응답이 이루어진 서비스와 url 정보, 응답 소요 시간과 요청 method 정보 등 말 그대로 access log에 대한 정보들을 자동으로 관리해 줍니다.

 

 

 

트레이싱 정보로는 trace id, span id 등 추적 가능한 정보들을 자동으로 구성해 줍니다.

 

해당 정보들은 jaeger/zipkin과 같은 백엔드 서비스와 연동할 수 있으며, 이 정보들을 통해 한 번의 사용자 요청을 처리하기 위해 어떤 서비스들 간 통신이 있었는지를 추적/감시할 수 있습니다.

 

또한 spring boot에서는 service mesh가 micrometer tracing과도 연계하여 w3c 기반의 trace 정보를 서로 공유할 수도 있습니다.

 

 

 

메트릭 정보로는 요청/응답이 이루어진 서비스와 소요 시간, 호스트 정보 등이 모두 metric으로 자동 관리가 이루어집니다.

 

그래서 prometheus와 같은 서비스를 이용하여 service mesh에서 발생된 metric 정보들을 수집할 수 있고, 수집된 metric 정보를 활용하여 grafana와 같은 서비스에서 대시보드를 구성할 수 있습니다.

 

결국 서비스들 간 통신이 이루어지는 것에 대해 시각화를 할 수 있으며, 알림 설정 까지도 이어지는 상황이 제공될 수 있습니다.

 

 

반응형

 

 

Control Plane과 Data Plane

 

service mesh는 크게 2개의 평면으로 나뉩니다.

 

control plane과 data plane의 아키텍처 설명

 

 

 

[ control plane ]

 

그중 첫 번째는 control plane이며, control plane의 역할은 service mesh 정책과 구성의 중앙 통제를 하는 것입니다.

 

control plane은 클러스터 내부에 존재하는 서비스의 트래픽 처리를 직접적으로 수행하는 곳은 아닙니다.

 

위에서 얘기했던 service mesh의 동작들이 어떤 식으로 구성되고 처리되어야 하는 것인지를 전체적으로 관리하는 곳이며, 정의된 방식에 맞게 정책과 보안 정보들을 생성하는 역할을 수행합니다.

 

단순히 얘기하면 설정 정보들이 담겨 있는 곳이라고 생각할 수 있습니다.

 

 

 

[ data plane ]

 

data plane은 control plane에 의해 구성된 정책과 구성들이 실제 트래픽에 직접적으로 적용이 되는 곳입니다.

 

data plane에서 실질적으로 트래픽 처리를 하는 곳은 프록시로 구성되는 envoy sidecar입니다.

 

sidecar라고 하는 것은 실질적으로 사용되는 애플리케이션 서비스 container와 별개로 부가적인 처리를 위해 동일 pod 내에 함께 배포되는 container를 의미합니다.

 

서비스로 전달되는 모든 요청들은 ingress gateway를 통해 envoy sidecar를 거치게 됩니다. (외부 → 내부, inbound)

 

"외부 → ingress gateway → envoy sidecar → 서비스 container"

 

 

반대로 서비스에서 외부로 전달하는 모든 요청들은 envoy sidecar를 거치며 egress gateway를 통해 전달됩니다. (내부 → 외부, outbound)

 

"서비스 container → envoy sidecar → egress gateway → 외부"

 

 

즉, 모든 트래픽의 처리가 envoy sidecar를 거쳐가게 되고 control plane이 정의해 둔 정책 및 구성들에 맞는 네트워크 통신이 이루어지게 됩니다.

 

 

 

control plane과 data plane에 대해서 정리해 보면 control plane은 두뇌, data plane은 손발이라고 표현해볼 수 있습니다.

 

어떤 방식으로 트래픽을 관리할 지에 대해 두뇌를 통해 생각해 보고, 두뇌가 생각한 것을 손발을 통해 직접적으로 적용이 되는 구조로 생각하면 이해하기 편합니다.

 

 

 

 

Istio

 

이제는 istio에 대해서 얘기해 보겠습니다.

 

istio는 현재 기준으로 kubernetes 환경에서 가장 대표적으로 service mesh 구현하기 위해 사용되는 오픈 소스입니다.

 

그래서 최근 service mesh를 구성을 고민하는 프로젝트에서는 istio를 활용하는 것이 올바른 방법이 될 수 있습니다.

 

 

 

[ istio가 제공하는 기능 ]

 

istio에서는 대표적으로 다음과 같은 많은 기능들이 제공되고 있습니다.

 

• L4/L7 트래픽 제어
• 보안
• telemetry
• 정책 관리

 

즉, service mesh를 통해 제공받기를 원하는 많은 기능들을 istio를 통해 활용할 수 있습니다.

 

 

 

[ envoy 기반 생태계 ]

 

istio는 envoy 기반의 생태계를 최초로 사용한 service mesh입니다.

 

그래서 envoy의 모든 기능과 유연성이 그대로 활용되어 사용되며, 애플리케이션 서비스와도 독립적으로 구성이 이루어집니다.

 

envoy에 대해서 더 많은 알고 싶으신 분들은 Envoy 공식 문서를 참고하시면 좋을 것 같습니다.

What is Envoy — envoy 1.36.0-dev-f61849 documentation

 

 

 

[ kubernetes 통합 환경 ]

 

istio는 kubernetes 환경에서 사용되는 것에 초점이 맞춰진 상태로 설계가 이루어졌습니다.

 

그래서 kubernetes가 제공하는 리소스를 그대로 활용하기도 하며, CRD를 통해서도 service mesh 구성을 위한 다양한 리소스가 구성되기도 합니다.

 

그러다 보니 helm, argo 등과 같이 kubernetes 환경에서 사용되는 다양한 기술들과도 함께 활용이 가능합니다.

 

 

 

[ 그 외 ]

 

단순한 기능 설정에서부터 필요한 경우에 더  많은 기능들을 점진적으로 적용할 수 있는 환경을 제공합니다.

 

그래서 프로젝트 상황에 맞게 기능 적용을 자유롭게 설정할 수 있습니다.

 

그리고 강력한 커뮤니티를 소유하고 있기에 많은 레퍼런스들이 존재하고, 대형 기업들에서도 많이 활용 하며 지원까지 하는 모습을 보이고 있습니다.

 

또한 control plane과 data plane의 관점에서 istio는 다음과 같이 구성이 이루어집니다.

 

• control plane >> istiod
• data plane >> envoy sidecar

 

작성된 내용 외에 istio에 대해 더 많은 정보를 알고 싶으신 분들은 Istio 공식 문서를 참고하시면 좋을 것 같습니다.

What is Istio?

 

 

 

 

Istio 설치

 

istio를 설치하는 방법은 다양하게 존재하며, 대표적인 방식으로 helm을 얘기할 수 있습니다.

 

istio 구축과 관련된 chart가 존재하는 repository를 추가하여 istio-base와 istiod 등 service mesh 구성을 위해 필요한 여러 chart를 이용하여 설치해볼 수 있습니다.

 

 

 

그러나 이곳에서는 operator를 이용하여 설치를 해보겠습니다.

 

operator는 kubernetes에서 애플리케이션 서비스의 배포와 수명 주기 관리들을 자동화하도록 컨트롤러 역할을 수행하는 kubernetes API의 클라이언트입니다.

 

그래서 istio operator를 사용한다면 한 번의 설치로 service mesh를 위해 필요한 서비스들이 자동으로 구성되며, 사용자 정의 기반의 설정도 함께 이루어질 수 있습니다.

 

 

 

[ 1. istio 설치 ]

 

istio operator를 이용하여 관리하기 위해서는 istio가 별도로 설치되어야 합니다.

 

linux나 mac을 이용해 kubernetes에 설치하시는 분들은 Istio Release Download를 참고하여 설치해 주시면 됩니다.

 

만약, window를 이용해 설치하시는 분들은 다음 순서대로 해주시면 됩니다.

 

• https://github.com/istio/istio/releases 접속
• 원하는 버전의 istio-{ version }-win.zip 파일 다운로드
• powershell 관리자 권한으로 실행
• 환경 변수 경로 설정 >> $ setx PATH "$env:PATH;{ istio 설치 경로 }\istio-{ version }\bin"
• powershell 관리자 권한으로 재 실행
• istioctl 설치 확인 >> $ istioctl version

 

 

 

[ 2. operator yaml 구성 ]

 

// istio-operator.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: istio-control-plane
  namespace: istio-system # istio namespace 설정
spec:
  profile: default # istio 기본 리소스 구성 적용 (istiod + ingress gateway)

  values:
    global:
      proxy:
        logLevel: info # logging level 설정

 

 

 

[ 3. istio 설치 ]

 

operator 기반으로 설치하기 때문에 helm, kubectl 등의 명령어를 사용하지 않고 istioctl을 이용하여 istio를 설치할 수 있습니다.

 

다만, 사전에 kube config 설정이 이루어진 상태여야 올바르게 동작합니다.

 

$ istioctl install -f istio-operator.yaml

 

 

 

[ 4. istio 설치 확인 ]

 

설치가 올바르게 되었다면 istiod, istio ingress 등의 pod가 자동으로 생성되어 있습니다.

 

다음과 같이 pod 목록을 확인하여 istio 관련 pod들이 올바르게 실행되고 있는지 확인해 주시면 됩니다.

 

$ kubectl get pods -n istio-system

 

 

 

[ 5. istio 자동 주입 설정 ]

 

istio가 설치가 되었다고 envoy sidecar가 모든 서비스에 자동으로 구성되는 것은 아닙니다.

 

sidecar 추가를 위해서는 namespace에 label 설정을 이용하여 istio 자동 주입을 해줄 수 있습니다.

 

 

 

예를 들어, sidecar가 추가되기 전 monitoring이라는 namespace에 다음과 같은 pod가 동작되고 있습니다.

 

envoy sidecar 자동 주입 전 애플리케이션 서비스 pod 상태

 

 

 

이때 monitoring namespace에 istio 자동 주입을 설정하고 싶은 경우 다음과 같이 label 설정을 해주시면 됩니다.

 

$ kubectl label namespace monitoring istio-injection=enabled --overwrite

 

 

 

label 설정이 되었다면 pod를 재 시작하거나 삭제하는 행위를 통해 새로운 pod가 실행되도록 해줍니다.

 

그러면 다음과 같이 기존 애플리케이션 서비스에 envoy sidecar가 추가되어 1개의 pod에  2개의 container가 존재하는 것을 확인할 수 있습니다.

 

envoy sidecar 자동 주입 후 애플리케이션 서비스 pod 상태

 

 

 

 

Revision 관리

 

istio에는 revision이라는 개념이 존재합니다.

 

revision이라고 하는 것은 istiod의 버전 관리를 위한 논리적인 단위입니다.

 

revision을 활용하게 되면 구 버전과 새로운 버전의 istio를 병렬로 운영하고 점진적으로 새로운 버전으로 전환할 수 있도록 관리할 수 있습니다.

 

위의 설정 방식처럼 istio를 설치하는 경우 revision은 기본적으로 default로 설정됩니다.

 

 

 

revision 관리는 다음과 같이 할 수 있습니다.

 

기존 상태에서 만약 istio의 설정을 변경하고 1-1 버전의 새로운 istio로 점진적인 버전 전환을 하고 싶은 경우를 예시로 들겠습니다.

 

[ 1. operator yaml spec 변경 ]

 

(revision 관리를 원하시는 프로젝트에서는 변경이 이루어지겠지만 저는 따로 변경하지는 않겠습니다.)

 

 

 

[ 2. 새로운 revision istio 설치 ]

 

$ istioctl install --set revision=1-1 -f istio-operator.yaml

 

 

 

[ 3. 새로운 revision istio 설치 확인 ]

 

위와 동일하게 pod 목록을 확인해 보시면 됩니다.

 

다만 이전과 달리 2개의 istiod가 다음과 같이 구성되어 있는 것을 볼 수 있습니다.

 

istio revision 설정 및 설치 후 kubernets pod 목록

 

 

 

[ 4. 새로운 revision istio 자동 주입 설정 ]

 

자동 주입의 경우는 이전과 동일하게 namespace에 label 설정을 이용하면 됩니다.

 

새로운 revision이 적용되고 싶은 namespace에 label을 설정해 주면 되고, 다만 기존과 다른 것은 revision의 버전을 명시해줘야 합니다.

 

$ kubectl label namespace monitoring istio-injection- (기존 istio 자동 주입 설정 label이 있는 경우 삭제 처리) 
$ kubectl label namespace monitoring istio.io/rev=1-1 --overwrite

 

 

 

그 뒤 새로운 버전의 envoy sidecar가 적용될 수 있도록 새로운 pod가 실행되도록 재 시작하거나 삭제하는 행위를 해주시면 됩니다.

 

pod가 새롭게 시작되었다면 다음 명령어를 통해 각 pod에 어떤 istiod가 설정되었는지 확인하여 올바르게 적용된 것을 알 수 있습니다.

 

$ istioctl proxy-status -n monitoring

 

 

 

 

 

 

 

이상으로 kubernetes service mesh 구축을 위한 istio에 대한 이해와 istio operator 설치하는 방법에 대해 간단하게 알아보는 시간이었습니다.

 

읽어주셔서 감사합니다.