İstehsalda Kubernetes istifadə edərək Istio-nu necə işə salmaq olar. 1-ci hissə

Nədir İstio? Bu, şəbəkə üzərində abstraksiya qatını əlavə edən bir texnologiya olan Xidmət mesh adlanan texnologiyadır. Biz klasterdəki trafikin hamısını və ya bir hissəsini kəsirik və onunla müəyyən əməliyyatlar toplusunu həyata keçiririk. Hansı? Məsələn, biz ağıllı marşrutlaşdırma həyata keçiririk və ya elektrik açarı yanaşmasını tətbiq edirik, biz trafiki qismən xidmətin yeni versiyasına keçirərək “kanareyka yerləşdirmə” təşkil edə bilərik və ya xarici qarşılıqlı əlaqəni məhdudlaşdıra və klasterdən bütün səfərlərə nəzarət edə bilərik. xarici şəbəkə. Müxtəlif mikroservislər arasında səfərlərə nəzarət etmək üçün siyasət qaydaları təyin etmək mümkündür. Nəhayət, biz bütün şəbəkə qarşılıqlı əlaqə xəritəsini əldə edə və vahid ölçülər toplusunu tətbiqlər üçün tamamilə şəffaf edə bilərik.

İş mexanizmi haqqında oxuya bilərsiniz rəsmi sənədlər. Istio bir çox vəzifə və problemləri həll etməyə imkan verən həqiqətən güclü bir vasitədir. Bu yazıda Istio ilə işə başladıqda adətən yaranan əsas suallara cavab vermək istərdim. Bu, onunla daha sürətli məşğul olmağa kömək edəcək.

İstehsalda Kubernetes istifadə edərək Istio-nu necə işə salmaq olar. 1-ci hissə

Əməliyyat prinsipi

Istio iki əsas sahədən ibarətdir - idarəetmə müstəvisi və məlumat müstəvisi. İdarəetmə təyyarəsi qalanın düzgün işləməsini təmin edən əsas komponentləri ehtiva edir. Cari versiyada (1.0) idarəetmə təyyarəsi üç əsas komponentdən ibarətdir: Pilot, Mixer, Citadel. Biz Citadel-i nəzərdən keçirməyəcəyik, xidmətlər arasında qarşılıqlı TLS təmin etmək üçün sertifikatlar yaratmaq lazımdır. Pilot və Mixer-in cihazına və məqsədinə daha yaxından nəzər salaq.

İstehsalda Kubernetes istifadə edərək Istio-nu necə işə salmaq olar. 1-ci hissə

Pilot, klasterdə olanlar haqqında bütün məlumatları - xidmətlər, onların son nöqtələri və marşrutlaşdırma qaydaları (məsələn, Canary yerləşdirmə qaydaları və ya elektrik kəsici qaydaları) paylayan əsas idarəetmə komponentidir.

Mikser, ölçüləri, qeydləri və şəbəkə qarşılıqlı əlaqəsi haqqında istənilən məlumatı toplamaq imkanı verən isteğe bağlı idarəetmə təyyarəsi komponentidir. O, həmçinin Siyasət qaydalarına və tarif limitlərinə riayət olunmasına nəzarət edir.

Məlumat müstəvisi yan vaqon proxy konteynerlərindən istifadə etməklə həyata keçirilir. Güclü standart olaraq istifadə olunur. elçi vəkil. O, nginx (nginmesh) kimi başqa bir tətbiq ilə əvəz edilə bilər.

Istio-nun tətbiqlərə tamamilə şəffaf işləməsi üçün avtomatik inyeksiya sistemi mövcuddur. Ən son tətbiq Kubernetes 1.9+ versiyaları üçün uyğundur (mutasiya qəbulu webhook). Kubernetes 1.7, 1.8 versiyaları üçün Başlatıcıdan istifadə etmək mümkündür.

Sidecar konteynerləri GRPC protokolundan istifadə edərək Pilot-a qoşulur ki, bu da klasterdə baş verən dəyişikliklər üçün təkan modelini optimallaşdırmağa imkan verir. GRPC Envoy-da 1.6 versiyasından, Istio-da isə 0.8 versiyasından istifadə olunur və pilot agentdir - işə salma seçimlərini konfiqurasiya edən elçi üzərində qolanq sarğıdır.

Pilot və Mixer tamamilə vətəndaşlığı olmayan komponentlərdir, bütün vəziyyət yaddaşda saxlanılır. Onlar üçün konfiqurasiya etcd-də saxlanılan Kubernetes Xüsusi Resursları şəklində qurulmuşdur.
Istio-agent Pilotun ünvanını alır və ona GRPC axını açır.

Dediyim kimi, Istio bütün funksionallığı tətbiqlər üçün tamamilə şəffaf şəkildə həyata keçirir. Gəlin görək necə. Alqoritm belədir:

  1. Xidmətin yeni versiyasının yerləşdirilməsi.
  2. Yan vaqon konteynerinin inyeksiya yanaşmasından asılı olaraq, istio-init konteyneri və istio-agent konteyneri (elçi) konfiqurasiyanın tətbiqi mərhələsində əlavə edilir və ya onlar Kubernetes Pod obyektinin təsvirinə artıq əl ilə daxil edilə bilər.
  3. İstio-init konteyneri iptables qaydalarını poda tətbiq edən skriptdir. İstio-agent konteynerinə bükülmüş trafiki konfiqurasiya etmək üçün iki seçim var: iptables yönləndirmə qaydalarından istifadə edin və ya TPROXY. Yazı zamanı defolt yanaşma yönləndirmə qaydalarıdır. İstio-init-də hansı trafikin tutulacağını və istio-agentə göndərilməsini konfiqurasiya etmək mümkündür. Məsələn, bütün gələn və gedən bütün trafiki tutmaq üçün parametrləri təyin etməlisiniz -i и -b mənaya keçir *. Tutmaq üçün xüsusi portları təyin edə bilərsiniz. Müəyyən bir alt şəbəkəyə müdaxilə etməmək üçün onu bayraqdan istifadə edərək təyin edə bilərsiniz -x.
  4. Başlanğıc konteynerləri icra edildikdən sonra pilot-agent (elçi) daxil olmaqla əsas olanlar işə salınır. O, GRPC vasitəsilə artıq yerləşdirilmiş Pilota qoşulur və klasterdəki bütün mövcud xidmətlər və marşrutlaşdırma siyasətləri haqqında məlumat alır. Alınan məlumatlara görə, o, klasterləri konfiqurasiya edir və onları birbaşa Kubernetes klasterindəki tətbiqlərimizin son nöqtələrinə təyin edir. Vacib bir məqamı da qeyd etmək lazımdır: elçi dinləməyə başladığı dinləyiciləri (IP, port cütləri) dinamik şəkildə konfiqurasiya edir. Buna görə də, sorğular poda daxil olduqda, yan arabada yönləndirmə iptables qaydalarından istifadə edilərək yönləndirildikdə, elçi artıq bu əlaqələri uğurla emal edə bilər və trafikin daha sonra harada proksi ediləcəyini anlaya bilər. Həmçinin bu mərhələdə Mikserə daha sonra baxacağımız məlumatlar göndərilir və izləmə spanları göndərilir.

Nəticədə, bir nöqtədən konfiqurasiya edə biləcəyimiz bütöv bir envoy proxy server şəbəkəsi əldə edirik (Pilot). Bütün daxil olan və gedən sorğular elçidən keçir. Üstəlik, yalnız TCP trafiki ələ keçirilir. Bu o deməkdir ki, Kubernetes xidmət IP-si dəyişdirilmədən UDP üzərindən kube-dns istifadə edərək həll olunur. Daha sonra, həll edildikdən sonra, gedən sorğu elçi tərəfindən tutulur və işlənir, o, sorğunun hansı son nöqtəyə göndərilməsinə qərar verir (və ya giriş siyasətləri və ya alqoritmin açarı vəziyyətində göndərilməməlidir).

Pilotu anladıq, indi Mixerin necə işlədiyini və nə üçün lazım olduğunu başa düşməliyik. Bunun üçün rəsmi sənədləri oxuya bilərsiniz burada.

Mikser hazırkı formada iki komponentdən ibarətdir: istio-temetriya, istio-politika (0.8 versiyasından əvvəl bir istio-mikser komponenti idi). Onların hər ikisi mikserdir, hər biri öz vəzifəsinə cavabdehdir. Istio telemetriya GRPC vasitəsilə Report konteynerlərindən kimin hara və hansı parametrlərlə getdiyi barədə məlumat alır. Istio-policy Siyasət qaydalarının təmin olunduğunu yoxlamaq üçün Yoxlama sorğularını qəbul edir. Siyasət yoxlamaları, əlbəttə ki, hər sorğu üçün həyata keçirilmir, lakin müəyyən bir müddət ərzində müştərinin yaddaşında (digər arabada) saxlanılır. Hesabat çekləri toplu sorğular kimi göndərilir. Bir az sonra necə konfiqurasiya ediləcəyini və hansı parametrlərin göndəriləcəyini görək.

Mikser telemetriya məlumatlarının yığılması və işlənməsi üzrə fasiləsiz işi təmin edən yüksək əlçatan komponent olmalıdır. Sistem nəticədə çoxsəviyyəli bufer kimi əldə edilir. Əvvəlcə məlumatlar qabların yan tərəfində, sonra mikser tərəfində buferlənir və sonra mikserin arxa tərəflərinə göndərilir. Nəticədə, sistem komponentlərindən hər hansı biri uğursuz olarsa, sistem bərpa edildikdən sonra bufer böyüyür və yuyulur. Mikser arxa tərəfləri telemetriya məlumatlarını göndərmək üçün son nöqtələrdir: statsd, newrelic və s. Öz backendinizi yaza bilərsiniz, bu olduqca sadədir və biz bunu necə edəcəyimizi görəcəyik.

İstehsalda Kubernetes istifadə edərək Istio-nu necə işə salmaq olar. 1-ci hissə

Ümumiləşdirsək, istio-temetriya ilə işləmə sxemi aşağıdakı kimidir.

  1. 1-ci xidmət 2-ci xidmətə sorğu göndərir.
  2. 1-ci xidmətdən ayrılarkən sorğu öz yan arabasına bükülür.
  3. Sidecar elçisi sorğunun xidmət 2-yə necə getdiyinə nəzarət edir və lazımi məlumatları hazırlayır.
  4. Sonra Hesabat sorğusundan istifadə edərək onu istio-temetriyaya göndərir.
  5. İstio-telemetriya bu Hesabatın backendlərə göndərilib-göndərilməyəcəyini, hansı və hansı məlumatların göndərilməli olduğunu müəyyən edir.
  6. Istio-telemetry, lazım gələrsə, Hesabat məlumatlarını backend-ə göndərir.

İndi gəlin yalnız əsas komponentlərdən (Pilot və yan vaqon elçisi) ibarət sistemdə Istio-nun necə yerləşdiriləcəyini görək.

Əvvəlcə Pilotun oxuduğu əsas konfiqurasiyaya (mesh) baxaq:

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

Bütün əsas idarəetmə komponentləri (idarə müstəvisi) Kubernetes-də ad məkanı istio-sistemində yerləşəcək.

Ən azı biz yalnız Pilotu yerləşdirməliyik. Bunun üçün istifadə edəcəyik belə bir konfiqurasiya.

Və konteynerin enjeksiyon yan arabasını əl ilə konfiqurasiya edəcəyik.

Başlanğıc konteyneri:

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

Və yan araba:

       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

Hər şeyin uğurla başlaması üçün siz ServiceAccount, ClusterRole, ClusterRoleBinding, Pilot üçün CRD yaratmalısınız, onların təsviri tapıla bilər. burada.

Nəticə etibarı ilə, elçi ilə yan arabanı daxil etdiyimiz xidmət uğurla başlamalı, pilotdan bütün kəşfləri almalı və sorğuları icra etməlidir.

Bütün idarəetmə müstəvisi komponentlərinin vətəndaşlığı olmayan tətbiqlər olduğunu və problemsiz üfüqi şəkildə ölçülə bildiyini başa düşmək vacibdir. Bütün məlumatlar etcd-də Kubernetes resurslarının fərdi təsvirləri şəklində saxlanılır.

Həmçinin, Istio (hələ eksperimental) klasterdən kənarda işləmək və bir neçə Kubernetes klasterləri arasında xidmət kəşfini izləmək və qarışdırmaq qabiliyyətinə malikdir. Bu barədə ətraflı oxuya bilərsiniz burada.

Çox klasterli quraşdırma üçün aşağıdakı məhdudiyyətlərdən xəbərdar olun:

  1. Pod CIDR və Service CIDR bütün klasterlər arasında unikal olmalıdır və üst-üstə düşməməlidir.
  2. Bütün CIDR Podları klasterlər arasında istənilən CIDR Podlarından əlçatan olmalıdır.
  3. Bütün Kubernetes API serverləri bir-biri üçün əlçatan olmalıdır.

Bu, Istio ilə başlamağınıza kömək edəcək ilkin məlumatdır. Bununla belə, hələ də çoxlu tələlər var. Məsələn, xarici trafikin yönləndirilməsinin xüsusiyyətləri (klasterdən kənar), yan avtomobillərin sazlanmasına yanaşmalar, profilin yaradılması, mikserin qurulması və xüsusi mikserin arxa hissəsinin yazılması, izləmə mexanizminin qurulması və envoy istifadə edərək onun işləməsi.
Bütün bunları növbəti nəşrlərdə nəzərdən keçirəcəyik. Suallarınızı verin, mən onları əhatə etməyə çalışacağam.

Mənbə: www.habr.com

Добавить комментарий