SAP Kyma Runtime이 Kubernetes 위에 Istio, NATS 기반 이벤팅, API Gateway, BTP Operator를 추가하여 서비스 메시 구성, 인증서 관리, BTP 서비스 통합을 자동화

Context

표준 Kubernetes 클러스터는 서비스 메시, 이벤팅 인프라, API 게이트웨이, BTP 서비스 자격증명 관리를 수동으로 설정해야 합니다. 각 컴포넌트를 별도로 설치하고 운영해야 하므로 초기 구성과 유지보수 복잡도가 높습니다.

Technical Solution

• Istio 서비스 메시 자동 주입: 레이블(istio-injection: enabled)이 지정된 네임스페이스의 모든 Pod에 Envoy 사이드카를 자동 삽입하여 mTLS, 트래픽 관리, 가시성 제공
• APIRule CRD로 API 게이트웨이 설정: 표준 Kubernetes Ingress 대신 APIRule을 사용하여 Istio VirtualService + Oathkeeper와 통합되는 API 노출
• NATS 기반 이벤팅 스택 통합: 사전 구성된 NATS 서버와 이벤팅 컨트롤러를 eventing-system 네임스페이스에 배포하여 이벤트 기반 아키텍처 즉시 사용
• BTP Operator로 서비스 관리 자동화: ServiceInstance/ServiceBinding CRD를 통해 BTP 서비스 인스턴스 프로비저닝과 자격증명을 Kubernetes Secret으로 선언적 관리
• 모듈식 설치 모델: Kyma CR에서 istio, api-gateway, eventing, btp-operator, serverless, telemetry 등을 선택적으로 활성화/비활성화하여 클러스터 영향 최소화

Impact

Istio 사이드카는 Pod당 메모리 약 50MB를 추가 사용합니다. 표준 Kubernetes에서 수동 cert-manager 설정 대신 통합 인증서 관리를 제공하고, 수동 External-DNS 설정 대신 *.kyma.ondemand.com에 대한 관리형 DNS를 제공합니다.

Key Takeaway

Kyma Runtime은 운영 부담을 줄이기 위해 선택 가능한 모듈식 구조로 설계되어 있으므로, 프로덕션 환경에서는 기본적으로 istio-injection: enabled 레이블 누락, Ingress 대신 APIRule 미사용, NATS의 인메모리 특성 간과 같은 다섯 가지 일반적인 함정을 피해야 합니다.