По суті: тут чиста імплементація, практично без нічого порівняно з Istio. Все, що робить контролер — збирає конфігурацію з CRD, пакує її в snapshot і віддає через gRPC-порт, на який ходить Envoy. Супер проста реалізація. Нова конфігурація, коли додається, потрапляє в snapshot буквально за кілька секунд. Без самого Envoy, контролер сам по собі безкорисний.

Підтримки Ingress чи Gateway API немає — так і планувалось. Для цього є Envoy Gateway та інші зрілі рішення. Тому порівнювати з Istio не зовсім коректно, на мою думку.
Окрім збірки та доставки конфігурації, тут також вбудований Let’s Encrypt/ACME клієнт (lego), який вміє запрошувати сертифікати та складати їх напряму у Vault або Secret. Це все.

Дякую за запитання! Але тут не зовсім про service mesh, тут більше про динамічну конфігурацію та доставку її на Envoy.

Якщо коротко, то Istio використовує свої абстракції, схожі на Envoy (VirtualService, DestinationRule), але в будь-якому разі, як ми знаємо, це обгортка над Envoy з підтримкою sidecar, mTLS, телеметрією і т.д.

Тут же фокус саме на конфігурації самого Envoy через Kubernetes CRD. Ми працюємо безпосередньо зі специфікаціями Envoy і будуємо потрібну нам конфігурацію без додаткового шару трансляції. CRD відповідають майже 1:1 нативному API Envoy, оскільки ми будуємо всю CRD-конфігурацію динамічно з Envoy protobuf.