ProHoster > Blog > Amministrazione > Cumu eseguisce Istio cù Kubernetes in a produzzione. Parte 1

Cumu eseguisce Istio cù Kubernetes in a produzzione. Parte 1

Ce Istio? Questu hè u chjamatu Service mesh, una tecnulugia chì aghjunghje una capa di astrazione nantu à a reta. Interceptemu tuttu o parte di u trafficu in u cluster è realizanu un certu settore di operazioni cun ellu. Chì? Per esempiu, facemu un routing intelligente, o implementemu l'approcciu di l'interruttore di circuitu, pudemu urganizà "implementazione canaria", cambiendu parzialmente u trafficu à una nova versione di u serviziu, o pudemu limità l'interazzione esterna è cuntrullà tutti i viaghji da u cluster à u rete esterna. Hè pussibule stabilisce e regule di pulitica per cuntrullà i viaghji trà i diversi microservizi. Infine, pudemu uttene tutta a mappa di l'interazzione di a rete è rende a cullizzioni unificata di metriche completamente trasparenti à l'applicazioni.

Pudete leghje nantu à u mecanismu di u travagliu in documentazione ufficiale. Istio hè un strumentu veramente putente chì vi permette di risolve parechje attività è prublemi. In questu articulu, mi piacerebbe risponde à e dumande principali chì sò generalmente sorgi quandu si principia cù Istio. Questu vi aiuterà à trattà più veloce.

Cumu eseguisce Istio cù Kubernetes in a produzzione. Parte 1

Come si travaglia

Istio hè custituitu di dui spazii principali - u pianu di cuntrollu è u pianu di dati. U pianu di cuntrollu cuntene i cumpunenti principali chì assicuranu u funziunamentu currettu di u restu. In a versione attuale (1.0) u pianu di cuntrollu hà trè cumpunenti principali: Pilot, Mixer, Citadel. Ùn avemu micca cunsideratu Citadella, hè necessariu di generà certificati per assicurà TLS mutuale trà i servizii. Fighjemu un ochju più vicinu à u dispusitivu è u scopu di Pilot and Mixer.

Cumu eseguisce Istio cù Kubernetes in a produzzione. Parte 1

Pilot hè u cumpunente di cuntrollu principale chì distribuisce tutte l'infurmazioni nantu à ciò chì avemu in u cluster - servizii, i so punti finali è e regule di routing (per esempiu, regule per l'implementazione di Canary o regule di circuit breaker).

Mixer hè un cumpunente opzionale di u pianu di cuntrollu chì furnisce a capacità di cullà metriche, logs, è qualsiasi infurmazione nantu à l'interazzione di a rete. Ellu monitoreghja ancu u rispettu di e regule di Politica è u rispettu di i limiti di tariffu.

U pianu di dati hè implementatu cù cuntenituri proxy sidecar. Potente hè utilizatu per difettu. mandatu mandatu. Pò esse rimpiazzatu da una altra implementazione, cum'è nginx (nginmesh).

In ordine per Istio per travaglià cumplettamente trasparenti à l'applicazioni, ci hè un sistema di iniezione automatica. L'ultima implementazione hè adattata per e versioni di Kubernetes 1.9+ (webhook di ammissione mutazionale). Per e versioni di Kubernetes 1.7, 1.8 hè pussibule aduprà l'Initializer.

I cuntenituri Sidecar sò cunnessi à Pilot cù u protokollu GRPC, chì vi permette di ottimisà u mudellu push per i cambiamenti in u cluster. GRPC hè stata utilizata in Envoy da a versione 1.6, in Istio hè stata utilizata da a versione 0.8 è hè un pilot-agent - un golang wrapper over envoy chì configura l'opzioni di lanciamentu.

Pilot è Mixer sò cumpunenti cumplettamente senza statu, tuttu u statu hè tenutu in memoria. A cunfigurazione per elli hè stabilita in forma di Kubernetes Custom Resources, chì sò guardati in etcd.
Istio-agent riceve l'indirizzu di u Pilot è apre un flussu GRPC.

Comu aghju dettu, Istio implementa tutte e funziunalità cumpletamente trasparenti à l'applicazioni. Videmu cumu. L'algoritmu hè questu:

  1. Implementazione di una nova versione di u serviziu.
  2. Sicondu l'approcciu di injecting container sidecar, u container istio-init è u container istio-agent (envoy) sò aghjuntu à u stadiu di applicà a cunfigurazione, o ponu esse inseriti manualmente in a descrizzione di l'entità Kubernetes Pod.
  3. U containeru istio-init hè un script chì applicà e regule iptables à u pod. Ci hè duie opzioni per cunfigurà u trafficu per esse impannillatu in un containeru istio-agent: utilizate e regule di redirect iptables, o TPROXY. À u mumentu di a scrittura, l'approcciu predeterminatu hè cù e regule di redirect. In istio-init, hè pussibule cunfigurà quale trafficu deve esse interceptatu è mandatu à istio-agent. Per esempiu, per interceptà tuttu u trafficu in entrata è in uscita, avete bisognu di stabilisce i paràmetri -i и -b in significatu *. Pudete specificà porti specifichi per intercepte. Per ùn intercepte una subnet specifica, pudete specificà cù a bandiera -x.
  4. Dopu chì i cuntenituri init sò eseguiti, i principali sò lanciati, cumpresu u pilotu-agente (inviatu). Cunnette à u Pilot digià implementatu via GRPC è riceve infurmazioni nantu à tutti i servizii esistenti è e pulitiche di routing in u cluster. Sicondu i dati ricevuti, cunfigurà i clusters è l'assigna direttamente à l'endpoints di e nostre applicazioni in u cluster Kubernetes. Hè ancu necessariu di nutà un puntu impurtante: l'envoy configura dinamicamente l'ascultori (IP, coppie di portu) chì principia à sente. Dunque, quandu e dumande entranu in u pod, sò rediretti cù e regule iptables di redirect in u sidecar, l'envoyu pò digià processà cun successu queste cunnessione è capisce induve proxy u trafficu. Ancu in questu stadiu, l'infurmazioni sò mandati à u Mixer, chì avemu da vede più tardi, è i tracce sò mandati.

In u risultatu, avemu una reta sana di servitori proxy mandatarii chì pudemu cunfigurà da un puntu (Pilot). Tutte e dumande in entrata è in uscita passanu per mandatu. Inoltre, solu u trafficu TCP hè interceptatu. Questu significa chì l'IP di u serviziu di Kubernetes hè risolta cù kube-dns sopra UDP senza cambià. Dopu, dopu à a risoluzione, a dumanda in uscita hè interceptata è trattata da l'envoy, chì hà digià decisu à quale endpoint a dumanda deve esse mandata (o micca mandata, in u casu di e pulitiche d'accessu o u circuit breaker di l'algoritmu).

Avemu capitu Pilot, avà avemu bisognu di capisce cumu funziona Mixer è perchè hè necessariu. Pudete leghje a documentazione ufficiale per questu ccà.

Mixer in a so forma attuale hè custituita da dui cumpunenti: istio-telemetry, istio-policy (prima di a versione 0.8 era un cumpunente istio-mixer). Tutti dui sò mixer, ognunu di li quali hè rispunsevuli di u so compitu. A telemetria Istio riceve infurmazione nantu à quale và induve è cù quali parametri da i containeri di rapportu sidecar via GRPC. Istio-policy accetta Verificate e dumande per verificà chì e regule di Politica sò soddisfatte. I cuntrolli di Poilicy sò, sicuru, micca realizati per ogni dumanda, ma sò cache nantu à u cliente (in u sidecar) per un certu tempu. I cuntrolli di rapportu sò mandati cum'è richieste di batch. Videmu cumu cunfigurà è quali paràmetri deve esse mandatu un pocu dopu.

U Mixer hè suppostu esse un cumpunente assai dispunibile chì assicura u travagliu ininterrottu nantu à l'assemblea è u processu di dati di telemetria. U sistema hè ottinutu cum'è un buffer multi-livellu. In principiu, i dati sò buffered in u sidecar sidecar di cuntenituri, dopu à u latu mixer, è poi mandatu à i cosi-chiamatu mixer backends. In u risultatu, se qualcunu di i cumpunenti di u sistema falla, u buffer cresce è hè lavatu dopu chì u sistema hè restauratu. I backend di Mixer sò endpoints per l'invio di dati di telemetria: statsd, newrelic, etc. Pudete scrive u vostru propiu backend, hè abbastanza simplice, è vedemu cumu fà.

Cumu eseguisce Istio cù Kubernetes in a produzzione. Parte 1

Per riassume, u schema per travaglià cù istio-telemetria hè a siguenti.

  1. U serviziu 1 manda una dumanda à u serviziu 2.
  2. Quandu abbanduneghja u serviziu 1, a dumanda hè impannillata in u so propiu sidecar.
  3. L'envoy Sidecar monitoreghja cumu a dumanda passa à u serviziu 2 è prepara l'infurmazioni necessarii.
  4. Allora u manda à istio-telemetria usendu una dumanda di rapportu.
  5. Istio-telemetria determina se stu Rapportu deve esse mandatu à i backends, à quale è quale dati deve esse mandatu.
  6. Istio-telemetria manda dati di rapportu à u backend se necessariu.

Avà vedemu cumu implementà Istio in u sistema, custituitu solu di i cumpunenti principali (pilot è sidecar mandatu).

Prima, fighjemu a cunfigurazione principale (maglia) chì Pilot leghje:

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

Tutti i cumpunenti principali di cuntrollu (pianu di cuntrollu) seranu situati in u namespace istio-system in Kubernetes.

À u minimu, avemu solu bisognu di implementà Pilot. Per questu avemu aduprà un tali cunfigurazione.

È cunfiguremu manualmente u sidecar injecting di u containeru.

Init container:

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

È sidecar:

       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

Per chì tuttu principia cù successu, avete bisognu di creà un ServiceAccount, ClusterRole, ClusterRoleBinding, CRD for Pilot, e descrizioni di quale si ponu truvà. ccà.

In u risultatu, u serviziu in quale avemu injected sidecar with envoy deve principià cù successu, riceve tutte e scuperte da u pilotu è processà e dumande.

Hè impurtante di capisce chì tutti i cumpunenti di u pianu di cuntrollu sò appiicazioni senza statu è ponu esse scalati horizontalmente senza prublemi. Tutte e dati sò almacenati in etcd in forma di descrizzioni persunalizati di risorse Kubernetes.

Inoltre, Istio (ancora sperimentale) hà a capacità di curriri fora di u cluster è a capacità di guardà è fumble scuperta di serviziu trà parechji clusters Kubernetes. Pudete leghje più nantu à questu ccà.

Per una installazione multi-cluster, sia cuscenti di e seguenti limitazioni:

  1. Pod CIDR è Service CIDR deve esse unichi in tutti i clusters è ùn deve micca sovrappone.
  2. Tutti i Pods CIDR devenu esse accessibili da qualsiasi Pod CIDR trà clusters.
  3. Tutti i servitori API Kubernetes devenu esse accessibili l'un à l'altru.

Questa hè l'infurmazione iniziale per aiutà à principià cù Istio. In ogni casu, ci sò ancu parechje trappule. Per esempiu, caratteristiche di routing u trafficu esternu (fora di u cluster), avvicinamenti à debugging sidecars, profiling, stallà un mixer è scrive un backend di mixer persunalizatu, stabilisce un mecanismu di traccia è u so funziunamentu cù l'envoy.
Tuttu chistu avemu da cunsiderà in e publicazioni seguenti. Fate e vostre dumande, pruvaraghju à copre.

Source: www.habr.com

Cumprate un hosting affidabile per i siti cù prutezzione DDoS, servitori VPS VDS 🔥 Cumprate un hosting di siti web affidabile cù prutezzione DDoS, servitori VPS VDS | ProHoster