Red Hat OpenShift Service Mesh 3: Developer 프리뷰 업데이트

올해 초 Red Hat은 차세대 OpenShift Service Mesh 버전 3의 개발자 프리뷰로 제공되는 Red Hat OpenShift 기반 Istio를 위한 새로운 Operator를 발표했습니다. 해당 포스트에서는 2024년 OpenShift Service Mesh에 적용될 변경 사항에 대한 중요한 배경지식을 제공합니다. 그 이후 Red Hat은 Sail Operator를 개발하는 동시에 OpenShift Service Mesh 2에서 고객을 지원하고 Service Mesh 3 계획에 대한 피드백을 수집해 왔습니다. 새로운 Operator는 개발자 프리뷰로 유지되지만, 이 포스트에서는 업데이트를 제공하고 향후 계획을 논의하며 OpenShift Service Mesh 사용자가 OpenShift Service Mesh 3를 준비하는 방법에 대한 초기 지침을 제공합니다.

Service Mesh 3.0 업데이트

Service Mesh 3 쿠버네티스 Operator는 현재 'Sail Operator'로 개발 중이며 OpenShift Operator 허브에서 커뮤니티 쿠버네티스 Operator로 사용할 수 있습니다. Sail 쿠버네티스 Operator는 야간에 업데이트되므로 작업을 계속 진행 중이며 변경될 수 있습니다. 이 블로그 포스트에서 설명하는 내용과 다를 수 있으므로 지금은 테스트용으로만 사용하시기 바랍니다. 쿠버네티스 Operator에 대한 최신 정보는 포함된 README를 참조하십시오.

Red Hat은 커뮤니티 협업을 강화하기 위해 이 커뮤니티 쿠버네티스 Operator를 업스트림 istio-ecosystem 구성으로 이동하는 동시에 핵심 Istio 프로젝트를 개선하여 OpenShift 기반 Istio의 호환성을 높일 계획입니다. OpenShift Service Mesh 3의 다운스트림 제품 아티팩트는 새로 생성된 openshift-service-mesh 구성에 상주하는 반면, maistra 구성은 Service Mesh 2에 계속 사용됩니다.

Istio 기반 솔루션 및 Istio 전용 쿠버네티스 Operator

이전 블로그 포스트에서 설명한 바와 같이 OpenShift Service Mesh 3는 새로운 Istio용 쿠버네티스 Operator를 기반으로 합니다. 현재 OpenShift Service Mesh 2 쿠버네티스 Operator와 달리, 새로운 쿠버네티스 Operator는 Istio 리소스만 관리하고 Kiali와 같은 Istio 통합은 구성하지 않습니다. Kiali, 지표, 추적 등과 같은 보완 구성 요소는 독립적으로 지원되는 제품의 쿠버네티스 Operator로 관리됩니다.

Sail Operator가 처음 릴리스되었을 때 Istio 컨트롤 플레인을 설치하는 데 필요한 사용자 정의 리소스는 IstioHelmInstall이었습니다. 이 리소스는 Istio의 단일 인스턴스(컨트롤 플레인 및 데이터 플레인)를 생성하고 관리함을 반영하기 위해 이름이 'Istio'로 변경되었습니다.

OpenShift Service Mesh 2에서 사용되는 ServiceMeshControlPlane 사용자 정의 리소스와 달리 Istio 리소스는 업스트림 Istio의 Helm 값을 사용하여 Istio 구성을 정의합니다. 이를 통해 사용자는 예시 커뮤니티 구성을 OpenShift Service Mesh 3로 더 쉽게 변환할 수 있습니다. 또한 앞으로 구성을 개선하기 위해 Istio 커뮤니티와 협력하는 데 도움이 됩니다. Red Hat은 istioctl의 설치 프로세스 및 권장되지 않는 업스트림 Istio Operator 설치에 사용되는 커뮤니티의 Istio Operator API와 향후 통합되는 것을 배제하지 않았습니다.

다음 작업에는 Istio의 개정판, 카나리아 방식의 업그레이드, 멀티 테넌시와 같은 기능을 더 효과적으로 지원하기 위해 구성 및 개선 사항의 구조를 향상하는 과정이 포함됩니다. 최신 정보는 쿠버네티스 Operator의 README 파일에서 확인할 수 있습니다.

릴리스 선택

Sail Operator를 처음 출시했을 때 Sail Operator는 최신 버전의 Istio를 배포했는데, 이는 사실상 개발 중인 Istio의 마스터 분기였습니다. 이렇게 하면 Istio 커뮤니티의 최신 기능을 경험하기에는 편리하지만 대부분의 경우 사용자는 안정성과 istioctl 및 Kiali와 같은 통합과의 호환성을 위해 공식 Istio 릴리스를 사용해야 합니다.

현재 최신 버전의 Istio(현재 1.20)가 기본으로 설정되어 있습니다. Istio CRD의 version 필드를 사용하여 이를 구성합니다. OpenShift 콘솔을 사용하여 새 인스턴스를 생성할 때 사용 가능한 Istio 릴리스 목록에서 선택할 수 있는 드롭다운 메뉴가 나타납니다. 사용 가능한 Istio 릴리스는 versions.yaml 파일에 정의되어 있으며, 새로운 Istio 릴리스가 제공될 때마다 업데이트됩니다.

Istio 버전 선택기 드롭다운 메뉴

Sail Operator를 기반으로 하는 향후의 OpenShift Service Mesh 3 제품 쿠버네티스 Operator는 OpenShift Service Mesh 릴리스를 유사한 방식으로 관리합니다. 이 version 필드는 Service Mesh 2.x에서 ServiceMeshControlPlane 리소스의 version 필드와 유사하지만, 사용자가 Z '패치' 릴리스 수준(예: 3.1.1)까지 버전을 지정할 수 있다는 점에 주목할 만한 차이가 있습니다. Red Hat은 OpenShift Service Mesh의 최신 패치 릴리스만 지원하지만, 사용자는 이 기능을 통해 특정 'z' 패치 릴리스로 고정하거나 롤백할 수 있으므로 패치 업데이트를 더 효과적으로 제어하고 유연하게 관리할 수 있습니다.

구성 검증

새 CRD를 사용하여 Istio를 구성하는 기본 필드는 values 필드입니다. 사용자는 이 강력한 필드를 통해 Istio Helm 구성 값을 직접 참조할 수 있습니다. 업스트림 Istio의 protobuf validation에 따라 존재하지 않는 구성 값과 기타 구성 오류를 포착하도록 이 필드에 유효성 검사를 추가했습니다.

또한 이러한 유효성 검사를 통해 값 필드를 다음과 같이 관리할 수 있습니다.

$ oc explain istio.spec.values 
KIND:     Istio 
VERSION:  operator.istio.io/v1alpha1 
RESOURCE: values <Object> 
DESCRIPTION: 
    Values defines the values to be passed to the Helm chart when installing 
    Istio. 
FIELDS: 
  base <Object> 
  cni <Object> 
  defaultRevision <string> 
  global <Object> 
  istio_cni <Object> 
  istiodRemote <Object> 
  meshConfig <> 
  ownerName <string> 
  pilot <Object> 
  revision <string> 
  revisionTags <[]string> 
  sidecarInjectorWebhook <Object> 
  telemetry <Object> 
  ztunnel <>

Istio의 protobuf 스키마에 아직 포함되지 않은 실험적 구성에 액세스하는 경우와 같이 이러한 유효성 검사를 재정의해야 하는 경우가 있을 수 있으므로 값과 동일한 rawValues 필드도 포함했습니다. 단, 유효성은 검사하지 않습니다.

Istio 리소스, 값, rawValues 필드는 계속 실험 중이며 변경될 수 있습니다. 최신 정보는 README 프로젝트를 참조하세요.

Istio 상태 및 구성

Istio 구성을 적용한 후에는 컨트롤 플레인의 상태를 검증해야 합니다. 다음 명령을 사용하여 이 작업을 수행합니다.

$ kubectl get istioundefinedundefinedundefined

NAME         READY  STATUS VERSION AGE

istio-sample True  Healthy v1.20.0 62sundefinedundefined

또는 상태 필드를 사용합니다.

Istio 사용자 지정 리소스 정의

확장된 경우 status.appliedValues 필드를 사용하여 구성이 spec.values 필드를 통해 예상대로 적용되었는지 확인할 수 있습니다.

OpenShift 기반 Istio

Red Hat은 커뮤니티 Istio와 통합하려는 이니셔티브의 일환으로 OpenShift에서 Istio의 호환성을 개선하기 위해 업스트림 Istio에 지속적으로 기여하고 있습니다. 이는 Istio 제품화 작업을 간소화하는 Red Hat과 커뮤니티, 고객, 파트너를 위한 것입니다. Red Hat은 이러한 노력을 통해 OpenShift에서 커뮤니티 Istio가 더 쉽게 실행되도록 하고 지원되는 OpenShift Service Mesh에 대한 원활한 온보딩 경로를 제공합니다.

이러한 노력의 예로 최근 Istio 1.20에서 강조된 바와 같이 Istio 컨트롤 플레인과 데이터 플레인 구성 요소에 anyuid SCC(Security Context Constraint) 권한을 부여할 필요가 없었습니다. Red Hat은 이와 같은 기여를 계속 이어갈 예정이며, 그중 가장 중요한 것은 Istio의 Ambient 메쉬가 OpenShift에서 작동하도록 하는 것입니다.

게이트웨이 모범 사례

이 쿠버네티스 Operator가 발표되었을 때는 기본 Istio 설치 구성 프로필과 유사하게 gateways를 자동으로 설치했습니다. 이는 각각 istio-ingressgateway 및 istio-egressgateway라는 기본 수신 및 송신 게이트웨이를 생성하는 OpenShift Service Mesh 2.x와 일치합니다.

이러한 자동 생성 게이트웨이는 시작하기 편리하지만 프로덕션 환경에 필요한 구성 기능은 제공하지 않습니다. 또한 게이트웨이는 컨트롤 플레인보다 데이터 플레인에서 애플리케이션을 사용하여 생성하고 관리하는 것이 더 효과적입니다. 해당 애플리케이션과 함께 생성 및 관리되는 게이트웨이는 게이트웨이의 범위를 더 작은 애플리케이션 집합으로 제한하고 컨트롤 플레인이 아닌 애플리케이션의 라이프사이클을 채택할 수 있도록 하여 보안을 강화한 사례입니다.

따라서 사용자가 게이트웨이 주입 또는 쿠버네티스 게이트웨이 API를 사용하여 애플리케이션과 함께 게이트웨이를 생성하도록 안내하기 위해 이러한 컨트롤 플레인 게이트웨이를 제거하기로 했습니다. OpenShift Service Mesh 2.x의 ServiceMeshControlPlane에 지정된 istio-ingressgateway 및 istio-egressgateway는 Service Mesh 3.0에 포함되지 않습니다. 대신 게이트웨이 주입 및 쿠버네티스 게이트웨이 API를 사용하여 Bookinfo 애플리케이션에 대한 게이트웨이 구성 예를 제공합니다.

 게이트웨이 주입을 사용하면 쿠버네티스 또는 OpenShift의 기타 워크로드와 마찬가지로 Envoy 프록시와 함께 주입된 개발 리소스를 사용하여 게이트웨이를 생성하고 관리할 수 있습니다. 이 접근 방식을 사용하면 애플리케이션 소유자가 게이트웨이를 완전히 제어할 수 있습니다. 이 방법은 OpenShift Service Mesh 2.3 이상에서 게이트웨이를 생성하고 관리하는 데 권장됩니다.

OpenShift Service Mesh 2.4의 기술 프리뷰에서 게이트웨이 API를 사용하면 게이트웨이 '배포' 인스턴스가 생성되고 각 게이트웨이 인스턴스로 구성됩니다.

이러한 옵션을 사용하면 GitOps 워크플로우의 일부로 게이트웨이를 애플리케이션과 함께 생성하고 관리할 수 있습니다.

쿠버네티스 게이트웨이 API

Kubernetes Gateway API는 쿠버네티스의 네트워킹을 모델링하는 차세대 API를 나타냅니다. 현재 쿠버네티스 Ingress API와 비교하여 대규모 조직 전반에서 네트워킹을 관리할 수 있도록 훨씬 더 향상된 유연성과 확장성을 제공합니다. 처음에는 클러스터 외부 클라이언트의 north/south 트래픽을 관리하기 위한 것이지만, Service Mesh를 포함하여 east/west 트래픽도 포함하도록 확장되었습니다.  GAMMA 이니셔티브는 게이트웨이 API가 서비스 메쉬 활용 사례를 다루는 방법을 정의하기 위해 개발되었습니다. 현재 Istio에는 트래픽 관리와 같이 대부분의 문서화된 태스크에 대한 게이트웨이 API 구성 예가 포함되어 있습니다.

게이트웨이 API는 OpenShift Service Mesh 2.4의 기술 프리뷰 기능으로 유지되며 기능 플래그로 활성화해야 하지만, 이제 커뮤니티에서 일반적으로 사용할 수 있습니다. API 버전 1.0은 Istio 1.20에서 사용할 수 있습니다(OpenShift Service Mesh 2.6 이상에 포함됨). Istio는 향후 게이트웨이 API를 모든 트래픽 관리를 위한 기본 API로 설정하는 동시에 Istio API(Gateway, VirtualService, DestinationRule 등)를 당분간 계속 지원할 예정입니다.

쿠버네티스 네트워킹을 위한 공통 표준을 제공할 수 있는 게이트웨이 API 프로젝트의 잠재력에 대한 Red Hat의 기대감은 서비스 메쉬를 훨씬 뛰어넘습니다.

Red Hat은 현재 OpenShift Ingress 사용자가 게이트웨이 API Ingress Operator를 통해 서비스 메쉬와 독립적으로 배포할 수 있는 게이트웨이 API 기반 구현을 개발하고 있습니다. 이 작업과 게이트웨이 API에 대한 자세한 내용은 이 블로그 포스트 및 최신 업데이트에서 확인할 수 있습니다.

한편 3Scale API Management를 제공한 팀은 Kuadrant.io 프로젝트를 진행하고 있는데, 이 프로젝트는 Gateway API를 활용하여 외부 트래픽이 수신 게이트웨이로 들어오는 방법과 관련된 활용 사례를 처리합니다(예: 멀티클러스터 연결, 글로벌 부하 분산, 속도 제한, 권한 부여). 다음 블로그 포스트에서 이 프로젝트에 대한 정보를 확인해 보세요.

Kiali와 같은 Istio 애드온 시작하기

OpenShift Service Mesh 3.0의 주목할 만한 변경 사항은 쿠버네티스 Operator가 Istio만 관리한다는 것입니다. Kiali, 분산 추적, 지표와 같은 통합 기능은 독립적으로 설치되고 관리됩니다. 이로 인해 '시작하기' 경험에 몇 가지 단계가 추가되지만 이러한 구성 요소를 구성할 때 더 많은 모듈성과 유연성을 확보할 수 있다는 장점이 있습니다.

사용자가 빠르게 시작하고 실행할 수 있도록 Istioctl, 샘플 게이트웨이, Prometheus, Jaeger, Kiali를 사용하여 Istio를 설정하는 지침을 쿠버네티스 Operator README에 추가했습니다. 이를 통해 OpenShift Service Mesh 2.x에서 즉시 사용할 수 있도록 제공하는 것과 거의 동일한 데모/개발 환경을 제공합니다. 또한 Istio가 자체적으로 설치되고 애드온이 독립적으로 설치되는 OpenShift Service Mesh 3에서 제공할 계획인 설치 워크플로우에 대한 프리뷰를 제공합니다. 물론 지원되는 Service Mesh 3.0은 지원되는 Istioctl 배포판의 각 Istio 애드온에 대해 지원되는 제품의 쿠버네티스 Operator를 사용합니다. 이러한 커뮤니티 Istio 애드온 구성은 데모/개발 전용이며 프로덕션 환경에 사용해서는 안 됩니다.

Service Mesh 3.0 준비

OpenShift Service Mesh 2 사용자는 Service Mesh 3.0 도입을 준비하기 위해 몇 가지 사항을 미리 수행할 수 있습니다.

OpenShift Service Mesh 3는 계속 Istio를 기반으로 하며, 최종 사용자가 사용할 가능성이 높은 Istio의 안정적인 API는 변경되지 않을 것이라는 점에 유의해야 합니다. OpenShift Service Mesh 3에서 변경되고 마이그레이션이 필요한 항목은 ServiceMeshControlPlane, ServiceMeshMemberRoll, ServiceMeshMemberRoll과 같은 컨트롤 플레인 구성 리소스입니다. 이러한 리소스는 일반적으로 애플리케이션 소유자가 아닌 관리자 또는 플랫폼 팀이 관리합니다. Red Hat은 관리자가 기존 컨트롤 플레인 구성을 Service Mesh 3 구성으로 마이그레이션할 수 있는 방법을 계속 모색할 것입니다.

애플리케이션별 구성( VirtualServices, DestinationRules, PeerAuthentication 등의 Istio 리소스)은 변경되지 않습니다. 따라서 사용자는 OpenShift Service Mesh 3로 전환할 때 애플리케이션 또는 서비스별 구성을 마이그레이션할 필요 없이 OpenShift Service Mesh 2 사용을 시작하거나 확장할 수 있다는 확신을 가져야 합니다.

사용자는 OpenShift Service Mesh 3.0으로 더 쉽게 전환할 수 있도록 사전에 몇 가지 조치를 취할 수 있습니다. 최신 OpenShift Service Mesh 릴리스(2.4 이상)를 사용하는 것 외에 다음을 수행할 수 있습니다.

• Istio 컨트롤 플레인(Service Mesh 2.0의 기본값)이 아닌 애플리케이션을 사용하여 Istio 게이트웨이를 생성하고 관리하기 위해 게이트웨이 주입을 채택하거나 마이그레이션합니다. 위에서 설명한 대로 3.0의 컨트롤 플레인은 게이트웨이를 생성하지 않습니다.
• 여러 컨트롤 플레인이 필요하지 않은 경우 클러스터 전체 모드를 사용합니다. 이 모드를 사용하면 Istiod가 클러스터 수준 리소스로 실행됩니다. 이는 Service Mesh 3.0의 기본값이 되며, 새롭게 출시될 다중 컨트롤 플레인 기능을 사용하여 여러 컨트롤 플레인을 생성할 수 있습니다.
• 지표를 캡처하기 위해 OpenShift의 사용자 워크로드 모니터링 또는 Red Hat Advanced Cluster Management의 관측성을 사용하도록 서비스 메쉬를 구성합니다. 이렇게 하면 OpenShift Service Mesh 2.x와 함께 설치된 지표 스택(Service Mesh 3에서는 제거됨)보다 훨씬 더 구성과 확장이 자유로운 경고 기능과 함께 프로덕션 등급의 모니터링 스택을 제공합니다.
• ServiceMeshControlPlane 리소스 내에서 직접 구성하는 대신 외부에서 구성된 Kiali 및 Jaeger 리소스를 사용합니다. 이러한 리소스는 Kiali 및 Jaeger 관리를 위해 유연성이 더 뛰어날 뿐만 아니라 Service Mesh 3에서 독립적으로 구성됩니다.

각 주제에 대한 자세한 내용은 나중에 블로그 포스트를 통해 게시할 예정입니다.

OpenShift Service Mesh의 다음 단계

다음 릴리스는 2024년 초의 OpenShift Service Mesh 2.5(Istio 1.18 기반)가 될 예정입니다. 또한 Red Hat은 고객이 OpenShift Service Mesh 2에서 3로 업그레이드할 수 있도록 최소 1년의 중복 지원을 제공하기 위해 2024년에 Istio 1.20 이상을 기반으로 2.6 릴리스를 제공하기로 결정했습니다. 2.6 릴리스에서는 기술 프리뷰 상태에서도 OpenShift Service Mesh 3에 대한 피드백을 수집할 수 있는 추가 시간이 제공됩니다.

OpenShift Service Mesh 3의 경우 Istio 구성을 더 효과적으로 관리하기 위해 사용자 지정 리소스 정의를 조정하고 Istio 컨트롤 플레인의 카나리아 업그레이드를 더 효과적으로 지원하는 기능을 추가하는 등 새로운 쿠버네티스 Operator를 지속적으로 발전시키고 있습니다. 기술 프리뷰는 2024년 1분기 말을 목표로 하고 있으며, 2024년 하반기에 상용화될 예정입니다. 물론 이러한 목표는 변경될 수 있습니다. Red Hat은 OpenShift Service Mesh 3를 상용화할 때까지 OpenShift Service Mesh 2.x으로 고객을 계속 지원할 예정입니다.

Red Hat OpenShift Service Mesh에 대해 자세히 알아보려면 이 페이지를 방문해 보세요.