클러스터 내 제어 영역에서 선택 기능 사용 설정
이 페이지에서는 클러스터 내 제어 영역에서 선택적 기능을 사용 설정하는 방법을 설명합니다. 관리형 제어 영역은 관리형 Anthos Service Mesh 구성을 참조하세요.
Anthos Service Mesh를 설치할 때 기본적으로 사용 설정되는 기능은 플랫폼에 따라 다릅니다. Anthos Service Mesh를 설치(또는 업그레이드)할 때 오버레이 파일을 포함하여 선택적 기능을 사용 설정합니다. 오버레이 파일은 제어 영역을 구성하는 데 사용되는 IstioOperator 커스텀 리소스(CR)를 포함하는 YAML 파일입니다. 오버레이 파일에서 기본 구성을 재정의하고 선택적 기능을 사용 설정하거나 기본 기능을 사용 중지할 수 있습니다. 오버레이 파일당 하나의 기능을 지정합니다. 오버레이를 더 많이 추가할 수 있으며 각 오버레이 파일은 이전 레이어의 구성을 재정의합니다.
오버레이 파일 정보
이 페이지의 오버레이 파일은 GitHub의 anthos-service-mesh 패키지에 있습니다. 이러한 파일에는 기본 구성에 대한 일반적인 맞춤설정이 포함되어 있습니다. 이 파일은 그대로 사용하거나 필요에 따라 추가로 변경할 수 있습니다.
Google에서 제공하는 asmcli 스크립트를 사용하여 Anthos Service Mesh를 설치할 때 --option 또는 --custom_overlay 옵션이 있는 하나 이상의 오버레이 파일을 지정할 수 있습니다. anthos-service-mesh 저장소의 파일을 변경할 필요가 없는 경우 --option을 사용할 수 있으며 스크립트가 자동으로 GitHub에서 파일을 가져옵니다. 그렇지 않으면 오버레이 파일을 변경한 후 --custom_overlay 옵션을 사용하여 asmcli에 전달할 수 있습니다.
| 오버레이 파일 하나에 여러 CR을 포함하지 않음 | 각 CR에 대해 별도의 오버레이 파일 만들기 |
|---|---|
 |
 |
선택 기능을 사용 설정하는 방법
다음 예시는 간단한 방식으로 커스텀 오버레이만 사용하여 선택적인 기능을 사용 설정하는 방법을 보여줍니다. OTHER_FLAGS를 기타 명령줄 옵션으로 바꿉니다.
asmcli install 명령어는 선택 기능을 사용 설정하기 위해 두 가지 방법을 제공합니다. 사용하는 방법은 오버레이 파일을 변경해야 하는지 여부에 따라 달라집니다.
오버레이 파일에 변경사항을 적용할 필요가 없으면
--option을 사용합니다.--option을 사용할 경우asmcli이 GitHub 저장소에서 파일을 가져오므로, 인터넷 연결이 필요합니다../asmcli install \ OTHER_FLAGS \ --option OPTION_NAMEOPTION_NAME을 사용 설정하려는 옵션으로 바꿉니다. 옵션 목록은anthos-service-mesh패키지를 참조하세요.오버레이 파일을 맞춤설정해야 하는 경우에는
--custom_overlay를 사용합니다../asmcli install \ OTHER_FLAGS \ --custom_overlay PATH_TO_FILEPATH_TO_FILE를 사용할 오버레이 파일의 경로로 바꿉니다.
선택 기능의 YAML
다음 섹션에서는 선택적 및 지원되는 기능을 사용 설정하기 위한 YAML을 제공합니다.
mTLS STRICT 모드
업그레이드 문제를 방지하고 더 유연한 설치를 제공하기 위해 global.mtls.enabled 구성이 IstioOperator CR에서 삭제되었습니다.
STRICT mTLS를 사용 설정하려면 대신 피어 인증 정책을 구성하세요.
Distroless 프록시 이미지
컨테이너 런타임의 콘텐츠를 필요한 패키지로만 제한하는 것이 좋습니다. 이 접근 방법은 CVE(Common Vulnerabilities and Exposure) 스캐너의 보안과 신호 대 잡음비를 향상시킵니다. Istio는 distroless 기본 이미지를 기반으로 프록시 이미지를 제공합니다.
다음 구성은 전체 Anthos Service Mesh에 대해 distroless 이미지를 사용 설정합니다. 이미지 유형 변경이 적용되려면 각 포드가 다시 시작되고 다시 삽입되어야 합니다.
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
meshConfig:
defaultConfig:
image:
imageType: distroless
distroless 이미지에는 프록시 이외의 바이너리가 포함되지 않습니다. 따라서 셸을 exec하거나 컨테이너 내에서 curl, ping 또는 기타 디버그 유틸리티를 사용할 수 없습니다. 셸을 실행하려고 하면 다음 오류가 표시됩니다.
error: Internal error occurred: error executing command in container: failed to exec in container: failed to start exec "<container-id>"
OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "sh": executable file not found in $PATH: unknown
특정 포드의 이러한 도구에 액세스해야 하는 경우 다음 포드 주석을 사용하여 imageType을 재정의할 수 있습니다.
sidecar.istio.io/proxyImageType: debug
주석을 통해 배포 이미지 유형을 변경한 후에는 배포를 다시 시작해야 합니다.
kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME
대부분의 프록시 디버깅 유형에서는 디버그 기본 이미지가 필요 없는 istioctl proxy-cmd를 사용해야 합니다.
커스텀 레지스트리에 커스텀 오버레이 사용
커스텀 Container Registry에서 Anthos Service Mesh를 설치해야 하는 경우 커스텀 레지스트리에 커스텀 오버레이를 사용할 수 있습니다. 예를 들면 다음과 같습니다.
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
hub: {private_registry_url}
다음은 커스텀 Container Registry에 미러링해야 하는 Anthos Service Mesh의 이미지 목록입니다.
- Install-cni -
gcr.io/gke-release/asm/install-cni:1.14.6-asm.16 - 관리형 데이터 영역 -
gcr.io/gke-release/asm/mdp:1.14.6-asm.16 - 파일럿 -
gcr.io/gke-release/asm/pilot:1.14.6-asm.16 - Proxyv2 -
gcr.io/gke-release/asm/proxyv2:1.14.6-asm.16
비공개 레지스트리에 이미지 추가
Anthos Service Mesh 이미지를 비공개 레지스트리로 내보내려면 다음 단계를 완료하세요.
-
Anthos Service Mesh 이미지를 가져옵니다.
docker pull gcr.io/gke-release/asm/install-cni:1.14.6-asm.16 docker pull gcr.io/gke-release/asm/mdp:1.14.6-asm.16 docker pull gcr.io/gke-release/asm/pilot:1.14.6-asm.16 docker pull gcr.io/gke-release/asm/proxyv2:1.14.6-asm.16
-
비공개 레지스트리 URL의 변수를 만듭니다.
export PRIVATE_REGISTRY_URL=PRIVATE_REGISTRY_URL
PRIVATE_REGISTRY_URL을 비공개 레지스트리 URL로 바꿉니다. -
비공개 레지스트리 URL로 이미지에 태그를 지정합니다.
docker tag gcr.io/gke-release/asm/install-cni:1.14.6-asm.16 \ ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/install-cni:1.14.6-asm.16 docker tag gcr.io/gke-release/asm/mdp:1.14.6-asm.16 \ ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/mdp:1.14.6-asm.16 docker tag gcr.io/gke-release/asm/pilot:1.14.6-asm.16 \ ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/pilot:1.14.6-asm.16 docker tag gcr.io/gke-release/asm/proxyv2:1.14.6-asm.16 \ ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/proxyv2:1.14.6-asm.16 - 태그가 지정된 이미지를 비공개 레지스트리로 내보냅니다.
docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/install-cni:1.14.6-asm.16 docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/mdp:1.14.6-asm.16 docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/pilot:1.14.6-asm.16 docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/proxyv2:1.14.6-asm.16 - (선택사항) 표준 서비스를 사용하는 경우 표준 서비스 이미지를 비공개 레지스트리에 추가합니다.
- Anthos Service Mesh 표준 서비스 이미지를 가져옵니다.
docker pull gcr.io/kubebuilder/kube-rbac-proxy:v0.5.0 docker pull gcr.io/gke-release/asm/canonical-service-controller:1.10.3-asm.16 - 비공개 레지스트리 URL로 이미지에 태그를 지정합니다.
docker tag gcr.io/kubebuilder/kube-rbac-proxy:v0.5.0 \ ${PRIVATE_REGISTRY_URL}/gcr.io/kubebuilder/kube-rbac-proxy:v0.5.0 docker tag gcr.io/gke-release/asm/canonical-service-controller:1.10.3-asm.16 \ ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/canonical-service-controller:1.10.3-asm.16 - 태그가 지정된 이미지를 비공개 레지스트리로 내보냅니다.
docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/kube-rbac-proxy:v0.5.0 docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/canonical-service-controller:1.10.3-asm.16
- Anthos Service Mesh 표준 서비스 이미지를 가져옵니다.
비공개 레지스트리에서 태그가 지정된 이미지를 가져올 수 있다면 절차가 성공적으로 완료된 것입니다.
Envoy를 stdout로 전달
자세한 내용은 Envoy의 액세스 로깅 사용 설정을 참조하세요.
Cloud Trace
Cloud Trace는 다음 플랫폼에서 Anthos Service Mesh 설치와 함께 사용할 수 있습니다.
- Google Cloud 기반 GKE
- GKE Enterprise Service Mesh 인증 기관(Mesh CA)으로 설치하는 경우 온프레미스 Anthos 클러스터
자세한 가격 책정 정보는 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 헤더를 전파해야 합니다.
이를 위해 애플리케이션이 수신 요청에서 송신 요청까지 적절한 헤더를 수집하고 전파해야 합니다. Anthos Service Mesh Stackdriver 추적 구성은 다음의 헤더 형식 중 하나를 허용하며, 다음과 같은 모든 형식을 전파합니다.
- B3(
x-b3-traceid,x-b3-spanid,x-b3parentspanid,x-b3-sampled,x-b3-flags) - W3C TraceContext(
traceparent) - Google Cloud Trace(
x-cloud-trace-context) - gRPC TraceBin(
grpc-trace-bin)
즉, 애플리케이션은 이러한 형식을 사용하여 추적 컨텍스트를 전파할 수 있으며 트레이스가 생성되고 Stackdriver로 적절하게 설정됩니다.
예시
다음은 원래 요청에 traceparent 헤더가 있는 HTTP-Get 요청의 예시입니다. 프록시에서 추가한 trace 컨텍스트 헤더를 확인하십시오.
$ kubectl exec -it sleep-557747455f-n6flv -- curl "httpbin:8000/anything?freeform=" -H "accept: application/json" -H "Traceparent: 00-7543d15e09e5d61801d4f74cde1269b8-604ef051d35c5b3f-01" -vv
* Trying 10.12.3.52:8000...
* Connected to httpbin (10.12.3.52) port 8000 (#0)
> GET /anything?freeform= HTTP/1.1
> Host: httpbin:8000
> User-Agent: curl/7.80.0-DEV
> accept: application/json
> Traceparent: 00-7543d15e09e5d61801d4f74cde1269b8-604ef051d35c5b3f-01
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< server: envoy
< date: Wed, 10 Nov 2021 20:36:04 GMT
< content-type: application/json
< content-length: 1032
< access-control-allow-origin: *
< access-control-allow-credentials: true
< x-envoy-upstream-service-time: 5
<
{
"args": {
"freeform": ""
},
"data": "",
"files": {},
"form": {},
"headers": {
"Accept": "application/json",
"Grpc-Trace-Bin": "AAB1Q9FeCeXWGAHU90zeEmm4AaDHmGRtdM7wAgE",
"Host": "httpbin:8000",
"Traceparent": "00-7543d15e09e5d61801d4f74cde1269b8-a0c798646d74cef0-01",
"User-Agent": "curl/7.80.0-DEV",
"X-B3-Sampled": "1",
"X-B3-Spanid": "a0c798646d74cef0",
"X-B3-Traceid": "7543d15e09e5d61801d4f74cde1269b8",
"X-Cloud-Trace-Context": "7543d15e09e5d61801d4f74cde1269b8/11585396123534413552;o=1",
"X-Envoy-Attempt-Count": "1",
"X-Forwarded-Client-Cert": "<REDACTED>"
},
"json": null,
"method": "GET",
"origin": "127.0.0.6",
"url": "http://httpbin:8000/anything?freeform="
}
반환된 요청 헤더 집합에는 전체 trace 컨텍스트 헤더 집합이 있습니다.
헤더를 전파하는 자세한 예시는 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 사용 설정
CNI 온프레미스 사용 설정
Google Cloud 외부에서 Google Cloud Observability 사용 설정
Google Cloud 외부에서 Istio CA가 포함된 Anthos Service Mesh를 설치하면 기본적으로 Prometheus에 측정항목이 보고됩니다. Anthos Service Mesh 대시보드를 사용할 수 있도록 이 옵션을 사용하여 대신 Google Cloud Observability에 측정항목을 보고하거나 Prometheus 및 Stackdriver 모두를 사용 설정합니다.
Stackdriver만
Stackdriver 및 Prometheus
내부 부하 분산기 사용 설정
게이트웨이 설치 및 업그레이드에 설명된 대로 삽입된 게이트웨이를 설치하여 GKE에 내부 부하 분산기를 설정하는 것이 좋습니다. 게이트웨이 서비스를 구성할 때 networking.gke.io/load-balancer-type: "Internal" 주석을 포함합니다.
인그레스 게이트웨이의 외부 인증서 관리
Envoy SDS를 사용하여 인그레스 게이트웨이에서 외부 인증서 관리를 사용 설정하는 방법에 대한 자세한 내용은 보안 게이트웨이를 참조하세요.