ProHoster > Blog > Administrasi > Kumaha ngajalankeun Istio nganggo Kubernetes dina produksi. Bagian 1

Kumaha ngajalankeun Istio nganggo Kubernetes dina produksi. Bagian 1

naon Istio? Ieu anu disebut Service bolong, téknologi anu nambihan lapisan abstraksi dina jaringan. Urang intercept sakabéh atawa bagian tina lalulintas di kluster jeung ngalakukeun hiji set tangtu operasi kalawan eta. Anu mana? Contona, urang ngalakukeun routing pinter, atawa urang nerapkeun pendekatan circuit breaker, urang tiasa ngatur "deployment kanaria", sawaréh pindah lalulintas keur versi anyar tina jasa, atawa urang bisa ngawatesan interaksi éksternal tur kadalikeun sakabéh lalampahan ti klaster ka jaringan éksternal. Kasebut nyaéta dimungkinkeun pikeun nyetél aturan kawijakan pikeun ngadalikeun perjalanan antara microservices béda. Tungtungna, urang tiasa nampi sadaya peta interaksi jaringan sareng ngadamel koleksi métrik anu ngahijikeun lengkep transparan pikeun aplikasi.

Anjeun tiasa maca ngeunaan mékanisme gawé di dokuméntasi resmi. Istio mangrupikeun alat anu kuat anu ngamungkinkeun anjeun pikeun ngabéréskeun seueur tugas sareng masalah. Dina tulisan ieu, kuring hoyong ngajawab patarosan utama anu biasana timbul nalika ngamimitian nganggo Istio. Ieu bakal nulungan anjeun nungkulan eta leuwih gancang.

Kumaha ngajalankeun Istio nganggo Kubernetes dina produksi. Bagian 1

Kumaha karya

Istio diwangun ku dua wewengkon utama - pesawat kontrol jeung pesawat data. Pesawat kontrol ngandung komponén utama anu mastikeun operasi bener tina sésana. Dina versi ayeuna (1.0) pesawat kontrol boga tilu komponén utama: Pilot, Mixer, Citadel. Kami moal nganggap Citadel, éta diperyogikeun pikeun ngahasilkeun sertipikat pikeun mastikeun silih TLS antara jasa. Hayu urang tingali langkung caket kana alat sareng tujuan Pilot sareng Mixer.

Kumaha ngajalankeun Istio nganggo Kubernetes dina produksi. Bagian 1

Pilot mangrupakeun komponén kontrol utama anu ngadistribusikaeun sagala informasi ngeunaan naon urang kudu di klaster - jasa, titik tungtung maranéhanana jeung aturan routing (Contona, aturan pikeun deployment Kanaria atawa aturan circuit breaker).

Mixer mangrupikeun komponén pesawat kontrol pilihan anu nyayogikeun kamampuan pikeun ngumpulkeun métrik, log, sareng inpormasi naon waé ngeunaan interaksi jaringan. Anjeunna ogé ngawaskeun patuh kana aturan Kabijakan sareng patuh kana wates laju.

Pesawat data dilaksanakeun nganggo wadah proxy sidecar. Kuat dianggo sacara standar. utusan proxy. Éta tiasa diganti ku palaksanaan anu sanés, sapertos nginx (nginmesh).

Supados Istio tiasa dianggo lengkep transparan pikeun aplikasi, aya sistem suntikan otomatis. Palaksanaan panganyarna cocog pikeun Kubernetes 1.9+ versi (mutational admission webhook). Pikeun versi Kubernetes 1.7, 1.8 tiasa nganggo Initializer.

Wadah Sidecar disambungkeun ka Pilot ngagunakeun protokol GRPC, nu ngidinan Anjeun pikeun ngaoptimalkeun model push pikeun parobahan lumangsung dina klaster. GRPC parantos dianggo dina Utusan ti saprak vérsi 1.6, dina Istio parantos dianggo ti saprak vérsi 0.8 sareng mangrupikeun pilot-agén - bungkus golang dina utusan anu ngonpigurasikeun pilihan peluncuran.

Pilot sareng Mixer mangrupikeun komponén stateless, sadaya kaayaan disimpen dina mémori. Konfigurasi pikeun aranjeunna diatur dina bentuk Kubernetes Custom Resources, anu disimpen dina jsb.
Istio-agén meunang alamat Pilot sarta muka aliran GRPC ka dinya.

Salaku Cenah mah, Istio implements sadayana fungsionalitas lengkep transparan pikeun aplikasi. Hayu urang tingali kumaha. Algoritma nyaéta kieu:

  1. Deploying versi anyar tina jasa.
  2. Gumantung kana pendekatan injecting wadah sidecar, wadah istio-init jeung wadah istio-agén (utusan) ditambahkeun dina tahap nerapkeun konfigurasi, atawa maranéhna geus bisa sacara manual diselapkeun kana déskripsi entitas Kubernetes Pod.
  3. Wadah istio-init mangrupikeun naskah anu nerapkeun aturan iptables kana pod. Aya dua pilihan pikeun ngonpigurasikeun lalu lintas pikeun dibungkus dina wadah istio-agén: nganggo aturan alihan iptables, atanapi TPROXY. Dina waktos nyerat, pendekatan standar nyaéta kalayan aturan alihan. Dina istio-init, kasebut nyaéta dimungkinkeun pikeun ngonpigurasikeun lalulintas nu kudu disadap tur dikirim ka istio-agén. Contona, pikeun ngahalangan sadaya lalu lintas asup sareng kaluar, anjeun kedah nyetél parameter -i и -b kana harti *. Anjeun tiasa nangtukeun port husus pikeun intercept. Dina raraga teu intercept hiji subnet husus, Anjeun bisa nangtukeun eta ngagunakeun bandéra -x.
  4. Saatos wadah init dieksekusi, anu utama diluncurkeun, kalebet agén pilot (utusan). Ieu nyambungkeun ka Pilot geus deployed via GRPC sarta narima informasi ngeunaan sagala jasa aya na kawijakan routing dina kluster. Numutkeun data anu ditampi, anjeunna ngonpigurasikeun klaster sareng masihan aranjeunna langsung ka tungtung aplikasi kami dina klaster Kubernetes. Ogé kudu dicatet hiji titik penting: utusan dinamis ngonpigurasikeun listeners (IP, pasangan port) nu dimimitian ngadangukeun. Ku alatan éta, nalika requests asupkeun pod nu, dialihkeun ngagunakeun aturan iptables alihan dina sidecar nu, utusan geus bisa hasil ngolah sambungan ieu tur ngartos dimana salajengna proxy lalulintas. Ogé dina tahap ieu, informasi dikirim ka Mixer, nu urang bakal kasampak di engké, sarta tracing bentang dikirim.

Hasilna, urang meunang sakabeh jaringan server proxy utusan nu urang bisa ngonpigurasikeun ti hiji titik (Pilot). Kabéh requests inbound jeung outbound ngaliwatan utusan. Leuwih ti éta, ngan lalulintas TCP anu disadap. Ieu ngandung harti yén IP layanan Kubernetes direngsekeun ngagunakeun kube-dns leuwih UDP tanpa ngarobah. Teras, saatos ngabéréskeun, pamundut anu kaluar dicegat sareng diolah ku utusan, anu parantos mutuskeun titik tungtung mana anu kedah dikirimkeun (atanapi henteu dikirim, dina kasus kabijakan aksés atanapi pemutus sirkuit algoritma).

Urang terang Pilot, ayeuna urang kedah ngartos kumaha Mixer jalan sareng naha éta diperyogikeun. Anjeun tiasa maca dokuméntasi resmi pikeun éta di dieu.

Mixer dina formulir ayeuna diwangun ku dua komponén: istio-telemétri, istio-kawijakan (saméméh versi 0.8 éta salah sahiji komponén istio-mixer). Duanana mangrupakeun mixers, nu masing-masing tanggung jawab tugas sorangan. Istio telemetry nampi inpormasi ngeunaan saha anu mana sareng naon parameter tina wadah Laporan sidecar via GRPC. Istio-kawijakan narima Cék requests pikeun pariksa yen aturan Sarat jeung Kaayaan anu wareg. Cék Poilicy, tangtosna, henteu dilaksanakeun pikeun unggal pamundut, tapi disimpen dina klien (dina sidecar) pikeun waktos anu tangtu. cék laporan dikirim salaku requests bets. Hayu urang tingali kumaha ngonpigurasikeun sareng parameter naon anu kedah dikirim sakedik engké.

The Mixer sakuduna dituju janten komponén kacida sadia nu ensures karya uninterrupted on assembly sarta ngolah data telemetry. Sistim nu dicandak salaku hasil salaku panyangga multi-tingkat. Mimitina, data disanggakeun dina sisi sidecar wadah, teras di sisi mixer, teras dikirim ka anu disebut backends mixer. Hasilna, lamun salah sahiji komponén sistem gagal, panyangga tumuwuh sarta flushed sanggeus sistem dibalikeun. Backends mixer mangrupikeun titik akhir pikeun ngirim data telemétri: statsd, newrelic, jsb. Anjeun tiasa nyerat backend anjeun nyalira, éta saderhana, sareng kami bakal ningali kumaha ngalakukeunana.

Kumaha ngajalankeun Istio nganggo Kubernetes dina produksi. Bagian 1

Pikeun nyimpulkeun, skéma pikeun gawé bareng istio-telemétri nyaéta kieu.

  1. Service 1 ngirimkeun pamundut ka layanan 2.
  2. Nalika ninggalkeun jasa 1, pamundut dibungkus dina sidecar sorangan.
  3. Utusan Sidecar ngawaskeun kumaha pamenta ka jasa 2 sareng nyiapkeun inpormasi anu diperyogikeun.
  4. Teras kirimkeun ka istio-telemétri nganggo pamundut Laporan.
  5. Istio-telemétri nangtukeun naha Laporan ieu kudu dikirim ka backends, nu jeung naon data kudu dikirim.
  6. Istio-telemétri ngirimkeun data Laporan ka backend lamun diperlukeun.

Ayeuna hayu urang tingali kumaha nyebarkeun Istio dina sistem, ngan diwangun ku komponén utama (Pilot jeung sidecar utusan).

Mimiti, hayu urang tingali konfigurasi utama (bolong) anu dibaca Pilot:

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

Sakabéh komponén kontrol utama (pesawat kontrol) bakal lokasina di namespace istio-system di Kubernetes.

Sahenteuna, urang ngan ukur kedah nyebarkeun Pilot. Pikeun ieu kami bakal ngagunakeun konfigurasi sapertos.

Sareng urang sacara manual bakal ngonpigurasikeun sidecar injecting tina wadahna.

Wadah ieu:

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

Jeung 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

Supados sadayana tiasa ngamimitian suksés, anjeun kedah nyiptakeun ServiceAccount, ClusterRole, ClusterRoleBinding, CRD for Pilot, déskripsi anu tiasa dipendakan. di dieu.

Hasilna, palayanan dimana urang nyuntik sidecar sareng utusan kedah ngamimitian suksés, nampi sadaya panemuan ti pilot sareng pamundut prosés.

Kadé ngartos yen sakabeh komponen pesawat kontrol mangrupakeun aplikasi stateless sarta bisa diskalakeun horisontal tanpa masalah. Sadaya data disimpen dina jsb dina bentuk déskripsi khusus sumberdaya Kubernetes.

Ogé, Istio (masih ékspérimén) mibanda kamampuhan pikeun ngajalankeun luar klaster jeung kamampuhan pikeun lalajo jeung fumble kapanggihna jasa antara sababaraha klaster Kubernetes. Anjeun tiasa maca langkung seueur ngeunaan ieu di dieu.

Pikeun pamasangan multi-cluster, perhatikeun watesan ieu:

  1. Pod CIDR sareng Service CIDR kedah unik dina sadaya klaster sareng teu kedah tumpang tindih.
  2. Sadaya CIDR Pods kedah tiasa diaksés tina mana-mana CIDR Pods antara klaster.
  3. Sadaya pangladén API Kubernetes kedah tiasa diaksés ku anu sanés.

Ieu mangrupikeun inpormasi awal pikeun ngabantosan anjeun ngamimitian sareng Istio. Sanajan kitu, aya kénéh loba pitfalls. Contona, fitur routing lalulintas éksternal (di luar klaster), ngadeukeutan ka debugging sidecars, profil, nyetel mixer jeung nulis backend mixer custom, nyetél mékanisme tracing sarta operasi na maké utusan.
Sadaya ieu bakal urang bahas dina publikasi di handap ieu. Tanya patarosan anjeun, abdi bakal nyobian nutupan aranjeunna.

sumber: www.habr.com

Tambahkeun komentar