용어

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

C

제어 영역

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

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

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

D

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

F

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

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 서비스 계정

istiod

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

IstioOperator

제어 영역을 구성하는 데 사용하는 커스텀 리소스입니다. 자세한 내용은 Istio 문서의 IstioOperator를 참조하세요.

M

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

N

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

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

P

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

R

원격 클러스터: 원격 클러스터는 클러스터 외부에 있는 제어 영역에 연결되는 클러스터입니다. 원격 클러스터는 기본 클러스터에서 실행되는 제어 영역 또는 외부 제어 영역에 연결할 수 있습니다.
수정 버전: 버전은 애플리케이션 코드 버전 및 구성의 시간 내 스냅샷을 나타냅니다. Anthos Service Mesh를 설치하거나 업그레이드하는 경우 버전을 식별하는 버전 라벨이 istiod에 추가됩니다. 자동 사이드카 삽입을 사용 설정하려면 네임스페이스에 버전 라벨을 추가하고 Pod를 다시 시작합니다. 버전 라벨은 새 제어 영역으로 안전하게 업그레이드하고 문제가 발생할 경우 원래 버전으로 롤백할 수 있도록 네임스페이스의 Pod를 특정 istiod 버전과 연결하는 데 사용합니다.

S

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

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 도메인을 자동으로 생성합니다. 이는 project-id.svc.id.goog 또는 project-id.hub.id.goog 형식의 클러스터 워크로드 풀을 기반으로 합니다.

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

W

워크로드: 워크로드는 플랫폼에 실행되는 컨테이너화된 애플리케이션, 서비스, 기타 프로그램(예: 일괄 작업 또는 데몬)입니다. 이 플랫폼은 Kubernetes 클러스터, 가상 머신 또는 기타 환경(예: 베어메탈용 Google Distributed Cloud Virtual)일 수 있습니다. 워크로드에는 이름, 네임스페이스, 고유 ID가 있습니다. Kubernetes에서 워크로드는 일반적으로 배포에 해당하지만 StatefulSet와 같은 다른 유형의 워크로드도 있습니다.