Anthos Service Mesh를 설치할 때 플랫폼마다 기본적으로 사용 설정되는 제어 영역 기능이 다릅니다. Anthos Service Mesh를 설치 (또는 업그레이드)할 때 overlay 파일을 포함하여 선택적 기능을 사용 설정합니다. 오버레이 파일은 제어 영역을 구성하는 데 사용되는 IstioOperator
커스텀 리소스(CR)를 포함하는 YAML 파일입니다. 기본 구성을 재정의하고 오버레이 파일에서 선택적 기능을 사용 설정할 수 있습니다. 오버레이를 더 많이 추가할 수 있으며 각 오버레이 파일은 이전 레이어의 구성을 재정의합니다.
오버레이 파일 정보
이 페이지의 오버레이 파일은 GitHub의 anthos-service-mesh
패키지에 있습니다. 이러한 파일에는 기본 구성에 대한 일반적인 맞춤설정이 포함되어 있습니다. 이 파일은 그대로 사용하거나 필요에 따라 추가로 변경할 수 있습니다.
istioctl install
명령어를 사용하여 Anthos Service Mesh를 설치할 때-f
명령줄 옵션으로 하나 이상의 오버레이 파일을 지정할 수 있습니다. 명령줄에서--set
옵션을 사용하여istioctl install
로 구성 매개변수를 지정하여 구성을 수정할 수 있지만, 다른 커스텀 리소스 파일과 함께 버전 제어 시스템에 파일을 저장할 수 있도록 오버레이 파일을 사용하는 것이 좋습니다. 업그레이드 후 제어 영역의 구성이 동일하게 유지되도록 Anthos Service Mesh를 업그레이드할 때 이 파일을 유지해야 합니다.Google에서 제공하는
install_asm
스크립트를 사용하여 Anthos Service Mesh를 설치할 때--option
또는--custom_overlay
옵션이 있는 하나 이상의 오버레이 파일을 지정할 수 있습니다.anthos-service-mesh
저장소의 파일을 변경할 필요가 없는 경우--option
을 사용할 수 있으며 스크립트가 자동으로 GitHub에서 파일을 가져옵니다. 그렇지 않으면 오버레이 파일을 변경한 후--custom_overlay
옵션을 사용하여install_asm
스크립트에 전달할 수 있습니다. 두 옵션을 모두 사용하는 예시는install_asm
예시를 참조하세요.
YAML 파일 하나에 여러 CR을 포함하지 않음 | 각 CR에 대해 별도의 YAML 파일 만들기 |
---|---|
anthos-service-mesh
패키지 다운로드
anthos-service-mesh
패키지를 다운로드하려면 다음 안내를 따르세요.
다음 단계에서는 kpt
를 사용하여 GitHub 저장소에서 asm
패키지를 다운로드합니다. 원하는 경우 git clone
을 대신 사용할 수 있습니다.
아직 설치하지 않았다면
kpt
를 설치합니다.gcloud components install kpt
다음 파일이 포함된 패키지를 다운로드합니다.
kpt pkg get \ https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.8-asm asm
다음 예시에서는
asm
패키지가 현재 작업 디렉터리에 있다고 가정합니다.
예시
Anthos Service Mesh 설치 시 이 기능을 사용 설정할 때 사용하는 명령어는 사용 중인 플랫폼과 install_asm
스크립트 또는 istioctl install
명령어 사용 여부에 따라 약간 다릅니다.
다음 모든 명령어는 istiod
에 버전 라벨을 설정합니다. istiod
배포 이름은 istiod-asm-186-8
로 설정되며 버전 라벨은 istio.io/rev=asm-186-8
형식입니다. 버전 라벨은 자동 사이드카 인젝터 웹훅에서 삽입된 사이드카를 특정 istiod
버전과 연결하는 데 사용됩니다. 네임스페이스에 사이드카 자동 주입을 사용 설정하려면 istiod
의 버전 라벨과 일치하는 버전으로 라벨을 지정합니다.
GKE On-Prem에서 이그레스 게이트웨이 사용 설정
이 예시에서는 온프레미스에 Anthos Service Mesh 설치 가이드의 단계를 따르고 Anthos Service Mesh 설치했다고 가정합니다.
이 가이드에는 CTX_CLUSTER1
환경 변수를 설정하고 cluster.yaml
를 구성하는 단계가 포함되어 있습니다. cluster.yaml
에서 구성하는 설정 중 하나는 버전입니다. egressgateways.yaml
파일에는 선택적 이그레스 게이트웨이를 사용 설정하기 위한 구성이 포함되어 있습니다.
VMware용 GKE에 Anthos Service Mesh를 설치합니다.
istioctl install --context="${CTX_CLUSTER1}" \ -f cluster.yaml \ -f asm/istio/options/egressgateways.yaml
VMware용 GKE 설치 가이드로 돌아가서 새 설치에 필요한 검증 웹훅을 구성해야 합니다.
명령줄에서 파일 순서는 중요합니다. 먼저 기본 기능에 필요한 구성이 있는 cluster.yaml
을 지정한 다음에 오버레이 파일을 지정합니다.
Google Cloud 기반 GKE에서 이그레스 게이트웨이 사용 설정
install_asm
스크립트를 사용하여 동일한 프로젝트에서 하나 이상의 클러스터를 설정하는 것이 좋습니다. 스크립트가 istiod
에 버전 라벨을 설정합니다.
이 예시에서는 GKE에서 Anthos Service Mesh 설치 가이드를 따라 Anthos Service Mesh 1.8.6를 설치하는 release-1.8-asm
분기에 install_asm
스크립트의 버전을 다운로드했다고 가정합니다.
install_asm
스크립트를 사용하여 이그레스 게이트웨이를 설치하려면 다음 안내를 따르세요.
./install_asm \
--project_id PROJECT_ID \
--cluster_name CLUSTER_NAME \
--cluster_location CLUSTER_LOCATION \
--mode install \
--enable_all \
--option egressgateways
이 명령어는 새 설치에 대한 스크립트를 실행하고 설치용 기본 CA인 Mesh CA를 사용 설정합니다. --enable_all
플래그를 사용하면 스크립트가 필요한 Google API를 사용 설정하고, Identity and Access Management 권한을 설정하고, 클러스터에 필요한 업데이트를 적용할 수 있습니다. 여기에는 GKE 워크로드 아이덴티티 사용 설정이 포함됩니다.
스크립트는 제어 영역을 구성하는 데 사용되는 GitHub에서 egressgateways.yaml
파일을 가져옵니다.
다른 프로젝트의 GKE 클러스터에서 이그레스 게이트웨이 사용 설정
현재 install_asm
스크립트는 다른 프로젝트의 클러스터에 Anthos Service Mesh 설치를 지원하지 않습니다.
다음 명령줄에서는 멀티 프로젝트 설치 및 마이그레이션의 모든 단계를 따른 후 Anthos Service Mesh를 설치하는 단계로 넘어왔다고 가정합니다.
Anthos Service Mesh 설치:
istioctl install \ -f asm/istio/istio-operator.yaml \ -f asm/istio/options/multiproject.yaml \ -f asm/istio/options/multicluster.yaml\ -f asm/istio/options/egressgateways.yaml \ --set revision=asm-186-8
다음 파일은
istio-operator.yaml
파일의 설정을 오버레이합니다.multiproject.yaml
파일은 멀티 프로젝트 메시의 기본 기능을 지정하는 데 사용됩니다. 다른 오버레이 파일보다 먼저 지정해야 합니다.multicluster.yaml
파일은 Anthos Service Mesh 멀티 클러스터 구성에 필요한 설정을 구성합니다.egressgateways.yaml
파일은 이그레스 게이트웨이를 구성합니다.
다중 프로젝트 설치 가이드로 돌아가서 새 설치에 필요한 유효성 검증 웹훅을 구성해야 합니다.
선택 기능의 YAML
다음 섹션에서는 선택적 및 지원되는 기능을 사용 설정하기 위한 YAML을 제공합니다.
mTLS STRICT
모드
업그레이드 문제를 방지하고 더 유연한 설치를 제공하기 위해 global.mtls.enabled
구성이 삭제되었습니다. STRICT
mTLS를 사용 설정하려면 대신 피어 인증 정책을 구성하세요.
Envoy를 stdout로 전달
자세한 내용은 Envoy의 액세스 로깅 사용 설정을 참조하세요.
Cloud Trace
GKE에서 설치 시 Cloud Trace를 사용 설정할 수 있습니다. 자세한 가격 책정 정보는 Cloud Trace 가격 책정 페이지를 참조하세요.
기본 샘플링 레이트는 1%이지만 tracing.sampling
값을 지정하여 기본값을 재정의할 수 있습니다. 값은 0.0에서 100.0 사이여야 하며 정밀도는 0.01입니다. 예를 들어 요청 10,000개마다 5개의 요청을 추적하려면 0.05를 사용합니다.
다음 예시는 샘플링 레이트 100%를 보여줍니다(데모 또는 문제 해결 목적으로만 수행).
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
meshConfig:
enableTracing: true
defaultConfig:
tracing:
sampling: 100
values:
global:
proxy:
tracer: stackdriver
참고로, 현재 추적기 구성은 프록시 부트스트랩 구성의 일부이므로 포드를 다시 시작하고 다시 주입받아 추적기 업데이트를 선택해야 합니다. 예를 들어 재시작 포드가 배치에 속하는 다음 명령어를 사용할 수 있습니다.
kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME
Trace 컨텍스트 전파
사이드카 프록시는 trace 스팬을 자동으로 전송할 수 있지만 전체 trace를 서로 결합하려면 약간의 힌트가 필요합니다. 프록시가 스팬 정보를 전송할 때 스팬이 단일 trace에 올바르게 연결될 수 있도록 하려면 애플리케이션이 관련 HTTP 헤더를 전파해야 합니다.
이렇게 하려면 애플리케이션이 수신 요청에서 송신 요청까지 다음 헤더를 수집하고 전파해야 합니다.
- x-request-id
- x-b3-traceid
- x-b3-spanid
- x-b3-parentspanid
- x-b3-sampled
- x-b3-flags
- x-ot-span-context
- x-cloud-trace-context
- traceparent
- grpc-trace-bin
헤더를 전파하는 예시는 Trace 컨텍스트 전파를 참조하세요.
커스텀 ID가 있는 클라이언트에서 trace 만들기
커스텀 ID로 클라이언트에서 trace를 만들려면 curl
명령어를 사용하여 외부 클라이언트로 요청을 만들고 trace를 강제로 표시합니다. 예를 들면 다음과 같습니다.
curl $URL --header "x-client-trace-id: 105445aa7843bc8bf206b12000100000"
x-client-trace-id
에 대한 자세한 내용은 Envoy 문서를 확인하세요.
이그레스 게이트웨이를 통한 이그레스
자세한 내용은 이그레스 게이트웨이를 참조하세요.
Istio 컨테이너 네트워크 인터페이스
Istio 컨테이너 네트워크 인터페이스(CNI)를 사용 설정하는 방법은 Anthos Service Mesh가 설치된 환경에 따라 달라집니다. 또한 네트워크 정책을 사용 설정해야 합니다.
GKE에서 CNI 사용 설정
VMware용 GKE에서 CNI 사용 설정
내부 부하 분산기 사용 설정
GKE에 설치하는 경우 Istio 인그레스 게이트웨이에 대한 내부 부하 분산기를 사용 설정할 수 있습니다.
인그레스 게이트웨이의 외부 인증서 관리
Envoy SDS를 사용하여 인그레스 게이트웨이에서 외부 인증서 관리를 사용 설정하는 방법에 대한 자세한 내용은 보안 게이트웨이를 참조하세요.