Closed guswns1659 closed 2 months ago
Istio 사이드카 프록시(Envoy)를 파드에 자동으로 주입하는 것은 Istio의 주요 기능 중 하나입니다. Istio는 이를 위해 "자동 사이드카 주입(auto sidecar injection)"이라는 메커니즘을 사용합니다. 이는 Istio의 컨트롤 플레인에서 이루어지며, Istio의 istio-sidecar-injector
라는 구성 요소가 이를 담당합니다. 이 기능은 파드를 생성할 때, Istio가 자동으로 사이드카 프록시 컨테이너를 파드에 추가하도록 합니다.
네임스페이스 라벨링:
kubectl label namespace <namespace> istio-injection=enabled
Webhook 구성:
MutatingAdmissionWebhook
기능을 사용하여 파드가 생성될 때 자동으로 사이드카 프록시를 주입합니다.istio-sidecar-injector
라는 MutatingAdmissionWebhook이 파드 생성 요청을 가로채고, 파드 스펙에 Envoy 사이드카 컨테이너를 추가합니다.파드 생성 시 사이드카 주입:
istio-sidecar-injector
가 파드의 정의를 수정하여 Envoy 사이드카 컨테이너를 추가합니다.네임스페이스 라벨링:
kubectl label namespace default istio-injection=enabled
파드 생성:
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 3
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: myimage:latest
ports:
- containerPort: 8080
자동 주입 확인:
istio-sidecar-injector
는 Envoy 사이드카를 파드에 주입합니다.파드가 실행 중인 상태에서 실제로 사이드카가 주입되었는지 확인할 수 있습니다:
kubectl get pods
kubectl describe pod <pod-name>
파드 설명에서 두 개의 컨테이너가 포함된 것을 확인할 수 있습니다: 하나는 원래의 애플리케이션 컨테이너, 다른 하나는 Envoy 사이드카 컨테이너입니다.
파드가 생성된 후, 실제로 주입된 사이드카 컨테이너를 확인할 수 있습니다:
kubectl get pods
kubectl describe pod <pod-name>
출력 예시에서 두 개의 컨테이너가 있음을 확인할 수 있습니다:
myapp-container
: 원래 정의된 애플리케이션 컨테이너istio-proxy
: Istio가 자동으로 주입한 Envoy 사이드카 컨테이너Containers:
myapp-container:
Container ID: docker://<id>
Image: myimage:latest
...
istio-proxy:
Container ID: docker://<id>
Image: istio/proxyv2:<version>
...
istio-sidecar-injector
를 사용하여 파드 생성 시 자동으로 Envoy 사이드카를 주입합니다.istio-injection=enabled
라벨을 추가해야 합니다.kubectl describe pod
명령어를 통해 주입된 사이드카 컨테이너를 확인할 수 있습니다.istio도 ingressgateway, pliot, envoy 등 다양한 타입이 존재
Istiod는 Istio의 통합된 컨트롤 플레인 컴포넌트입니다. 이전에는 Pilot, Galley, Citadel, 사이드카 주입기(Sidecar Injector) 등의 개별적인 컴포넌트로 구성되었으나, Istio 1.5부터 istiod
라는 단일 바이너리로 통합되었습니다.
기능:
이점:
자세한 내용은 Istio 공식 블로그에서 확인할 수 있습니다【110†source】.
IngressGateway는 외부 트래픽을 서비스 메쉬 내부로 라우팅하는 역할을 합니다. 이는 Kubernetes의 Ingress와 유사하지만, Istio의 고급 트래픽 관리 기능을 활용할 수 있습니다.
자세한 내용은 Istio 문서에서 확인할 수 있습니다.
EgressGateway는 서비스 메쉬 내부에서 외부로 나가는 트래픽을 관리합니다. 이는 외부 서비스와의 통신을 제어하고 모니터링하는 데 사용됩니다.
자세한 내용은 Istio 문서에서 확인할 수 있습니다.
Envoy는 Istio의 데이터 플레인 컴포넌트로, 각 서비스마다 사이드카 패턴으로 배포됩니다. 모든 서비스 간의 통신을 가로채고 관리하는 역할을 합니다.
자세한 내용은 Envoy 공식 문서에서 확인할 수 있습니다.
k8s와 유사하게 컨트롤 플레인과 데이터 플레인으로 나눠진다.
Envoy는 Kubernetes에서 사이드카 패턴을 사용하여 서비스 오브젝트가 파드로 보내는 요청을 가로챕니다. 이는 Envoy 프록시가 각 파드에 사이드카 컨테이너로 주입됨으로써 이루어집니다. 다음은 Envoy가 Kubernetes 서비스 오브젝트를 통해 파드로 보내는 요청을 어떻게 가로채는지 설명합니다.
사이드카 패턴:
Envoy 사이드카 자동 주입:
istio-sidecar-injector
를 사용하여 새로운 파드가 생성될 때 Envoy 프록시를 자동으로 주입합니다. 이를 위해 네임스페이스에 istio-injection=enabled
라벨을 추가해야 합니다.IP 테이블 설정:
트래픽 리디렉션:
kubectl label namespace default istio-injection=enabled
파드 정의에는 Envoy 프록시가 명시되지 않지만, 파드 생성 시 자동으로 주입됩니다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 3
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: myimage:latest
ports:
- containerPort: 8080
Envoy 프록시는 초기화 컨테이너를 통해 다음과 같은 iptables 규칙을 설정합니다:
# Redirect all outbound traffic to Envoy
iptables -t nat -A OUTPUT -p tcp -j REDIRECT --to-port 15001
# Redirect inbound traffic to Envoy
iptables -t nat -A PREROUTING -p tcp -j REDIRECT --to-port 15001
이 규칙들은 파드 내의 모든 트래픽이 Envoy 프록시를 통과하도록 합니다.
netstat -tuln
키워드