Istio 설정

Istio 추가 기능 설치

커뮤니티 Istio 대신 관리 Istio 추가 기능을 설치할 수 있습니다.

시작하기 전에

• 당신이 가지고 있는지 확인하십시오 작가 또는 관리자 IBM Cloud IAM 서비스 액세스 역할 ~을 위한 IBM Cloud Kubernetes Service.
• 코어가 4개이고 메모리가 16GB 이상인 작업자 노드가 3개 이상 있는 표준 Kubernetes 클러스터(b3c.4x16)를 작성하십시오.
• 클러스터의 관리 Istio 추가 기능과 동시에 커뮤니티 Istio를 실행할 수 없습니다. 기존 클러스터를 사용하며 이전에 IBM Helm 차트를 사용하거나 다른 방법을 통해 클러스터에 Istio를 설치한 경우에는 해당 Istio 설치를 제거하십시오.
• 클래식 다중 구역 클러스터: IBM Cloud 인프라 계정에 대해 VRF(Virtual Routing and Forwarding) 를 사용으로 설정했는지 확인하십시오. VRF를 사용으로 설정하려면 VRF 사용을 참조하십시오. VRF가 이미 사용으로 설정되었는지 확인하려면 ibmcloud account show 명령을 사용하십시오. VRF를 사용할 수 없거나 사용하지 않으려면 VLAN Spanning을 사용으로 설정하십시오. 이 작업을 수행하려면 다음이 필요합니다. 네트워크 VLAN 스패닝 관리 인프라 권한을 부여하거나 계정 소유자에게 이를 활성화하도록 요청할 수 있습니다. VLAN 스패닝이 이미 활성화되어 있는지 확인하려면 ibmcloud ks vlan spanning get --region <region> 명령.

추가 기능 업데이트

IBM Cloud 에 의해 테스트되고 IBM Cloud Kubernetes Service에서 사용하도록 승인된 Istio 추가 기능을 업데이트하십시오.

관리 추가 기능을 사용하여 설치된 Istio 버전을 업데이트하려면 istioctl을 사용하지 마십시오. Istio 버전의 업데이트를 포함한 관리 Istio 추가 기능을 업데이트하려면 다음 단계만 사용하십시오.

지원되지 않는 버전의 Istio 추가 기능에서 업데이트하려면 Istio 컴포넌트 를 IBM Cloud Kubernetes Service에서 지원되는 최신 패치 버전으로 업데이트하십시오.

Istio 설치 사용자 정의

managed-istio-custom configmap 리소스를 편집하여 Istio 구성 옵션 세트를 사용자 정의할 수 있습니다. 이러한 설정에는 제어 플레인 및 서비스 메시의 모니터링, 로깅 및 네트워킹에 대한 추가 제어가 포함됩니다.

1. 해당 컨텐츠 및 인라인 문서를 검토하기 위해 managed-istio-custom configmap 리소스에 대해 설명하십시오.

   kubectl describe cm managed-istio-custom -n ibm-operators
   

2. managed-istio-custom configmap 리소스를 편집하십시오.

   kubectl edit cm managed-istio-custom -n ibm-operators
   

3. data 섹션에서 다음 구성 옵션 중 하나 이상의 <key>: "<value>" 쌍을 추가하십시오.

   istio-components-pilot-requests-cpu

   기본값: "500m"

   CPU 요청을 구성합니다.milli CPU istiod 구성 요소 포드. 이 값을 변경하는 경우 주의하십시오. 이 값을 너무 낮게 설정하면 제어 플레인이 올바르게 작동하지 않을 수 있으며, 너무 높게 설정하면 istiod 팟(Pod)이 스케줄되지 않을 수 있습니다.

   istio-global-logging-level

   기본값: "default:info"

   제어 플레인 컴포넌트에 대한 로그 범위 및 로그 메시지의 레벨을 정의합니다. 범위는 제어 플레인 컴포넌트 내 기능 영역을 나타내며 각 범위는 특정 로그 정보 레벨을 지원합니다. 카테고리화되지 않은 로그 메시지를 위한 default 로깅 범위는 기본 info 레벨에서 제어 플레인의 모든 구성요소에 적용됩니다.

   개별 컴포넌트 범위의 로그 레벨을 지정하려면 쉼표로 구분된 범위 및 레벨 목록을 입력하십시오(예: "<scope>:<level>,<scope>:<level>"). 각 제어 플레인 구성요소의 범위 목록과 로그 메시지의 정보 수준은 다음을 참조하세요. Istio 구성요소 로깅 문서. 데이터 플레인의 로그 수준을 변경하려면 istioctl proxy-config log <pod> --level <level> 명령.

   istio-global-outboundTrafficPolicy-mode

   기본값: "ALLOW_ANY"

   기본적으로 서비스 메시의 모든 아웃바운드 트래픽이 허용됩니다. 서비스 메시에서 서비스 레지스트리에 정의되지 않았거나 서비스 메시 내에 ServiceEntry가 없는 호스트로 향하는 아웃바운드 트래픽을 차단하려는 경우 REGISTRY_ONLY로 설정합니다.

   istio-egressgateway-public-1-enabled

   기본값: "true"

   기본 Istio 송신 게이트웨이를 비활성화하려면 다음으로 설정합니다."false". 예를 들면, 대신 사용자 정의 Egress 게이트웨이를 작성할 수 있습니다.

   istio-global-proxy-accessLogFile

   기본값: ""

   Envoy 프록시는 액세스 정보를 표준 출력으로 표시합니다. 이러한 로그는 수신 또는 송신 문제를 디버그할 때 유용합니다. Envoy 컨테이너에 대해 kubectl logs 명령을 실행할 때 이 액세스 정보를 보려는 경우 "/dev/stdout"으로 설정합니다.

   istio-ingressgateway-public-1|2|3-enabled

   기본값: 구역 1의 "true"만 해당합니다.

   앱의 고가용성을 높이려면 공용 istio-ingressgateway 로드 밸런서를 작성할 각 구역에 대해 "true"(으)로 설정하십시오. 기본 Ingress 게이트웨이 대신 사용자 정의 Ingress 게이트웨이를 사용하려는 경우에는 "false"로 설정할 수 있습니다.

   istio-ingressgateway-zone-1|2|3

   기본값: "<zone>"

   추가 기능을 설치할 때 및 Istio 패치 업데이트를 적용할 때마다 자동으로 채워지는, 작업자 노드가 배치되는 구역입니다. 이러한 필드는 클러스터의 구역을 istio-ingressgateway-public-1|2|3-enabled 필드에 적용합니다. 이 설정에 나열된 영역이 클러스터 영역과 동기화되지 않은 경우 다음을 실행하여 자동 채우기 작업을 다시 시작할 수 있습니다.kubectl delete pod -n ibm-system -l addon.cleanup=istio 그리고 kubectl delete job -n ibm-system -l addon.cleanup=istio.

   istio-monitoring-telemetry

   기본값: "true"

   기본적으로 텔레메트리 메트릭 및 Prometheus 지원이 사용 가능합니다. 텔레메트리 메트릭과 연관된 성능 문제를 제거하고 모니터링을 모두 사용 안함으로 설정하려면 "false"로 설정하십시오.

   istio-meshConfig-enableTracing

   기본값: "true"

   기본적으로, Istio는 100개의 요청마다 1개의 추적 범위를 생성합니다. 추적 범위를 사용하지 않으려면 "false"로 설정하십시오.

   istio-pilot-traceSampling

   기본값: "1.0"

   기본적으로 Istio 는 100개의 요청마다 1개의 추적 범위를 생성합니다.이는 샘플링 비율 1%입니다. 추가 추적 범위를 생성하려면 백분율 값을 늘리십시오.

   istio-components-pilot-hpa-maxReplicas

   기본값: "5"

   기본적으로 Istio는 istiod에 대한 기본 HPA(Horizontal Pod Autoscaler) 최대 Pod를 5로 설정합니다. 구성을 업데이트하기 위해 istiod에 증가된 리소스가 필요한 대규모 서비스 메시가 있는 경우가 아니면 이 값을 늘리지 마십시오.

   예를 들어, Configmap은 다음 예제와 같습니다.

   apiVersion: v1
   data:
     istio-ingressgateway-zone-1: dal10
     <key: value> # such as istio-egressgateway-public-1-enabled: "false"
   kind: ConfigMap
   metadata:
     name: managed-istio-custom
     namespace: ibm-operators
   

   configmap에 이 테이블의 옵션이 표시되지 않습니까? ConfigMap에 사용자 정의 값이 포함되어 있어 ConfigMap이 시간이 지나면서 릴리스된 옵션으로 업데이트되지 않은 것입니다. 대신 configmap의 사본을 백업한 후 클러스터에서 해당 configmap을 삭제할 수 있습니다. 약 5분 후 클러스터에 새 옵션이 포함된 기본 configmap이 작성됩니다. 이제 이전에 구성된 설정을 백업에서 이 기본 configmap으로 복사하고 새 설정을 구성한 후 변경사항을 적용할 수 있습니다.

4. 구성 파일을 저장하고 닫으십시오.

5. istio-global-logging-level 또는 istio-global-proxy-accessLogFile 설정을 변경한 경우, 데이터 플레인 팟(Pod)에 변경사항을 적용하려면 해당 팟을 다시 시작해야 합니다.

   1. istio-system 네임스페이스에 없는 모든 데이터 플레인 팟(Pod)의 목록을 가져오십시오.

      istioctl version --short=false | grep "data plane version" | grep -v istio-system
      

      출력 예

      data plane version: version.ProxyInfo{ID:"test-6f86fc4677-vsbsf.default", IstioVersion:"1.22.1"}
      data plane version: version.ProxyInfo{ID:"rerun-xfs-f8958bb94-j6n89.default", IstioVersion:"1.22.1"}
      data plane version: version.ProxyInfo{ID:"test2-5cbc75859c-jh6bx.default", IstioVersion:"1.22.1"}
      data plane version: version.ProxyInfo{ID:"minio-test-78b5d4597d-hkpvt.default", IstioVersion:"1.22.1"}
      data plane version: version.ProxyInfo{ID:"sb-887f89d7d-7s8ts.default", IstioVersion:"1.22.1"}
      data plane version: version.ProxyInfo{ID:"gid-deployment-5dc86db4c4-kdshs.default", IstioVersion:"1.22.1"}
      

   2. 각 팟(Pod)을 삭제하여 다시 시작하십시오. 이전 단계의 출력에서는 팟 이름과 네임스페이스가 각 항목에 data plane version: version.ProxyInfo{ID:"<pod_name>.<namespace>", IstioVersion:"1.22.1"}(으)로 나열됩니다.

      kubectl delete pod <pod_name> -n <namespace>
      

변경하고 싶으신가요? ConfigMap 환경?

Configmap에 추가한 설정을 변경하려면 패치 스크립트를 사용할 수 있습니다. 예를 들어, istio-global-proxy-accessLogFile: "/dev/stdout" 설정을 추가했고 나중에 다시 ""로 변경하려는 경우 kubectl patch cm managed-istio-custom -n ibm-operators --type='json' -p='[{"op": "add", "path": "/data/istio-global-proxy-accessLogFile", "value":""}]'를 실행할 수 있습니다.

사용자 정의 설정을 디버깅해야 합니까?

로그를 확인하세요.addon-istio-operator (Istio 버전 1.10 또는 그 이후) 또는 managed-istio-operator (Istio 버전 1.9 또는 이전) 포드를 실행하여 kubectl logs -n ibm-operators -l name=managed-istio-operator. Istio 오퍼레이터는 사용자에 의해 변경된 모든 사용자 정의 Istio 변경사항을 유효성 검증하고 조정합니다.

Istio 추가 기능을 사용 안함으로 설정하면 managed-istio-custom configmap이 설치 제거 중에 제거되지 않습니다. Istio 추가 기능을 다시 사용으로 설정하는 경우 사용자 정의된 configmap이 설치 중에 적용됩니다. 이후의 Istio 설치에서 사용자 정의 설정을 다시 사용하지 않으려면 kubectl delete cm -n ibm-operators managed-istio-custom을(를) 실행하여 Istio 추가 기능을 사용 안함으로 설정한 후에는 configmap을 삭제해야 합니다. Istio 추가 기능을 다시 사용으로 설정하면 기본 configmap이 설치 중에 적용됩니다.

Istio 추가 기능 설치 제거

Istio 작업을 마치면 클러스터에서 Istio 리소스를 정리하고 Istio 추가 기능을 제거할 수 있습니다.

kubectl delete deployment -n ibm-operators addon-istio-operator --ignore-not-found=true
kubectl delete serviceaccount -n ibm-operators addon-istio-operator --ignore-not-found=true
kubectl delete clusterrolebinding addon-istio-operator --ignore-not-found=true
kubectl delete clusterrole addon-istio-operator --ignore-not-found=true

클러스터에서 기타 Istio 설치의 설치 제거

이전에 IBM Helm 차트의 사용이나 기타 방법을 통해 Istio를 클러스터에 설치한 경우에는 클러스터에서 관리 Istio 추가 기능을 사용으로 설정하기 전에 해당 Istio 설치를 제거하십시오. Istio가 이미 클러스터에 있는지 확인하려면 kubectl get namespaces를 실행하여 해당 출력에서 istio-system 네임스페이스를 찾으십시오.

• IBM Cloud Istio Helm 차트를 사용하여 Istio를 설치한 경우

  1. Istio Helm 배치를 설치 제거하십시오.

     helm del istio --purge
     

  2. Helm 2.9 이하를 사용한 경우, 추가 작업 리소스를 삭제하십시오.

     kubectl -n istio-system delete job --all
     

  3. 설치 제거 프로세스는 최대 10분 정도 소요됩니다. 클러스터에 Istio 관리 추가 기능을 설치하기 전에 우선 kubectl get namespaces를 실행하고 istio-system 네임스페이스가 제거되었는지 확인하십시오.

• Istio를 수동으로 설치했거나 Istio 커뮤니티를 사용한 경우 Helm 차트를 참조하세요. Istio 제거 문서.

• 이전에 클러스터에 BookInfo를 설치한 경우 해당 리소스를 정리하십시오.

  1. 디렉토리를 Istio 파일 위치로 변경하십시오.

     cd <filepath>/istio-1.22.1
     

  2. 클러스터에서 모든 BookInfo 서비스, 팟(Pod) 및 배치를 삭제하십시오.

     samples/bookinfo/platform/kube/cleanup.sh
     

  3. 설치 제거 프로세스는 최대 10분 정도 소요됩니다. 클러스터에 Istio 관리 추가 기능을 설치하기 전에 우선 kubectl get namespaces를 실행하고 istio-system 네임스페이스가 제거되었는지 확인하십시오.

Istio 추가 기능 문제점 해결

관리 Istio 추가 기능을 사용할 때 발생할 수 있는 일부 공통적인 문제를 해결하려면 관리 추가 기능 문제점 해결을 참조하십시오.

2단계: Istio 연산자 제거

Istio 오퍼레이터 배치, 서비스 계정, 클러스터 역할 바인딩, 클러스터 역할을 삭제하십시오.

다음 명령을 실행하십시오.

kubectl delete deployment -n ibm-operators addon-istio-operator --ignore-not-found=true
kubectl delete serviceaccount -n ibm-operators addon-istio-operator --ignore-not-found=true
kubectl delete clusterrolebinding addon-istio-operator --ignore-not-found=true
kubectl delete clusterrole addon-istio-operator --ignore-not-found=true

3단계: 자원 저장

생성하거나 수정한 리소스를 저장합니다.istio-system 네임스페이스와 모두 Kubernetes 사용자 정의 리소스 정의(CRD)에 의해 자동으로 생성된 리소스입니다.

1. IOP에서 파이널라이저를 삭제하십시오. managed-istio IOP 사용 예:

   kubectl patch -n ibm-operators istiooperator/managed-istio --type json --patch='[ { "op": "remove", "path": "/metadata/finalizers" } ]'
   

2. managed-istio-custom ConfigMap 을 저장하여 문제점을 해결하거나 나중에 추가 기능을 다시 설치하십시오.

   kubectl get cm -n ibm-operators managed-istio-custom -o yaml > Customizations.yaml
   

3. 모든 IstioOperator CR (IOP) 을 저장하십시오.

   a. IOP 자원을 나열하십시오.

   kubectl get iop -A
   

   b. 나열된 각 IOP 자원에 대해 각 자원을 파일에 저장하십시오.

   kubectl get iop -n <IOP_namespace> <IOP_name> -o yaml > <IOP_name>.yaml
   

4. 다시 적용할 준비를 하려면 저장된 YAML 파일에서 status 섹션을 제거하십시오. metadata 섹션에서 name 및 namespace 를 유지하고 다른 모든 정보는 제거하십시오.

   결과:

   apiVersion: install.istio.io/v1alpha1
   kind: IstioOperator
   metadata:
     name: NAME
     namespace: NAMESPACE
   spec:
     <spec_info>
   

5. 다음 단계를 계속하기 전에 10분 동안 기다리십시오.

4단계: IOP의 설치 프로그램 변경

사용자 정의 Ingress 게이트웨이의 경우와 같이 모든 Istio 운영자 (IOP) 자원을 삭제하십시오.

1. Istio 운영자에 대해 delete 명령을 실행하여 IOP 자원이 작성한 자원 (예: 배치 또는 서비스) 을 자동으로 제거하십시오.

   kubectl delete IstioOperator <resource_name> -n <namespace>
   

2. 이전 단계에서 저장한 각 IOP 파일에 대해 upgrade 명령을 실행하십시오.

   istioctl upgrade -f <filename>.yaml
   

5단계: 제거 ConfigMap

ConfigMap 이 이전에 저장되었으므로 제거할 수 있습니다.

managed-istio-custom ConfigMap을 제거하십시오.

kubectl delete cm -n ibm-operators managed-istio-custom

추가 기능 제거가 완료되었으며 필요에 따라 커뮤니티 Istio를 계속 사용하고 업그레이드할 수 있습니다.