v1.21 서비스 메시 문서를 보고 있습니다.

사용 가능한 버전

Cloud Service Mesh
1.22 보관 파일
1.21 보관 파일
1.20 보관 파일
1.19 보관 파일
1.18 보관 파일

이 페이지는 Cloud Translation API를 통해 번역되었습니다.

Kubernetes 워크로드 온보딩

이 페이지에서는 Cloud Service Mesh를 사용하여 Kubernetes 워크로드를 온보딩하는 방법을 보여줍니다.

Kubernetes 서비스 배포

Cloud Service Mesh를 사용하는 클러스터에 Kubernetes 서비스를 배포하려면 다음을 수행해야 합니다.

모든 컨테이너에 대해 Kubernetes 서비스를 만듭니다. 모든 배포에는 Kubernetes 서비스가 연결되어 있어야 합니다.
서비스 포트의 이름을 지정합니다. GKE를 사용하여 이름이 지정되지 않은 서비스 포트를 정의할 수 있지만 Cloud Service Mesh에서는 포트 프로토콜과 일치하는 포트 이름을 제공해야 합니다.
배포에 라벨을 지정합니다. 이를 통해 같은 서비스 버전 간에 트래픽 분할과 같은 Cloud Service Mesh 트래픽 관리 기능을 사용할 수 있습니다.

배포 및 서비스의 다음 예시는 이러한 요구사항을 보여줍니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloserver
spec:
  replicas: 1
  selector:
    matchLabels:
      app: helloserver
  template:
    metadata:
      labels:
        app: helloserver
    spec:
      containers:
      - image: gcr.io/google-samples/istio/helloserver:v0.0.1
        imagePullPolicy: Always
        name: main
      restartPolicy: Always
      terminationGracePeriodSeconds: 5

apiVersion: v1
kind: Service
metadata:
  name: hellosvc
spec:
  ports:
  - name: http
    port: 80
    targetPort: 8080
  selector:
    app: helloserver
  type: LoadBalancer

Cloud Service Mesh를 사용하는 클러스터에 서비스를 배포한 후에는 사이드카 프록시를 삽입해야 합니다.

예시: Online Boutique 샘플 배포

anthos-service-mesh-packages 저장소의 Online Boutique 샘플 애플리케이션은 microservices-demo 저장소의 원래 매니페스트 세트에서 수정됩니다. 권장사항에 따라 각 서비스는 고유한 서비스 계정을 사용하여 별도의 네임스페이스에 배포됩니다.

애플리케이션의 네임스페이스를 만듭니다.

kubectl apply -f \
  DIR_PATH/samples/online-boutique/kubernetes-manifests/namespaces

예상 출력:

namespace/ad created
namespace/cart created
namespace/checkout created
namespace/currency created
namespace/email created
namespace/frontend created
namespace/loadgenerator created
namespace/payment created
namespace/product-catalog created
namespace/recommendation created
namespace/shipping created

삽입할 네임스페이스를 사용 설정합니다. 이 단계는 컨트롤 플레인 구현에 따라 다릅니다.

관리형(TD)

기본 삽입 라벨을 네임스페이스에 적용합니다.

for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do
  kubectl label namespace $ns \
      istio.io/rev- istio-injection=enabled --overwrite
done;

관리형(Istiod)

권장: 다음 명령어를 실행하여 네임스페이스에 기본 삽입 라벨을 적용합니다.

  for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do
    kubectl label namespace $ns \
        istio.io/rev- istio-injection=enabled --overwrite
  done;

관리형 Istiod 컨트롤 플레인이 있는 기존 사용자: 기본 삽입을 사용하는 것이 좋지만 버전 기반 삽입은 지원됩니다. 다음 안내를 따르세요.

다음 명령어를 실행하여 사용 가능한 출시 채널을 찾습니다.
```
kubectl -n istio-system get controlplanerevision
```
출력은 다음과 비슷합니다.
```
NAME                AGE
asm-managed-rapid   6d7h
```
참고: 이전 목록에 두 개의 컨트롤 플레인 버전이 표시되면 하나를 삭제합니다. 클러스터에 여러 컨트롤 플레인 채널을 두는 방식은 지원되지 않습니다.

출력에서 NAME 열 아래의 값은 Cloud Service Mesh 버전에 사용 가능한 출시 채널에 해당하는 버전 라벨입니다.

네임스페이스에 버전 라벨을 적용합니다.

for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do
  kubectl label namespace $ns \
      istio-injection- istio.io/rev=REVISION_LABEL --overwrite
done;

클러스터 내

권장: 다음 명령어를 실행하여 네임스페이스에 기본 삽입 라벨을 적용합니다.

  for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do
    kubectl label namespace $ns \
        istio.io/rev- istio-injection=enabled --overwrite
  done;

기본 삽입을 사용하는 것이 좋지만 버전 기반 삽입이 지원됩니다. 다음 안내를 따르세요.

다음 명령어를 사용하여 istiod에서 버전 라벨을 찾습니다.

kubectl get deploy -n istio-system -l app=istiod -o \
   jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'

네임스페이스에 버전 라벨을 적용합니다. 다음 명령어에서 REVISION_LABEL은 이전 단계에서 확인한 istiod 버전 라벨의 값입니다.

for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do
  kubectl label namespace $ns \
      istio-injection- istio.io/rev=REVISION_LABEL --overwrite
done;

클러스터에 샘플 애플리케이션을 배포합니다.

서비스 계정 및 배포 생성:

kubectl apply -f \
 DIR_PATH/samples/online-boutique/kubernetes-manifests/deployments

예상 출력:

serviceaccount/ad created
deployment.apps/adservice created
serviceaccount/cart created
deployment.apps/cartservice created
serviceaccount/checkout created
deployment.apps/checkoutservice created
serviceaccount/currency created
deployment.apps/currencyservice created
serviceaccount/email created
deployment.apps/emailservice created
serviceaccount/frontend created
deployment.apps/frontend created
serviceaccount/loadgenerator created
deployment.apps/loadgenerator created
serviceaccount/payment created
deployment.apps/paymentservice created
serviceaccount/product-catalog created
deployment.apps/productcatalogservice created
serviceaccount/recommendation created
deployment.apps/recommendationservice created
serviceaccount/shipping created
deployment.apps/shippingservice created

서비스 생성:

kubectl apply -f \
 DIR_PATH/samples/online-boutique/kubernetes-manifests/services

예상 출력:

service/adservice created
service/cartservice created
service/checkoutservice created
service/currencyservice created
service/emailservice created
service/frontend created
service/frontend-external created
service/paymentservice created
service/productcatalogservice created
service/recommendationservice created
service/shippingservice created

서비스 항목 생성:

kubectl apply -f \
 DIR_PATH/samples/online-boutique/istio-manifests/allow-egress-googleapis.yaml

예상 출력:

serviceentry.networking.istio.io/allow-egress-googleapis created
serviceentry.networking.istio.io/allow-egress-google-metadata created

서비스 포트 이름 지정

Cloud Service Mesh에 포함하려면 서비스 포트 이름을 지정해야 하고 이름에 포트의 프로토콜이 포함되어야 합니다. 예를 들면 다음과 같습니다.

apiVersion: v1
kind: Service
metadata:
  name: ratings
  labels:
    app: ratings
    service: ratings
spec:
  ports:
  - port: 9080
    name: http

서비스 포트 이름에는 name: protocol[-suffix] 문법 서픽스가 포함될 수 있습니다. 여기에서 대괄호는 대시로 시작해야 하는 선택적 서픽스를 나타냅니다. 예를 들면 다음과 같습니다.

kind: Service
metadata:
  name: myservice
spec:
  ports:
  - number: 3306
    name: mysql
  - number: 80
    name: http-web

측정항목을 Google Cloud 콘솔에 표시하려면 http, http2 또는 grpc 프로토콜 중 하나를 사용하여 서비스 포트의 이름을 지정해야 합니다. https 프로토콜으로 명명된 서비스 포트는 tcp로 처리되고, 이러한 서비스에 대한 측정항목이 표시되지 않습니다.

사이드카 프록시 삽입

이 섹션에서는 Cloud Service Mesh를 사용하여 사이드카 프록시 삽입을 구성하여 네트워크 보안, 신뢰성, 관측 가능성을 개선하는 방법을 설명합니다. 이러한 기능이 애플리케이션의 기본 컨테이너에서 추상화되고 동일한 포드에서 별도의 컨테이너로 제공되는 프로세스 외부의 공통 프록시로 구현됩니다. 서비스 메시에 참여하도록 프로덕션 애플리케이션을 재설계하지 않고도 Cloud Service Mesh 기능을 사용할 수 있습니다.

Cloud Service Mesh가 워크로드의 포드에 구성한 네임스페이스 라벨을 감지하면 자동 사이드카 프록시 삽입(자동 삽입)이 발생합니다. 프록시는 워크로드에 대한 모든 인바운드 및 아웃바운드 트래픽을 가로채고 Cloud Service Mesh와 통신합니다.

이 태스크에 필요한 권한

이 페이지에서 태스크를 수행하려면 roles/container.clusterAdmin 이상의 역할이 있어야 합니다. 이 역할에 포함된 권한에 대한 자세한 내용은 Google Kubernetes Engine 역할을 참조하세요.

자동 사이드카 삽입 사용 설정

네임스페이스의 삽입을 사용 설정합니다. 이 단계는 컨트롤 플레인 구현에 따라 다릅니다.
관리형(TD)
1. 기본 삽입 라벨을 네임스페이스에 적용합니다.
```
kubectl label namespace NAMESPACE
    istio.io/rev- istio-injection=enabled --overwrite
```
관리형(Istiod)
권장: 다음 명령어를 실행하여 네임스페이스에 기본 삽입 라벨을 적용합니다.
```
  kubectl label namespace NAMESPACE \
      istio.io/rev- istio-injection=enabled --overwrite
```
관리형 Istiod 컨트롤 플레인이 있는 기존 사용자: 기본 삽입을 사용하는 것이 좋지만 버전 기반 삽입은 지원됩니다. 다음 안내를 따르세요.
1. 다음 명령어를 실행하여 사용 가능한 출시 채널을 찾습니다.
  kubectl -n istio-system get controlplanerevision
  출력은 다음과 비슷합니다.
  NAME AGE asm-managed-rapid 6d7h
  참고: 위 목록에 두 개의 컨트롤 플레인 버전이 표시되면 하나를 삭제합니다. 클러스터에 여러 컨트롤 플레인 채널을 두는 방식은 지원되지 않습니다.
  
  출력에서 NAME 열 아래의 값은 Cloud Service Mesh 버전에 사용 가능한 출시 채널에 해당하는 버전 라벨입니다.
2. 네임스페이스에 버전 라벨을 적용합니다.
  kubectl label namespace NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
클러스터 내
권장: 다음 명령어를 실행하여 네임스페이스에 기본 삽입 라벨을 적용합니다.
```
  kubectl label namespace NAMESPACE \
      istio.io/rev- istio-injection=enabled --overwrite
```
기본 삽입을 사용하는 것이 좋지만 버전 기반 삽입이 지원됩니다. 다음 안내를 따르세요.
1. 다음 명령어를 사용하여 istiod에서 버전 라벨을 찾습니다.
  kubectl get deploy -n istio-system -l app=istiod -o \ jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
2. 네임스페이스에 버전 라벨을 적용합니다. 다음 명령어에서 REVISION_LABEL은 이전 단계에서 확인한 istiod 버전 라벨의 값입니다.
  kubectl label namespace NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
다음 섹션의 단계를 사용하여 영향을 받는 포드를 다시 시작합니다.

다음과 같이 demo 네임스페이스에 주석을 추가합니다.

kubectl annotate --overwrite namespace NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"true"}'

포드를 다시 시작하여 사이드카 프록시 업데이트

자동 사이드카 삽입을 사용하면 포드를 다시 시작하여 기존 포드의 사이드카를 업데이트할 수 있습니다.

포드를 다시 시작하는 방법은 포드가 배포의 일부로 생성되었는지에 따라 달라집니다.

배포를 사용한 경우 사이드카가 있는 모든 포드가 다시 시작되도록 배포를 다시 시작합니다.
```
kubectl rollout restart deployment -n NAMESPACE
```
배포를 사용하지 않은 경우, 포드를 삭제하면 사이드카로 자동으로 재생성됩니다.
```
kubectl delete pod -n NAMESPACE --all
```
네임스페이스의 모든 포드에 사이드카가 삽입되어 있는지 확인합니다.
```
kubectl get pod -n NAMESPACE
```
위 명령어의 결과로 반환된 다음 출력 예시의 경우 READY 열에서 각 워크로드마다 컨테이너가 2개(기본 컨테이너와 사이드카 프록시 컨테이너)가 있다는 것을 확인할 수 있습니다.
```
NAME                    READY   STATUS    RESTARTS   AGE
WORKLOAD           2/2     Running   0          20s
...
```