Üretimde Kubernetes kullanarak Istio nasıl çalıştırılır. Bölüm 1

Ne Istio? Bu, ağ üzerinden bir soyutlama katmanı ekleyen bir teknoloji olan Hizmet ağı olarak adlandırılır. Kümedeki trafiğin tamamını veya bir kısmını yakalar ve onunla belirli bir dizi işlem gerçekleştiririz. Hangisi? Örneğin, akıllı yönlendirme yaparız veya devre kesici yaklaşımını uygularız, trafiği hizmetin yeni bir sürümüne kısmen değiştirerek "kanarya dağıtımını" organize edebilir veya dış etkileşimleri sınırlayabilir ve kümeden kümeye yapılan tüm gezileri kontrol edebiliriz. harici ağ. Farklı mikro hizmetler arasındaki gezileri kontrol etmek için ilke kuralları belirlemek mümkündür. Son olarak, tüm ağ etkileşimi haritasını alabilir ve birleştirilmiş ölçüm koleksiyonunu uygulamalar için tamamen şeffaf hale getirebiliriz.

Çalışma mekanizması hakkında okuyabilirsiniz. resmi belgeler. Istio, birçok görevi ve sorunu çözmenizi sağlayan gerçekten güçlü bir araçtır. Bu yazıda, genellikle Istio'ya başlarken ortaya çıkan ana soruları yanıtlamak istiyorum. Bu, onunla daha hızlı başa çıkmanıza yardımcı olacaktır.

Üretimde Kubernetes kullanarak Istio nasıl çalıştırılır. Bölüm 1

Çalışma prensibi

Istio iki ana alandan oluşur - kontrol düzlemi ve veri düzlemi. Kontrol düzlemi, geri kalanın doğru çalışmasını sağlayan ana bileşenleri içerir. Mevcut sürümde (1.0), kontrol düzleminin üç ana bileşeni vardır: Pilot, Karıştırıcı, Citadel. Citadel'i dikkate almayacağız, hizmetler arasında karşılıklı TLS sağlamak için sertifikaların oluşturulması gerekiyor. Pilot and Mixer'ın cihazına ve amacına daha yakından bakalım.

Üretimde Kubernetes kullanarak Istio nasıl çalıştırılır. Bölüm 1

Pilot, kümede sahip olduğumuz hizmetler, uç noktaları ve yönlendirme kuralları (örneğin, Canary konuşlandırma kuralları veya devre kesici kuralları) hakkındaki tüm bilgileri dağıtan ana kontrol bileşenidir.

Karıştırıcı, ölçümleri, günlükleri ve ağ etkileşimiyle ilgili her türlü bilgiyi toplama yeteneği sağlayan isteğe bağlı bir kontrol düzlemi bileşenidir. Ayrıca Politika kurallarına uyumu ve oran limitlerine uyumu denetler.

Veri düzlemi, yan araba proxy kapsayıcıları kullanılarak gerçekleştirilir. Güçlü, varsayılan olarak kullanılır. elçi vekili. Nginx (nginmesh) gibi başka bir uygulama ile değiştirilebilir.

Istio'nun uygulamalara tamamen şeffaf çalışabilmesi için otomatik enjeksiyon sistemi bulunmaktadır. En son uygulama, Kubernetes 1.9+ sürümleri (mutasyonel kabul web kancası) için uygundur. Kubernetes 1.7, 1.8 sürümleri için Başlatıcı kullanmak mümkündür.

Sidecar konteynerleri, kümede meydana gelen değişiklikler için itme modelini optimize etmenize izin veren GRPC protokolü kullanılarak Pilot'a bağlanır. GRPC, Envoy'da 1.6 sürümünden beri, Istio'da ise 0.8 sürümünden beri kullanılmaktadır ve bir pilot aracıdır - başlatma seçeneklerini yapılandıran bir golang sarmalayıcısı.

Pilot ve Mikser tamamen durum bilgisi olmayan bileşenlerdir, tüm durum bellekte tutulur. Bunlar için yapılandırma, etcd'de depolanan Kubernetes Özel Kaynakları biçiminde ayarlanır.
Istio-agent, Pilot'un adresini alır ve ona bir GRPC akışı açar.

Dediğim gibi Istio, tüm işlevleri uygulamalara tamamen şeffaf bir şekilde uygular. Nasıl olduğunu görelim. Algoritma şudur:

  1. Hizmetin yeni bir sürümünü dağıtma.
  2. Sepet kapsayıcı ekleme yaklaşımına bağlı olarak istio-init kapsayıcısı ve istio-agent kapsayıcısı (elçi), yapılandırma uygulama aşamasında eklenir veya Kubernetes Pod varlığının açıklamasına manuel olarak eklenebilir.
  3. istio-init kabı, iptables kurallarını bölmeye uygulayan bir betiktir. Bir istio-agent kapsayıcısına sarılacak trafiği yapılandırmak için iki seçenek vardır: iptables yönlendirme kurallarını kullanın veya TPROXY. Yazma sırasında, varsayılan yaklaşım yönlendirme kurallarıdır. istio-init'te, hangi trafiğin durdurulması ve istio-agent'a gönderilmesi gerektiğini yapılandırmak mümkündür. Örneğin, gelen ve giden tüm trafiği durdurmak için parametreleri ayarlamanız gerekir. -i и -b anlam içine *. Engellemek için belirli bağlantı noktalarını belirleyebilirsiniz. Belirli bir alt ağı engellememek için bayrağı kullanarak belirtebilirsiniz. -x.
  4. Başlatma kapları yürütüldükten sonra, pilot aracı (elçi) dahil olmak üzere ana kaplar başlatılır. Halihazırda dağıtılan Pilot'a GRPC aracılığıyla bağlanır ve kümedeki tüm mevcut hizmetler ve yönlendirme politikaları hakkında bilgi alır. Alınan verilere göre kümeleri yapılandırır ve doğrudan Kubernetes kümesindeki uygulamalarımızın uç noktalarına atar. Ayrıca önemli bir noktayı da belirtmek gerekir: envoy, dinlemeye başladığı dinleyicileri (IP, port çiftleri) dinamik olarak yapılandırır. Bu nedenle, istekler bölmeye girdiğinde, sepetteki yönlendirme iptables kuralları kullanılarak yeniden yönlendirildiğinde, elçi bu bağlantıları zaten başarılı bir şekilde işleyebilir ve trafiği daha fazla nerede proxy olarak kullanacağını anlayabilir. Ayrıca bu aşamada Mixer'a daha sonra bakacağımız bilgiler gönderilerek trace span'lar gönderilir.

Sonuç olarak, bir noktadan (Pilot) yapılandırabileceğimiz bütün bir elçi proxy sunucusu ağı elde ederiz. Tüm gelen ve giden istekler elçiden geçer. Ayrıca, yalnızca TCP trafiği yakalanır. Bu, Kubernetes hizmet IP'sinin değişmeden UDP üzerinden kube-dns kullanılarak çözüldüğü anlamına gelir. Ardından, çözümlemeden sonra giden istek, isteğin hangi uç noktaya gönderileceğine (veya erişim politikaları veya algoritmanın devre kesicisi durumunda gönderilmeyeceğine) zaten karar veren elçi tarafından durdurulur ve işlenir.

Pilot'u anladık, şimdi Mixer'ın nasıl çalıştığını ve neden gerekli olduğunu anlamamız gerekiyor. Bunun için resmi belgeleri okuyabilirsiniz burada.

Mevcut haliyle mikser iki bileşenden oluşur: istio-telemetri, istio-policy (0.8 sürümünden önce bir istio-mixer bileşeniydi). İkisi de mikserdir ve her biri kendi görevinden sorumludur. Istio telemetri, GRPC aracılığıyla sepet Rapor konteynerlerinden kimin nereye ve hangi parametrelerle gittiği hakkında bilgi alır. Istio-policy, İlke kurallarının karşılandığını doğrulamak için Kontrol isteklerini kabul eder. Politika kontrolleri elbette her istek için yapılmaz, ancak istemcide (sepette) belirli bir süre önbelleğe alınır. Rapor kontrolleri toplu istekler olarak gönderilir. Nasıl yapılandırılacağını ve hangi parametrelerin biraz sonra gönderilmesi gerektiğini görelim.

Karıştırıcının, telemetri verilerinin birleştirilmesi ve işlenmesi üzerinde kesintisiz çalışma sağlayan yüksek düzeyde kullanılabilir bir bileşen olması beklenir. Sonuç olarak sistem çok seviyeli bir tampon olarak elde edilir. Başlangıçta, veriler kapların sepet tarafında arabelleğe alınır, ardından mikser tarafında tutulur ve ardından mikser arka uçlarına gönderilir. Sonuç olarak, sistem bileşenlerinden herhangi biri arızalanırsa, arabellek büyür ve sistem geri yüklendikten sonra temizlenir. Karıştırıcı arka uçları, telemetri verilerini göndermek için uç noktalardır: statsd, newrelic, vb. Kendi arka uçunuzu yazabilirsiniz, bu oldukça basit ve nasıl yapacağımızı göreceğiz.

Üretimde Kubernetes kullanarak Istio nasıl çalıştırılır. Bölüm 1

Özetlemek gerekirse, istio-telemetri ile çalışma şeması aşağıdaki gibidir.

  1. Servis 1, servis 2'ye bir istek gönderir.
  2. Hizmet 1'den ayrılırken istek kendi sepetine sarılır.
  3. Sidecar elçisi, talebin 2. servise nasıl gittiğini takip eder ve gerekli bilgileri hazırlar.
  4. Ardından bunu bir Rapor isteği kullanarak istio-telemetriye gönderir.
  5. Istio-telemetri, bu Raporun arka uçlara gönderilip gönderilmeyeceğini, hangi verilerin ve hangi verilerin gönderileceğini belirler.
  6. Istio-telemetry, gerekirse Rapor verilerini arka uca gönderir.

Şimdi sadece ana bileşenlerden (Pilot ve sepet elçisi) oluşan sistemde Istio'nun nasıl konuşlandırılacağına bakalım.

Öncelikle Pilot'un okuduğu ana konfigürasyona (mesh) bakalım:

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

Tüm ana kontrol bileşenleri (kontrol düzlemi), Kubernetes'teki ad alanı istio-sisteminde yer alacaktır.

En azından, yalnızca Pilot'u konuşlandırmamız gerekiyor. Bunun için kullanıyoruz böyle bir yapılandırma.

Ve konteynerin enjeksiyon sepetini manuel olarak yapılandıracağız.

Başlangıç ​​kabı:

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

Ve sepet:

       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

Her şeyin başarılı bir şekilde başlaması için, açıklamaları bulunan bir ServiceAccount, ClusterRole, ClusterRoleBinding, CRD for Pilot oluşturmanız gerekir. burada.

Sonuç olarak, içine sidecar with envoy enjekte ettiğimiz hizmet başarılı bir şekilde başlamalı, tüm keşifleri pilottan almalı ve istekleri işleme almalıdır.

Tüm kontrol düzlemi bileşenlerinin durum bilgisiz uygulamalar olduğunu ve sorunsuz bir şekilde yatay olarak ölçeklendirilebileceğini anlamak önemlidir. Tüm veriler, Kubernetes kaynaklarının özel açıklamaları biçiminde etcd'de depolanır.

Ayrıca, Istio (hâlâ deneyseldir), kümenin dışında çalışma yeteneğine ve çeşitli Kubernetes kümeleri arasında hizmet keşfini izleme ve karıştırma yeteneğine sahiptir. Bu konuda daha fazlasını okuyabilirsiniz burada.

Çoklu küme yüklemesi için aşağıdaki sınırlamalara dikkat edin:

  1. Pod CIDR ve Service CIDR, tüm kümelerde benzersiz olmalı ve çakışmamalıdır.
  2. Kümeler arasındaki tüm CIDR Bölmelerinden tüm CIDR Bölmelerine erişilebilir olmalıdır.
  3. Tüm Kubernetes API sunucuları birbirleri tarafından erişilebilir olmalıdır.

Bu, Istio'yu kullanmaya başlamanıza yardımcı olacak ilk bilgilerdir. Ancak, hala birçok tuzak var. Örneğin, dış trafiği yönlendirme özellikleri (küme dışında), sepetlerde hata ayıklamaya yönelik yaklaşımlar, profil oluşturma, bir karıştırıcı kurma ve özel bir karıştırıcı arka uç yazma, bir izleme mekanizması kurma ve elçi kullanarak çalışması.
Bütün bunları aşağıdaki yayınlarda ele alacağız. Sorularınızı sorun, cevaplamaya çalışacağım.

Kaynak: habr.com

Yorum ekle