Service Mesh : Istio 데모, kiali, Envoy

섹션 2

이스티오란?

• 다양한 툴과 프레임워크가 모두 패키지화된 일종의 컬렉션
• Serivce Mesh의 예, Istio == Service Mesh 라고 할 수 있음

그 전에,

Service mesh가 뭔데 나왔을까

• 클러스터 기반 MSA로 인기, 쿠버네티스 프레임워크가 부족하다고 생각해서.
• Service Mesh가 K8s를 대체하지는 X
• ⇒ Extra layer of SW you deploy alongside your cluster(e.g. K8s)
• 모든 종류의 분산 아키텍처 = 서로 네트워킹하는 다수의 SW 컴포넌트가 있는 아키텍처는 service mesh의 도움을 받을 것

MSA에서 service mesh가 필요한, 나온 이유

• In standard MSA
  • 많은 쿠버네티스 pod, pod에 컨테이너 포함 (다수 가능, 보통은 하나)
  • 이 컨테이너들이 모두 네트워크화되어 있음 → 쿠버네티스 안의 서비스 발견 메커니즘을 이용해서 네트워크 호출 할 수 있기 때문
  • 쿠버네티스는 pod 관리에 능함 → ex. 어떤 pod 사용 안하려고 할 때, kube API 명령/kubectl 명령/yaml 수정 및 적용 ⇒ 쿠버네티스는 그것에 응답해서 스케줄링을 하고 사용하지 않게 됨.
  • 하지만 약점 : pod들 사이의 상호연결을 관리하고 그것들에 대한 가시성을 제공하는 부분
    • 저렇게 컨테이너가 컨테이너에 네트워크 호출 가능 → 하지만 이 연결에서 무엇이 일어날까?
    • ex ) 네트워크 호출받은 컨테이너 안에 오류가 있을 수 있음 → 네트워크 요청이 충족되지 않을 수 있다는 얘기
    • 어떤 컨테이너에 문제가 있는지 알면 괜찮지만, 수천 개의 MS → 수많은 네트워크 호출 조합 있음 ⇒ 표준적인 쿠버네티스로는 컨테이너 사이의 연결에 대해 어떤 가시성이나 통제력이 X
    • ⇒ 그래서 이 부분에 도움을 주는 게 서비스 메시!

섹션 3

cat 3-kiali-secret.yaml
apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: kiali
  namespace: istio-system
  labels:
    app: kiali
data:
  username: YWRtaW4=
  passphrase: YWRtaW4=

kiali : password = passphrase

암호화 아니고 그냥 인코딩

$ echo YWRtaW4= | base64 -d
admin

→ 문자열을 에코하고 base64 -d 를 통해서 실행할 수 있고, 그러면 그게 디코딩될 거임. 그건 그냥 문자열 admin이고, Base64 인코딩된 것.

Base64로 인코딩된 YWRtaW4= 문자열을 디코딩하여 admin을 출력

• base64 에 대해 …이 방식은 이진 데이터를 64개의 ASCII 문자로 변환하여 텍스트 형태로 표현합니다.Base64 인코딩의 개념
  • 목적: 바이너리 데이터를 텍스트 형태로 변환하여 텍스트 기반 프로토콜에서 쉽게 전송하고, 데이터가 손상되지 않도록 하기 위함입니다.
  • 사용 문자 집합: A-Z, a-z, 0-9, +, / (64개의 문자). 끝을 나타내는 패딩 문자로 '='를 사용합니다.
  • Base64의 활용
  • 이메일: 바이너리 데이터를 이메일 본문에 포함하기 위해 Base64로 인코딩합니다.
  • 데이터 URI: 웹 페이지에서 이미지 등의 바이너리 데이터를 인라인으로 포함할 때 사용됩니다.
  • JWT (JSON Web Tokens): JWT의 일부로 Base64 URL Safe 인코딩이 사용됩니다.
  • Kubernetes 시크릿: Kubernetes의 시크릿 데이터는 Base64로 인코딩되어 저장됩니다.
  • Base64의 한계
  • 인코딩된 데이터는 원래 데이터보다 약 33% 더 큽니다.
  • 민감한 데이터를 Base64로 인코딩하는 것만으로는 보안이 보장되지 않으므로, 추가적인 암호화가 필요합니다.
  • 이를 통해 Base64 인코딩은 텍스트 기반 환경에서 바이너리 데이터를 안전하고 쉽게 전송할 수 있게 해주는 중요한 도구임을 알 수 있습니다.
• Base64 인코딩은 주로 바이너리 데이터를 텍스트 기반 프로토콜(예: 이메일이나 JSON, XML)에서 전송할 때 사용됩니다.
• Base64는 바이너리 데이터를 텍스트로 인코딩하기 위한 인코딩 방식 중 하나입니다.

---

• 원래 사이드카 주입 pod 따로 있었는데 버전 업데이트 이후 istiod 안에 기능 들어감
  • 사이드카 = pod 안에 추가적인 컨테이너가 있어서 추가적인 도움을 주는 헬퍼 컨테이너.
  • 이스티오 프록시가 종종 사이드카라고 불림
  • 컨트롤 플레인 컴포넌트 중에는 인젝터가 있음
    • 인젝터 → 기본적으로 pod를 스케줄링을 할 때 항상 모니터링을 함. 이 pod가 그걸 탐지하고 자동으로 그 사이드카 또는 프록시를 추가하게 됨. 우리가 구성해야 하는 유일한 캐시.
    • 사이드카 프록시와 파드에 대해서 더 자세히…
      • 사이드카 프록시: Istio의 프록시는 Envoy 프록시를 사용하며, 각 서비스의 파드 옆에 사이드카 형태로 배치됩니다. 이 사이드카 프록시는 서비스 간의 트래픽을 가로채어 트래픽 관리, 보안, 모니터링 등의 기능을 제공합니다.
      • Istio 컨트롤 플레인 컴포넌트 중 인젝터
      • 인젝터(Injector): Istio의 사이드카 인젝터는 파드가 생성될 때 해당 파드에 자동으로 사이드카 프록시를 주입하는 역할을 합니다. 이 기능은 Istio의 컨트롤 플레인 컴포넌트 중 하나인 istio-sidecar-injector에 의해 수행됩니다.
      • 동작 방식
      1. 파드 스케줄링: 새로운 파드가 생성되고 스케줄링될 때, 사이드카 인젝터가 이를 감지합니다.
      2. 사이드카 주입: 사이드카 인젝터는 생성된 파드에 사이드카 프록시(Envoy)를 자동으로 주입합니다. 이를 통해 모든 서비스 간의 통신이 사이드카 프록시를 통해 이루어지게 됩니다.
      3. 정책 및 설정 적용: Istio 컨트롤 플레인은 정책 및 설정을 사이드카 프록시로 전달하여 트래픽 관리, 보안 정책 적용 등을 수행합니다.
      4. 구성 요소
      • MutatingWebhookConfiguration: Kubernetes의 웹훅 기능을 이용하여 파드가 생성될 때마다 사이드카 인젝터가 트리거됩니다. 이를 위해 Istio는 MutatingWebhookConfiguration을 설정합니다.
      • istiod: Istio의 주요 컨트롤 플레인 컴포넌트로, 인젝터를 비롯한 여러 기능을 제공합니다. istiod는 설정, 정책, 인증서 발급 등을 담당합니다.
      • 요약
      • Istio는 서비스 간의 트래픽을 관리하기 위해 각 서비스 파드 옆에 사이드카 프록시(Envoy)를 배치합니다.
      • 사이드카 인젝터는 새로운 파드가 생성될 때 자동으로 사이드카 프록시를 주입하는 역할을 합니다.
      • 이를 통해 Istio는 일관된 방식으로 트래픽 관리, 보안, 모니터링 등의 기능을 제공할 수 있습니다.
      • 이와 같은 자동화된 사이드카 주입 메커니즘 덕분에 개발자는 별도의 작업 없이 Istio의 강력한 기능을 사용할 수 있습니다.
    • Istio 사이드카 프록시
  • 기본적으로 사이드카 인젝터는 아무것도 하지 않을 것.
    • 작동하게 하려면? 레이블을 설정해야 함. 그리고 그건 네임스페이스를 기준으로 작동
    • if 이스티오가 데이터를 수집하길 원하는 특정한 네임스페이스가 있다면, 그 네임스페이스를 취하고 그것에 레이블을 지정.
    • if 이스티오가 전체 아키텍처에 걸쳐 작동하길 원한다면, 시스템에 있는 모든 네임스페이스에 레이블을 추가.

kiali로 시스템 시각화하기

• kiali : 클러스터 시각화 툴, 아랫것들에 대한 답변을 주는 역할을 함
  • What microservices are part of my istio service mesh?
  • how are they connected and performing?
• init 컨테이너 → 메인 컨테이너가 시작하기 전에 실행되는 컨테이너
• 컨테이너 2개씩임 → 이스티오가 자동으로 추가적인 사이드카 컨테이너를 주입하고, 그게 여기서 프록시 역할을 하게 됨
  • 만약 1개씩이라면? namespace label 지정을 안해서 그렇다
• minikube ip : 새로 minikube 클러스터 시작할 때마다 달라지니 체크
• ip주소:30080 실행 안되는 오류
  • 에러 이유: timeout
  • 에러 원인 : the docker driver doesn't work with nodeports.근데 내가 도커로 띄워놔서 안되는 거셈Note that for services in other namespaces (like istio-system), you will need to add -n as well.

Docker 드라이버를 사용하는 Minikube는 Docker 컨테이너 내에서 실행되기 때문에, NodePort와 같은 고정된 포트를 호스트 시스템으로 노출하는 데 어려움이 있습니다. minikube service 명령어는 이러한 문제를 해결하기 위해 포트 포워딩을 설정하여, 호스트 시스템에서 Kubernetes 서비스에 접근할 수 있게 해줍니다.

• • 
    얘로 접속하면 잘보임

    $ minikube service kiali -n istio-system --url
    http://127.0.0.1:55567
    http://127.0.0.1:55568
    ❗  Because you are using a Docker driver on darwin, the terminal needs to be open to run it.

  • kiali도 마찬가지임
  • $ minikube service fleetman-webapp --url http://127.0.0.1:55355 ❗ Because you are using a Docker driver on darwin, the terminal needs to be open to run it.
  •  

Docker 드라이버가 NodePort와 함께 동작하지 않는 이유는 주로 Docker의 네트워크 격리와 관련이 있습니다. Docker 드라이버를 사용할 때 Minikube는 Docker 컨테이너 안에서 Kubernetes 클러스터를 실행하게 됩니다. 이 Docker 컨테이너의 네트워킹 설정이 NodePort와 호환되지 않을 수 있습니다.

• •  
  • the docker driver doesn't work with nodeports , so you access using "minikube service".
  • 이거 확인해보면 webapp type은 nodeport임

• service entry : external 호출할떄 있는 istio 특유의 개념, 쿠버네티스 클러스터의 일부 아님

섹션 4

Envoy

• envoy == data plane의 핵심 기술
• Istio의 핵심 모듈인 proxy를 구현하기 위해서 이미 잘 구현된 오픈소스인 Envoy(lyft에서 공개한 오픈소스)를 활용
• Envoy는 istio와 독립적인 proxy 기술을 제공하고 있으며, low level의 기능요소들을 제공
• 따라서 envoy를 잘 활용할 수 있는 기술들(istio와 같은)을 함께 활용하는 것이 효과적임
• Envoy는 어플리케이션에서 발생하는 모든 네트워크 기능에 대한 메트릭을 수집하여 시각화하거나, 어플리케이션 변경없이 네트워크 설정을 쉽게 변경/적용할 수 있도록 지원 (proxy = sidecar = envoy 모두 같은 의미로 사용될 수 있음)

Q. 그럼 Istio없이 Envoy만 사용하면 되지 않을까?

• Envoy는 kubernetes과 관련없는 자체적인 기술요소
• 따라서 이를 kubernetes에서 활용하기 위해서는 수많은 작업들이 필요함
  • 일단 envoy를 실행하기 위한 설정들은 kubernetes와 관련성이 전혀 없으므로, 이 모든 설정을 kubernetes에서 동작할 수 있는 방식으로 변환하여 구현해야 한다.
  • Envoy tutorial을 보면 구현할 수 있겠지만, 많은 학습시간과 시행착오가 필요할 것
• Istio는 envoy를 kubernetes환경에서 쉽게 사용할 수 있도록 단순화함
  • kubernetes yaml을 정의하면 istio에서 자동으로 envoy 설정으로 변환해 주는 역할
    • 즉, 사용자는 envoy에 대한 학습없이 쉽게 kubernetes에서 실행이 가능
  • Istio는 kubernetes에 종속되지 않으며, 다양한 플랫폼을 지원