프로덕션 환경에서 Kubernetes를 사용하여 Istio를 실행하는 방법입니다. 1 부

무엇인가 이스 티오? 이것은 네트워크에 추상화 계층을 추가하는 기술인 소위 서비스 메시입니다. 우리는 클러스터에서 트래픽의 전부 또는 일부를 가로채서 특정 작업 집합을 수행합니다. 어느 것? 예를 들어 스마트 라우팅을 수행하거나 회로 차단기 접근 방식을 구현하거나 "카나리아 배포"를 구성하여 부분적으로 트래픽을 새 버전의 서비스로 전환하거나 외부 상호 작용을 제한하고 클러스터에서 클러스터로의 모든 이동을 제어할 수 있습니다. 외부 네트워크. 서로 다른 마이크로 서비스 간의 이동을 제어하는 ​​정책 규칙을 설정할 수 있습니다. 마지막으로, 우리는 전체 네트워크 상호작용 맵을 얻을 수 있고 통합 메트릭 모음을 애플리케이션에 완전히 투명하게 만들 수 있습니다.

작업 메커니즘에 대해 읽을 수 있습니다. 공식 문서. Istio는 많은 작업과 문제를 해결할 수 있는 정말 강력한 도구입니다. 이 기사에서는 Istio를 시작할 때 일반적으로 발생하는 주요 질문에 답하고 싶습니다. 이것은 당신이 그것을 더 빨리 처리하는 데 도움이 될 것입니다.

운영 원칙

Istio는 컨트롤 플레인과 데이터 플레인의 두 가지 주요 영역으로 구성됩니다. 컨트롤 플레인에는 나머지의 올바른 작동을 보장하는 주요 구성 요소가 포함되어 있습니다. 현재 버전(1.0)에서 컨트롤 플레인에는 파일럿, 믹서, 시타델의 세 가지 주요 구성 요소가 있습니다. 우리는 Citadel을 고려하지 않을 것이며 서비스 간 상호 TLS를 보장하기 위해 인증서를 생성하는 데 필요합니다. 파일럿과 믹서의 장치와 용도에 대해 자세히 살펴보겠습니다.

파일럿은 클러스터에 있는 서비스, 엔드포인트 및 라우팅 규칙(예: 카나리아 배포 규칙 또는 회로 차단기 규칙)에 대한 모든 정보를 배포하는 주요 제어 구성 요소입니다.

Mixer는 메트릭, 로그 및 네트워크 상호 작용에 대한 정보를 수집하는 기능을 제공하는 선택적 컨트롤 플레인 구성 요소입니다. 또한 정책 규칙 준수 및 속도 제한 준수를 모니터링합니다.

데이터 평면은 사이드카 프록시 컨테이너를 사용하여 구현됩니다. 강력함은 기본적으로 사용됩니다. 사절 대리인. nginx(nginmesh)와 같은 다른 구현으로 대체할 수 있습니다.

Istio가 애플리케이션에 완전히 투명하게 작동하기 위해 자동 주입 시스템이 있습니다. 최신 구현은 Kubernetes 1.9+ 버전(변형 허용 웹훅)에 적합합니다. Kubernetes 버전 1.7, 1.8의 경우 Initializer를 사용할 수 있습니다.

사이드카 컨테이너는 클러스터에서 발생하는 변경 사항에 대해 푸시 모델을 최적화할 수 있는 GRPC 프로토콜을 사용하여 파일럿에 연결됩니다. GRPC는 버전 1.6부터 Envoy에서 사용되었고 Istio에서는 버전 0.8부터 사용되었으며 시작 옵션을 구성하는 envoy에 대한 golang 래퍼인 파일럿 에이전트입니다.

파일럿과 믹서는 완전히 상태 비저장 구성 요소이며 모든 상태는 메모리에 보관됩니다. 이에 대한 구성은 etcd에 저장되는 Kubernetes 사용자 지정 리소스 형식으로 설정됩니다.
Istio-agent는 파일럿의 주소를 가져와 GRPC 스트림을 엽니다.

내가 말했듯이 Istio는 애플리케이션에 완전히 투명한 모든 기능을 구현합니다. 방법을 알아보겠습니다. 알고리즘은 다음과 같습니다.

1. 새 버전의 서비스를 배포합니다.
2. 사이드카 컨테이너 주입 방식에 따라 구성 적용 단계에서 istio-init 컨테이너와 istio-agent 컨테이너(envoy)가 추가되거나 이미 수동으로 Kubernetes Pod 엔티티의 디스크립션에 삽입될 수 있습니다.
3. istio-init 컨테이너는 포드에 iptables 규칙을 적용하는 스크립트입니다. istio-agent 컨테이너에서 래핑할 트래픽을 구성하는 두 가지 옵션이 있습니다. iptables 리디렉션 규칙 사용 또는 트프록시. 작성 당시 기본 접근 방식은 리디렉션 규칙을 사용하는 것입니다. istio-init에서 가로채서 istio-agent로 전송해야 하는 트래픽을 구성할 수 있습니다. 예를 들어 들어오는 모든 트래픽과 나가는 모든 트래픽을 가로채려면 매개변수를 설정해야 합니다. -i и -b 의미상 *. 차단할 특정 포트를 지정할 수 있습니다. 특정 서브넷을 가로채지 않으려면 플래그를 사용하여 지정할 수 있습니다. -x.
4. 초기화 컨테이너가 실행된 후 파일럿 에이전트(특사)를 포함하여 기본 컨테이너가 시작됩니다. GRPC를 통해 이미 배포된 파일럿에 연결하고 클러스터의 모든 기존 서비스 및 라우팅 정책에 대한 정보를 받습니다. 받은 데이터에 따라 그는 클러스터를 구성하고 이를 Kubernetes 클러스터에 있는 애플리케이션의 엔드포인트에 직접 할당합니다. 또한 중요한 점에 유의해야 합니다. envoy는 수신을 시작하는 수신기(IP, 포트 쌍)를 동적으로 구성합니다. 따라서 요청이 팟(Pod)에 입력되고 사이드카의 리디렉션 iptables 규칙을 사용하여 리디렉션되면 Envoy는 이미 이러한 연결을 성공적으로 처리하고 트래픽을 추가로 프록시할 위치를 이해할 수 있습니다. 또한 이 단계에서는 나중에 살펴볼 Mixer로 정보가 전송되고 추적 스팬이 전송됩니다.

결과적으로 우리는 한 지점(파일럿)에서 구성할 수 있는 사절 프록시 서버의 전체 네트워크를 얻습니다. 모든 인바운드 및 아웃바운드 요청은 특사를 거칩니다. 또한 TCP 트래픽만 차단됩니다. 즉, Kubernetes 서비스 IP는 변경 없이 UDP를 통해 kube-dns를 사용하여 확인됩니다. 그런 다음 해결 후 나가는 요청을 가로채서 envoy가 처리합니다. envoy는 이미 요청을 보낼 끝점을 결정합니다(또는 액세스 정책 또는 알고리즘의 회로 차단기의 경우 보내지 않음).

우리는 Pilot을 알아냈고 이제 Mixer가 어떻게 작동하고 왜 필요한지 이해해야 합니다. 당신은 그것에 대한 공식 문서를 읽을 수 있습니다 여기에.

현재 형태의 믹서는 istio-telemetry, istio-policy(버전 0.8 이전에는 하나의 istio-mixer 구성 요소였습니다)의 두 가지 구성 요소로 구성됩니다. 둘 다 믹서이며 각각 자체 작업을 담당합니다. Istio 원격 측정은 GRPC를 통해 사이드카 보고서 컨테이너에서 누가 어떤 매개변수로 어디로 가는지에 대한 정보를 수신합니다. Istio-policy는 Policy 규칙이 충족되었는지 확인하기 위해 Check 요청을 수락합니다. 물론 정책 검사는 모든 요청에 ​​대해 수행되지는 않지만 일정 시간 동안 클라이언트(사이드카)에 캐시됩니다. 보고서 확인은 일괄 요청으로 전송됩니다. 나중에 구성하는 방법과 어떤 매개 변수를 보내야 하는지 살펴보겠습니다.

믹서는 원격 측정 데이터의 조립 및 처리에 대한 중단 없는 작업을 보장하는 고가용성 구성 요소로 간주됩니다. 시스템은 결과적으로 다중 레벨 버퍼로 획득됩니다. 처음에는 데이터가 컨테이너의 사이드카 측에 버퍼링된 다음 믹서 측에 버퍼링된 다음 소위 믹서 백엔드로 전송됩니다. 결과적으로 시스템 구성 요소 중 하나라도 실패하면 버퍼가 커지고 시스템이 복원된 후 플러시됩니다. 믹서 백엔드는 원격 분석 데이터(statsd, newrelic 등)를 전송하기 위한 엔드포인트입니다. 자신만의 백엔드를 작성할 수 있습니다. 매우 간단하며 그 방법을 살펴보겠습니다.

요약하면 istio-telemetry 작업 방식은 다음과 같습니다.

1. 서비스 1은 서비스 2에 요청을 보냅니다.
2. 서비스 1을 떠날 때 요청은 자체 사이드카에 래핑됩니다.
3. Sidecar envoy는 요청이 서비스 2로 어떻게 가는지 모니터링하고 필요한 정보를 준비합니다.
4. 그런 다음 보고 요청을 사용하여 istio-telemetry로 보냅니다.
5. Istio-telemetry는 이 보고서를 백엔드로 보낼지 여부, 보낼 데이터 및 보낼 데이터를 결정합니다.
6. Istio-telemetry는 필요한 경우 보고서 데이터를 백엔드로 보냅니다.

이제 주요 구성 요소(파일럿 및 사이드카 특사)로만 구성된 Istio를 시스템에 배포하는 방법을 살펴보겠습니다.

먼저 파일럿이 읽는 기본 구성(메시)을 살펴보겠습니다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: istio
  namespace: istio-system
  labels:
    app: istio
    service: istio
data:
  mesh: |-

    # пока что не включаем отправку tracing информации (pilot настроит envoy’и таким образом, что отправка не будет происходить)
    enableTracing: false

    # пока что не указываем mixer endpoint’ы, чтобы sidecar контейнеры не отправляли информацию туда
    #mixerCheckServer: istio-policy.istio-system:15004
    #mixerReportServer: istio-telemetry.istio-system:15004

    # ставим временной промежуток, с которым будет envoy переспрашивать Pilot (это для старой версии envoy proxy)
    rdsRefreshDelay: 5s

    # default конфигурация для envoy sidecar
    defaultConfig:
      # аналогично как rdsRefreshDelay
      discoveryRefreshDelay: 5s

      # оставляем по умолчанию (путь к конфигурации и бинарю envoy)
      configPath: "/etc/istio/proxy"
      binaryPath: "/usr/local/bin/envoy"

      # дефолтное имя запущенного sidecar контейнера (используется, например, в именах сервиса при отправке tracing span’ов)
      serviceCluster: istio-proxy

      # время, которое будет ждать envoy до того, как он принудительно завершит все установленные соединения
      drainDuration: 45s
      parentShutdownDuration: 1m0s

      # по умолчанию используются REDIRECT правила iptables. Можно изменить на TPROXY.
      #interceptionMode: REDIRECT

      # Порт, на котором будет запущена admin панель каждого sidecar контейнера (envoy)
      proxyAdminPort: 15000

      # адрес, по которому будут отправляться trace’ы по zipkin протоколу (в начале мы отключили саму отправку, поэтому это поле сейчас не будет использоваться)
      zipkinAddress: tracing-collector.tracing:9411

      # statsd адрес для отправки метрик envoy контейнеров (отключаем)
      # statsdUdpAddress: aggregator:8126

      # выключаем поддержку опции Mutual TLS
      controlPlaneAuthPolicy: NONE

      # адрес, на котором будет слушать istio-pilot для того, чтобы сообщать информацию о service discovery всем sidecar контейнерам
      discoveryAddress: istio-pilot.istio-system:15007

모든 주요 제어 구성 요소(제어 평면)는 Kubernetes의 네임스페이스 istio-system에 있습니다.

최소한 파일럿만 배포하면 됩니다. 이를 위해 우리는 그런 구성.

그리고 컨테이너의 주입 사이드카를 수동으로 구성합니다.

컨테이너 초기화:

initContainers:
 - name: istio-init
   args:
   - -p
   - "15001"
   - -u
   - "1337"
   - -m
   - REDIRECT
   - -i
   - '*'
   - -b
   - '*'
   - -d
   - ""
   image: istio/proxy_init:1.0.0
   imagePullPolicy: IfNotPresent
   resources:
     limits:
       memory: 128Mi
   securityContext:
     capabilities:
       add:
       - NET_ADMIN

그리고 사이드카:

       name: istio-proxy
       args:
         - "bash"
         - "-c"
         - |
           exec /usr/local/bin/pilot-agent proxy sidecar 
           --configPath 
           /etc/istio/proxy 
           --binaryPath 
           /usr/local/bin/envoy 
           --serviceCluster 
           service-name 
           --drainDuration 
           45s 
           --parentShutdownDuration 
           1m0s 
           --discoveryAddress 
           istio-pilot.istio-system:15007 
           --discoveryRefreshDelay 
           1s 
           --connectTimeout 
           10s 
           --proxyAdminPort 
           "15000" 
           --controlPlaneAuthPolicy 
           NONE
         env:
         - name: POD_NAME
           valueFrom:
             fieldRef:
               fieldPath: metadata.name
         - name: POD_NAMESPACE
           valueFrom:
             fieldRef:
               fieldPath: metadata.namespace
         - name: INSTANCE_IP
           valueFrom:
             fieldRef:
               fieldPath: status.podIP
         - name: ISTIO_META_POD_NAME
           valueFrom:
             fieldRef:
               fieldPath: metadata.name
         - name: ISTIO_META_INTERCEPTION_MODE
           value: REDIRECT
         image: istio/proxyv2:1.0.0
         imagePullPolicy: IfNotPresent
         resources:
           requests:
             cpu: 100m
             memory: 128Mi
           limits:
             memory: 2048Mi
         securityContext:
           privileged: false
           readOnlyRootFilesystem: true
           runAsUser: 1337
         volumeMounts:
         - mountPath: /etc/istio/proxy
           name: istio-envoy

모든 것을 성공적으로 시작하려면 ServiceAccount, ClusterRole, ClusterRoleBinding, CRD for Pilot을 생성해야 합니다. 이에 대한 설명은 찾을 수 있습니다. 여기에.

결과적으로 사이드카에 envoy를 삽입한 서비스가 성공적으로 시작되고 파일럿으로부터 모든 검색을 수신하고 요청을 처리해야 합니다.

모든 컨트롤 플레인 구성 요소는 상태 비저장 애플리케이션이며 문제 없이 수평으로 확장될 수 있음을 이해하는 것이 중요합니다. 모든 데이터는 Kubernetes 리소스의 사용자 지정 설명 형식으로 etcd에 저장됩니다.

또한 Istio(아직 실험적)에는 클러스터 외부에서 실행할 수 있는 기능과 여러 Kubernetes 클러스터 간에 서비스 검색을 감시하고 더듬는 기능이 있습니다. 이것에 대해 더 읽을 수 있습니다 여기에.

다중 클러스터 설치의 경우 다음 제한 사항에 유의하십시오.

1. 포드 CIDR 및 서비스 CIDR은 모든 클러스터에서 고유해야 하며 겹치지 않아야 합니다.
2. 모든 CIDR 포드는 클러스터 간의 모든 CIDR 포드에서 액세스할 수 있어야 합니다.
3. 모든 Kubernetes API 서버는 서로 액세스할 수 있어야 합니다.

Istio를 시작하는 데 도움이 되는 초기 정보입니다. 그러나 여전히 많은 함정이 있습니다. 예를 들어 외부 트래픽 라우팅(클러스터 외부) 기능, 사이드카 디버깅 접근 방식, 프로파일링, 믹서 설정 및 사용자 지정 믹서 백엔드 작성, 추적 메커니즘 설정 및 envoy를 사용한 작업.
이 모든 것은 다음 간행물에서 고려할 것입니다. 귀하의 질문에 답변해 드리겠습니다.

출처 : habr.com