Istio on GKE 업그레이드

이 가이드에는 특정 업그레이드 지침이 포함된 모든 출시 버전에 대한 업그레이드 노트가 포함되어 있습니다. 이 가이드에 설명되지 않은 업그레이드의 경우 특별한 작업을 수행할 필요가 없습니다.

Istio 1.1.3에서 업그레이드

Istio on GKE 부가기능 버전 1.1.3-gke.0에는 PodDisruptionBudget(PDB) 정의가 있습니다. 이 정의에서는 사용 가능한 복제본 수가 최소 1 이상이어야 합니다. 버전 1.1.7-gke.0부터는 부가기능에 이 요구사항이 더 이상 없습니다. 하지만 이 PDB가 설치된 후에는 PDB를 위반할 경우 다른 버전으로의 업그레이드가 방지됩니다. 즉, 1.1.3-gke.0에서 더 높은 버전 1.1.x(예: 1.1.7-gke.0)로 업그레이드하려면 먼저 모든 Istio HorizontalPodAutoscaler 리소스에 대해 minReplicas 값을 2 이상으로 늘려야 합니다. 그렇지 않으면 PodDisruptionBudget 위반으로 인해 업그레이드가 실패합니다.

Istio 1.1로 업그레이드

1.0.x에서 1.1.x로 GKE 클러스터를 업그레이드하려면 먼저 해당 구성이 1.1과 호환되는지 확인해야 합니다. Istio 1.1의 다음 변경사항은 잠재적으로 하위 호환성을 가지며, 중단 또는 예상치 않은 동작을 방지하기 위해 구성을 업데이트해야 할 수 있습니다. 구성 확인을 위해 업그레이드 스크립트를 실행하는 것이 좋습니다.

주석을 통한 TLS 동작 재정의

1.0에서는 주석을 통해 TLS 정책을 수정합니다. 1.1에서는 이러한 주석이 작동하지 않으며, 대신 Policy 및 DestinationRule을 구성해야 합니다. 자세한 내용은 Istio 문서를 참조하세요.

업그레이드 프로세스

Istio 문서에 따라 주석을 Policy 및 DestinationRule로 바꿉니다. 이 변경은 1.0 구성을 중단시키지 않습니다. 1.1로 업그레이드한 후에는 이전 주석이 효과가 없으며, 따라서 이전 주석을 삭제하거나 그대로 둘 수도 있습니다.

RbacConfig에서 ClusterRbacConfigㄹ로 이름 변경

RbacConfig CRD 이름이 ClusterRbacConfig로 변경되었습니다. 스키마는 변경되지 않았습니다.

업그레이드 프로세스

모든 RbacConfig CR에 대해 동일한 ClusterRbacConfig CR을 만듭니다.

대상 규칙 우선 적용

서비스로 사이드카 라우팅하는 중에는 사이드카와 동일한 네임스페이스에 있는 대상 서비스에 대한 대상 규칙이 우선 적용되고, 이후 서비스 네임스페이스에 있는 대상 규칙이 적용되고, 마지막으로 다른 네임스페이스에 있는 대상 규칙이 적용됩니다(있는 경우).

업그레이드 프로세스

DestinationRules에서 동일한 대상 서비스에 대해 여러 네임스페이스의 규칙이 포함되어 있는지 확인합니다. 그렇다면 규칙을 자세히 조사하여 얼마나 겹치는지 확인하고, 원하는 동작을 위해 올바른 우선 순위로 적용되는지 확인합니다.