Kubernetes 워크로드 온보딩

참고: 이 가이드는 Istio API가 포함된 Cloud Service Mesh만 지원하고 Google Cloud API를 지원하지 않습니다. 자세한 내용은 Cloud Service Mesh 개요를 참조하세요.

이 페이지에서는 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 저장소의 원래 매니페스트 세트에서 수정됩니다. 권장사항에 따라 각 서비스는 고유한 서비스 계정을 사용하여 별도의 네임스페이스에 배포됩니다.

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

   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
   

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

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

   1. 다음 명령어를 실행하여 사용 가능한 출시 채널을 찾습니다.

      kubectl -n istio-system get controlplanerevision
      

      출력은 다음과 비슷합니다.

      NAME                AGE
      asm-managed-rapid   6d7h
      

      참고: 이전 목록에 두 개의 컨트롤 플레인 버전이 표시되면 하나를 삭제합니다. 클러스터에 여러 컨트롤 플레인 채널을 두는 방식은 지원되지 않습니다.

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

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

      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;
   

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

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

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

   2. 네임스페이스에 버전 라벨을 적용합니다. 다음 명령어에서 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;
      

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

   1. 서비스 계정 및 배포 생성:

      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
      

   2. 서비스 생성:

      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
      

   3. 서비스 항목 생성:

      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 역할을 참조하세요.

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

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

   관리형(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
      

2. 다음 섹션의 단계를 사용하여 영향을 받는 포드를 다시 시작합니다.

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

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

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

주의: 블루-그린 배포용으로 부하 분산기 또는 라우터가 설정되어 있지 않으면 스테이징 환경에서 포드 재시작을 테스트하여 서비스에서 잠재적인 트래픽 중단을 처리할 수 있는지 확인합니다.

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

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

1. 배포를 사용한 경우 사이드카가 있는 모든 포드가 다시 시작되도록 배포를 다시 시작합니다.

   kubectl rollout restart deployment -n NAMESPACE

   배포를 사용하지 않은 경우, 포드를 삭제하면 사이드카로 자동으로 재생성됩니다.

   kubectl delete pod -n NAMESPACE --all

2. 네임스페이스의 모든 포드에 사이드카가 삽입되어 있는지 확인합니다.

   kubectl get pod -n NAMESPACE

   위 명령어의 결과로 반환된 다음 출력 예시의 경우 READY 열에서 각 워크로드마다 컨테이너가 2개(기본 컨테이너와 사이드카 프록시 컨테이너)가 있다는 것을 확인할 수 있습니다.

   NAME                    READY   STATUS    RESTARTS   AGE
   WORKLOAD           2/2     Running   0          20s
   ...