Anthos Service Mesh 1.12는 지원 종료되어 더 이상 지원되지 않습니다. 이전 버전에서 업그레이드를 참조하세요.

최신 문서를 보거나 사용 가능한 다른 버전을 선택합니다.

사용 가능한 버전

용어

이 페이지에서는 Anthos Service Mesh 문서에 사용되는 용어의 간략한 정의와 자세한 정보를 볼 수 있는 링크를 제공합니다.

A

Anthos 워크로드 아이덴티티: trust domain, namespace, service account의 튜플입니다. Anthos 워크로드 x509 인증서에 spiffe://<workload_identity_pool>/ns/<namespace>/sa/<serviceaccount>의 SPIFFE ID 형식이 있습니다. 다른 사용자 인증 정보 유형(예: OIDC 토큰)의 경우 형식은 다를 수 있습니다.

C

카나리아 클러스터 마이그레이션

카나리아 클러스터 마이그레이션은 Istio에서 Anthos Service Mesh로 마이그레이션하는 데 사용되는 일반적인 마이그레이션 전략으로, 별도의 새 클러스터에서 Anthos Service Mesh를 사용 설정합니다. Istio 1.11 이상을 관리형 Anthos Service Mesh로 마이그레이션 튜토리얼에서 카나리아 클러스터 마이그레이션 전략을 설명합니다. 클러스터 내 Anthos Service Mesh에서 관리형 Anthos Service Mesh로 마이그레이션할 때도 카나리아 클러스터 마이그레이션을 사용할 수 있습니다. 다른 일반적인 마이그레이션 전략은 카나리아 제어 영역 마이그레이션입니다.

카나리아 제어 영역 마이그레이션

카나리아 제어 영역 마이그레이션은 Istio에서 Anthos Service Mesh로 마이그레이션하는 데 사용되는 일반적인 마이그레이션 전략입니다. 여기서 Anthos Service Mesh는 Istio가 설치된 기존 클러스터에서 사용 설정됩니다. 마이그레이션은 데이터 영역에서 Anthos Service Mesh를 사용하도록 네임스페이스 라벨을 다시 지정하는 방식으로 구성됩니다. 클러스터 내 Anthos Service Mesh에서 관리형 Anthos Service Mesh로 마이그레이션할 때도 카나리아 클러스터 마이그레이션을 사용할 수 있습니다. 다른 일반적인 마이그레이션 전략은 카나리아 클러스터 마이그레이션입니다.

카나리아 업그레이드

버전 기반 업그레이드를 참조하세요.

표준 서비스

Anthos Service Mesh의 워크로드에 적용되는 라벨로, 하나 이상의 워크로드를 서비스 메시 내 논리적 서비스로 그룹화할 수 있습니다. 워크로드는 정확히 하나의 표준 서비스에 속하지만 여러 Kubernetes 서비스에 속할 수 있습니다. 표준 서비스는 이름과 네임스페이스로 식별되며, 하나 이상의 표준 버전으로 세분화할 수 있습니다.

제어 영역

제어 영역은 메시 또는 메시의 하위 집합을 구성하여 내부에서 워크로드 인스턴스 간의 통신을 관리하는 시스템 서비스의 집합입니다. Anthos Service Mesh 1.9 이상에서는 두 가지 제어 영역을 제공합니다.

Google 관리 제어 영역: 완전 관리형 Google Cloud 서비스입니다. 안정성, 업그레이드, 확장, 보안은 Google에서 처리됩니다. 관리형 Anthos Service Mesh는 Google 관리 제어 영역과 선택적 Google 관리 데이터 영역으로 구성됩니다.
클러스터 내 제어 영역: 클러스터에 설치하는 istiod의 Google 지원 배포입니다. istiod를 사용하여 Anthos Service Mesh를 설치할 때 보안 및 확장을 업그레이드하고 구성해야 합니다.

제어 영역은 구성을 사이드카 프록시에 배포하지만 메시에서 워크로드의 트래픽 처리에 직접 관여하지 않습니다.

D

데이터 영역: 데이터 영역은 메시의 일부로, 워크로드 인스턴스 간의 통신을 직접 처리합니다. Anthos Service Mesh의 데이터 영역은 사이드카로 배포된 프록시를 사용하여 메시 서비스가 보내고 받는 모든 TCP 트래픽을 중재하고 제어합니다. 관리형 Anthos Service Mesh는 Google 관리 데이터 영역을 제공합니다.

E

이그레스 게이트웨이: 이그레스 게이트웨이는 메시를 나가는 트래픽에 대해 전용 종료 노드를 구성할 수 있게 해주는 Envoy 프록시입니다. 게이트웨이 커스텀 리소스를 사용하여 프록시를 구성합니다. 이그레스 게이트웨이를 사용하면 외부 네트워크를 액세스할 수 있거나 액세스해야 하는 서비스를 제한할 수 있습니다. 자세한 내용은 게이트웨이 설치 및 업그레이드를 참조하세요.

F

Fleet: Fleet(이전에는 Environ이라 함)을 사용하면 클러스터를 구성하여 멀티 클러스터를 더욱 간편하게 관리할 수 있습니다. Fleet에 클러스터를 등록하면 ID, 네임스페이스, 서비스에 '동일성' 개념이 도입되어 멀티 클러스터 메시 관리가 간소화됩니다. 클러스터가 서로 다른 프로젝트에 있는 경우 클러스터가 생성된 프로젝트가 아닌 Fleet 호스트 프로젝트를 사용하여 클러스터를 등록해야 합니다. Fleet에 대한 자세한 내용은 Fleet 소개를 참조하세요.

H

하이드레이션된 매니페스트: 대상에 배포가 준비된 매니페스트입니다. 매니페스트를 하이드레이션하려면 일반적으로 Helm, Kustomize, kpt와 같은 도구를 사용하여 매니페스트의 변수 값을 설정합니다.

I

ID

ID는 보안 인프라의 기본적인 개념입니다. Anthos Service Mesh ID 모델은 최고 수준의 워크로드 아이덴티티를 기반으로 합니다. 서비스 간 통신이 시작될 때 두 당사자가 상호 인증을 위해 ID 정보가 포함된 사용자 인증 정보를 교환합니다.

클라이언트는 서버의 ID를 보안 이름 정보와 확인하여 서버에서 서비스 실행이 승인되었는지 확인합니다.

서버는 클라이언트의 ID를 확인하여 클라이언트가 액세스할 수 있는 정보를 파악합니다. 서버에서 구성된 승인 정책에 따라 액세스를 허용할지 여부를 결정합니다.

서버는 ID를 사용하여 특정 클라이언트가 액세스한 시간 및 정보를 감사할 수 있습니다. 또한 사용되는 서비스에 따라 클라이언트에게 비용을 청구할 수 있으며, 비용을 지불하지 않은 클라이언트의 서비스 액세스를 거부할 수도 있습니다.

Anthos Service Mesh ID 모델은 사람 사용자, 개별 서비스 또는 서비스 그룹을 나타낼 수 있을 만큼 유연하고 상세합니다. 최고 수준의 서비스 ID가 없는 플랫폼에서는 Anthos Service Mesh가 서비스 이름과 같은 서비스 인스턴스를 그룹핑할 수 있는 다른 ID를 사용할 수 있습니다.

Anthos Service Mesh는 다양한 플랫폼에서 다음과 같은 서비스 ID를 지원합니다.

Kubernetes: Kubernetes 서비스 계정
Google Kubernetes Engine: Google Cloud 서비스 계정
Google Cloud: Google Cloud 서비스 계정

인그레스 게이트웨이

인그레스 게이트웨이는 메시 외부에서 들어오는 트래픽을 처리하기 위해 부하 분산기로 작동하는 Envoy 프록시입니다. 게이트웨이 커스텀 리소스를 사용하여 부하 분산기를 구성하고, 수신 트래픽을 보호하고 워크로드로 라우팅하는 방법을 제어하는 가상 서비스 및 인증 정책을 만듭니다. 자세한 내용은 게이트웨이 설치 및 업그레이드를 참조하세요.

삽입

삽입 또는 자동 삽입은 생성 시 포드 사양을 수정하기 위한 변형 웹훅 사용을 나타냅니다. 삽입을 사용하여 메시 서비스에 대해 Envoy 프록시 사이드카 구성을 추가하거나 게이트웨이의 Envoy 프록시를 구성합니다.

인플레이스 업그레이드

인플레이스 업그레이드는 기존 제어 영역을 새로운 버전으로 바꿉니다. 권장사항에 따라 버전 기반 업그레이드가 권장됩니다.

istiod

istiod('daemon'의 'd')는 제어 영역 서비스를 제공하는 통합 모놀리식 바이너리입니다. Anthos Service Mesh 1.5 이전에는 제어 영역 서비스가 Pilot, Citadel, Mixer, Galley라는 별도의 구성요소에 의해 제공되었습니다.

IstioOperator

클러스터 내 제어 영역을 구성하는 데 사용하는 커스텀 리소스입니다. 자세한 내용은 선택적 기능 사용 설정을 참조하세요.

달러

관리형 인스턴스 그룹(MIG)

한 VM의 최소 MIG 크기로 시작하여 여러 개의 동일한 VM에서 애플리케이션을 운영할 수 있습니다. 자동 확장, 자동 복구, 리전(멀티 영역) 배포, 자동 업데이트 등의 자동화된 MIG 서비스를 활용하여 워크로드의 확장성 및 가용성을 높일 수 있습니다. 자세한 내용은 관리형 인스턴스 그룹(MIG)을 참조하세요.

매니페스트

포드, 배포, 서비스 또는 인그레스와 같은 Kubernetes 리소스를 생성, 수정, 삭제하는 데 사용되는 Kubernetes 구성 객체입니다. Anthos Service Mesh 문서에서는 제어 영역을 구성하는 데 사용하는 매니페스트를 오버레이 파일이라고 부릅니다.

매니페스트는 렌더링(하드레이션이라고도 함) 상태 또는 렌더링되지 않은 상태 중 하나로 존재합니다. 렌더링되지 않은 매니페스트는 대상에 배포할 준비가 되지 않은 것입니다. 매니페스트에 특정 값을 채우는 렌더링 프로세스는 주로 Helm, Kustomize, kpt 같은 도구에서 수행됩니다.

Mesh CA

mTLS 인증서를 관리하는 Google 관리형 인증 기관의 이름입니다. Mesh CA는 Google Cloud의 GKE 클러스터에 Anthos Service Mesh를 설치할 때 기본적으로 사용 설정되며 원하는 경우 VMware 또는 베어메탈용 GKE에 Anthos Service Mesh 1.10 이상을 설치할 때 Mesh CA를 사용 설정할 수 있습니다. 자세한 내용은 보안 개요를 참조하세요.

상호 TLS

Anthos Service Mesh는 메시의 서비스 간 인증 및 암호화에 상호 TLS(mTLS)를 사용합니다. mTLS를 사용하면 워크로드가 서로의 ID를 확인하고, 인증할 수 있습니다. 브라우저가 웹 서버를 신뢰하고 교환되는 데이터를 암호화할 수 있도록 HTTPS에서 간단한 TLS를 사용하는 것은 잘 알고 계실 것입니다. 단순한 TLS를 사용하면 클라이언트는 인증서를 확인하여 서버의 신뢰성을 확인합니다. mTLS는 클라이언트와 서버가 서로 인증서를 교환하여 ID를 확인하는 TLS 구현입니다.

N

네트워크: Anthos Service Mesh는 일반 연결을 기준으로 단순화된 네트워크 정의를 사용합니다. 워크로드 인스턴스는 게이트웨이 없이 직접 통신할 수 있는 경우 동일한 네트워크에 있습니다.

O

오버레이 파일: IstioOperator 커스텀 리소스(CR)가 포함된 YAML 파일입니다. 오버레이 파일을 사용하여 클러스터 내 제어 영역을 구성합니다. 기본 제어 영역 구성을 재정의하고 asmcli install에 전달하는 YAML 파일에서 지원되는 선택적 기능을 사용 설정할 수 있습니다. 오버레이를 더 많이 추가할 수 있으며 각 오버레이 파일은 이전 레이어의 구성을 재정의합니다. 기본적으로 사용 설정되지 않은 기능을 사용 설정하는 데 사용할 수 있는 YAML의 선택적 기능 사용 설정을 참조하세요.

P

기본 클러스터: 기본 클러스터는 제어 영역이 있는 클러스터입니다. 단일 메시는 고가용성을 위해 또는 지연 시간을 줄이기 위해 두 개 이상의 기본 클러스터를 가질 수 있습니다. Istio 1.7 문서에서는 다중 기본 배포를 복제된 제어 영역이라고 부릅니다.

R

원격 클러스터: 원격 클러스터는 클러스터 외부에 있는 제어 영역에 연결되는 클러스터입니다. 원격 클러스터는 기본 클러스터에서 실행되는 제어 영역 또는 외부 제어 영역에 연결할 수 있습니다.
수정 버전: 버전은 애플리케이션 코드 버전 및 구성의 시간 내 스냅샷을 나타냅니다. Anthos Service Mesh를 설치하거나 업그레이드할 때 버전 라벨이 제어 영역에 추가됩니다. 자동 사이드카 삽입을 사용 설정하려면 네임스페이스에 버전 라벨을 추가하고 Pod를 다시 시작합니다. 버전 라벨은 네임스페이스의 Pod를 특정 제어 영역 버전과 연결합니다.
버전 기반 업그레이드: OSS Istio에서 마이그레이션 및 업그레이드는 버전 기반 업그레이드 프로세스(Istio 문서의 '카나리아 업그레이드')를 따릅니다. 버전 기반 업그레이드에서는 새 버전의 제어 영역이 기존 제어 영역과 함께 설치됩니다. 그런 후 일부 워크로드를 새 버전으로 이동하여 모든 트래픽을 새 버전으로 마이그레이션 하기 전 워크로드 일부에서 업그레이드 효과를 모니터링합니다.

S

보안 이름: 서버 ID는 인증서에 인코딩되지만 서비스 이름은 검색 서비스 또는 DNS를 통해 검색됩니다. 보안 이름 정보는 서버 ID를 서비스 이름에 매핑합니다. ID A를 서비스 이름 B에 매핑하면 'A가 서비스 B를 실행할 권한이 있음'을 의미합니다. 제어 영역은 apiserver를 감시하고 보안 이름 매핑을 생성하고 사이드카 프록시에 안전하게 배포합니다.
서비스 메시: 서비스 메시 또는 간단히 메시는 워크로드 인스턴스 간에 관리형의 관측 가능한 보안 통신을 가능하게 해주는 인프라 레이어입니다.
사이드카: 워크로드와 함께 유틸리티 또는 도우미를 실행하기 위한 패턴입니다. Kubernetes를 사용하는 경우 사이드카가 포드의 워크로드 컨테이너와 함께 실행됩니다. 서비스 메시와 관련된 논의에서는 '사이드카'라는 단어가 프록시를 의미할 때가 종종 있습니다.

T

trust 도메인

trust 도메인은 시스템의 신뢰할 수 있는 루트에 해당하며 워크로드 아이덴티티의 일부입니다.

Anthos Service Mesh는 trust 도메인을 사용하여 메시 내의 모든 ID를 만듭니다. 예를 들어 SPIFFE ID spiffe://mytrustdomain.com/ns/default/sa/myname에서 하위 문자열 mytrustdomain.com은 워크로드가 mytrustdomain.com라는 트러트스 도메인에서 가져온 것임을 특정합니다.

Mesh CA를 사용할 경우 Anthos Service Mesh에서 trust 도메인을 자동으로 생성합니다. 클러스터의 워크로드 풀을 기반으로 합니다.

클러스터가 동일한 신뢰할 수 있는 루트를 공유하는 한 멀티 클러스터 메시에 하나 이상의 trust 도메인을 사용할 수 있습니다.

W

워크로드: 워크로드는 플랫폼에 실행되는 컨테이너화된 애플리케이션, 서비스, 기타 프로그램(예: 일괄 작업 또는 데몬)입니다. 이 플랫폼은 Kubernetes 클러스터, 가상 머신 또는 기타 환경(예: 베어메탈용 Google Distributed Cloud Virtual)일 수 있습니다. 워크로드에는 이름, 네임스페이스, 고유 ID가 있습니다. Kubernetes에서 워크로드는 일반적으로 배포에 해당하지만 StatefulSet와 같은 다른 유형의 워크로드도 있습니다.
WorkloadEntry: 메시에 포함되어야 하는 비 Kubernetes-Pod 엔드포인트를 설명하고 Kubernetes 포드와 동일하게 처리할 수 있습니다. 이 경우에는 각 VM이 메시에서 WorkloadEntry로 등록됩니다. 자세한 내용은 https://istio.io/latest/blog/2020/workload-entry/를 참조하세요.
WorkloadGroup: 워크로드 인스턴스의 컬렉션을 설명합니다. WorkloadGroup을 참조하세요.
워크로드 아이덴티티 풀: Anthos Service Mesh의 트러스트 도메인이라고도 하는 트러스트 경계입니다.