📌 Notice

[도전과제1] Istio 관리의 새로운 방식, Sail Operator

본 포스팅은 Istio의 기존 In-Cluster Operator가 deprecated된 이후,
새로운 관리 도구인 Sail Operator에 대해서 정리한 블로그입니다.

쿠버네티스 환경에서 Istio를 선언적이고 GitOps 친화적으로 운영하고자 고민했던 분들께 도움이 되었으면 합니다 🙌

🔗 관련 링크:

• Istio In-Cluster Operator Deprecation
• Introducing the Sail Operator
• Sail Operator 1.0 GA Released

📌 Summary

• Istio In-Cluster Operator의 복잡성과 한계를 해소하기 위해 Sail Operator가 등장했습니다.

• Sail은 Helm 기반으로 GitOps에 최적화되어 있으며, 기존 IstioOperator와 경량 CRD(Istio)를 모두 지원합니다.

• RevisionBased 전략을 통해 무중단 업그레이드 및 안정적인 Istio 버전 관리를 실현할 수 있습니다.

📌 기존 Operator의 한계, 그리고 새로운 선택지

Istio는 복잡한 트래픽 제어와 관찰 가능성, 보안 정책까지 제공하는 강력한 서비스 메시 솔루션입니다.
하지만 그만큼 설치와 업그레이드, 운영이 어렵다는 인식도 함께 따라왔죠.

기존에는 istioctl, Helm, 그리고 In-Cluster Operator라는 세 가지 방식으로 Istio를 관리할 수 있었지만,
Istio 팀은 2025년까지 In-Cluster Operator의 지원을 중단하겠다고 공식 발표했습니다.

👉 Step. 01 In-Cluster Operator는 왜 사라졌을까?

Istio는 한동안 In-Cluster Operator를 공식적인 설치/운영 수단 중 하나로 제공해 왔습니다.
하지만 이 방식은 2025년 기준으로 완전히 지원 중단(deprecated) 되었고,
사용자들은 이제 Helm 또는 Sail Operator 같은 대체 수단으로 전환할 것을 권장받고 있습니다.

그렇다면 왜 기존 방식이 더 이상 유지되지 않았을까요?

✅ 이유 1. 사용률은 낮고, 복잡도는 높았다

Istio 공식 블로그에 따르면, In-Cluster Operator의 실사용률은 10% 미만이었습니다.
반면 대부분의 사용자는 여전히 istioctl 또는 Helm 기반 설치 방식을 선호했습니다.

• 높은 권한의 컨트롤러가 클러스터 내에서 동작
• 설정 변경/버전 업그레이드 시 복잡한 순서 관리 필요
• GitOps와 통합이 애매한 구조

즉, 복잡한 구조에 비해 실익이 낮은 방식이었던 셈입니다.

✅ 이유 2. GitOps와의 궁합이 나빴다

In-Cluster Operator는 자체적으로 Istio 리소스를 생성하고 관리하지만,
GitOps에서는 선언적 상태(=Git의 값)를 신뢰해야 하며, 직접 제어 가능한 구조가 필요합니다.

• Operator가 자동으로 만든 리소스는 Git에 없는 경우가 많고
• 업데이트 시 의도하지 않은 drift(불일치)가 발생하기 쉬웠습니다.
• Argo CD나 Flux와 함께 쓰기에 컨트롤러 간 충돌 위험도 존재했습니다.

결국 GitOps 관점에서는 Operator 기반 관리가 불투명한 블랙박스가 될 수 있었습니다.

✅ 이유 3. Helm 생태계의 발전

Istio가 Operator를 도입한 시점은 Helm v2 시절로, 기능상 제약이 많았습니다.
그러나 Helm v3부터는 CRD 설치, 의존성 관리, values 병합 등 기능이 크게 향상되었고,
현재는 Istio 자체도 Helm 기반 배포를 1순위로 권장합니다.

즉, Operator를 통해 얻던 많은 이점이 더 이상 Helm의 대안이 될 이유가 없어진 것입니다.

💬 운영자의 실제 목소리

"IstioOperator 리소스는 Git에 있는데 실제 리소스는 Operator가 만든 거라 diff가 자꾸 납니다..."
"업그레이드 순서 때문에 istiod보다 gateway가 먼저 설치되는 일이 생기기도 했죠..."
"GitOps 도입하고부터는 사실 좀 부담됐어요. 눈에 안 보이니까요."

👉 Step. 02 Sail Operator의 등장과 의의

Istio In-Cluster Operator가 사라진 자리를 대체하기 위해 등장한 새로운 방식이 바로 Sail Operator입니다.

2024년 후반 공식 소개 이후, 2025년 3월 v1.0 GA 버전이 릴리즈되며
Istio 운영을 위한 새로운 표준 관리 도구로 자리잡고 있습니다.

✅ Sail Operator란?

Sail Operator는 Red Hat이 주도적으로 개발한 Istio 전용 Operator입니다.
기존 In-Cluster Operator와는 다르게, Helm 기반 구성을 바탕으로 GitOps 패턴에 맞춘
운영 방식에 최적화되어 있습니다.

• Git에 선언적으로 정의한 IstioOperator 리소스를 그대로 유지하면서
• 내부적으로 Helm을 사용해 실제 리소스를 명시적이고 추적 가능한 방식으로 설치/관리합니다.
• 이는 기존 Helm Chart 생태계를 그대로 활용할 수 있다는 의미이기도 합니다.

✅ 즉, 기존 구조는 최대한 유지하면서도
더 투명하고 Git 친화적인 방식으로 바뀌었다는 점이 핵심입니다.

✅ 기존 Operator와의 주요 차이점

Sail Operator는 Helm으로 구성된 Istio 설치를 Operator 패턴으로 관리할 수 있는 하이브리드 구조이며,
기존 사용자 입장에서는 적은 변경만으로도 더 나은 GitOps 환경을 구축할 수 있다는 장점이 있습니다.

🔗 공식 블로그 참고

• 🧭 Introducing the Sail Operator
• 🚢 Sail Operator 1.0 GA Released
• 🗑 In-Cluster Operator Deprecation Notice

📌 Sail Operator 실습 및 설치

이제 본격적으로 Sail Operator를 활용해 Istio를 선언적으로 배포해보겠습니다.
이번 실습은 로컬에서도 실행 가능한 Kind 기반 클러스터에서 진행되며, Helm을 사용합니다.

📦 Step 01. Kind 기반 클러스터 구성

관찰 도구(Prometheus, Grafana, Kiali 등)를 NodePort로 노출할 수 있도록
포트 매핑과 기본 유틸 설치를 포함한 Kind 클러스터를 구성합니다.

cat <<EOF | kind create cluster --name myk8s --image kindest/node:v1.24.12 --config=-
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
EOF
# 클러스터에 접속하여 기본 패키지 설치:
docker exec -it myk8s bash -c 'apt update && apt install -y vim curl wget net-tools dnsutils'

🚢 Step 02. Sail Operator 설치

Helm을 통해 Sail Operator를 설치합니다:

helm repo add sail-operator https://istio-ecosystem.github.io/sail-operator
helm repo update

kubectl create namespace sail-operator
helm install sail-operator sail-operator/sail-operator --version 1.0.0 -n sail-operator

🔁 Step. 03 Sail Operator를 활용한 안전한 Istio 업그레이드

이번 Step에서는 sailoperator.io/v1 API 그룹을 사용하는 Sail Operator 전용 리소스를 통해
RevisionBased 전략 기반의 Istio 업그레이드 시나리오를 실습해봅니다.

Sail Operator는 자체적으로 Istio 및 IstioRevisionTag라는 경량 CRD를 제공하며,
버전 관리 및 업그레이드를 훨씬 간단하고 안전하게 수행할 수 있도록 지원합니다.

✅ 1. Istio 1.24.2 배포 및 기본 RevisionTag 설정

kubectl create ns istio-system

cat <<EOF | kubectl apply -f -
apiVersion: sailoperator.io/v1
kind: Istio
metadata:
  name: default
spec:
  namespace: istio-system
  version: 1.24.2
  updateStrategy:
    type: RevisionBased
    inactiveRevisionDeletionGracePeriodSeconds: 30
---
apiVersion: sailoperator.io/v1
kind: IstioRevisionTag
metadata:
  name: default
spec:
  targetRef:
    kind: Istio
    name: default
EOF

✅ 2. 현재 Istio 상태 확인

status.revision 필드로 실제 revision 이름 확인 가능 (예: istio-default-1-24-2)

kubectl get istio -A
kubectl get pods -n istio-system
kubectl get istiorevisiontag -A

✅ 3. 샘플 배포

버전 업그레이드를 실습하기 위해 샘플 어플리케이션을 배포합니다.

# Create a namespace and label it to enable Istio injection:
kubectl create namespace sample
kubectl label namespace sample istio-injection=enabled

#After labeling the namespace you will see that the IstioRevisionTag resource status will change to ‘In Use: True’, because there is now a resource using the revision default-v1-24-2:
kubectl get istiorevisiontag
NAME      STATUS    IN USE   REVISION          AGE
default   Healthy   True     default-v1-24-2   6m24s

#Deploy the sample application:
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.25/samples/sleep/sleep.yaml -n sample

⏫ 4. Istio 업그레이드: 1.24.3으로 변경

단순히 spec.version만 변경하면 됩니다.

Sail Operator는 지정된 Istio 제어 평면이 사용 중인지 자동으로 감지하고 위에 보이는 "In Use" 상태 조건에 이 정보를 기록합니다. 현재 모든 IstioRevisions과 IstioRevisionTag는 "In Use"으로 간주됩니다.

이전 개정판은 default-v1-24-2 샘플 애플리케이션의 사이드카에서 참조되므로 사용 중인 것으로 간주됩니다.

새로운 개정판은 default-v1-24-3 태그에 의해 참조되므로 사용 중인 것으로 간주됩니다.
해당 태그는 샘플 네임스페이스에서 참조되므로 사용 중인 것으로 간주됩니다.

kubectl patch istio default -n istio-system --type merge -p '{"spec":{"version":"1.24.3"}}'

watch로 리소스 변경 실시간 추적하기

리비전별 리소스 생성/삭제가 무중단으로 이루어지는 것을 확인합니다.

# Istiod 등 새로운 Revision 생성 및 상태 추적
watch 'kubectl get deploy -n istio-system'

# RevisionPod 생성 상태 추적
watch 'kubectl get pods -n istio-system -o wide'

# 서비스 엔드포인트 변경 여부 확인
watch 'kubectl get endpoints -n istio-system'

IstioRevision이 더 이상 사용되지 않고 Istio 리소스의 활성 리비전이 아닌 경우(예: spec.version 필드에 설정된 버전이 아닌 경우)

Sail Operator는 유예 기간(기본값 30초) 후 해당 리비전을 삭제합니다.

# 버전 패치 후에 파드를 롤아웃(재시작)하면, Istio 리소스에는 하나의 개정판만 존재하는것을 확인할 수 있습니다.
kubectl rollout restart deployment -n sample

📌 Conclusion

Sail Operator는 기존 In-Cluster Operator의 복잡함을 넘어서 간결하고 GitOps 친화적인 Istio 관리 방식을 제시합니다.

기존과 동일한 IstioOperator 리소스를 유지하면서도 새롭게 도입된 sailoperator.io/v1 기반의 경량 리소스를 통해 버전 관리와 업그레이드 작업이 훨씬 단순해졌습니다.

특히, RevisionBased 전략을 활용하면 무중단 업그레이드, 자동 리비전 전환, 정책 기반 리비전 정리 등 운영자가 반복적으로 겪는 어려운 문제들을 Sail Operator가 대신 처리해 줍니다.

이번 실습에서는 Kind 기반 환경에서 Sail Operator를 직접 설치하고, Istio를 선언적으로 배포한 뒤, 안전하게 업그레이드하는 과정을 따라가며 Sail Operator가 어떤 가치를 제공하는지 체감해볼 수 있었습니다.