search

ByeongHunKim / Cloudclub-istio-skyline

☁️ Cloud Club's collaborative journey exploring Istio and service mesh technologies 🚀
https://www.cloudclub.kr/
2 stars 0 forks source link

[Question] Envoy Proxy가 Application Pod에 injection 되는 상세 과정은? #12

Closed ByeongHunKim closed 1 month ago

ByeongHunKim commented 1 month ago

Question / 질문 내용

Istio sidecar injection 되는 상세 과정

Context / 상황 설명

k label namespace default istio-injection=enabled

해당 네임스페이스에 'istio-injection=enabled' 라벨이 추가된 이후에 어떤 동작 원리로 sidecar container가 주입되는 지 이해하지 못하였습니다

What I've Tried / 시도한 방법 질문에 대한 답을 찾기 위해 시도해본 방법이 있다면 설명해주세요

유튜브 링크

Resources / 관련 자료 질문과 관련된 문서, 링크, 코드 등이 있다면 여기에 첨부해주세요

Additional context / 추가 사항 기타 추가적인 정보나 생각이 있다면 여기에 작성해주세요

  1. 라벨링 자체의 영향:
kubectl label namespace default istio-injection=enabled

이 명령을 실행하면 즉시 'default' 네임스페이스에 'istio-injection=enabled' 라벨이 추가됩니다 하지만 이 시점에서는 MutatingWebhookConfiguration이 직접적으로 실행되지 않습니다

$kubectl get mutatingwebhookconfigurations istio-sidecar-injector
image
  1. MutatingWebhookConfiguration의 실행 시점:

MutatingWebhookConfiguration은 새로운 Pod가 해당 네임스페이스에 생성될 때 실행됩니다 즉, 라벨링 이후에 새로운 Pod가 생성될 때 Istio 사이드카 주입이 이루어집니다

  1. 기존 Pod에 대한 영향:

이미 실행 중인 Pod들은 이 변경의 영향을 받지 않습니다 기존 Pod에 Istio 사이드카를 주입하려면 해당 Pod를 재시작해야 합니다( $kubectl rollout restart deployment )

  1. 동작 메커니즘:

Pod 생성 요청이 Kubernetes API 서버로 전송됩니다 API 서버는 MutatingWebhookConfiguration을 확인하고, 설정된 조건(이 경우 'istio-injection=enabled' 라벨)과 일치하는지 확인합니다 조건이 일치하면, API 서버는 istio-sidecar-injector 웹훅을 호출합니다 웹훅은 Pod 스펙을 수정하여 Istio 사이드카 컨테이너를 추가합니다 수정된 Pod 스펙이 다시 API 서버로 전달되고, 최종적으로 이 수정된 스펙으로 Pod가 생성됩니다

ByeongHunKim commented 1 month ago
image
ByeongHunKim commented 1 month ago

Dynamic Admission Control Docs

ByeongHunKim commented 1 month ago

https://www.solo.io/blog/istios-networking-in-depth/

ByeongHunKim commented 1 month ago

https://coffeewhale.com/kubernetes/admission-control/2021/04/28/opa1/

ByeongHunKim commented 1 month ago
image

Mutating Admission Controller 에 대한 내용

먼저 성호님이 주셨던 링크에 있는 설명을 첨부하자면 아래와 같은데, 이렇게 이해하면 편할 것 같다

예를 들어, 어떤 사람이 미술 전시관을 관람한다고 생각해 봅시다. 그 사람은 전시관 입구에서 신원확인(Authentication)을 받은 후 표 검사를 통해 입장할 수 있는 허가(Authorization)를 받습니다. 그렇다고 해서 그 사람이 전시품을 마음대로 만지거나 훼손할 수 있는 것은 아니기에 전시장에서 전시품을 만지는 행동을 제한(validating admission control) 받거나 목소리를 낮추도록(mutating admission control) 요구 받습니다. 이것이 Admission Control입니다. 관리자의 정책에 따라 세부적인 작업을 제한하거나 변경 시키는 것입니다.

쿠버네티스의 많은 컴포넌트들이 그렇듯이 Admission Control도 Webhook으로 사용자에게 API가 열려 있습니다. 쿠버네티스가 정의한 인터페이스만 잘 맞춘다면 사용자는 자신만의 Admission Controller를 구현할 수 있습니다. 쿠버네티스에서는 이것을 Dynamic Admission Controller 라고 부르고 크게 MutatingWebhook과 ValidatingWebhook으로 나뉩니다.

  1. Istio를 설치하면 istio-sidecar-injector라는 Mutating Webhook이 쿠버네티스 API 서버에 등록됨(공식문서). 이 Webhook이 새로운 파드 생성 요청을 감지하고 가로챈다
  2. 파드 생성 요청이 들어오면, API 서버는 먼저 인증과 권한 검사를 수행한다. 검사를 통과하면 Mutating Admission Controller 단계로 넘어간다(k8s docs - admission-controllers).
  3. 이때 Kubernetes API 서버는 MutatingWebhookConfiguration에 정의된 모든 Admission Webhook을 실행하는데, istio-sidecar-injector Mutating Webhook도 호출된다. Webhook은 파드의 네임스페이스 레이블(istio-injection=enabled)과 파드 어노테이션(sidecar.istio.io/inject) 등을 확인해 사이드카 주입 여부를 결정한다
  4. 주입이 필요하다고 판단되면, Webhook은 파드 스펙을 변경해 Envoy 프록시 컨테이너와 설정을 추가
  5. Mutating Webhook 설정은 MutatingWebhookConfiguration 오브젝트에 정의되어 있다 
    kubectl get mutatingwebhookconfigurations
# output
# NAME                                   WEBHOOKS   AGE
# istio-sidecar-injector                 4          112d

Istio의 Mutating Admission Controller가 어떻게 트리거링 되는가?

istio-sidecar-injector의 namespaceSelector를 실제로 확인해보고 검증

kubectl get mutatingwebhookconfigurations istio-sidecar-injector -o jsonpath='{.webhooks[2]}' | yq -P
namespaceSelector:
  matchExpressions:
    - key: istio-injection
      operator: In
      values:
        - enabled

조건 확인:

    - key: istio-injection
      operator: In
      values:
        - enabled