개요

이스티오의 컨트롤 플레인은 현재 istiod이다.

과거 이스티오는 세 가지 컴포넌트를 통해 컨트롤 플레인을 구성했다.

• Pilot - 엔보이의 프록시 라우팅 규칙을 관리하고, 서비스 디스커버리와 로드 밸런싱 설정을 담당하는 코어.
• Galley - 쿠버네티스 속에서 필요한 설정을 세팅하고 연결
• Citadel - mTLS를 위한 인증서 관리 및 보안

그러나 오늘날에는 이것들을 한 프로세스로 통합하여 istiod라는 프로세스 하나로 제공한다.^[1]
위 컴포넌트들의 이름과 기능들은 전부 istiod에 녹아들었다.
참고로 파드 이름은 istiod이나, 실제 컨테이너 이미지에서 실행되는 명령어를 보면 pilot-discovery이다.

기능

서비스 메시로서, istiod의 역할은 간단하게 한 마디로 요약할 수 있다.
사용자의 설정 정보를 데이터 플레인에 적용한다.
마치 쿠버네티스가 컨트롤러를 통해 희망 상태와 현재 상태를 맞춰나가는 것처럼, 사용자가 정의한 희망 상태에 맞춰서 메시의 현재 상태를 최대한 맞추어 나가는 프로세스로서 동작하는 것이 istiod이다.

동작 - 동기화

그렇다면 어떻게 그러한 기능을 수행하는가?
istiod는 데이터 플레인을 관리하기 위해 두 가지 대상과 통신한다.

• kube-apiserver - 이벤트 제공자
  • 사용자가 생성, 변경한 리소스를 추적해 현재 클러스터에 반영
  • 현재 클러스터의 상태, 런타임, 버전 정보 등을 파악하여 기존 설정에 맞게 조정
• 데이터 플레인
  • 각 프록시들의 상태 추적 감시
  • 설정 정보 주입

요약하자면 api 서버로부터 각종 설정 정보와 클러스터의 상태를 전달 받고 이를 바탕으로 데이터 플레인에 여러 설정을 하는 것이다.

궁극적 일관성(eventual consistency)

이때 설정하는 과정을 동기화(sync)라고 표현하는데, 컨트롤 플레인의 설정이 즉각적으로 데이터 플레인에 반영되지 않기 때문이다.
이스티오는 설계 상 궁극적 일관성(eventual contistency) 을 지향한다.
시시각각 변화하는 클러스터의 상태를 완벽히 관리하는 것도 어려운 일이거니와, 모든 설정이 즉각적으로 반영시키는 작업은 큰 부하가 심하게 발생시킬 것이다.
그래서 빠르게 모든 설정을 적용하는 것은 포기하는 대신 시간이 지나면 반드시 설정이 반영되도록 설계된 것이다.
(그렇기에 트러블슈팅을 할 때는 제대로 설정이 동기화됐는지부터 확인해야 한다.)

자그마한 예시를 통해 궁극적 일관성에 대해 조금 더 생각해볼 부분을 짚어보자.

• 노드의 kubelet은 자신이 관리하는 워크로드의 헬스체크를 수행하고 이를 kube-apiserver로 전송한다.
• istiod는 api서버와 통신한다.
  • 이스티오 관련 리소스가 생성될 때, 관련한 정보를 얻기 위해 istiod가 api 서버와 통신하는 건 너무도 당연하다.

서비스 B-2가 죽은 상황을 생각해보자.
istiod는 모든 설정을 동기화시켜주고 있기 때문에, B-2가 죽으면 언젠가 동기화가 되지 않는 순간을 포착하고 문제가 생겼음을 알 수 있을 것이다.
하지만 동기화는 기본적으로 설정이 변경됐을 때 수행하는 작업이기에, istiod는 실제 서비스의 상태 여부를 판단할 때 kube-apiserver를 활용한다.
(이 헬스체크는 엔보이들이 개별적으로 행하는 이상치 탐지와 관련 없다.)

위 상황에서 istiod가 A에게 해당 설정을 전파하기 전에 A가 B-2로 트래픽을 보내는 순간이 있을 수 있다.
이렇게 이미 죽었지만 트래픽을 받는 워크로드를 유령 워크로드(phantom workload)라 부르며, 이는 장애 상황 유발 및 성능 저하를 일으킨다.
궁극적 일관성을 지향하니 언젠가는 분명 해당 사항에 대해istiod는 B-2를 클러스터로 삼고 있는 A에게 이를 알려주고 설정을 바꿀 것이다.
아무튼 이런 간극이 있을 수 있기에 이를 최적화하는 것도 안정적인 클러스터를 운영하는 하나의 중요한 요건이라 할 수 있다.

istiod 내부 동기화 프로세스

istiod 내부에서 일어나는 동작을 조금 더 살펴보자.^[2]
기본적으로 istiod에서의 흐름은 api 서버 -> istiod -> 데이터 플레인 방향으로 이뤄진다.
데이터 플레인에서 설정을 넣어주는 작업을 푸시라고 부르기 때문에 대체로 내부 요소를 설명할 때도 푸시라는 이름의 메트릭이 많다.
간단하게 먼저 이벤트를 받고, 이들을 모아서 큐에 넣는다.
그리고 이 큐에서 이벤트를 꺼내 데이터 플레인에 전달할 수 있도록 파싱하는 작업을 거친 뒤에 설정들을 그대로 푸시한다.

이때 istiod는 프로세스 상 크게 두 가지 성능 최적화 기법을 적용한다.

• DiscoveryServer가 동기화할 이벤트를 수신하고 디바운스(Debounce)
  • 실시간으로 모든 이벤트를 작업하지 않고 이벤트를 병합하여 처리하는 동작을 말한다.
  • 여러 동작을 한꺼번에, 효율적으로 처리하여 자원 소모를 줄이고 성능을 향상시키는 것이다.
• 병합된 이벤트를 작업 큐에 넣고, 한번에 최대 처리 가능한 개수에 맞춰 쓰로틀(Throttle) 하여 푸시
  • 이벤트를 1)엔보이 설정으로 변환하고, 2)푸시하는 작업을 해야 한다.
  • 이때 이미 처리되는 항목을 더 빨리 처리되도록 보장하면서, 컨텍스트 스위칭을 줄인다.

이벤트들은 api 서버로부터 받아오는 것들이고, 사용자의 설정이든 클러스터 단에서의 변화든 다양한 이벤트가 발생할 수 있을 것이다.
일차적으로는 이것들을 그룹화시키는 디바운싱 작업을 거쳐서 작업 큐에 넣고, 이후에는 개수 단위로 배치 처리하는 식으로 동기화가 일어난다.
E-이스티오 컨트롤 플레인 성능 최적화를 할 때는 이 각각의 부분에 대한 메트릭을 측정하고 대응해야 한다.

네트워크 구성도(포트 정보)

istiod를 포트 기준으로 구성하자면 위와 같은 모양을 하고 있다.^[3]

• 9876 - ControlZ 인터페이스 포트
  • ControlZ는 istiod를 직접적으로 모니터링할 때만 여는 웹 대시보드이다.^[4]
• 8080 - 서비스 메시의 상태를 노출하는 디버그용 포트이나, deprecated됨
  • 근데 아직도 pilot-discovery request GET해서 사용할 수 있긴 하다.
  • /debug 하위로 다양한 엔드포인트를 노출하는데, 운영환경에서는 ENABLE_DEBUG_ON_HTTP: false로 환경변수를 전달해 비활성화하는 것이 좋다.
• 15010 - 데이터 플레인에서 각종 설정을 받기 위해 사용되는 포트
  • 즉, 이 통로를 통해 istiod는 데이터 플레인을 관리한다.
• 15012 - 위 포트와 같지만 TLS를 통해 통신 간 암호화를 하는 포트로, 기본으로 쓰인다.
• 15014 - 컨트롤 플레인의 프로메테우스 메트릭 노출 포트
• 15017 - 데이터 플레인에 사이드카를 주입하는 어드미션 웹훅 포트로, 앞단의 서비스가 443 트래픽을 이쪽으로 포워딩한다.

디버그용 포트

8080 포트는 deprecated됐다고는 하나 아직 사용할 수는 있다.
각 엔드포인트 정보는 다음과 같다.

• 파일럿 인지하는 서비스 메시 상태
  • /debug/adsz : 클러스터, 루트, 리스너 설정
  • /debug/adsz?push=true : 이 파일럿이 관리하는 모든 프록시에 대한 푸시 트리거
  • /debug/edsz=*proxyID*=*<pod>.<namespace>* : 프록시가 알고 있는 엔드포인트들
  • /debug/authorizationz : 네임스페이스에 적용되는 인가 정책 목록
• 파일럿이 알고 있는 데이터 플레인 설정 정보
  • /debug/config_distribution : 이 파일럿 인스턴스에 연결된 모든 엔보이의 버전 상태
  • /debug/config_dump?proxyID=<pod>.<namespace> : 이스티오 파일럿의 현재 알려진 상태에 따라 엔보이 설정 생성
  • /debug/syncz : 이 파일럿이 관리하는 프록시 표시
    • 또한 프록시로 보낸 최신 논스 nonce 와 응답받은 최신 논스도 보여준다. 이 둘이 동일하면 프록시의 설정이 최신인 것이다.

이런 정보는 직접 이렇게 뜯어서 알기보다는 Kiali나, istioctl을 이용해서 간접적으로 볼 수 있다.
더 상세한 정보가 굳이 필요할 때 활용할 법한 정보.

ControlZ

istioctl dashboard controlz deployment/istiod.istio-system

위 디버그 정보들을 웹 ui로 보려면 Controlz를 사용하면 된다.
이건 컨트롤플레인을 모니터링하기 위해 내부적으로 제공되는 ui이다.

다만 위 /debug 경로로 요청해서 보는 것만큼 많은 설정을 보여주지는 않으니 참고하자.

관련 문서

EXPLAIN - 파생 문서

기타 문서

참고

Istio 1기 - Istio Hands-on