클러스터 내 제어 영역에서 선택 기능 사용 설정

이 페이지에서는 클러스터 내 제어 영역에서 선택적 기능을 사용 설정하는 방법을 설명합니다. 관리형 컨트롤 플레인은 관리형 Cloud Service Mesh 구성을 참조하세요.

클러스터 내 Cloud Service Mesh를 설치할 때 기본적으로 사용 설정되는 기능은 플랫폼에 따라 다릅니다. Cloud Service Mesh를 설치(또는 업그레이드)할 때 오버레이 파일을 포함하여 기본 구성을 재정의하고 선택적 기능을 사용 설정할 수 있습니다. 오버레이 파일은 제어 영역을 구성하는 데 사용되는 IstioOperator 커스텀 리소스(CR)를 포함하는 YAML 파일입니다. 오버레이 파일당 하나의 기능을 지정합니다. 오버레이를 더 많이 추가할 수 있으며 각 오버레이 파일은 이전 레이어의 구성을 재정의합니다.

주의: asmcli install을 사용하면 기존 제어 영역 구성을 덮어씁니다. 기존 설치에 선택 기능을 사용 설정하는 경우 사용 설정할 기능에 대한 오버레이 파일뿐 아니라 원래 구성에 유지하려는 모든 파일을 지정해야 합니다. 업그레이드를 통하거나 추가 선택 기능을 사용 설정할 때 동일한 구성을 제어 영역에 적용할 수 있도록 설치에 사용하는 오버레이 파일을 소스 제어에 저장하는 것이 좋습니다. 이렇게 하면 선택적 기능을 사용 설정할 때 다운타임이 발생하지 않습니다.

오버레이 파일 정보

이 페이지의 오버레이 파일은 GitHub의 anthos-service-mesh 패키지에 있습니다. 이러한 파일에는 기본 구성에 대한 일반적인 맞춤설정이 포함되어 있습니다. 이 파일은 그대로 사용하거나 필요에 따라 추가로 변경할 수 있습니다.

Google에서 제공하는 asmcli 스크립트를 사용하여 Cloud Service Mesh를 설치할 때 --option 또는 --custom_overlay 옵션이 있는 하나 이상의 오버레이 파일을 지정할 수 있습니다. anthos-service-mesh 저장소의 파일을 변경할 필요가 없는 경우 --option을 사용할 수 있으며 스크립트가 자동으로 GitHub에서 파일을 가져옵니다. 그렇지 않으면 오버레이 파일을 변경한 후 --custom_overlay 옵션을 사용하여 asmcli에 전달할 수 있습니다.

중요: istioctl install은 파일에서 찾은 첫 번째 CR만 적용하므로 오버레이 파일에 IstioOperator CR을 두 개 이상 지정하지 마세요.

오버레이 파일 하나에 여러 CR을 포함하지 않음	각 CR에 대해 별도의 오버레이 파일 만들기

선택 기능을 사용 설정하는 방법

다음 예시는 간단한 방식으로 커스텀 오버레이만 사용하여 선택적인 기능을 사용 설정하는 방법을 보여줍니다. OTHER_FLAGS를 필수 설치 플래그로 바꿉니다.

중요: 명령줄에서 파일의 순서가 중요합니다. 기본 기능에 필요한 구성을 먼저 지정한 후 오버레이 파일 구성을 지정해야 합니다.

asmcli install 명령어는 선택 기능을 사용 설정하기 위해 두 가지 방법을 제공합니다. 사용하는 방법은 오버레이 파일을 변경해야 하는지 여부에 따라 달라집니다.

• 오버레이 파일에 변경사항을 적용할 필요가 없으면 --option을 사용합니다. --option을 사용할 경우 asmcli이 GitHub 저장소에서 파일을 가져오므로, 인터넷 연결이 필요합니다.

  ./asmcli install \
    OTHER_FLAGS \
    --option OPTION_NAME
  

  OPTION_NAME을 사용 설정하려는 옵션으로 바꿉니다. .yaml 확장자를 생략하고 오버레이 파일 이름(예: iap-operator 및 attached-cluster)만 포함해야 합니다. 옵션 목록은 anthos-service-mesh 패키지를 참조하세요.

• 오버레이 파일을 맞춤설정해야 하는 경우에는 --custom_overlay를 사용합니다.

  ./asmcli install \
    OTHER_FLAGS \
    --custom_overlay PATH_TO_FILE
  

  PATH_TO_FILE를 사용할 오버레이 파일의 경로로 바꿉니다.

선택 기능의 YAML

다음 섹션에서는 선택적 및 지원되는 기능을 사용 설정하기 위한 YAML을 제공합니다.

mTLS STRICT 모드

업그레이드 문제를 방지하고 더 유연한 설치를 제공하기 위해 global.mtls.enabled 구성이 IstioOperator CR에서 삭제되었습니다. STRICT mTLS를 사용 설정하려면 대신 피어 인증 정책을 구성하세요.

Distroless 프록시 이미지

컨테이너 런타임의 콘텐츠를 필요한 패키지로만 제한하는 것이 좋습니다. 이 접근 방법은 CVE(Common Vulnerabilities and Exposure) 스캐너의 보안과 신호 대 잡음비를 향상시킵니다. Istio는 distroless 기본 이미지를 기반으로 프록시 이미지를 제공합니다.

다음 구성은 전체 Cloud 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에서 Cloud Service Mesh를 설치해야 하는 경우 커스텀 레지스트리에 커스텀 오버레이를 사용할 수 있습니다. 예를 들면 다음과 같습니다.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  hub: {private_registry_url}

다음은 커스텀 Container Registry에 미러링해야 하는 Cloud Service Mesh의 이미지 목록입니다.

• Install-cni - gke.gcr.io/asm/install-cni:1.15.7-asm.23
• 관리형 데이터 영역 - gke.gcr.io/asm/mdp:1.15.7-asm.23
• 파일럿 - gke.gcr.io/asm/pilot:1.15.7-asm.23
• Proxyv2 - gke.gcr.io/asm/proxyv2:1.15.7-asm.23

참고: 표준 서비스를 사용하는 경우 커스텀 컨테이너 레지스트리 gcr.io/kubebuilder/kube-rbac-proxy:v0.13.1 및 gke.gcr.io/asm/canonical-service-controller:1.10.3-asm.16도 미러링해야 합니다.

비공개 레지스트리에 이미지 추가

Cloud Service Mesh 이미지를 비공개 레지스트리로 내보내려면 다음 단계를 완료하세요.

참고: gcr.io에서 가져오고 비공개 레지스트리로 내보낼 수 있는 클라이언트를 사용합니다.

1. Cloud Service Mesh 이미지를 가져옵니다.

   docker pull gke.gcr.io/asm/install-cni:1.15.7-asm.23
   docker pull gke.gcr.io/asm/mdp:1.15.7-asm.23
   docker pull gke.gcr.io/asm/pilot:1.15.7-asm.23
   docker pull gke.gcr.io/asm/proxyv2:1.15.7-asm.23
   

2. 비공개 레지스트리 URL의 변수를 만듭니다.

   export PRIVATE_REGISTRY_URL=PRIVATE_REGISTRY_URL
   

   PRIVATE_REGISTRY_URL을 비공개 레지스트리 URL로 바꿉니다.
3. 비공개 레지스트리 URL로 이미지에 태그를 지정합니다.

   docker tag gke.gcr.io/asm/install-cni:1.15.7-asm.23 \
    ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/install-cni:1.15.7-asm.23
   docker tag gke.gcr.io/asm/mdp:1.15.7-asm.23 \
    ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/mdp:1.15.7-asm.23
   docker tag gke.gcr.io/asm/pilot:1.15.7-asm.23 \
    ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/pilot:1.15.7-asm.23
   docker tag gke.gcr.io/asm/proxyv2:1.15.7-asm.23 \
    ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/proxyv2:1.15.7-asm.23
   

4. 태그가 지정된 이미지를 비공개 레지스트리로 내보냅니다.

   docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/install-cni:1.15.7-asm.23
   docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/mdp:1.15.7-asm.23
   docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/pilot:1.15.7-asm.23
   docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/proxyv2:1.15.7-asm.23
   

5. (선택사항) 표준 서비스를 사용하는 경우 표준 서비스 이미지를 비공개 레지스트리에 추가합니다.
   1. Cloud Service Mesh 표준 서비스 이미지를 가져옵니다.

              docker pull gcr.io/kubebuilder/kube-rbac-proxy:v0.13.1
              docker pull gke.gcr.io/asm/canonical-service-controller:1.10.3-asm.16
              

   2. 비공개 레지스트리 URL로 이미지에 태그를 지정합니다.

              docker tag gcr.io/kubebuilder/kube-rbac-proxy:v0.13.1 \
              ${PRIVATE_REGISTRY_URL}/gcr.io/kubebuilder/kube-rbac-proxy:v0.13.1
              docker tag gke.gcr.io/asm/canonical-service-controller:1.10.3-asm.16 \
              ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/canonical-service-controller:1.10.3-asm.16
              

   3. 태그가 지정된 이미지를 비공개 레지스트리로 내보냅니다.

              docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/kube-rbac-proxy:v0.13.1
              docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/canonical-service-controller:1.10.3-asm.16
              

비공개 레지스트리에서 태그가 지정된 이미지를 가져올 수 있다면 절차가 성공적으로 완료된 것입니다.

종료 드레이닝 기간 늘리기

기본적으로 Envoy는 포드가 종료될 때 기존 연결이 완료될 때까지 5초(5s)를 기다립니다.

포드 terminationGracePeriodSeconds는 terminationDrainDuration 값보다 커야 합니다.

자세한 내용은 전역 메시 옵션을 참조하세요.

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    defaultConfig:
      terminationDrainDuration: 30s

액세스 로그 사용 설정

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: "/dev/stdout"

자세한 내용은 Envoy의 액세스 로깅 사용 설정을 참조하세요.

Cloud Trace

Cloud Trace는 다음 플랫폼에서 Cloud Service Mesh 설치와 함께 제공됩니다.

• Google Cloud 기반 GKE
• Cloud Service Mesh 인증 기관으로 설치하는 경우 온프레미스 GKE Enterprise 클러스터

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    enableTracing: true
  values:
    global:
      proxy:
        tracer: stackdriver

자세한 내용은 trace 액세스를 참조하세요.

이그레스 게이트웨이를 통한 이그레스

게이트웨이 설치 및 업그레이드에 설명된 대로 삽입된 게이트웨이를 설치하는 것이 좋습니다.

Istio 컨테이너 네트워크 인터페이스

Istio 컨테이너 네트워크 인터페이스(CNI)를 사용 설정하는 방법은 Cloud Service Mesh가 설치된 환경에 따라 달라집니다.

1. 네트워크 정책을 사용 설정합니다.

2. 플랫폼과 일치하는 오버레이 파일을 선택합니다.

GKE에서 CNI 사용 설정

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    cni:
      enabled: true
      namespace: kube-system
  values:
    cni:
      cniBinDir: /home/kubernetes/bin
      excludeNamespaces:
        - istio-system
        - kube-system

CNI 온프레미스 사용 설정

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    cni:
      enabled: true
      namespace: kube-system
  values:
    cni:
      cniBinDir: /opt/cni/bin
      excludeNamespaces:
        - istio-system
        - kube-system
        - gke-system

Google Cloud 외부 트래픽 로그 사용 설정

Google Cloud 외부에서 Istio CA가 포함된 Cloud Service Mesh를 설치하면 기본적으로 Prometheus에 측정항목이 보고됩니다. Cloud Service Mesh 대시보드를 사용할 수 있도록 이 옵션을 사용하여 트래픽 로그를 대신 보고하거나 Prometheus와 Stackdriver를 모두 사용 설정합니다.

Stackdriver만

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  values:
    telemetry:
      enabled: true
      v2:
        enabled: true
        prometheus:
          enabled: false
        stackdriver:
          enabled: true

Stackdriver 및 Prometheus

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  values:
    telemetry:
      enabled: true
      v2:
        enabled: true
        prometheus:
          enabled: true
        stackdriver:
          enabled: true

내부 부하 분산기 사용 설정

게이트웨이 설치 및 업그레이드에 설명된 대로 삽입된 게이트웨이를 설치하여 GKE에 내부 부하 분산기를 설정하는 것이 좋습니다. 게이트웨이 서비스를 구성할 때 networking.gke.io/load-balancer-type: "Internal" 주석을 포함합니다.

인그레스 게이트웨이의 외부 인증서 관리

Envoy SDS를 사용하여 인그레스 게이트웨이에서 외부 인증서 관리를 사용 설정하는 방법에 대한 자세한 내용은 보안 게이트웨이를 참조하세요.