이 페이지에서는 GKE(Google Kubernetes Engine)의 Anthos Service Mesh에 Compute Engine 가상 머신(VM)을 추가하는 방법에 대해 설명합니다. 이 페이지에는 VM을 추가하기 위해 클러스터를 준비하는 옵션과 함께 Anthos Service Mesh 1.11.8를 설치하는 방법이 나와있습니다.
Anthos Service Mesh 1.9 or a 1.10 patch release가 이미 설치된 경우 이 페이지에서는 VM 추가에 필요한 옵션과 함께 Anthos Service Mesh 1.11.8로 업그레이드하는 방법을 보여줍니다.
Anthos Service Mesh 1.9가 있고 업그레이드하지 않으려면 Anthos Service Mesh 1.9 가이드에서 Anthos Service Mesh 1.9에 VM 추가 안내를 참조하세요.
이전 버전의 Anthos Service Mesh가 있으면 먼저 1.9 이상으로 Anthos Service Mesh를 업그레이드해야 합니다.
이 페이지에서는 클러스터 내 제어 영역 또는 Google 관리 제어 영역을 설치하기 위한 명령줄을 제공합니다.
소개
Anthos Service Mesh를 사용하면 메시의 Google Kubernetes Engine(GKE) 클러스터에서 실행되는 서비스와 함께 관리형 인스턴스 그룹(MIG)에서 실행되는 서비스를 관리, 관측, 보호할 수 있습니다. 이를 통해 메시에서 Compute Engine 인스턴스에 다음을 수행할 수 있습니다.
- 트래픽을 관리합니다.
- mTLS를 시행합니다.
- 서비스 트래픽에 액세스 제어를 적용합니다.
- Google Cloud 서비스에 안전하게 액세스합니다.
- 측정항목, 로깅, 추적 데이터를 수집합니다.
- Google Cloud Console을 사용하여 서비스를 모니터링합니다.
이렇게 하면 컨테이너화가 적합하지 않거나 준비되지 않은 기존 애플리케이션에서 Anthos Service Mesh 기능을 활용할 수 있으며, 해당 워크로드를 나머지 서비스와 통합할 수 있습니다.
작동 방식
Anthos Service Mesh는 가상 머신 워크로드를 나타내기 위해 다음과 같이 두 가지 CRD(커스텀 리소스 정의)를 제공합니다.
WorkloadGroup
은 공통 속성을 공유하는 가상 머신 워크로드의 논리적 그룹을 나타냅니다. 이것은 Kubernetes의 배포와 비슷합니다.WorkloadEntry
는 가상 머신 워크로드의 단일 인스턴스를 나타냅니다. 이것은 Kubernetes의 포드와 비슷합니다.- 그러면
Service
는WorkloadGroup
을 선택하고 Anthos Service Mesh가Pod
와 유사한 방식으로 VM 인스턴스로 트래픽을 라우팅하도록 할 수 있습니다. 이렇게 하면 VM이 메시의 다른 워크로드처럼 작동할 수 있습니다.
각 Compute Engine 인스턴스 그룹에 대해 Compute Engine 인스턴스 템플릿을 만듭니다. 이 템플릿은 해당 그룹에 있는 각 Compute Engine 인스턴스에 대해 서비스 프록시 에이전트를 지정합니다. 설치 중 에이전트는 서비스 프록시를 부트스트랩하고, 트래픽 가로채기를 설정하고, Compute Engine 인스턴스의 수명 주기 동안 서비스 프록시 상태를 모니터링합니다. 프록시는 Anthos Service Mesh 제어 영역과 연결되고, 그런 후 각 Compute Engine 인스턴스를 해당 WorkloadGroup에 대한 WorkloadEntry로 자동으로 등록합니다. 이렇게 해서 클러스터의 Kubernetes 포드와 같이 Anthos Service Mesh가 각 인스턴스를 서비스 엔드포인트로 취급할 수 있습니다. 또한 Kubernetes 포드에서와 같이 VM 워크로드에 대해 Kubernetes 서비스를 만들 수 있습니다.
최소 MIG 크기 0부터 시작하여 Compute Engine 인스턴스에서 워크로드 수를 수평 확장하려면 인스턴스 그룹 자동 확장을 참조하세요.
서비스 프록시 에이전트는 VM Manager를 사용하여 에이전트가 MIG의 각 VM에 설치되었는지 확인합니다. 인스턴스 그룹 및 VM 관리에 대한 자세한 내용은 관리형 인스턴스 그룹(MIG) 및 VM Manager를 참조하세요.
지원되는 Linux 배포판
OS 버전 | 지원 |
---|---|
Debian 10 | |
Debian 9 | |
Centos 8 | |
Centos 7 |
OS 배포에 대한 자세한 내용은 Debian 지원 또는 CentOS 지원을 참조하세요.
제한사항
- 메시 제어 영역은 Anthos Service Mesh 1.9 이상이어야 합니다.
- Compute Engine 인스턴스 템플릿에서 생성된 Compute Engine 관리형 인스턴스 그룹만 지원됩니다.
- 클러스터 및 VM은 동일한 네트워크, 동일한 프로젝트에 있어야 하며, 단일 네트워크 인터페이스를 사용해야 합니다.
- Anthos 구독 없이도 이 기능을 사용할 수 있지만 Google Cloud Console의 특정 UI 요소 및 기능은 Anthos 구독자에게만 제공됩니다. 구독자와 비구독자가 사용할 수 있는 항목에 대한 상세 설명은 Anthos 및 Anthos Service Mesh UI 차이점을 참조하세요.
- Google 관리 제어 영역 및 Google 관리 데이터 영역을 모두 클러스터에 배포할 수 있지만 Google 관리 데이터 영역은 VM의 프록시를 관리하지 않습니다.
기본 요건
시작하기 전에 다음 사항을 확인하세요.
기본 요건에 설명된 Cloud 프로젝트, Anthos 라이선스, 일반 요구사항을 검토하세요.
클러스터 요구사항
계속하기 전에 클러스터가 GKE 요구사항을 충족하는지 확인합니다. 또한 Anthos Service Mesh VM 지원에는 다음이 필요합니다.
- Anthos Service Mesh를 설치할 때 Mesh CA를 인증 기관(CA)으로 지정합니다.
- 원격 분석을 위해 Stackdriver를 재정의하지 않습니다. Stackdriver는 Anthos Service Mesh를 설치할 때 기본적으로 구성됩니다.
- 클러스터가 Fleet에 등록됩니다. 하지만 클러스터가 등록되지 않았으면 VM 설치 프로세스가 지정된 프로젝트에 클러스터를 등록합니다.
시작하기
시작하기의 단계에 따라 다음 작업을 수행하세요.
Anthos Service Mesh를 설치하지 않았으면 다음 섹션을 계속 진행합니다. 기존 Anthos Service Mesh 설치가 있으면 기존 설치의 단계를 따릅니다.
새 설치
Anthos Service Mesh 1.11 제어 영역을 준비하여 VM에 대해 Anthos Service Mesh 클러스터를 설정합니다. 실행하는 명령어는 클러스터에 설치하려는 Anthos Service Mesh 제어 영역 유형에 따라 달라집니다.
클러스터 내
다음 명령어는 VM을 추가할 수 있도록 제어 영역을 준비하는 --option vm
으로 Anthos Service Mesh 클러스터 내 제어 영역을 설치하는 방법을 보여줍니다.
./asmcli install \
--project_id PROJECT_ID \
--cluster_name CLUSTER_NAME \
--cluster_location CLUSTER_LOCATION \
--output_dir DIR_PATH \
--enable_all \
--ca mesh_ca \
--option vm
--project_id
,--cluster_name
,--cluster_location
: 클러스터가 있는 프로젝트 ID, 클러스터 이름, 클러스터 영역 또는 리전을 지정합니다.--output_dir
asmcli
가anthos-service-mesh
패키지를 다운로드하고 설치 파일을 추출하며,istioctl
, 샘플, 매니페스트가 포함되는 디렉터리를 지정하려면 이 옵션을 포함합니다. 그렇지 않으면asmcli
가 파일을tmp
디렉터리에 다운로드합니다. 상대 경로 또는 전체 경로를 지정할 수 있습니다. 여기서 환경 변수$PWD
는 작동하지 않습니다.--enable_all
: 스크립트의 다음 작업을 허용합니다.- 필요한 IAM 권한을 부여합니다.
- 필요한 Google API를 사용 설정합니다.
- 메시를 식별하는 라벨을 클러스터에 설정합니다.
- 아직 등록되지 않은 경우 Fleet에 클러스터를 등록합니다.
--ca mesh_ca
: Mesh CA를 인증 기관으로 사용합니다.asmcli
에서 Fleet 워크로드 아이덴티티를 사용하도록 Mesh CA를 구성합니다.--option vm
: VM을 서비스 메시에 포함할 클러스터를 준비합니다.
클러스터에서 기존 워크로드가 실행되고 있으면 워크로드를 다시 배포한 후 이 페이지로 돌아와서 VM을 추가합니다.
관리형 서비스 메시
다음 명령어는 VM을 추가할 수 있도록 제어 영역을 준비하는 --option vm
으로 Anthos Service Mesh Google 관리 제어 영역을 배포하는 방법을 보여줍니다. 사용 가능한 다른 옵션에 대한 자세한 내용은 Google 관리 제어 영역 적용을 참조하세요.
관리형 Anthos Service Mesh 문서에 asmcli install
대신 install_asm
스크립트가 사용되지만 두 설치 스크립트 모두 동일한 방식으로 옵션을 지정합니다.
./asmcli install \
--project_id PROJECT_ID \
--cluster_name CLUSTER_NAME \
--cluster_location CLUSTER_LOCATION \
--output_dir DIR_PATH \
--enable_all \
--ca mesh_ca \
--option vm \
--managed
--project_id
,--cluster_name
,--cluster_location
: 클러스터가 있는 프로젝트 ID, 클러스터 이름, 클러스터 영역 또는 리전을 지정합니다.--output_dir
asmcli
가anthos-service-mesh
패키지를 다운로드하고 설치 파일을 추출하며,istioctl
, 샘플, 매니페스트가 포함되는 디렉터리를 지정하려면 이 옵션을 포함합니다. 그렇지 않으면asmcli
가 파일을tmp
디렉터리에 다운로드합니다. 상대 경로 또는 전체 경로를 지정할 수 있습니다. 여기서 환경 변수$PWD
는 작동하지 않습니다.--enable_all
: 스크립트의 다음 작업을 허용합니다.- 필요한 IAM 권한을 부여합니다.
- 필요한 Google API를 사용 설정합니다.
- 메시를 식별하는 라벨을 클러스터에 설정합니다.
- 아직 등록되지 않은 경우 Fleet에 클러스터를 등록합니다.
--ca mesh_ca
: Mesh CA를 인증 기관으로 사용합니다.asmcli
에서 Fleet 워크로드 아이덴티티를 사용하도록 Mesh CA를 구성합니다.--option vm
: VM을 서비스 메시에 포함할 클러스터를 준비합니다.--managed
: Google 관리 제어 영역을 배포합니다.
기존 설치
Anthos Service Mesh가 클러스터에 이미 설치되어 있으면 다음 단계를 수행합니다.
아직 등록하지 않은 경우 Fleet에 클러스터를 등록합니다.
다음 명령어를 실행하여 Anthos Service Mesh 설치가 VM 워크로드에 사용할 준비가 되었는지 확인합니다. 클러스터 내 및 Google 관리 제어 영역 모두에 대해 동일한 명령어를 실행합니다.
./asmcli experimental vm prepare-cluster \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION
성공하면 명령어가 다음을 출력합니다.
The cluster is ready for adding VM workloads. Please follow the Anthos Service Mesh for Compute Engine VM user guide to add Compute Engine VMs to your mesh.
이 명령은 다음을 수행합니다.
클러스터 내
VM 자동 등록 사용 설정: 이 작업은
PILOT_ENABLE_WORKLOAD_ENTRY_AUTOREGISTRATION
및PILOT_ENABLE_CROSS_CLUSTER_WORKLOAD_ENTRY
변수를 true로 설정하여 수행됩니다. 이 기능을 사용 설정하면 새 VM 인스턴스가WorkloadGroup
에 등록되고 트래픽을 VM으로 라우팅하기 위한 새WorkloadEntry
CR이 생성됩니다.asmcli
에 설치된 모든 Anthos Service Mesh 1.9 이상 버전 제어 영역에는 기본적으로 VM 자동 등록이 사용 설정됩니다.확장 게이트웨이 설치: 이 게이트웨이는 이름이
eastwest
이고 Anthos Service Mesh 구성 패키지에 정의되어 있습니다. 또한 이렇게 하면 VM에 제어 영역이 노출됩니다.IdentityProvider
CRD를 설치하고 VM이 Anthos Service Mesh 제어 영역에 인증을 수행하고 나머지 서비스 메시와 안전하게 통신할 수 있도록 GoogleIdentityProvider
CR을 등록합니다.asmcli
스크립트에서--enable_all
또는--enable_registration
을 사용하는 경우 클러스터를 Fleet에 등록하고 워크로드 아이덴티티를 사용 설정합니다.제품군 내에서
Service Mesh
기능을 사용 설정합니다. 이 기능은 VM이 메시와 안전하게 통신하도록 허용하는 데 필요한 정책을 관리합니다.
관리형 서비스 메시
VM 자동 등록 사용 설정: 모든 Anthos Service Mesh Google 관리 제어 영역에 기본적으로 VM 자동 등록이 사용 설정됩니다.
IdentityProvider
CRD를 설치하고 VM이 Anthos Service Mesh Google 관리 제어 영역에 인증을 수행하고 나머지 서비스 메시와 안전하게 통신할 수 있도록 GoogleIdentityProvider
CR을 등록합니다.asmcli
스크립트에서--enable_all
또는--enable_registration
을 사용하는 경우 클러스터를 Fleet에 등록하고 워크로드 아이덴티티를 사용 설정합니다.제품군 내에서
Service Mesh
기능을 사용 설정합니다. 이 기능은 VM이 메시와 안전하게 통신하도록 허용하는 데 필요한 정책을 관리합니다.
인그레스 게이트웨이 설치
Anthos Service Mesh는 서비스 메시의 일부로 게이트웨이를 배포 및 관리하는 옵션을 제공합니다. 게이트웨이는 들어오거나 나가는 HTTP/TCP 연결을 수신하는 메시지의 에지에서 작동하는 부하 분산기를 설명합니다. 게이트웨이는 메시로 들어오고 나가는 트래픽을 미세하게 제어할 수 있는 Envoy 프록시입니다.
아직 없으면 인그레스 게이트웨이의 네임스페이스를 만듭니다. 게이트웨이는 사용자 워크로드입니다. 권장사항에 따라 제어 영역 네임스페이스에 배포하지 않아야 합니다.
GATEWAY_NAMESPACE
를 네임스페이스의 이름으로 바꿉니다.kubectl create namespace GATEWAY_NAMESPACE
게이트웨이 네임스페이스에서 버전 라벨을 적용하여 게이트웨이에서 자동 삽입을 사용 설정합니다. 버전 라벨은 사이드카 인젝터 웹훅에서 삽입된 프록시를 특정 제어 영역 버전과 연결하는 데 사용됩니다. 사용하는 라벨은 관리형 Anthos Service Mesh 또는 클러스터 내 제어 영역을 배포했는지에 따라 달라집니다.
클러스터 내
다음 명령어를 사용하여
istiod
에서 버전 라벨을 찾습니다.kubectl get deploy -n istio-system -l app=istiod -o \ jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
네임스페이스에 버전 라벨을 적용합니다. 다음 명령어에서
REVISION
은 이전 단계에서 확인한istiod
버전 라벨의 값입니다.kubectl label namespace GATEWAY_NAMESPACE \ istio-injection- istio.io/rev=REVISION --overwrite
관리형 서비스 메시
네임스페이스에
asm-managed
버전 라벨을 적용합니다.kubectl label namespace GATEWAY_NAMESPACE \ istio-injection- istio.io/rev=asm-managed --overwrite
이 라벨은 Anthos Service Mesh 버전에 대한 현재 관리형 Anthos Service Mesh 출시 채널에 해당합니다.
출력에서
"istio-injection not found"
메시지는 무시해도 됩니다. 즉, 네임스페이스에 이전에istio-injection
라벨이 사용되지 않았으며, Anthos Service Mesh를 새로 설치하거나 새로 배포해야 합니다. 네임스페이스에istio-injection
및 버전 라벨이 모두 포함된 경우 자동 삽입이 실패하기 때문에 Anthos Service Mesh 문서에서 모든kubectl label
명령어에는istio-injection
라벨 삭제가 포함됩니다.samples/gateways/istio-ingressgateway/
디렉터리에 있는 예시 인그레스 게이트웨이 구성을 있는 그대로 배포하거나 필요에 따라 수정할 수 있습니다.kubectl apply -n GATEWAY_NAMESPACE \ -f DIR_PATH/samples/gateways/istio-ingressgateway
게이트웨이 권장사항에 대해 자세히 알아보세요.
VM 추가
이 섹션에서는 gcloud
로 만드는 인스턴스 템플릿을 기준으로 메시에 Compute Engine 인스턴스를 추가합니다.
gcloud
는 서비스 프록시 에이전트에 필요한 구성만 생성합니다.
인스턴스 템플릿에 구성을 더 포함하려면 gcloud
참조 가이드에서 자세한 내용을 참조하세요
메시에 VM을 추가하려면 다음 단계를 따릅니다.
이후 단계에서 사용할 다음 환경 변수를 설정합니다. 각 VM 워크로드에 대해 다음 변수를 설정합니다.
- WORKLOAD_NAME은 VM이 포함된 워크로드의 이름이며, 영숫자 소문자로 구성된 호환되는 DNS-1123 하위 도메인이어야 합니다.
- WORKLOAD_VERSION은 VM이 포함된 워크로드의 버전입니다. 선택사항.
- WORKLOAD_SERVICE_ACCOUNT는 VM이 실행되는 서비스 GCP 서비스 계정입니다.
- WORKLOAD_NAMESPACE는 워크로드의 네임스페이스입니다.
- ASM_INSTANCE_TEMPLATE은 만들 인스턴스 템플릿의 이름입니다. Compute Engine 인스턴스 템플릿 이름에는 밑줄이 허용되지 않습니다.
VM 워크로드의 네임스페이스가 아직 없으면 만듭니다.
kubectl create ns WORKLOAD_NAMESPACE
네임스페이스에 제어 영역 버전을 라벨로 지정합니다.
클러스터 내
다음 예시에서 REVISION으로 표시된 제어 영역 버전을 찾는 방법에 대한 예시는 워크로드 배포 및 다시 배포를 참조하세요.
kubectl label ns WORKLOAD_NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
관리형 서비스 메시
다음 예시에서
asm-managed
버전을 설정하는 방법에 대한 예시는 애플리케이션 배포를 참조하세요.kubectl label ns WORKLOAD_NAMESPACE istio-injection- istio.io/rev=asm-managed --overwrite
등록할 VM에 대해
WorkloadGroup
을 만듭니다.kubectl apply -f - << EOF apiVersion: networking.istio.io/v1alpha3 kind: WorkloadGroup metadata: name: WORKLOAD_NAME namespace: WORKLOAD_NAMESPACE spec: metadata: labels: app.kubernetes.io/name: WORKLOAD_NAME app.kubernetes.io/version: WORKLOAD_VERSION annotations: security.cloud.google.com/IdentityProvider: google template: serviceAccount: WORKLOAD_SERVICE_ACCOUNT EOF
필드 설명 name
VM이 포함된 워크로드의 이름입니다. namespace
워크로드가 포함된 네임스페이스입니다. app.kubernetes.io/name
Kubernetes 애플리케이션의 권장 라벨입니다. VM 워크로드에 사용자 고유 라벨을 사용할 수 있습니다. app.kubernetes.io/version
Kubernetes 애플리케이션의 권장 라벨입니다. VM 워크로드에 사용자 고유 라벨을 사용할 수 있습니다. serviceAccount
SPIFFE 형식으로 워크로드 ID 일부로 사용되는 VM 및 프로젝트에 사용되는 서비스 계정 ID입니다. 자세한 내용은 서비스 계정을 참조하세요. security.cloud.google.com/IdentityProvider
VM에 사용할 ID 공급업체입니다. 클러스터에 등록되어 있어야 합니다. Compute Engine VM의 경우 google
로 설정해야 합니다.IdentityProvider
는 VM의 사용자 인증 정보를 인증하는 방법과 VM의 서비스 계정을 추출할 위치를 제어 영역에 알려줍니다.--mesh
플래그와 함께gcloud beta compute instance-templates create
명령어를 사용하여 Anthos Service Mesh Compute Engine 인스턴스에 대해 인스턴스 템플릿을 만듭니다.gcloud
는 클러스터 기본 요건을 확인하고, Anthos Service Mesh에 대해 VM 라벨을 추가하고, 서비스 프록시 에이전트에 대해 커스텀 메타데이터 구성을 생성하고, 새 인스턴스 템플릿을 만듭니다.인스턴스 템플릿에 네트워크 연결이 필요한 시작 스크립트가 포함된 경우 이 스크립트는 일시적인 네트워크 연결 문제에 대한 복원력이 우수해야 합니다. 일시적인 네트워크 장애에 대한 복원력을 추가하는 방법의 예시는 데모 애플리케이션을 참조하세요.
인스턴스 템플릿 만들기에 대한 자세한 내용은 인스턴스 템플릿 만들기를 참조하세요.
gcloud beta compute instance-templates create \ ASM_INSTANCE_TEMPLATE \ --mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=WORKLOAD_NAMESPACE/WORKLOAD_NAME \ --project PROJECT_ID
만드는 각 MIG에 대해 다음 환경 변수를 설정합니다.
- INSTANCE_GROUP_NAME은 만들려는 Compute Engine 인스턴스 그룹의 이름입니다.
- ASM_INSTANCE_TEMPLATE은 만들 인스턴스 템플릿의 이름입니다. Compute Engine 인스턴스 템플릿 이름에는 밑줄이 허용되지 않습니다.
- INSTANCE_GROUP_ZONE은 만들 Compute Engine 인스턴스 그룹의 영역입니다.
- PROJECT_ID는 클러스터가 생성된 프로젝트 ID입니다.
- SIZE는 만들 인스턴스 그룹의 크기입니다. 인스턴스 그룹이 생성된 후 변경할 수 있습니다.
- WORKLOAD_NAME은 VM이 포함된 워크로드의 이름입니다.
- WORKLOAD_NAMESPACE는 워크로드의 네임스페이스입니다.
이전 단계에서 만든 변수를 사용하여 VM 워크로드의 관리형 인스턴스 그룹을 만듭니다.
gcloud compute instance-groups managed create INSTANCE_GROUP_NAME \ --template ASM_INSTANCE_TEMPLATE \ --zone=INSTANCE_GROUP_ZONE \ --project=PROJECT_ID \ --size=SIZE
영역 또는 리전 MIG 크기 0부터 시작하여 Compute Engine 인스턴스에서 워크로드 수를 수평 확장하려면 인스턴스 그룹 자동 확장을 참조하세요. 그룹 만들기에 대한 자세한 내용은 gcloud compute instance-groups managed create를 참조하세요.
인스턴스가 시작되면 클러스터에서 Anthos Service Mesh 제어 영역에 자동으로 인증을 수행하고 제어 영역이 각 VM을
WorkloadEntry
로 등록합니다.MIG의 VM 인스턴스 시작이 완료되면 다음 명령어를 사용하여 워크로드 네임스페이스에서 등록된 VM을 볼 수 있습니다.
kubectl get workloadentry -n WORKLOAD_NAMESPACE
위에서 추가한 VM 워크로드를 노출시키기 위해 Kubernetes 서비스를 추가합니다. 올바른 트래픽 라우팅을 위해서는 위에서 등록된 VM
WorkloadGroup
에서 서비스가 해당 라벨을 선택하도록 해야 합니다.다음 예시에서는 WORKLOAD_NAMESPACE 네임스페이스에서 HTTP 포트 80을 사용해서
app.kubernetes.io/name: WORKLOAD_NAME
라벨로 VM 워크로드를 노출하는 WORKLOAD_NAME이라는 Kubernetes 서비스를 만듭니다.kubectl apply -f - << EOF apiVersion: v1 kind: Service metadata: name: WORKLOAD_NAME namespace: WORKLOAD_NAMESPACE labels: asm_resource_type: VM spec: ports: - port: 80 name: http selector: app.kubernetes.io/name: WORKLOAD_NAME EOF
Kubernetes 서비스를 만드는 방법에 대한 자세한 내용은 https://kubernetes.io/docs/concepts/services-networking/service/#defining-a-service를 참조하세요.
VM에서 샘플 애플리케이션을 사용하려면 샘플 애플리케이션 배포를 참조하세요.
클러스터 내 제어 영역 업그레이드 후 워크로드 다시 배포
이전 섹션에서 Anthos Service Mesh를 업그레이드하고 워크로드가 클러스터에서 실행되는 경우에는 이를 새 제어 영역으로 전환합니다.
VM 워크로드에 대해 새 인스턴스 템플릿을 만들고 MIG에서 VM에 대해 순차적 업데이트를 수행합니다.
다음 명령어를 사용하여
istiod
에서 버전 라벨을 찾습니다.kubectl -n istio-system get pods -l app=istiod --show-labels
명령어 출력은 다음과 비슷합니다. 마이그레이션 출력은 업그레이드와 약간 다릅니다. 다음 예시는 마이그레이션의 출력입니다.
NAME READY STATUS RESTARTS AGE LABELS istiod-7744bc8dd7-qhlss 1/1 Running 0 49m app=istiod,istio.io/rev=default,istio=pilot,pod-template-hash=7744bc8dd7 istiod-asm-1118-4-85d86774f7-flrt2 1/1 Running 0 26m app=istiod,istio.io/rev=asm-1118-4,istio=istiod,pod-template-hash=85d86774f7 istiod-asm-1118-4-85d86774f7-tcwtn 1/1 Running 0 26m app=istiod,istio.io/rev=asm-1118-4,istio=istiod,pod-template-hash=85d86774f7
출력의
LABELS
열 아래에서istio.io/rev=
프리픽스 다음에 있는 새 버전의istiod
버전 라벨 값을 확인하세요. 이 예시에서 값은asm-1118-4
입니다.또한 이전
istiod
버전의 버전 라벨 값을 기록해 두세요. 워크로드를 새 버전으로 이동하고 나면istiod
의 이전 버전을 삭제할 때 필요합니다. 예시 출력에서 이전 버전istiod
에 대한 버전 라벨 값은default
입니다.
네임스페이스에 버전 라벨을 추가하고
istio-injection
라벨을 삭제합니다(있는 경우). 다음 명령어에서REVISION
을istiod
의 새 버전과 일치하는 값으로 변경합니다.kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite
출력에
"istio-injection not found"
가 표시되면 무시해도 됩니다. 이것은 이전에 네임스페이스에istio-injection
라벨이 없음을 의미합니다. 네임스페이스에istio-injection
및 버전 라벨이 모두 포함된 경우 자동 삽입이 실패하기 때문에 Anthos Service Mesh 문서에서 모든kubectl label
명령어에는istio-injection
라벨 삭제가 포함됩니다.gcloud
를 사용하여 새 인스턴스 템플릿을 만듭니다. 동일한 워크로드에 대해 인스턴스 템플릿이 있으면 동일한 구성을 포함해야 합니다.gcloud beta compute instance-templates create NEW_ASM_INSTANCE_TEMPLATE \ --mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=WORKLOAD_NAMESPACE/WORKLOAD_NAME \ --project PROJECT_ID
워크로드의 기존 MIG에 대해 순차적 업데이트를 수행합니다.
자세한 내용은 기본 순차적 업데이트 시작을 참조하세요.
gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \ --version=template=NEW_ASM_INSTANCE_TEMPLATE \ --zone=INSTANCE_GROUP_ZONE
VM 워크로드를 테스트하여 예상대로 작동하는지 확인합니다.
VM 애플리케이션 업그레이드
WorkloadGroup
변경사항 또는 인스턴스 템플릿 구성 변경사항을 포함하여 애플리케이션이 업데이트된 경우 VM 워크로드의 MIG를 업데이트하기 위해 새 인스턴스 템플릿이 필요합니다.
WorkloadGroup
변경이 적용되거나 새 소스 인스턴스 템플릿이 생성되면 Anthos Service Mesh에 대해 새 인스턴스 템플릿을 만들고 MIG의 VM에 대해 순차적 업데이트를 수행합니다.
gcloud
를 사용하여 새 인스턴스 템플릿을 만듭니다.gcloud beta compute instance-templates create NEW_ASM_INSTANCE_TEMPLATE \ --mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=WORKLOAD_NAMESPACE/WORKLOAD_NAME \ --project PROJECT_ID
워크로드의 기존 MIG에 대해 순차적 업데이트를 수행합니다. MIG 순차적 업데이트를 사용하는 방법은 기본 순차적 업데이트 시작을 참조하세요.
gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \ --version=template=NEW_ASM_INSTANCE_TEMPLATE \ --zone=INSTANCE_GROUP_ZONE
VM 워크로드를 테스트하여 예상대로 작동하는지 확인합니다.
샘플 애플리케이션 배포
새 메시 구성이 올바르게 작동하는지 시연하기 위해 Bookinfo 샘플 애플리케이션을 설치할 수 있습니다. 이 예시에서는 VM에서 MySQL 데이터베이스를 실행하고 등급 서비스가 데이터베이스에서 등급 값을 읽습니다.
클러스터에 Bookinfo 설치
다음 단계를 따라 각 서비스와 함께 사이드카 프록시가 삽입된 BookInfo 애플리케이션 서비스를 배포합니다. BookInfo 애플리케이션은 default
네임스페이스에 배포됩니다.
Anthos Service Mesh를 설치한 컴퓨터의 명령줄에서 스크립트 다운로드 단계 중에 만든 Anthos Service Mesh 설치 디렉터리의 루트로 이동합니다.
자동 사이드카 삽입을 사용 설정하려면 Anthos Service Mesh 제어 영역 유형에 따라 아래의 안내를 선택합니다.
클러스터 내
다음 명령어를 사용하여
istiod
에서 이후 단계에서 사용할 버전 라벨 값을 포함하는 라벨을 찾습니다.kubectl -n istio-system get pods -l app=istiod --show-labels
출력은 다음과 유사합니다.
NAME READY STATUS RESTARTS AGE LABELS istiod-asm-1118-4-5788d57586-bljj4 1/1 Running 0 23h app=istiod,istio.io/rev=asm-1118-4,istio=istiod,pod-template-hash=5788d57586 istiod-asm-1118-4-5788d57586-vsklm 1/1 Running 1 23h app=istiod,istio.io/rev=asm-1118-4,istio=istiod,pod-template-hash=5788d57586
출력의
LABELS
열 아래에서istio.io/rev=
프리픽스 다음에 있는istiod
버전 라벨의 값을 확인합니다. 이 예시에서 값은asm-1118-4
입니다.관리형 서비스 메시
asm-managed
리비전을 사용하여 VM을 추가합니다.default
네임스페이스에 버전 라벨을 적용합니다.클러스터 내
다음 명령어에서
REVISION
은 이전 단계에서 확인한istiod
버전 라벨의 값입니다.kubectl label namespace default istio-injection- istio.io/rev=REVISION --overwrite
출력에서
"istio-injection not found"
메시지는 무시해도 됩니다. 즉, 네임스페이스에 이전에istio-injection
라벨이 사용되지 않았으며, Anthos Service Mesh를 새로 설치하거나 새로 배포해야 합니다. 네임스페이스에istio-injection
및 버전 라벨이 모두 포함된 경우 자동 삽입이 실패하기 때문에 Anthos Service Mesh 문서에서 모든kubectl label
명령어에는istio-injection
라벨 삭제가 포함됩니다.관리형 서비스 메시
kubectl label namespace default istio-injection- istio.io/rev=asm-managed --overwrite
kubectl
을 사용하여 애플리케이션을 기본 네임스페이스에 배포합니다.kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml
다음 명령어를 실행하여 애플리케이션이 올바르게 배포되었는지 확인합니다.
kubectl get services
예상 출력:
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE details 10.0.0.31 <none> 9080/TCP 6m kubernetes 10.0.0.1 <none> 443/TCP 7d productpage 10.0.0.120 <none> 9080/TCP 6m ratings 10.0.0.15 <none> 9080/TCP 6m reviews 10.0.0.170 <none> 9080/TCP 6m
및
kubectl get pod
예상 출력:
NAME READY STATUS RESTARTS AGE details-v1-1520924117-48z17 2/2 Running 0 6m productpage-v1-560495357-jk1lz 2/2 Running 0 6m ratings-v1-734492171-rnr5l 2/2 Running 0 6m reviews-v1-874083890-f0qf0 2/2 Running 0 6m reviews-v2-1343845940-b34q5 2/2 Running 0 6m reviews-v3-1813607990-8ch52 2/2 Running 0 6m
마지막으로 애플리케이션에 대해 인그레스 게이트웨이 라우팅을 정의합니다.
kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml
예상 출력:
gateway.networking.istio.io/bookinfo-gateway created virtualservice.networking.istio.io/bookinfo created
제품 페이지에 액세스할 수 있는지 확인합니다. 다음 명령어에서
GATEWAY_NAMESPACE
는 Istio 게이트웨이의 네임스페이스입니다.export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}') export INGRESS_PORT=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].port}') export GATEWAY_URL="${INGRESS_HOST}:${INGRESS_PORT}" curl -s "http://${GATEWAY_URL}/productpage" | grep -o "<title>.*</title>"
예상 출력:
<title>Simple Bookstore App</title>
Compute Engine 인스턴스 만들기 및 MySQL 설치
이 단계에서는 VM에서 실행되는 MySQL 인스턴스에 대해 Compute Engine 인스턴스 템플릿을 만듭니다. 자세한 단계는 가상 머신을 사용하는 Bookinfo를 참조하세요.
MySQL을 설치하고 시작 시 평점 데이터베이스를 추가하도록 시작 스크립트를 만듭니다. CentOS를 사용하는 경우 mariadb-server가 준비되는 데 최대 10분이 걸립니다.
Debian
cat << "EOF" > init-mysql #!/bin/bash # Wait until Envoy is ready before installing mysql while true; do rt=$(curl -s 127.0.0.1:15000/ready) if [[ $? -eq 0 ]] && [[ "${rt}" -eq "LIVE" ]]; then echo "envoy is ready" break fi sleep 1 done # Wait until DNS is ready before installing mysql while true; do curl -I productpage.default.svc:9080 if [[ $? -eq 0 ]]; then echo "dns is ready" break fi sleep 1 done sudo apt-get update && sudo apt-get install -y mariadb-server sudo sed -i '/bind-address/c\bind-address = 0.0.0.0' /etc/mysql/mariadb.conf.d/50-server.cnf cat <<EOD | sudo mysql # Grant access to root GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION; # Grant root access to other IPs CREATE USER 'root'@'%' IDENTIFIED BY 'password'; GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION; FLUSH PRIVILEGES; quit EOD sudo systemctl restart mysql curl -LO https://raw.githubusercontent.com/istio/istio/release-1.11/samples/bookinfo/src/mysql/mysqldb-init.sql mysql -u root -ppassword < mysqldb-init.sql EOF
CentOS
cat << "EOF" > init-mysql #!/bin/bash # Wait until Envoy is ready before installing mysql while true; do rt=$(curl -s 127.0.0.1:15000/ready) if [[ $? -eq 0 ]] && [[ "${rt}" -eq "LIVE" ]]; then echo "envoy is ready" break fi sleep 1 done # Wait until DNS is ready before installing mysql while true; do curl -I productpage.default.svc:9080 if [[ $? -eq 0 ]]; then echo "dns is ready" break fi sleep 1 done sudo yum update -y && sudo yum install -y mariadb-server # Wait until mysql is ready while true; do rt=$(which mysql) if [[ ! -z "${rt}" ]]; then echo "mysql is ready" break fi sleep 1 done sudo sed -i '/bind-address/c\bind-address = 0.0.0.0' /etc/my.cnf.d/mariadb-server.cnf sudo systemctl restart mariadb cat > grantaccess.sql << EOD GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION; CREATE USER 'root'@'%' IDENTIFIED BY 'password'; GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION; FLUSH PRIVILEGES; EOD until sudo mysql < grantaccess.sql; do sleep 1 done sudo systemctl restart mariadb curl -LO https://raw.githubusercontent.com/istio/istio/release-1.11/samples/bookinfo/src/mysql/mysqldb-init.sql mysql -u root -ppassword < mysqldb-init.sql EOF
MySQL 워크로드에 대해
WorkloadGroup
을 만듭니다.kubectl apply -f - << EOF apiVersion: networking.istio.io/v1alpha3 kind: WorkloadGroup metadata: name: mysql namespace: default spec: metadata: labels: app.kubernetes.io/name: mysql annotations: security.cloud.google.com/IdentityProvider: google template: serviceAccount: WORKLOAD_SERVICE_ACCOUNT EOF
gcloud
를 사용하여 메시의 인스턴스를 준비하고 위에 만든 시작 스크립트를 포함하는 새 인스턴스 템플릿을 만듭니다.Debian
gcloud beta compute instance-templates create asm-mysql-instance-template \ --mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=default/mysql \ --project PROJECT_ID \ --metadata-from-file=startup-script=init-mysql \ --image-project=debian-cloud --image-family=debian-10 --boot-disk-size=10GB
CentOS
gcloud beta compute instance-templates create asm-mysql-instance-template \ --mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=default/mysql \ --project PROJECT_ID \ --metadata-from-file=startup-script=init-mysql \ --image-project=centos-cloud --image-family=centos-8 --boot-disk-size=20GB
새로 생성된 인스턴스 템플릿을 사용하여 Compute Engine MIG를 만듭니다.
gcloud compute instance-groups managed create mysql-instance \ --template asm-mysql-instance-template \ --zone=us-central1-c \ --project=PROJECT_ID \ --size=1
서비스 만들기
다음 명령어를 사용하여 MySQL 서비스에 대해 Kubernetes 서비스를 만듭니다.
kubectl apply -f - << EOF
apiVersion: v1
kind: Service
metadata:
name: mysql
namespace: default
labels:
asm_resource_type: VM
spec:
ports:
- name: mysql
port: 3306
protocol: TCP
targetPort: 3306
selector:
app.kubernetes.io/name: mysql
EOF
Anthos UI 대시보드 사용
생성된 새 VM 기반 서비스를 보려면 왼쪽의 기본 탐색 메뉴에서 Anthos > 서비스 메시를 클릭합니다. 그러면 메시에서 실행되는 서비스의 테이블이 표시됩니다. 추가한 서비스가 VM
의 Type
값 및 일부 고급 측정항목과 함께 테이블에 표시됩니다. VM 기반 서비스에서 더 많은 원격 분석을 보려면 서비스 이름을 클릭하여 서비스 수준 대시보드를 표시합니다.
Anthos UI 대시보드 사용 방법에 대한 자세한 내용은 Cloud Console에서 Anthos Service Mesh 탐색을 참조하세요.
VM 워크로드 트래픽 관리
VM에서 트래픽이 들어오고 나가는 방법을 제어하는 네트워킹 규칙을 변경할 수 있습니다.
새 등급 서비스 트래픽 제어(Pod-VM)
Bookinfo에서 위에서 생성된 MySQL 인스턴스를 데이터 소스로 사용하는 다른 등급 서비스를 만들고 검토 서비스가 새 등급 서비스를 사용하도록 강제하는 라우팅 규칙을 지정합니다.
MySQL 인스턴스를 사용하도록 새 등급 서비스를 만듭니다.
kubectl apply -f - << EOF apiVersion: apps/v1 kind: Deployment metadata: name: ratings-v2-mysql-vm labels: app: ratings version: v2-mysql-vm spec: replicas: 1 selector: matchLabels: app: ratings version: v2-mysql-vm template: metadata: labels: app: ratings version: v2-mysql-vm spec: serviceAccountName: bookinfo-ratings containers: - name: ratings image: docker.io/istio/examples-bookinfo-ratings-v2:1.16.2 imagePullPolicy: IfNotPresent env: - name: DB_TYPE value: "mysql" - name: MYSQL_DB_HOST value: mysql.default.svc.cluster.local - name: MYSQL_DB_PORT value: "3306" - name: MYSQL_DB_USER value: root - name: MYSQL_DB_PASSWORD value: password ports: - containerPort: 9080 EOF
라우팅 규칙을 만듭니다.
kubectl apply -f - << EOF apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - route: - destination: host: reviews subset: v3 --- apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ratings spec: hosts: - ratings http: - route: - destination: host: ratings subset: v2-mysql-vm EOF
생성된 서비스에 대해 대상 규칙을 적용합니다.
kubectl apply -f - << EOF apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: reviews spec: host: reviews subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 - name: v3 labels: version: v3 --- apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: ratings spec: host: ratings subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 - name: v2-mysql labels: version: v2-mysql - name: v2-mysql-vm labels: version: v2-mysql-vm EOF
애플리케이션 배포 검증
BookInfo 애플리케이션이 작동하는지 확인하려면 인그레스 게이트웨이로 트래픽을 보내야 합니다.
GKE에 Anthos Service Mesh를 설치한 경우 이전 단계에서 만든 인그레스 게이트웨이의 외부 IP 주소를 가져옵니다.
kubectl get svc istio-ingressgateway -n GATEWAY_NAMESPACE
출력:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE istio-ingressgateway LoadBalancer 10.19.247.233 35.239.7.64 80:31380/TCP,443:31390/TCP,31400:31400/TCP 27m
이 예시에서 인그레스 서비스의 IP 주소는
35.239.7.64
입니다.
애플리케이션 시험 사용
curl
을 사용하여 BookInfo 앱이 실행되는지 확인합니다.curl -I http://EXTERNAL_IP/productpage
응답에
200
이 표시되면 애플리케이션이 Anthos Service Mesh와 함께 올바르게 작동되고 있음을 나타냅니다.BookInfo 웹페이지를 보려면 브라우저에 다음 주소를 입력합니다.
http://EXTERNAL_IP/productpage
Bookinfo 애플리케이션 홈페이지에서
Reviewer1
로부터 별 5개를 표시하고Reviewer2
로부터 별 4개를 표시하는지 확인합니다.
VM 워크로드에 보안 적용
VM 워크로드에 보안을 적용하는 것은 Kubernetes 워크로드에 보안을 적용하는 것과 동일합니다. 자세한 내용은 Istio 보안을 참조하세요.
이전 단계를 완료한 후 Compute Engine VM에 Google에서 발급한 워크로드 인증서가 포함됩니다. 인증서에서 SubjectAlternativeName
값은 spiffe://<workload_identity_pool>/ns/WORKLOAD_NAMESPACE/sa/WORKLOAD_SERVICE_ACCOUNT
형식의 VM의 Anthos 워크로드 아이덴티티를 표시합니다.
자세한 내용은 워크로드 아이덴티티 풀을 참조하세요.
메시에 mTLS의 엄격한 모드 사용 설정
다음 YAML을 적용하여 엄격한 mTLS를 메시 전체에 적용합니다.
kubectl apply -f - << EOF
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: istio-system
spec:
mtls:
mode: STRICT
EOF
서비스 간 트래픽 승인
AuthorizationPolicy를 사용하여 Compute Engine VM의 애플리케이션과 다른 메시 워크로드(예: GKE 클러스터의 항목) 사이의 액세스를 제어합니다.
예시: Kubernetes 워크로드의 Compute Engine VM 액세스 거부
다음 승인 정책은 Kubernetes 워크로드 ratings
가 ratings
MySQL 서버를 제공하는 Compute Engine VM 워크로드에 액세스하는 것을 거부합니다.
kubectl apply -f - << EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: mysql-deny
namespace: default
spec:
selector:
matchLabels:
app.kubernetes.io/name: mysql
action: DENY
rules:
- from:
- source:
principals: ["cluster.local/ns/default/sa/bookinfo-ratings"]
EOF
AuthorizationPolicy
예시를 적용한 후에는 제품 페이지의 도서 리뷰 섹션에 Ratings service
is currently unavailable
오류 메시지가 표시됩니다.
Cloud Monitoring 에이전트 설치
Cloud Monitoring 에이전트를 설치하여 VM 인스턴스에서 시스템 및 애플리케이션 측정항목을 수집하고 모니터링할 수 있습니다. 이를 통해 에이전트의 CPU 및 메모리 사용 예시와 같은 주요 측정항목을 모니터링할 수 있습니다.
자세한 내용은 Cloud Monitoring 에이전트 문서를 참조하세요.
문제 해결
문제 해결 팁은 VM 지원 문제 해결을 참조하세요.