[Question] Istio init container 와 pause container의 연관성

[ByeongHunKim]

Question / 질문 내용

Istio init container 와 pause container의 연관성

Context / 상황 설명

9 에서 istio init container가 iptables 규칙을 수정해주는 것과 직접 sidecar가 inject된 어플리케이션 컨테이너를 검증해보며 이해했는데 어떻게 어플리케이션 컨테이너도 같은 규칙을 적용 받는지(?)

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

문서를 찾아보고 있습니다

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

https://learnk8s.io/kubernetes-network-packets#:~:text=to%2Dcontainer%20communication.-,How%20Linux%20network%20namespaces%20work%20in%20a%20pod,-Let%27s%20consider%20a

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

init container는 pause container가 설정한 네트워크 네임스페이스 내에서 작동

파드 별로 별도의 리눅스 네임스페이스를 가진다 ( = Linux 커널의 네임스페이스 기능을 활용하여 파드 내의 모든 컨테이너는 동일한 네트워크 네임스페이스를 공유 )

파드 내 모든 컨테이너는 이 네트워크 네임스페이스를 공유하므로, 동일한 IP 주소와 포트 공간을 갖게 됨

istio-init 컨테이너가 실행되어 iptables 규칙을 추가해줘도 규칙들은 파드의 공유된 네트워크 네임스페이스에 적용된다

• 그렇기 때문에 proxy container, application container로 iptables 규칙을 조회해도, 전체 파드에 적용된 규칙을 확인할 수 있는 것 같다

[ByeongHunKim]

참고용 블로그

[ByeongHunKim]

istio-injection=enabled 라벨이 추가된 이후 파드의 생성 및 초기화 과정

• 결과적으론 PAUSE 컨테이너가 Network namespace를 만들어준 뒤, 나머지 컨테이너들은 PAUSE 컨테이너의 Network namespace를 공유받아 동일한 IP를 사용하게 되는 것

1. 파드 생성 요청

Kubernetes API 서버가 새 파드 생성 요청을 받음

2. Istio 사이드카 주입

istio-injection=enabled 라벨이 있는 네임스페이스에서 파드가 생성될 때, Istio의 mutating webhook이 작동하여 파드 스펙을 수정하며, 이 단계에서 Istio init 컨테이너와 Envoy 프록시 컨테이너가 파드 스펙에 추가됨

3. 파드 스케줄링

수정된 파드 스펙이 Kubernetes 스케줄러에 의해 노드에 할당

4. Pause 컨테이너 시작

노드의 Kubelet이 파드를 시작할 때, 가장 먼저 pause 컨테이너를 실행 이 컨테이너는

• 파드의 네트워크 네임스페이스를 생성
• 파드의 IP 주소를 할당
• 기본적인 네트워크 설정을 구성

5. Istio Init 컨테이너 실행

Pause 컨테이너가 실행된 후, Istio init 컨테이너가 시작 이 컨테이너는:

• Pause 컨테이너가 설정한 네트워크 네임스페이스 내에서 작동
• iptables 규칙을 수정하여 인바운드/아웃바운드 트래픽을 Envoy 프록시로 리다이렉트하도록 설정

6. 애플리케이션 컨테이너 및 Envoy 프록시 시작:

Init 컨테이너가 성공적으로 완료되면, 애플리케이션 컨테이너와 Envoy 프록시 컨테이너가 동시에 시작